Archive for the ‘Solutions’ Category

« Older Entries
Newer Entries »

HP’s SWFScan does not find simple XSS in Flash Apps

Tuesday, April 21st, 2009

This will a short post on my review of the new HP’s solution for auditing Flash apps – SWFScan. It has a variety of features, some of which are highlighted on the HP’s Blog here.

Before that, I have used Stefano’s Tool, SWFIntruder. It is a nice tool to audit Actionscript 2 apps, but it only reports XSS issues and does not support Actionscript 3. This time, I was out of luck, since I needed to audit a Actionscript 3 App. Also, I could not decompile and study its source code since the free tool Flare does not work on Actionscript 3.

So, I decided to give HP’s tool a try. I had a lot of expectations from this tool, since HP already has a popular tool WebInspect which is known in the industry for its website and web services auditing capabilities. I ran this tool on my app and it decompiled beautifully the complete source code of the flash app. It has a useful search feature which can aid in manually studying source code for vulnerabilities. However, I wanted to see some of its automatic auditing capabilities. So, I ran the scan and found it to find some issues like crypto issues(sha0/sha1), stacktraces, etc. Apart from that, it didn’t report any serious issues like XSS, etc. It also does report a large number of false positives in checks that start with “Possible/Potentially – - – -”. But i am willing to ignore those as long as the tool can effectively find some important vulnerabilities.

I didn’t know my app had any XSS issues or not, so I decided to use the free test.swf which is provided as part of SWFIntruder.

To my surprise, HP’s SWFScan tool did not report any of the 5 XSS issues reported by SWFIntruder.

If you see the screenshots below, swfscan shows you the vulnerabilities it found and the decompiled source code. Using manual inspection, a penetration tester can easily locate XSS issues in parameters such as _root.obj and _root.sd which are directly written into html without any escaping/filtering. I hope this free SWFScan tool improves in the near future and does not miss auditing such simple vulnerabilities.

SWFScan

SWFIntruder

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , ,
Posted in Flash, Solutions, Tools, WebAppSec, XSS | No Comments »

Phishing with Non Scriptable User Input

Monday, March 2nd, 2009

This week I did pentest of a commercial application. I was frustated to find that most of the user supplied content was sanitized using html entities, before being sent to the browser. So, it was not possible to inject my scripted content to cause XSS.

Just when I was about to give up, I found the possibility of a phishing attack in one of the pages, specifically the error page in the application. The problem was user supplied content from the url paramater list was put directly into the error page, filtered only for XSS characters and the whitespace character. In a normal scenario, user is redirected to the error page, resulting in:


http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=jack

Using URL encoding and the ‘%09′ ASCII character (horizontal tab), I can phish a user to go evilsite.com. Evilsite.com will have the same inferface looks as the legitimate site and some users might unknowingly fall prey into typing their login credentials.


http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=%2e%54%68%69%73%09%73%69%74%65%09%69%73%09%63%75%72%72%65%6e%74%6c%79%09%64%6f%77%6e%09%66%6f%72%09%6d%61%69%6e%74%65%6e%61%6e%63%65%2e%09%50%6c%65%61%73%65%09%75%73%65%09%65%76%69%6c%73%69%74%65%2e%63%6f%6d

This class of phishing attack can apply to any page. It does not confine to error pages and is not blocked by filtering and encoding mechanisms. The only requirement is user’s language characters (including whitespace character like %09, %20, etc) should be injectable in the page output and the rendered page should sound convincing to phish a user into going to evil site. If the user is not convinced and types the domain name directly into the address bar, this attack will fail :( .

A solution to this issue is to use url encoding or html entities for all the special characters [not just XSS chars < > " '] before writing back user’s input data back to the browser. For links, using url encoding instead of html entities also protects from HTTP Parameter Pollution.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Phishing, Solutions, WebAppSec | 2 Comments »

Breaking the STEALTH myth of Desktop Locking Softwares

Thursday, February 5th, 2009

In this post, I will be talking about the security vulnerabilities in various desktop locking softwares such as Folder Guard, Lock Folder XP, etc. In fact, I will question their claims, one of which is given on their website as:

“You can even completely hide your private folders from virtually all applications, and such folders would remain invisible until you enter a valid password.”

Is this really true?? No, not at all. Let’s see how. Actually, my friend used one of these softwares and challenged me if I can expose his data without the password used to lock the data. So, I decided to give it a try.

I first downloaded and installed a trial copy of Folder Guard software on my computer. Then I created a folder named “mysecretfiles” inside directory “test” on G: drive. Then, I opened Folder Guard, created a login password and locked this folder. The configuration setting I used for this folder was Access = “No Access” and Visibility = “Hidden”. You should see a similar screenshot after you lock a folder.

I closed Folder Guard and clicked on “Yes” in the “Start Protecting the System” dialog box. This caused Folder Guard to enable protection on my folder. As a result, I didn’t see my locked folder in Windows Explorer.

I tried to understand how these softwares work. Almost all of them placed hooks into the windows device drivers and block access calls to locked files and folders. This model is flawed because an attacker can use the back channel, often referred to as Direct Disk Access Mode.

So, I decided to fire my favorite Disk Editor WinHex and I could easily see and browse my locked folder with ease. I could look inside my locked file “mysensitivedata.txt” and check its contents with my username, password and SSN :) . The other best part of this disk editor is that I don’t need to install it, I could just easily run it from a USB pen stick.

So, the best protection to protect your data is still to use industry standard encryption with algorithms such as AES, 3DES, etc. Even if the data falls in wrong hands, the confidentiality of the data won’t be compromised. Use softwares like TrueCrypt to protect your sensitive data.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , ,
Posted in Auth(entication/orization), Exploits, Information Gathering, Solutions, Tools | 3 Comments »

« Older Entries
Newer Entries »