Secure Web

Security? Who cares...

Over the weekend I was running some errands and made a purchase with my credit card. The cashier did her normal glance at the back of the card before proceeding on with the transaction. Now rather than signing the back of my credit card, I instead write "See Driver's License"; the hope is that the cashier will verify against my driver's license that I am really me instead of an imperfect signature comparison. Unfortunately only 25% of the cashiers ever ask to see my license. I'll even watch them flip the card over, read what I wrote, and then continue on as if there's no problem.

This got me thinking about security in general and web application security in particular. The cashier is part of a group of people who are on the front line of security and more than half of them don't care enough to enforce the policies. If we can't get the front line whose job it is to care to actually care, then what are the chances of getting someone who is more indirectly involved to care? Most developers are more worried about the functionality of what is being built than the security. Sure, they care but only so much as it's easy to integrate. If it involves heavy lifting, then it's easier to focus only on the feature set and ignore security.

At least until something blows up and security becomes the feature set.

- Mike Kazmierczak, Cenzic, Inc.

SQL Injection Cheat Sheet

Ferruh Mavituna released a new version of their SQL Injection Cheat Sheet, currently version 1.4. This is a great resource for anyone doing appliation penetration testing, but it also assumes some advanced SQL knowledge on the part of the reader in order to understand the usefulness of some of the examples.

You can view the 1.4 version of the cheat sheet here. Where MySQL is concerned, another helpful resource is the MySQL 5.0 Reference Manual.

Enjoy!

-tom

Swimming with Sharks No. 1: Flagstar

In this installment of Swimming with Sharks we will look at a recent phishing site targeting users of Flagstar Bank. I chose this site not entirely at random, but because it also exhibited the technique of IP address obfuscation using Hexidecimal.

    

The address 0xdc.0x74.0x4e.0x85 is the hexidecimal representation of: 220.116.78.143. The Phisher encoded the address this way to trick ordinary users who might not know a hex representation of an IP address and therefore overlook its significance. A reverse DNS lookup reveals that this address is assigned to APNIC, the Asia Pacific Network Information Center, and that the IP address is allocated to Kornet, a korean ISP who obtained the IP from KRNIC the National Internet Registry of Korea. Kornet has a reputation of being a haven for hackers and spammers. Finally, 220.116.78.143 is in use by onnuriwold.net, the presbyterian church of South korea.

The Phishing site is rather simple, having been mirrored from the target. On inspection some of the mirrored links are broken and the Versign authenticity seal present in the original website is not being displayed correctly, nor did the Phishers attempt to spoof it in any way. Filling out the form shown above redirects you to another form where the user is asked to input their social security number and other banking information:

 

Two unique characteristics of this form at that it involves fetching external images. The Small Lock, partially obscured in the screenshot, points to an image on mycatswebsite.com and the submit button is an image from etimebanker.bankofthewest.com:

A cursory examination of the server revealed that it was running a old version of Zeroboard, and was most likely penetrated via the remote code inclusion vulnerability: CVE-2005-0380. While many apsects of the Phishing site were rushed, incomplete, and amateurish I am still puzzled by the off site link to mycatswebsite.com.

-Tom 

Swimming with Sharks: Introduction

Have you ever wanted to know just how phishers perform their scams, get a peek into their inner workings? I decided to start this series due to the number of people I have run into who were interested in learning how and why that Phishing was so successful and the types of strategies and technologies that Phishers use.

In each installment of this series we will look at a different Phishing site and analyze it in detail. Like Marcus Aurellius we will ask: "what is the thing-in-itself; what is its proper constitution;". We will start by determining where the site is located, who owns the domain, who is running the server on which the phishing site is installed. Then we will examine the technical aspects of the site: its structure, composition, and function. We will try and discover how the site originated, that is, how it got installed on the server where we found it. In many cases it won't be clear, but if enough evidence is turned up I will offer a theory.

A word of caution. Do not attempt to casually explore Phishing websites in your browser. It's not difficult for a hostile website to install Malware on any visitors system.  A Phishing site is in its very nature a malicious construct and should be treated with the same care with which you handle toxic waste. Even if you are fully patched there are vectors of attack that arise from both reported but unpatched security vulnerabilities as well as operating system vulnerabilities that can be exploited via the browser.

When studying Phishing sites I use the following configuration:

Vmware Server:  running Windows 2003 with the latest security patches. I surf the phishing sites using IE 7 for maximum compatibility, i.e. I want to see the sites as the victim see them.

Paros Proxy: An open-source Man-in-the-Middle Proxy

Ethereal: A Protocol Sniffer/Analyzer Program

If you want to open a Phishing email for purposes of reporting the site, I recommend you use Lynx, a text-based web browser. You can download a lynx installer for Win32 from here. For general web browsing, I recommend running Firefox with NoScript.

Finally, there are number of anti-phishing clearing houses where you can report phishing when you get an email. There is the Anti-Phishing Working Group as well as Phishtank. The first installment of Swimming with Sharks will be coming out on Friday April 6.

-Tom

Protecting Yourself From XSS

While an organization can run security assessments against their own web applications on a regular basis and fix any discovered Cross-Site Scripting (XSS) vulnerabilities, there are still many web sites out there that aren't fixing their own XSS problems. Or worse yet, don't even know what XSS is or how it can affect them. But there is a way for individuals to protect themselves.

One of the ways that a XSS vulnerability gets exploited is via phishing, faking a company's web site in order to gain information. This is most commonly done with a pop-up window faking another web site. In this case the pop-up window hides the location bar, thereby trying to emulate the original web site. Normally, there might be a legitimate reason for hiding the location such as better using the window space available but it might also be to hide that the web page is being served up from a non-expected location. Fortunately Firefox provides an easy method of uncovering this type of problem.

• From within Firefox, type about:config in the URL box
• Filter down to dom.disable_window_open_feature.location
• Toggle the value to true

This will modify all your pop-up windows to always display the URL box. It's then a simple matter to verify that the site you are visiting is really sticking to the expected URL.

- Mike Kazmierczak, Cenzic, Inc.