Saiweb

Most of the time when I review our log watches each morning I become enraged at the number of automated attacks,

But ever so occasional I find one that frankly intrigues me.

Today is just such an occasion where I have had multiple Brute force login attempts, the ingenious part is this attack has been designed to bypass tools such as fail2ban, blockhosts etc, and this is how

1. Attack is launched from
2. has PTR set for
3. Failed login attempts record due to reverse lookup
4. There is no A record, attacker maintains their own nameservers for the
5. fail2ban notes failed logins, attempts to resolve to an IP but fails, due to missing A record
6. Attacker can continue brute force attempts unhindered by being banned

I am still reading into how to counter this and will update this post as I figure out how to work around it, it’s a very sneaky and frankly quiet clever method of working around most automated blacklisting/banning tools.

Update 1:
One method I am trialing is the “log target” feature of iptables, in an attempt to match login failure times to the iptables log, I’ll post back with results.

Outputs

Update 2: Defeating the hack

Now granted this would be a lot worse had the attacking IP been dynamic, fortunatly in this case it’s not

Ip’s have been masked to prevent anyone complaining or threatening legal action (again) for inferring you should block their ip / network range … and me firing off the obligatory “Well if you policed your own network I wouldn’t have to post this no would I” email,

Maybe I am just being Cynical in my “old” age …

Any how as you may have guess I’m black holing the ip with the 390 connection entries.

Thanks

Being as I spoke to a load of people during the course of this I realy can not remember who contributed what to this solution, so I’ll just have to thank you all let me know if you want a crediting link.

Tweet

Before you read any further note, I will not be including the original hack file, simply due to peoples stupidity in putting this on a production environment to play with, if you use the code you do so at your own risk, and by reading this blog entry / using the code provided you agree to accept all liability upon yourself for your own actions. Don’t be an idiot.

Around 10 days ago I came across this seemingly innocuous little file.

What I am going to cover in this entry is dissecting the ‘payload’ and not so much the web app in question or methods used to compromise it,

Whereas I will not at this time provide the original file, I will provide you with the md5 and sha1 hashes of the file so you can check it’s not lurking on your systems:

md5: 9ee3e6523d154114460d320477a8665a
sha1: 9c64fecea5620d70a716bbd74f6e89612a4a79c7

The bit we are interested in is the last line of the file:

Were you to run this line you would get

Confused yet? now I can appreciate the thinking behind packing a payload to avoid detection, but in this case the payload is packed 12 times, and no before you ask I did not manually run each returned statement to find this out.

Enter Python-Fu:

Copy the first payload lines into a file named payload.raw, take the above code and copy it into a file named dissect.py.

When dissect.py is run you will get the following output:

As such you may want to run it using the following command:

And what you will find after unpacking 12 times in total, the “payload” is the r57shell, this script is an information gathering tool and pseudo shell, meaning it will run any command on the host server that php can, providing in most cases ssh esq access to the exploited host, allowing you to do pretty much anything you wanted at this point, some of the features also include /etc/passwd /etc/shadow dumping, aswell as searching for a tirade of common file *.sql* admin* etc, it’s a one stop script for information gathering on a LAMP/WAMP based host.

Defense: modify php.ini to disable eval(), exec, shell_exec and all none essential functions.

And of course, ensure your web apps are patched and up to date as well as the host they are running on.

Tweet