Is your web site hacker safe? Obviously by hacker I don’t mean people who ride horses in the country or work as cab drivers. No, according to Wikipedia the term hacker as used in the popular press is to describe those who subvert computer security without authorization or indeed, anyone who has been accused of using technology (usually a computer or the Internet) for terrorism, vandalism, credit card fraud, identity theft, intellectual property theft, and many other forms of crime. This can mean taking control of a remote computer through a network, or software cracking. This is the pejorative sense of hacker, also called cracker or black-hat hacker or simply criminal’ in order to preserve unambiguity..
My image of a hacker is a technical expert with specialist knowledge and techniques that can be used in order to try to detect flaws in a computer system or software. These experts (with a white or black hat) go to underground conventions. The terminology that they use includes terms such as:
firewall code injection attack, where a trojan is settled in an already opened browser, which is already check summed by the firewall.
shatter attacks which try to break into the Win 32 messaging system
trojan print servers in order to gain administrative right of any windows machine
The basic tools for these hackers are Netcat, Etereal an Nmap. All this sound very fascinating but what has it got do with me?
For me it gets more interesting with SQL injection attacks. This down to earth technique is very effective and rather dangerous. This is a hacking method which enables one to access a database server via the input of a web application. If the web application doesn’t do any field validations one can extract, modify, add, or delete content from the database. Hackers tend to send invalid SQL queries. If the DBA doesn’t switch them off the attacker gets additional info served on a plate via the error messages. He can then try more things out until he gets a valid SQL. Another method is the so called blind SQL injection attack exploring the WHERE clause. The standard example is the online shop with the detailed info on an article which could result in an URL like www.someexampleshop.com/show_article?ID=123
The SQL behind this is something like
select * from articles where ID=123
A hacker would add sub queries to the URL in order to get e.g. the usernames and/or passwords, credit card info, etc from tables. It sounds all rather simplistic, but the threat is there, certainly when the hackers are using automated tools like Squeal and Absinthe. Gone are the days when hackers spent days or even weeks trying to guess database and fields names with tedious trial and error methods. These brute force tools will do the dirty work for them.
Is this preventable? Maybe not for 100%, but there are some rules of thumb. The most important one is to leave the SQL out of the application and let the DB server do all the SQL stuff (via e.g. stored procedures). Furthermore you can filter out values that are not required, work with less obvious URLs and try to encode a much as possible.
If you find all of this far fetched, what do you think about the following? According to Johnny Long, the most dangerous people are the webmasters themselves and their negligence. They don’t know/care about the consequences when they put data on their web server or open up directories. One might think that one needs to be a genius to find these documents, but there is one tool that will help people find them: Google. That’s why Johnny Long likes to call these webmasters ‘googledorks’ (gOO gÃ´l’DÃ´rk, noun, slang) : An inept or foolish person as revealed by Google.
Guess what happens if you type this in the Google search bar:
ext:pwd inurl:(service | authors | administrators | users) “# -FrontPage-“
and it’s not always windows that is to blame:
filetype:cfg ks intext:rootpw -sample -test howto
Even SAP ITS is mentioned:
intitle:”ITS System Information” “Please log on to the SAP System”
There are now 1034 entries in the Google Hackers Database, but I leave it open to discussion whether they are all valuable for possible hackers. You can use this database too for checking your site for any vulnerability. One doesn’t need to type them all though. Tools like Gooscan, Athena, SiteDigger and Wikto can be a help. Some serious warnings though. First of all, examine only your site. Secondly, some of these tools violate the Google Terms of Service , prohibiting any automated querying. Some tools therefore require a Google API key . I tried the latter tools myself in order to test my site. They are rather slow and they break frequently. Some of them resume, some don’t. They certainly didn’t convince me. In other words, use at own risk.
As you know, I have a weak spot for A Simulation of Semaphores (thanks for voting btw). As far as I know, there are/were two preventing’ google hacks. The first one was supposed to be Goopot. I say supposed, since apart from being mentioned in a couple of articles, I haven’t seen anything about it. The official launch was due at the end of last year though. One that is effectively live is a project called GHH . The Google Hack Honeypot project was conceived by Greg Smith and Ryan McGeehan, both students at the DePaul University. It is designed to provide reconnaissance against attackers that use search engines as a hacking tool against your resources. It uses the above mentioned GHDB as a source of information.
Although it’s still a young project (version 1 was released in February this year), I can’t resist voicing the following observations:
- each vulnerability requires it’s own honeypot, so if you want to detect several GHDB signatures, you have to install multiple honeypots
- currently only 7 honeypots are available. That’s barely 0.007 % of the total GHDB. So if you need one, you’re forced to write your own. The community doesn’t seem to be interested in this project, or is it?
- only php pots are currently supported
- it logs the activity in a local CVS file, a log viewer/analyzer is not (yet) available
- unlike the spam honeypot, you’re on your own as regards to taking action if you find an attack. There is no central instance which does this for you. The question is whether there is an individual, or even company, with enough resources to analyse the logs and take further action (eventually in court)?
- why should you place a honeypot anyway? The goal is not to let Google index vulnerabilities on your site. When you place this honeypot you get the opposite effect don’t you? Or is that too simplistic a view? The spam honey pot project uses fake addresses and reroutes all the harmful stuff to the central server in order to spare your server.
There are some simple things one can do in order to prevent people from hacking into your site:
- always change the defaults. This means all defaults – from passwords to directories to
- only things in directories that people are allowed to see, anything else shouldn’t be there at all
- Enable HotLink protection, which prevents other (unpriviliged) websites from directly linking to files
- disable directory indexing
You need to rely on the software/hardware manufacturers for the other stuff. Unless you write/make everything yourself in which case you need to be confident that it’ll be better – you can’t change a lot. Be sure to update things regularly though, especially security related issues.
In response to Craig’s comments, I’d like to share some links to useful information. Making your applications and infrastructure secure isn’t something new and SAP has done some serious thinking about this with vary valuable solutions as a result. So I don’t have to reinvent the wheel and think about my own solutions.
All the info can be found at the security section of the Service Marketplace. This section features things like:
- NW 04 security and network security guides
- DB and OS platform security guides
- EP security guides
- BW security guides
Additionally, I have the following links in my bookmarks:
- SAP FAQ on security
- Adding Security to your J2EE Applications
- SAP Netweaver Security on SDN
- Secure Business with SAP
- SAP Security Partners