xmlrpc.php - webmaster strategies for battling botnets
 

Has anyone come up with any interesting ideas and strategies for battling the people who attempt to exploit xmlrpc.php or other vulnerable software. Im looking specifically at things that would annoy the people doing the scans, but without actually being considered a retaliatory hack.

Im looking at anything that can cause problems to the bot software on the serverside. Things like linking xmlrpc.php to an image bomb, or lagging out the client.

At present im logging them and sending emails to the organisations that own the ip ranges, with varied success.

Also i dont actually use much php, and what i do use i write myself, and it is usually really simple stuff like dishing up env variables for ip discovery scripts.

The server is locked down pretty tightly, and all permissions are set as they should be, SELinux is run on enforcing, and the machine updates itself daily via yum. Rkhunter and chkrootkit run daily and generate reports that are emailed to me as well. So its not really the security side that im wanting to know about. The only services with wan connection are the web server and ftp over ssl with a strict no non-ssl connections policy. Everything else is locked down and shutdown.

So thanks to anyone who replies with any interesting ideas or strategies, i look forward to them.

It's not *about* botnets...
 

Here's my take on the matter. I haven't read any good articles on this but it is not hard to imagine that botnets can be humonguous in size. If the payload is sought after and the size reaches critical mass, in their most evolved form, become entities with economical value. They are assets of an organisation that invests in them for business. Like in RL, an organisation that uses botnets to generate revenue is a hierarchical one (and most likely compartmentalised). At the bottom of which you can find (freelance) groups which only task it is to come up with their (payed for) quotum of hosts to repair or expand a botnet or to create a new one. This means you'll not be hurting the people you would like to hurt the most ("management"), the people you are trying to hurt ("coolies") won't care and on this scale it'll be asymmetrical warfare in the bad sense of the word unless you target the right things.


On the lowest level this would mean cleaning up after coolies, sanitising hosts, undoing their work. Theoretically this should cause major annoyance since you target them where it hurts the most: by taking away their investment. Practically speaking it's a Sysiphus task. You can not accomplish this because we're talking about millions of hosts. This means necessity for cooperation between you, organisations like CERT's, judicial systems across continents and ISP's.

On the highest level you need to look at why botnets evolved in the first place and it's not because of a lack of security. Lack of security is just a vehicle, an opportunity. I have to emphasise the next has should not be interpreted as me having idealistic or political notions of sorts, it's just an aggregation of facts. The way RL economy works, industries (are forced to) spend large amounts of money on marketing to create and maintain marketshare. And since almost all business are too dumb to translate their plans into a business strategy adapted to online economics, botnets, like almost all online advertising, are the 1:1 equivalent of "brick 'n mortar" marketing tactics. And just like with RL you'll see that for some forms of marketing need to be upped in scale to justify the cost, think Direct Marketing and such. So, theoretically speaking, taking away the idea (mass) advertising is a useful, valuable instrument should see both economies rid of botnets and UCE. Practically speaking this too is a Sysiphus task since it would mean detoxing everybody who is conditioned to buy into whatever advertising offers. (I could do a piece on that but that would go too far here, shame really. Go read Fravia.)


So, what's left, then? Well, we're still left with the fact that economical entities (have to) operate inside certain structures. For botnet owners this means they need middlemen ("account managers") to chase for deals. Since the businesses that execute these kind of deals tend to operate on the cheap, deals will to go to the lowest bidder. This means some for of centralised auctioning has to take place. Theoretically speaking infiltrating that part of the chain is the most effective IMHO since you can creatively play with the same strategies you would use in other situations. Remember you're not dealing with higly evolved beings here: it's simply about gain. Like the Nigeria scams people who value money above anything else are willing to jump through hoops to get it...


//me wonders what Chort thinks of this... ;-p

Thanks unSpawn,

It made an interesting read, and i guess no matter what i do at my level, their isnt much that can be done. For the minute i have added links to a dummy xmlrpc.php, that logs the ip and whois information to a date stamped file. So at least i can just go through the attempts with a bit more ease, and decide which ones are worth sending abuse reports about.

Your idea on penetrating the infrastructure and stringing them along the Nigerians is an interesting one. With the right amount of intelligence on the main players, and a bit of strategy, im sure it would be possible to get them to play off each other. Crippling the infrastructure though is likely to be more troublesome, as it would require some sort distributed attack by many governments, judicial systems, ISP's and users. Its not something i see going away in the long term. But identification of the individuals, gathering of intel, and then the passing on of that intel to the agencies within the country the buyer and seller reside will eventually lead to them being removed from the playing field.

Things which will be of most interest i suspect are the financial dealings, and any information on where the money trail flows. if this could be hampered it would certainly put a dent in business.

