Sunday, July 3, 2011

Alert: vsftpd download backdoored

[With thanks to Mathias Kresin for being the first to notice]

An incident, what fun! Earlier today, I was alerted that a vsftpd download from the master site (vsftpd-2.3.4.tar.gz) appeared to contain a backdoor:

http://pastebin.com/AetT9sS5

The bad tarball is (sha256sum):

2a4bb16562e0d594c37b4dd3b426cb012aa8457151d4718a5abd226cef9be3a5 vsftpd-2.3.4.tar.gz

And, of course, the GPG signature notices:

$ gpg ./vsftpd-2.3.4.tar.gz.asc
gpg: Signature made Tue 15 Feb 2011 02:38:11 PM PST using DSA key ID 3C0E751C
gpg: BAD signature from "Chris Evans <chris@scary.beasts.org>"

Check your signatures :)

Ideally, you'll see something like:

gpg: Signature made Tue 15 Feb 2011 02:38:11 PM PST using DSA key ID 3C0E751C
gpg: Good signature from "Chris Evans <chris@scary.beasts.org>"
Primary key fingerprint: 8660 FD32 91B1 84CD BC2F 6418 AA62 EC46 3C0E 751C


Signatures aside, I also took the liberty of moving most of the vsftpd site and latest download to a hosting provider I have more faith in:

https://security.appspot.com/vsftpd.html
https://security.appspot.com/downloads/vsftpd-2.3.4.tar.gz
https://security.appspot.com/downloads/vsftpd-2.3.4.tar.gz.asc

The backdoor payload is interesting. In response to a :) smiley face in the FTP username, a TCP callback shell is attempted. There is no obfuscation. More interestingly, there's no attempt to broadcast any notification of installation of the bad package. So it's unclear how victims would be identified; and also pretty much guaranteed that any major redistributor would notice the badness. Therefore, perhaps someone was just having some lulz instead of seriously trying to cause trouble.

