3

EDIT : Sorry, my question clearly wasn't clear. I don't want to report attempted server attacks internally; we already have systems that log. record and report that activity.

What I was keen to do was to report the attacks to the perpetrator's ISP or somesuch.

Original question:

Our sites are immune to SQL Injection (AFAIK!), but of course we still get targeted regularly.

Is there some way I could automate reporting of attempted attacks - reverse DNS lookup etc.?

Although I guess its only worthwhile if, overall, it would be doing the community a favour.

Ditto I suppose for all the other attacks we see - probing for wide-open BBS, MySQL, PHPAdmin, etc.

Kristen
  • 187
  • 8

6 Answers6

4

Donate your logs to SANS! They have a client for most firewalls that will pull the logs and send them to the DShield database.

charlesbridge
  • 827
  • 5
  • 14
  • That looks useful, thanks. Not sure I can detect this at the firewall, but their format for client-submissions doens't look too onerous. – Kristen Oct 16 '09 at 12:03
3

Either everyone else understood something else or I did, but from what I can understand you are trying to report the people attempting SQL injections to their ISPs.

This will usually be a dead end, and you're better off just blocking the users attempting the attacks, as most machines performing attacks are not usually owned by the 'hacker', and instead they could be compromised machines, or someone abusing a website which offers free vulnerability scans or something similar.

gekkz
  • 4,229
  • 2
  • 20
  • 19
  • You did understand, thanks. I've clarified my question. On re-reading it it is clear to me that "Report" was ambiguous. – Kristen Oct 16 '09 at 11:56
1

Most ISPs have an abuse@ispname.com email address for reporting such things.. If you can revers lookup the ISP name from the IP I would send the info there.

Chris Nava
  • 1,147
  • 1
  • 7
  • 9
0

By SQL injection from sites, I take it: (a) you have some web forms, (b) there's a SQL back-end, (c) you use methods which prevent user input from being mis-interpreted as SQL (parameterized queries, etc.)

But still you would like to detect attempts at SQL injection. Ok.

One of the standard ways to attempt SQL injection is to probe around seeking an input field which is incorporated to a SQL query by using string insertion. For example:

snprintf(buf, dimensionof(buf), "SELECT calory_limit FROM user_diets WHERE user_firstname='%s' AND user_surname='%s'", firstname, surname);

Where surname and firstname are unfiltered inputs from a web form. In this example, a user could provide the name firstname=Johnny', surname='-';DROP DATABASE;--

The sprintf would result in:

SELECT calory_limit FROM user_diets WHERE user_firstname='Johnny'' AND user_surname=''-';DROP DATABASE;--'

Because '' (two single quotes) in SQL is interpreted as an escaped ' which is part of the string, we have "broken open" the string delimiter in the intended original statement. This lets us convert what later should have been string, surname, into commmand.

In short, look for people entering fields which:

  • End in a single quote mark
  • Begin with a single quote mark
  • Contain a "--" at or near the end (The purpose of wrapping the attack payloads up with a SQL comment delimiter is that without that, the attacker's distortion of the intended query could leave some unparsable command bits at the end. These could generate an error message to a log and alert you.)

Also, you might consider the same heuristics after, e.g., UTF-8 decoding the input. Or UTF-8 decoding it twice over. The penetration tester will be thinking about bugs that might be in your code, so they will try inputs which seem not to make sense -- such as twice-UTF-8-encoded single quote marks.

Also, look for " and other HTML entity sequences.

You can search arxiv.org and find some papers which detail certain specific attack flavors: cross-site scripting, SQL injection, URL modification. Reading some papers there will lead you to more.

Heath Hunnicutt
  • 109
  • 1
0

Playing devils advocate, it's almost always pointless to waste your time reporting these machines. Most attacks come from zombies machines that the user has no idea is even occurring. So even if you report them to their ISP and their ISP cuts their connection until they have their machine cleaned they will most likely just end up infected again later or even if they don't the fact you removed 1 zombie machine from the internet is a meaningless achievement.

The only time I would say it's worth reporting these attempts is if the machine is part of a hosted network like ThePlanet. Taking a compromised server off the internet is a big deal especially since the owner of the server might not even realize it's compromised. The other difference is the scale of attacks the server is capable of versus the home pc.

Chris Marisic
  • 1,424
  • 8
  • 33
  • 51
-2

afrinic.net, apnic.net, arin.net, jpnic.net, krnic.net, lacnic.net, ripe.net or twnic.net all have web-sites that you can perform a whois lookup. I normally start with the American (arin) NIC. You can also download a whois client. I use the GNU JWHOIS. It's OK. Additionally one can also get some information by using a PING -a -n 1 command. For example: 6.127.6.109.rev.sfr.net

Phil Huhn
  • 1