Application security

Iframe & the security risk

Web application security is always an important topic to discuss because websites seem to be the first target of malicious hackers. Hackers use websites to spread their malwares and worms, and they use the compromised websites for spamming and other purposes. OWASP has created an outline to secure a web application from the most dangerous vulnerabilities in web application, but it is always good to be actively learning about the new weaknesses and the new ways that an attacker might use to hack into a web application. Hackers are always trying to discover new ways to trick a user so from a penetration tester's point of view a website administrator should take care of each and every vulnerability and the weaknesses that an attacker may exploit to hack into a website. There are so many automatic tools and manual techniques available to test a website for the most common vulnerabilities, like SQL injection, cross site scripting, security misconfiguration and others, but we should take care about the variant of these vulnerabilities. SQL-injection is dangerous because an attacker may get access into a database and steal the information of the user and the administrator of the website, but what if an attacker simply hijacks the user or simply redirects your visitor to a malicious website. This can break the trust of the visitor on your website.

In this article, we will discuss the attack at HTML level or attack at HTML codes, iframe is the part of HTML or a technique used in HTML to embed some file (document, video and others) in the same HTML page. The simple way to explain iframe is that "iframe is the technique to display the information from another web page within the same (current) page". Security risk in iframe is an important topic to discuss because the usage of iframe is very common- even the most famous social networking websites are using iframe. The simple attribute to use iframe is as follows:

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

<iframe src="/globalassets/wysiwyg-images-folder/www.infosecinstitute.com"></iframe>

The above picture shows how to display another website within a website.

Example 2:

<iframe src='/globalassets/wysiwyg-images-folder/www.infosecinstitute.com/' width='500' height='600' style='visibility: hidden;'></iframe>

Width and height of an iframe has been defined, but since the frame visibility is hidden there is no physical presence of Infosec Institute's website. This technique is not used by the attacker because the frame occupies the area (width and height).

<iframe src='/globalassets/wysiwyg-images-folder/www.infosecinstitute.com/' width='1' height='1' style='visibility: hidden;'></iframe>

Now it is completely hidden from the user's eye, but the iframe is working as normal. Look at the picture below.

Here I put Infosec Institute's website URL, but an attacker can insert the URL of some malware and spamming website.

Obfuscated iFrame injection attacks

Obfuscated iframe injection attack is a dangerous and tricky attack because it is very difficult to detect and find the malicious injection code on a website. Obfuscated is the way to hide the meaning of the communication so that it is difficult to find the injected code. The aim of this attack is the same- to trick the user and then redirect to the third party web page to exploit the user. If a website has been compromised by using iframe injection attack, then it is easy to find and locate the injection code because the code is easy to read. However, in an obfuscated iframe injection attack, it is not easy to read the injected code.

Let's consider an example- A website has been compromised and it redirects or displays another web page within a page to sell some products. The visitor of this website trusts your website, and they usually purchase products so you need to make sure to clean the website from this tricky attack. A simple way is to review the index page for the possible iframe and redirect code. Let's suppose you have reviewed but have not found any URL of the third party website. Now, there is no URL of the third party website so what is the problem? Sometimes attackers use human weaknesses (social engineering technique) in a web application attack. Let's suppose there is a code like:

[sourcecode]

++++%23wp+/+GPL%0A%3CScript+Language%3D%27Javascript%27%3E%0A++++%3C%21--%0A++++document.write%28unescape%28%273c696672616d65207372633d27687474703a2f2f696e666

f736563696e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374

796c653d277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e%27%29%29%3B%0A

++++//--%3E%0A++++%3C/Script%3E

[/sourcecode]

It seems to be normal and an important code for this website; but in reality, it is the root cause of the problem. Let's decode it by using the java decoding function and the result is:

[sourcecode]

#wp / GPL

<Script Language='Javascript'>

<!--

