Building a Honeypot To Observe Shellshock Attacks In the Real World 41
Nerval's Lobster writes A look at some of the Shellshock-related reports from the past week makes it seem as if attackers are flooding networks with cyberattacks targeting the vulnerability in Bash that was disclosed last week. While the attackers haven't wholesale adopted the flaw, there have been quite a few attacks—but the reality is that attackers are treating the flaw as just one of many methods available in their tool kits. One way to get a front-row seat of what the attacks look like is to set up a honeypot. Luckily, threat intelligence firm ThreatStream released ShockPot, a version of its honeypot software with a specific flag, "is_shellshock," that captures attempts to trigger the Bash vulnerability. Setting up ShockPot on a Linux server from cloud host Linode.com is a snap. Since attackers are systematically scanning all available addresses in the IPv4 space, it's just a matter of time before someone finds a particular ShockPot machine. And that was definitely the case, as a honeypot set up by a Dice (yes, yes, we know) tech writer captured a total of seven Shellshock attack attempts out of 123 total attacks. On one hand, that's a lot for a machine no one knows anything about; on the other, it indicates that attackers haven't wholesale dumped other methods in favor of going after this particular bug. PHP was the most common attack method observed on this honeypot, with various attempts to trigger vulnerabilities in popular PHP applications and to execute malicious PHP scripts.
Article was low in details (Score:5, Informative)
Well that was a waste of time to read (yeah yeah, I know...). Essence is: a vulnerable server is created, and watching logfiles of people connecting, it can be seen that people first recon the honeypot, to see if it's exploitable, and then try to exploit the shellshock vulnerability.
Well d'oh. Was the author surprised by this? How is this different to /any/ other vulnerability? First recon, then exploit. The article sounds like it was written by somebody who's never heard of "computer security" and is trying to wrap his head around basic concepts.
Re: (Score:1)
Or just trying to dumb it down for a "general" audience.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
The article sounds like it was written by somebody who's never heard of "computer security" and is trying to wrap his head around basic concepts.
And also someone who is presumably not running any web-servers - otherwise they'd only need to check their own web logs. I've got hosting with Bytemark [bytemark.co.uk] and DigitalOcean [digitalocean.com] and both have had a hand full shellshock attempts amongst all the usual PHP/WordPress/MySQLAdmin/whatever attempts.
The only very moderately interesting thing I've noticed is that Shellshock attempts seem to only by IP address and not by host (I'm hosting multiple websites per VM), so presumably most shellshock-bots are just sweeping IP ran
order of magnitude hilarty, 7 out of 123 (Score:1)
my domains that have been around for 15 years get hundreds of attacks a day, over a dozen bash vulnerability probe attackers per day in the last week.
Worthless article using invalid wording (Score:2, Interesting)
What "popular" php apps are passing variables unsanitized to the shell?
They are the vectors that need to be described. What software is vulnerable.
To date I've not read a single thing that clarifies this.
FUD
Wordpress? (Score:3)
They seem to have problems with every other vulnerability, why would they want to leave this one out?
Yes, that is *snark* directed against Wordpress and their history of poor security. No, I do not know if there are any actual Wordpress exploits.
Re: (Score:1)
Yeah, don't bash php
lulz
CloudFlare did a similar analysis (Score:5, Informative)
See https://blog.cloudflare.com/inside-shellshock/ [cloudflare.com].
Not the remote exploit many are looking for (Score:4, Interesting)
I recently had one IP address in China make over 10,000 attempts to log in as root via ssh in one morning. By comparison on the same day I saw only 109 failed attempts to load various php configuration pages.
Re: (Score:1)
Re: (Score:1)
A simple iptable rule would throttle the rate at which you accept ssh connection would solve this problem.
That is one of many options.
Why are you allowing them to hammer your server and fill your logs with crap?
I find it amusing to see how hard some people will work to try to compromise my inconsequential system. I set my messages log to turn over at a very high file size now so I can see the activities more readily through only one file. Even with people attacking at this frequency they pose no real danger to my system, either by way of filling my "logs with crap" or by actually trying to get it (as a prohibited user name).
Re: (Score:3)
I find it amusing to see how hard some people will work to try to compromise my inconsequential system.
Lol, same here. The only thing of value on my file server is the stuff I'm sharing publically anyways. When I look through my logs at all the fancy attack vectors I think to myself they'd be better off pointing a web browser at index.html, it would sure save them a lot of trouble.
Re: (Score:2)
Re: (Score:2)
Well, no, not really. They're mostly after the server resources in the first place, to be (ab)used as spambots or DDoS drones. That is something 'pointing a web browser at index.html' will not help them with, so they try other tactics.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
He's got the failed password values in cleartext in his
Pardon the sarcasm (Score:3)
I replied directly as sarcasm, and perhaps should have added this as an addendum to the same post. I used to do the same at home where I had no concerns if a hacker was actually successful. I never gave free access like you, I was still running both tcpwrappers and an application called Netwatch (similar to fail2ban). I did log everything, and spent a good deal of time probing the people attempting to hack my stuff, tracking their traffic, etc... Partially this was a bit of morbid curiosity, partially l
Re: (Score:1)
An office environment is quite different, different actions, different tolerances, and different expectations.
Agreed. Systems at work I keep locked down and secured much differently. At home only one system is accessible to the outside world at all, and only on two ports.
Re: (Score:1)
I find it amusing to see how hard some people will work to try to compromise my inconsequential system.
These are automated attack that scan whole ip range.
i am well aware that there is nothing special about my system being targeted. I don't pretend that my system harbors great secrets of immense value to the Chinese. Indeed they would probably use my system to try to compromise other open systems.
Just use a rate limiting firewall like everyone else, the only down side is that you may not be able to brag about large numbers
Has it occurred to you that maybe I find this interesting? Sure there are solutions to it, and many of them. I know I can solve this problem if I want but I actually rather enjoy watching it take place. it's rather like watching an animal repeatedly try for a
Duh (Score:2, Redundant)
You can't advertise massive numbers if you throttle or run something like fail2ban!
Re: (Score:2)
Why do you allow anybody to connect to a port they have to business using?!?!?!?!
My servers limit connections on port 22 to the IP-range of my ISP and my static IP from work.
Zero unauthorized login attempts over SSH for the past years.
Re: (Score:2)
Fuck Slashdot.
Why would you allow anybody to connect on a port they have no business using?!?!?!?!
My servers limit connections on port 22 to the IP-range of my ISP and my static IP from work.
Zero unauthorized login attempts over SSH for the past years.
Re: (Score:1)
Geeze, you must love sifting through millions of lines of crap in your logs.
Here, let me help you:
$ wget http://www.snafu.priv.at/mystuff/pam_recent.c
$ gcc -shared -fPIC -Xlinker -x -o pam_recent.so pam_recent.c -lpam
Read the instructions on the .c file, its pretty clear cut.
Then download and install xtables_addons and enable the TARPIT module. Load it, tweak your init scripts to modprobe it automatically on boot.
Then, add the following to your /etc/sysconfig/iptables or equivalent, where appropriate:
-A INP
Shared hosting (Score:3)
...Since attackers are systematically scanning all available addresses in the IPv4 space...
If your site is on a server that does shared (or virtual) hosting, then IP address scans will usualy not trigger shellshock from your site because your site needs to be accessed via its URL. Accesses via IP address will usually go to a main site on that server, and that main site may not have any exploitable content.
... On one hand, that's a lot for a machine no one knows anything about; on the other, it indicates that attackers haven't wholesale dumped other methods in favor of going after this particular bug....
This is a straw man. Of course the bad guys are not going to walk away from all the other exploits in their toolbox. No one said they would.
Most of the shellshock accesses I see are just scans, i.e., the bad guys are building an inventory of what hosts are vulnerable. I haven't seen too many (i.e., only a very few) attempts to take over the host.... yet.
Just grep for () in your /var/log/apache2/referer. (Score:2)
fgrep '()'
Names (Score:2)
I went to VirusPalooza!!! The headliners were ShellSHOCK and Heartbleed. They were great. Also saw a bunch of others: Viruses from yesteryear like Wabbit and Creeper System, awesome viruses from the '80s CyberAIDS, Festering Hate Apple ProDOS, and Ghostball, modern stars like Stuxnet and CryptoLocker, and who could forget Y2K?!?