So thanks again, your posts are as ever, well though out and interesting to read through. But its to be expected of the LQ security god. ;)

Thanks for your time and opinion, and hopefully have a good day.

M

I can't help but think that unSpawn meant Fravia+, rather than Flavia, or perhaps I am missing out on something that I should know about...

As to botnets, I haven't spent a lot of time thinking about them because they're fundamentally such an impossible phenomenon to brake (that's not a typo).

For the time being, I have decided to do the digital equivilant of closing my eyes, covering my ears, and humming a happy tune. I wrote a tight firewall that discards most packets without even logging, and I deployed my websites entirely with static HTML and the bare minimum of Apache modules, on OpenBSD for maximum security. All my machines for personal use are OS X. My network won't get infected.

My recommendation for anyone else would be to either use static HTML for your sites, or become a PHP security disciple. If you use PHP (or any language for generating dynamic content) without researching how to secure it, it's only a matter of time before you will be compromised.

Does that address the botnet problem? No, it just ignores it and hopes that you won't be targeted by a botnet. My attitude hopes against hope that secure web apps coding practices will virally spread at a high enough rate that it doesn't get totally out-paced by the increase of exploitable hosts, but that's really a lost cause.

We can think all the way through the various levels of these schemes and try to come up with ways to combat them at each level, but ultimately I don't think that any solution will succeed in putting a significant dent in their operations. The only Ultimate way to address these problems is to develop and universally deploy Ultimate authentication. That way everyeone could definitively verify the identity of any person or organization. Once that is in place, you can have real reputation systems to track the trustworthiness of individuals or corporations. Reputation services are useless without authentication, and authentication is useless without reputation. The two go hand-in-hand. [edit: In a way, Phil Z. got this right with PGP a long time ago, but the problem is that it's so cumbersom to use "correctly" that a statistically significant amount of people will never adopt it.]

The problem is, once we have authentication and reputation services that are highly trusted, it becomes almost impossible to prove that you have been scammed. Right now, although it's a hassle, most identity-theft victims can get their identities reinstated and most of their credit problems corrected. Imagine if we had a system that most people believed was unbeatable... If your identity is stolen in such a system (and it's bound to happen, no security is perfect) how could you ever hope to prove that you didn't perform the actions that an attacker performed with your identity? The harder it becomes to exploit people (and thus make a little money off of lots of people), the easier it becomes to score big off a few people. So while we can succeed in limiting the sheer number of people that botnets and other malicious theft technologies affect, we will be making it much easier to take a few people for all they are worth.

Which is worse?

One thing is for sure: Crime will never be "solved". Trying to protect people from themselves is nobel, but somewhat futile. I've taken the approach of protecting myself well (at least digitally, I should do a lot more on the real-life identity front) and trying to minimize the possibility that I will be taken advantage of. Everyone else is left to fend for themselves and rely on the judicial system, but I don't put much trust in that.

How does this all relate to botnets? At the root of it all, botnets play on vulnerabilities in human trust. Trust in technology that doesn't deserve to be trusted, trust in the financial system, trust in the legal system... We really shouldn't trust so much, but than again if we didn't the world would be a very bleak and disconnected place. That's just a fundamental problem of organized society.

PS Yes this is mostly philosophical and not technical. That's because I don't believe there is a technical solution right now.

i guess no matter what i do at my level, their isnt much that can be done. For the minute i have added links to a dummy xmlrpc.php, that logs the ip and whois information to a date stamped file. So at least i can just go through the attempts with a bit more ease, and decide which ones are worth sending abuse reports about.
Like you and Chort already indicated making sure everything that *can* practically be denied, configuring PHP more strictly (does anybody actually *use* Hardened-PHP I wonder?), not using any|flawed PHP-based apps and regularly auditing are the best measures you can take to shield yourself. Since coolies will move on pretty quickly I don't think you are granted much time to keep them busy (look into tarpitting?).


Things which will be of most interest i suspect are the financial dealings, and any information on where the money trail flows. if this could be hampered it would certainly put a dent in business.
Well, like I said it's basically finding out what hurts the most. Maybe you can't track 'em down, but OTOH it's a game people *can* play (though not without hazard me thinks) as long as they're creative.


its to be expected of the LQ security god.
I'm not. I'm so bad, it's a crime.


unSpawn meant Fravia+, rather than Flavia
Thanks. I'll correct my post. Apparently it's been some time I visited the Castle.


The only Ultimate way to address these problems is to develop and universally deploy Ultimate authentication.
DNS was RFC'ed with security extensions, nobody uses them. Richmod came up with a "passport", works only for some sites. Another community tried to create one, still works for some sites. Not perfectly fitting examples but if you scale it up then I think *any* global auth initiative is doomed to die a horrible death.