document.write(unescape('3c696672616d65207372633d27687474703a2f2f696e666f73656369

6e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374796c653d

277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e'));

//-->

</Script>

[/sourcecode]

Again, it seems to be a legitimate piece of code because the attacker has created it very carefully and used the term "GPL" "wp" and "Java" so the code seems to be legitimate. In actuality, it is the root cause but how can this be confirmed. Everything is good with the code, but the numbers and letters seems to be HEX. In the next step, we need to decrypt it via hex decoder. Remember take only:

[sourcecode]

3c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272

077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a206869

6464656e3b273e3c2f696672616d653e

[/sourcecode]

The result is:

<iframe src='/globalassets/wysiwyg-images-folder/www.infosecinstitute.com/' width='1' height='1' style='visibility: hidden;'></iframe>

Now, you can imagine why it is difficult to fight against the obfuscated iframe injection attack.

How to clean Iframe injected code

Accidents may happen at any time with anyone, so if your website has been hacked by the hackers and they have injected their malicious code in iframe, stay calm and take some serious action to protect the identity and the confidential information of your visitor. Wordpress websites seems to be the most active target of iframe injection attack. The common practice used by hackers is to redirect the user to some malware website or they simply exploit the browser cross domain vulnerability to take control on the victim. So, in this section, I will discuss how to take immediate and relevant action against iframe injection attack.

• Shut down your website, and display the regular maintenance message. It is always good to shut it down immediately otherwise the malware can spread in your visitor computer.
• Create a backup of your website (core files, database and all other folders). Even though it is an infected website, backup is necessary because if something wrong were to happen during the cleaning process you could recover your website at the same condition. If some previous backup is available, then that is wonderful.
• Make sure your computer is clean from the malware and viruses; if you have any doubt on your computer, then clean it first. It is a necessary step because the malware has an ability to record the FTP credentials.
• Passwords - Change all of the passwords associated with your website (FTP password, SSH password, Admin password, Cpanl or other hosting panel password, database password and so on).
• If a clean backup of your website is available, then kindly scan it once by using an Anti-virus software to make sure that it is clean. After that, upload it on your web server, and check the functionality and everything. If there is still some problem, then you need to manually check the files to identify the injected code.
• If there is no clean backup available, then manually locate the injected code and remove it. I have discussed both (simple iframe injection and hidden iframe injection) possible cases of iframe injection attack, so follow the previous procedure to analyze the code for the possible injection. (It is recommended to make a backup of each change.)
• Make sure that the website no longer contains the injected code. Now, it is recommended to find the possible ways and the root cause of the problem. You need to find out how the hacker has injected the code for future prevention. The most common and possible ways that an attacker may use are:
  • Outdated CMS (content management system) software (make sure to update all the software and plugins to the newest version)
  • Vulnerability at the server software (the web host company is responsible to keep update the server software's)
  • FTP and other credentials have been compromised, SFTP is recommended over FTP.
  • Vulnerability at the application level (in web application code).
• Your computer must have an Anti-virus and anti-malware software. Do not forget to scan your computer before going to the FTP of your website. It is not recommended to save the password of FTP and SSH.

iframe & phishing

Phishing attack vector in iframe is important to discuss because some famous social networking websites, like Facebook, allow users and developers to integrate the third party web page to their fan pages and other applications by using iframe. So the iframe is dangerous because an attacker might use it for phishing purposes. The proven concept of iframe phishing attack has been discussed by f-secure lab. In the analyses, they have successfully demonstrated the phishing and other scamming by using iframe.

[sourcecode]

<html>

<head>

<title>Infosec Institute iFrame by Irfan</title>

</head>

<iframe src="/author/irfan/" width="1450" height="300" frameborder="0"></iframe>

<iframe src="http://phishing.com/wp-login" width="1450" height="250" frameborder="0"></iframe>

</body>

</html>

[/sourcecode]

Now you can see how easy is to trap the user into a phishing website, an attacker might exploit the cross site scripting (XSS) vulnerability on a web application to inject the phishing code as an iframe.

The other dangerous variant of iframe attack is that an attacker might redirect the user to a web page that automatically downloads some malicious file (the malicious file might be hidden behind a general file). An attacker could also exploit the vulnerability of software- for example, having the user download a malicious PDF file and then run into an old and vulnerable version of adobe reader. This scenario would allow an attacker to own the remote computer.

Conclusion

Hackers are always using some new way to trick users, so it is your job to keep updated with the dangerous and common security threats that can exploit your website. Iframe is a dangerous attack because it breaks the trust that a user has in your website. It is always good to build a relationship and establish trust with your users, and making sure that your website is clean will allow users to easily trust your website.