This blog has moved - go to http://www.maxxxie.net/

Some time ago, I read this article, which describes the results of one guy's fight against spam. The disconnection of McColo, a host which did nothing to stop spam going through its networks, effectively took out 75% of the world's spam problem. And I have to say that my own inbox seems to be much cleaner as a result.

Last year, I took a uni subject whose topic was IT security. Its focus was on the Linux operating system, but there was enough generic material that it got me interested in security not just at the network layer, but also at the application layer.

By examining Apache logs from one of my public-facing servers, I was able to detect attempts at Remote File Inclusion exploits. I downloaded a few of these RFIs, and they weren't anything too malicious in themselves - mostly fingerprinting apps. But I found two that were very interesting and downright sophisticated. One was a simple script that caused the exploited server to send email. In other words, spam. It was nice, but required some spammer to actually sit at the console and enter in addresses, then click "send". The second script was far more substantial. It caused the server to retrieve files from another server, install them and join an IRC botnet. This caused the server to be remotely operated by whoever was in charge of the IRC server. Examining the script revealed spam functions and also Distributed Denial of Service (DDoS) functions. I found myself in awe of the person who'd written this script. I also wanted to kill him.

On the topic of poorly-written web apps, I knew from researching osCommerce that a single poorly-written module could compromise an entire site. I actively researched vulnerabilities in osCommerce as a purely educational exercise. The Customer Testimonials SQL injection flaw was well publicised. I set up a dummy site with dummy information, on my local Apache server, and installed the vulnerable code, just to see just how bad it was. It was BAD.

One thing I found interesting was that the bulk of the vulnerability/security/bug reporting sites never really described the exploit in enough detail that a newbie like me could cut'n'paste it into a script. This was annoying, at best, as I could not easily check my development site to see the results of an exploit. I understand why they did it. They don't want noobs getting their hands on recipes on how to exploit vulnerable code. I GET IT! But what about not-so-noobs, who really do need to know how to probe for a vulnerability (eg to ensure that a patch has actually fixed the problem)? I guess that's an open-ended question. But in saying that....

... I did eventually figure out the appropriate code to inject into the Customer Testimonials addin. And I ran it against my dummy site, and wouldn't you know it, I exposed a whole bunch of fictitious credit card numbers. For fun and games, I used Google to find vulnerable sites. I didn't expect to find any. I was wrong. So very, very, very wrong. I managed to expose data on a number of vulnerable osC sites. It put a shiver up my spine. I disconnected my DSL modem at that point. I fully expected visits from the federal police. They never came. I'm sure they would've enjoyed my retelling of the journey of intellectual discovery that caused me to run exploits on public sites. You know, in the name of education.

There is a commonly-held belief that having SSL (Secure Sockets Layer) installed on a site makes the information stored on that site secure. The little padlock you see on your screen when you enter a secure session (https://.....) encrypts the data being passed between your computer and the web site in question only whilst it is being transmitted. Once that data (eg your credit card details) arrives at the web site, there is nothing - NOTHING - preventing that data from being stored in clear text, on a database that can be exploited. And if the web site in question contains exploitable code, it could be as easy as figuring out the right string to cut'n'paste into the right place. Visa (and other vendors) are enforcing a new standard called PCI. The idea here is that a web site that collects/stores information such as credit card details must be in compliance with the standards imposed by PCI, and that failure to do so may result in substantial fines for the vendor.

But there is absolutely nothing to force a vendor into PCI compliance - and some vendors only find out about it after their site has been compromised, and their customers' data exposed. Not only do they get their credit card merchant status revoked (and rightly so), they lose all their customers' business (would you do business with a site you knew had been compromised?), and they get hit with a huge bill from the credit card company.

The days of the average Joe Schmoe setting up a commerce web site to generate side-line revenue are long gone. Anyone thinking of joining the internet sales revolution needs to consider there's more to it than just buying from suppliers and selling to customers. Education and information is key here. Research your obligations. Meet them. Prevent exploitation before it happens. And if you're lucky, after all of that, you'll make a profit.