People didn't buy into Passport because it came out at the gloomiest point in Microsoft's track record for security; no one trusted them. The nail in the coffin was when someone discovered you could chanage the password for any Passport user quite easily. They've fixed it now, but it doesn't matter. Microsoft had one chance to prove they could get consumer privacy/security right and they blew it.

Liberty Alliance just seems like your typical death-by-commitee. Too much discussion and nothing ever gets done.

Global auth is doomed to failure, just look at ISAKMP. What a waste of time that was. If IPSec had been designed from the out-set to just simply be the best encrypted IP protocol and not tried to be ultimately flexible, SSL VPNs would never have been invented and most of our traffic today would probably be encrypted. Thanks to people with too-grand of a vision, IPSec is mostly a failure (which all relates back to the choice of ISAKMP for authentication). Does anyone use ISAKMP for anything other than IPSec? Not that I'm aware of...

Authentication will have to be built into each protocol at the application layer. Trying to design "One Authentication System to rule them all, One Authentication System to find them, One Authentication System to bring them all, and in the darkness bind them" is not going to work. Trying to solve too big of a problem at one time makes your solution hoplessly complex, and complexity breeds both insecurity, and confusion. Confusion leads to low adoption rates and even more security problems (from misconfigurations, etc).

Having multiple authentication systems won't be that big of a burden to Reputation. You can more or less aggregate the Reputation on top of various different Authentication Systems--it's kind of like a meta-directory. Creating that meta-directory should not be a problem at all, in fact it could probably use DNS just as DNSBlackLists do today (just use multiple resource locators for record, to indicate it's reputation with various authenticated services).

Hi,

My box is locked down as tight as possible without interfering with what i need to use it for. I dont use php that often, its more of an easier way of logging environment variable for me than perl, so i use it for that, and on occasion ive been known to use the same to work out if a proxy is working properly. Beyond that i do most my stuff in js and html.

If i ever need to do anything more advanced, i will look at all the ways to do so and choose something secure.

I've come a long way since i first posted on here (about getting hacked :( ), nowadays i admit to being slightly paranoid about my servers, and checking logs on a daily basis, and doing my best to keep everything updated and locked down.

I'm hoping in my lifetime to affect the way things move in our industry, hopefully towards a more secure future. If that doesnt work, i'll just unplug everything and go live in a jungle, and be oblivious to it all :p.

The key to the problem at hand is education. We need to get the message out to people about how serious it is if your computer has been exploited. How the legalities could affect you. But i suspect the problem will only really start to go away with the current youngest generation who seem to be more computer literate and understand the problems a little better than people who were brought up without computers.

This discussion has been very useful to me, and has produced a fair amount of reading for me, but i'll fit it in. :)

Thanks unSpawn and chort.

v00

This makes a good example (not to pick on you): Even tiny tidbits of code can be exploited in big ways. In fact, it's often that one forgotten test script off in a corner somewhere in a directory that's not even linked that will 0wn your entire site. If even one page allows for remote file inclusions, you're hosed. No matter how simple or small your dynamic web code is, if it reads input, or allows for file inclusions, it can potentially be exploited unless you specifically hardened it against those attacks.

This is why I say it's better to use static HTML, unless you're a web programming security guru. I've been in security for years, but the riskiest thing I've done with my website is to turn on server side includes (for static HTML only), and even that scares me. I don't have the time to learn how to secure JSP, PHP, Ruby, etc so I just simply don't use them (and leave all those extra DSO modules disabled).

Just to emphasize: A single, tiny script can compromise your entire box. Think very, very hard before enabling any scripting languages.

I took your recommendation as a good one, chort.

PHP is now disabled on my server. I dont have time to learn how to do it securely, to much networking and java to deal with for the minute, not that i have much need for php either.

:)

Regarding botnet I think the best counter attack is to honeypot them so we get the auth credential to join the IRC channels. Depending on what commands are available we can cause significant disruption on the botnet as a whole. Especially if there is an uninstall command. This is just an idea, as I have never actually did this.

I agree that there is no 100% security, but with just static HTML your feature set is quite limited, besides not being applicable to actual real world environments. If they don't come thought the SQL injection they will come through somewhere else. The thing is to try and build a in-depth defense with multiple layers. And monitor the logs, so that when one layer is broken you get some warning that someone is trying to get in. This will allow you to fix the problem before your whole system is owned.

If a tiny script will basically break the whole security of your system it is not properly secure. With a tiny script they can for example have control over the database. Now if your database is properly setup they can only destroy the database of the client who setup the vulnerable script, so their own fault. However if the authentication table is the same as your ssh, then you got a problem if you are not chrooting your users. So now even with local access they need to go through the chroot jail, which you can make more difficult to overcome with a grsecurity patch.
Now they go through the chroot and got root. This is always a problem, however if you are running the server in a Xen environment or have an image install, you can quickly kick them from the system. Now going through all this will generate lots of logs that should eventually trigger your suspicion that something is wrong.