34 comments:

  1. "So it's unclear how victims would be identified..."
    Maybe by trying to log in as a smilie face?

    ReplyDelete
  2. @⬡ -- trying that for every site on the internet is inefficient, possibly even prohibitive. A more sophisticated attack along these lines usually involves the backdoored software pinging back somewhere when it is launched.

    ReplyDelete
  3. If the attacker was able to view the access log for whatever server was hosting the tarball, that would probably give them a good list of IPs to go after.

    ReplyDelete
  4. "usually involves the backdoored software pinging back somewhere when it is launched."

    There haven't been enough known cases to make that claim. It's just how you would do it. It's also how one would be caught.

    As far as scanning being prohibitive, www.shodanhq.com

    EC2 for scanning is another option.

    So how did they get in?

    ReplyDelete
  5. the smiley scanner was already written and launched when your code got backdoored doud... inet round robin!

    ReplyDelete
  6. "So it's unclear how victims would be identified..."

    Maybe the person who put the backdoor in wasn't intending to make a botnet out of the victim machines.

    Maybe they wanted to see if it would go undetected long enough that they could just assume that anyone running VSFTP was backdoored and then they could have fun hopping from site to site seeing what they now had access to.

    Or, i think more likely, they just wanted to see how long it took the VSFTP team to notice that the code had been messed with.

    ReplyDelete
  7. Could you share a copy of the backdoored code so that i can try to write a snort rule for inclusion in emerging threats?

    ReplyDelete
  8. Please ignore/delete my previous comment, i did not see the pastebin link. I will propose a rule addition for emergingthreats.

    ReplyDelete
  9. something like the the ProFTPD backdoor would have been more devastating (it had a HTTP GET to some server in Saudi Arabia iirc), I wonder for how long this has been backdoored? can't have been very long.

    ReplyDelete
  10. or the payload could be primary in hibernate status, until the next payload/ download is attempted ?

    ReplyDelete
  11. unless they also had access to your download logs?

    ReplyDelete
  12. Maybe they have access to download logs...

    ReplyDelete
  13. It could be a targeted attack.

    ReplyDelete
  14. No I like to use either a drop virus or a BlindSQL, but a DoS attack shuts'em up good.

    ReplyDelete
  15. Just depends on how paranoid you want to be. If you are targeting a specific site that you know uses this service; its pretty easy to tell when they've "upgraded". If you watch them closely you might even know their upgrade schedule so the attack can happen (or did happen) before anyone notices.

    And while we are talking paranoia; Chris, how much would you charge to put a backdoor in this software for me? 5 figures- 6 figures- 7? How much if its not obfuscated and easily "deniable"?

    I don't mean to question your integrity specifically- just to acknowledge the attack methodology across all software both opensource and closed source.

    At least if it costs 7 figures to have you place the backdoor, people would probably have to be the target of a nation-state, as opposed to an average (income) joe they've pissed off on IRC to be the victim of the attack.

    Across all published software, finding someone to accept such a payment seem plausible.


    -Monta

    ReplyDelete
  16. So if want to find out if I have the bad version of "vsftpd" , the way to test is to login as ":)" (no quotes).

    And no password?

    And do I have to use a special port to connect?

    I installed it through:
    apt-get install vsftpd
    (a week ago)

    Sorry for these noob questions I just started linux server.

    Thank you

    ReplyDelete
  17. Perhaps the person also have access to the download site logs and simply try the IP that were used to downloaded the software?

    ReplyDelete
  18. Perhaps the person also have access to the download site logs and simply try the IP that were used to downloaded the software?

    ReplyDelete
  19. Any idea how long the backdoored tarball was up, or how many people downloaded while it was up?

    What hosting provider was it on? Do they have upload logs?

    ReplyDelete
  20. Evil smilies are evil

    ReplyDelete
  21. Do you know if any downstream actually (was stupid enough) to pull down and package the compromised code?

    ReplyDelete
  22. Identifying victims isn't so hard, as long as one has access to a botnet it's just a matter of telling the bots to scan subnets and try to log onto ftp hosts using a "smilie", sure, it may take some more time, but given that FTP bruteforcers are considered background noise, while an FTP server suddenly sending out (say) and email may be noticed, I think that the approach isn't totally wrong (from the "attacker" point of view)

    ReplyDelete
  23. Can you tell which source file(s) and functions were modified and what to look for in the code?

    ReplyDelete
  24. Inefficiency is small price to pay for stealth. Pinging back somewhere risks detection by monitoring tools. Also, what proof does the author offer that he isn't responsible for the back door to begin with?

    ReplyDelete
  25. Linus doesn't trust Google with his code....why should you?

    ReplyDelete
  26. Or maybe they just had one particular victim in mind.

    ReplyDelete
  27. It's even enough if the target ftp runs under that backdoored version...

    No need to inform the attacker, just a victim which update without checking the integrity ..

    ReplyDelete
  28. it might be inefficient, but it's safer then having a control point that receives acks from the infected/affected boxes.

    ReplyDelete
  29. Maybe an attacker had access to logs of the compromised hosting server. Some victims, who downloded the source by the same IP address where they finally installed compiled vsftpd, could be easily identified by the attacker or eventually by you.

    ReplyDelete
  30. This isn't good... have they found who did this?

    ReplyDelete
  31. May be someone has to raise the hand & say I'm the one who did that

    ReplyDelete
  32. What sort of hosting did you have, that the blame lies with the web host ? surely you are responsible for your own data?

    ReplyDelete
  33. Matt "Breakpoint" HeckJuly 15, 2012 at 7:48 PM

    I'm dismayed to observe that an important reason for doing this wasn't even considered: tampering with the package immediately prior to someone attempting to download a current version of it for use in the shipping firmware of an embedded system.

    In other words, if you know someone is about to obtain a package because they need to deploy it as part of an embedded system, and you can compromise the binary long enough to get it onto the master disk image, then you have compromised every instance of that product.

    That would be a high-payoff target, and would also explain the lack of an announcement of vulnerability-- if the attack is successful, you would simply know that EVERY instance of that embedded device is vulnerable.

    Another reason it is very important to verify your package hashes when preparing an embedded system (or at least use a package manager that will do so on your behalf). Obviously, it does raise some concerns with respect to things like Buildroot, as it just gets whatever source is current for a number of things...

    --Matt "Breakpoint" Heck

    ReplyDelete