XMLRPC vulnerability: An oldie but a goodie
And oldie but a goodie: we run a number of honeypots as part of our ongoing efforts to learn what attackers are doing and how to best protect customers and users of our products. An interesting trend we have seen lately is the use of a very old xmlrpc vulnerability from 2005 being widely used in attacks. What’s really interesting is that there appears to be a new variant to this old vulnerability. Could there be holes in new applications using this old vulnerability? And what should you do about it?
Heres a link to the vulnerability details: http://www.securityfocus.com/bid/14088/info
So this is what we are seeing on our honeypots:
<?xml version=”1.0″?><methodCall><methodName>examples.getStateName</methodName><params><param><value><name>‘,”));echo’-OWNAGE-‘; echo getcwd(); echo’Hihi’; echo php_uname(); echo’_hihi’; exit;/*</name></value></param></params></methodCall>
The key to this old attack is the bolded section of that request, this little bit:
That takes advantage of a bug in the original xmlrpc code that allowed an escape sequence to feed code in. Our WAF rules have been protecting systems against this attack since 2005. In fact it was one of the first “complex” attacks we wrote rules for, so it was very surprising to us to see such widespread and constant attacks against what is a fairly old web vulnerability. We first suspected that this may be because there are still that many vulnerability systems out there, or it may be that some new web application is using old xmlrpc code and inherited this old vulnerability. It was then that we started to see a different variant at the same time from the same hosts:
(gzinflate(base64_decode(‘badness here’))); echo’_hihi’;exit;/*</name></value></param></params></methodCall>
What intesting here is the escape sequences are slightly different from the old 2005 variant, this time around is using:
So theres apparently some variant of xmlrpc that has a new (or old depending on how you look at it) vulnerability in it that uses a slightly almost subtlly different way of escaping and injecting code, and there are enough systems with the old 2005 vulnerability in them to be worth attacking them too.
So the moral of the story here is that if you are hosting web applications, you or your customers may be running code that is either so old its got very widely known vulnerabilities in it or its got a variant of an old vulnerabilty in new code. The sad truth is that we humans dont write very secure code naturally, it takes a lot of concerted effort to do things right so just because a vulnerability was widely publized does not mean that it was either fixed, or that we learned anything from it and won’t make that mistake again. We have so many vulnerabilities historically its understandable if a developer didnt know about this one in particular, and in so doing it makes sense how they might make the same mistake another person did.
Even if you are deligent and keeping your applications up to date, you may have an “old” vulnerability in a new application. Its best to assume that as vulnerabilities get older, peoples memory fades too and therefore old mistakes will crop up again in new code. So when securing web applications, its best to assume you have some old vulnerabilities on your systems, even if all you have are shiny new web applications and install a Web Application Firewall to protect against this, even if you think a vulnerability is so old it doesnt effect you anymore.