During October 2015 the curl web site sent out 1127 gigabytes of data. This was the first time we crossed the terabyte limit within a single month.
Looking at the stats a little closer, I noticed that in July 2015 a particular single package started to get very popular. The exact URL was
http://curl.haxx.se/gknw.net/7.40.0/dist-w32/curl-7.40.0-devel-mingw32.zip
Curious. In October it alone was downloaded more than 300,000 times, accounting for over 70% of the site’s bandwidth. Why?
The downloads came from what appears to be different locations. They don’t use any HTTP referer headers and they used different User-agent headers. I couldn’t really see a search bot gone haywire or a malicious robot stuck in a crazy mode.
After I shared some of this data over in our IRC channel (#curl on freenode), Björn Stenberg stumbled over this AVG slide set, describing how a particular malware works when it infects a computer. Downloading that particular file is thus a step in its procedures to create a trojan that will run on the host system – see slide 11 for the curl details. The slide also mentions that an updated version of the malware comes bundled with the curl library already, which then I guess makes the hits we see on the curl site being done by the older versions still being run.
Of course, we can’t be completely sure this is the source for the increased download of this particular file but it seems highly likely.
I renamed the file just now to see what happens.
Evil use of good code
We can of course not prevent evil uses of our code. We provide source code and we even host some binaries of curl and libcurl and both good and bad actors are able to take advantage of our offers.
This rename won’t prevent a dedicated hacker, but hopefully it can prevent a few new victims from getting this malware running on their machines.
Update: the hacker news discussion about this post.
Poor package maintainers, seeing their source files disappear.. 🙂
@Kurt,
I’m not sure that package maintainers would be bothered very much by this. The package name has ming32 in it, which I believe is a windows-only thing? If that’s true, then only cygwin users would be impacted, not CentOS/Debian/Arch/etc. True, we shouldn’t discount the windows users, but I certainly wouldn’t be as concerned about them as I would the *nix folks.
@Kurt: this wasn’t a source package, this was a binary build for Windows… and anyone using the download page or download wizard on the site will get the renamed version!
Ok, thanks. Wasn’t obvious to me from the path alone.
if (curl_site_is_down()) {
update_malware();
} else {
download_curl();
}
And how exactly do you update the malware? Using curl…
There is no other HTTP client besides curl.
But than how did it download curl? Exactly, using curl…
Simple and genius 🙂 should look after international statistics to see how much this renaming impact and how much also will try the 404’d link.
Could you replace it with an updated binary that includes the expected files but when the malware runs the executable or calls the library function, it triggers something to actively remove the malware?
Doesn’t work if the malware does a checksum check on the downloaded file (if it only checks the size that’d be easy enough to fake I guess) but it’d be interesting to know if it was possible.
Removing that particular file relieves the immediate symptom, but this seems like a great opportunity to get at the disease. Did you consider replacing that binary with one that would attempt to notify the network admin, report the compromised / targeted machine to some security authority, or simply crash (I imagine it would take the malware authors longer to figure out there was a “bug” in curl than that the curl distribution endpoint was 404’ing)?
You need send IPs of those poor victims to (some antivirus company? for analisys) so they can clean up PC or whatever it is
Since you have this vector against the virus, why not whip up a little exploit against the virus that removes it? Is there anything special about how it makes the request that you can fingerprint on?
To those asserting this is an opportunity to fight the malware – well, yes, I suppose it is. It is also an opportunity to damage thousands of machines more than they already are.
Even ignoring any potential legal issues, do you want to be ethically on the hook for any potential bug in your super-duper-malware-fighter that does damage? Remember, you’re essentially playing corewars on a bunch of other people’s machines. Are you sure you’re that good, and that you’ve taken into account all the vagaries of possible configurations on all those machines? What about what the malware might do?
I would hope anyone seriously considering this would think those, and other, questions through.
Perhaps too late. But it would have been nice if the package was replaced with a curl-exe saying “your computer is likely infected”.
Removing the package is a good step anyhow.
Kjell: that’s a libcurl.DLL package, adding an exe to the package wouldn’t make a difference.
Also, purposely adding code to have it run on others’ computers without their permission could probably be considered at least bordering to illegal. Not to mention that I can’t even be perfectly sure when the malware is the one doing the download.
I won’t waste any time going down that route.