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.
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:
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:
<iframe src=”http://www.ehacking.net”></iframe>
The above statement shows how to display another website within a website.
Example 2:
<iframe src=’http://ehacking.net/’ 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).
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=’http://ehacking.net/’ 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.
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.
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:
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%273c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e%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:
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<Script Language='Javascript'> <!--document.write(unescape('3c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e')); //--> </Script> |
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:
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 | 3c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e |
The result is:
<iframe src=’http://infosecinstitute.com/’ width=’1′ height=’1′ style=’visibility: hidden;’></iframe>
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.
No comments:
Post a Comment