For what i require Krugger, static html is more than adequate. I dont have websites that require sql interaction, nor do i have websites that really need php. I just make simple sites, that suit whatever purpose im building them for.

I already have a couple of layers of security. My webserver runs as a user without shell access. I have selinux set to enforcing with a custom set of rules that denies pretty much everything. I dont have sshd started, nor any other service i dont need. I dont use apache for hosting either. My ftp has force_ssl rules in place, that allow neither anonymous or non-encrypted logins. I have 32+ character alpha-numeric passwords on all accounts. The computer is updated twice daily with yum.

That alone is a start i hope.

Once you get owned, it tends to make you very paranoid about security. It did with me, and i have taken many precautions ever since. All violation attempts are reported to the isp/company that owns the ip, which may not really hurt the botnet as such, but its one less machine in some cases that can be used for evil purposes. I like to keep chipping away at things, because eventually they will break.

I'm currently looking into the possibility of using vmware to host the webserver on a virtual machine, so i can ghost it easily, and just set it to restore the old image over the current one, say twice a day, making it pointless to attempt to hack.

Also the possibility of getting auth credentials to an irc channel or two would be nice. Gaining control of the botnet would be nicer. First thing i'd do is get every bot to email the fbi (or other law enforcement agency) saying it was a bot, along with whatever information it currently had stored. ;)

I agree on honeypotting. once you get the login, you have two options.
1.report the ip's and logins to CERT or other authorities
2.toast the IRC server
Disabling php and removing the file to a honeypot seems to be best, although moving to an outside server would assure things, because you could disable ssh connections and remove all files.
also, try portscanning the ips with nmap.

I agree on honeypotting. once you get the login, you have two options.
1.report the ip's and logins to CERT or other authorities
2.toast the IRC server
Not to thwart your efforts, but IMHO the part you can play in their operations is a rather small one (think classes, not single IP's), so honeypotting or tarpitting has only a wee chance of catching something and no chance of making a dent in the performance of what they do. Getting a remote IP doesn't mean much either since only daft people would scan w/o intermediaries, so what you probably see is just another slave or otherwise compromised (expendable) box. Retalliation is not only a waste of time, it is also the best way to attract attention. Remember this is a form of asymmetrical "warfare" so if you go for "old stylee" taunting they would have no problem paying back in tenfold or more. The risk and severity of that kind of consequences makes retalliation not a "standard operating procedure" thing and I don't want to see it advertised as such.

That's the point. If you don't need to have scripting functionality, why keep it? You could "properly secure" the system by spending days learning how to harden your script language and database, or you could just simply disable scripting and use static HTML, since you didn't really need scripting in the first place. Having something not enabled at all is far more security than hardening any way.

If you do need dynamically generated content, then it will be worth it to invest the time to harden it, but I submit that the majority of people currently using PHP/Ruby/Python/etc on their websites don't actually need it. If you're doing ecommerce or something like that which requires dynamic content, do it right and hire a web developer with a good history of developing and deploying secure applications. Then hire a third-party security consultant to come in and audit their work. Does that cost a lot of money? Yep, but if you're running a site that relies on dynamic content to make money, it should be well worth it.

As an alternative, you could learn how to secure dynamic websites, but don't do it on a "production" site as you're rolling it out. Do it on test sites, not connected to the Internet. You could setup multi-tiered server environments with virtualization (VMware, Xen, etc) to test your applications. Before you roll it out, make sure a third-party evaluates the security of your site.

Securing dynamic websites takes a lot of time/effort/money. Why go through all that trouble if you don't have to?

ooh, hadn't thout of them using proxies...
Here's an idea, write a script to add the botnet's ip's to an iptables firewall or blacklist. I really don't know much about iptables, or scripting for that matter, but it should just be a matter of sending the connection log output to a config file for your firewall.Installing AIDE couldn't hurt as well.

Hi, if you are thinking about honeypotting those botnets I suggest that you try Nepenthes, that is a low interaction honeypot that even I can use without any problems.

I'm not a very experienced Linux user but I catch about 2-4 botnet cc's every time that I decide to run nepenthes (usually I run it for a week or so when I feel like playing with malware). And it has other nice
features too, it auto dl's (using ftp) malware binaries and submits those to norman sandbox (from there you get botnet cc's and passwords).

http://nepenthes.mwcollect.org/

Mailinglist for botnet reporting.
http://www.whitestar.linuxbox.org/ma...stinfo/botnets
http://www.shadowserver.org/wiki/

Cheers,

/////