How to Exploit an Iframe Vulnerability & Security

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:

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

Example 2:

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).

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

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:

1 2 3 4

++++%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

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:

1 2 3 4 5 6 7 8

#wp / GPL

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:

1 2 3

3c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272 077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a206869 6464656e3b273e3c2f696672616d653e

The result is:

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

Note: If you want to learn more about Linux and Windows based Penetration testing, you might want to subscribe our RSS feed and Email Subscription  or become our Facebook fan! You will get all the latest updates at both the places.