Botnet Billionaires | TechSNAP 170

Botnet Billionaires | TechSNAP 170

Want to make billions in days? Quit your job and become a botnet master. We’ll share the story about a Brazilian botnet that you’ve just got to hear.

Plus a major flaw in Android, encryption done right, your questions, our answers & much much more!

Thanks to:




Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed

— Show Notes: —

Botnet stealing from Brazilian banks rampent, maybe into the billions of dollars

  • In Brazil, the most common form of payment, for everything from taxes, utility bills or large purchases and almost all business-to-business payments is “Boleto Bancario” (or just boleto for short)
  • It is basically an bank transfer, somewhere between a cheque and a wire transfer
  • Most Brazilians do not have credit cards, and credit card processing is expensive (usually 3-5% or more) and the merchant usually has to wait 30 days to receive the funds
  • A boleto usually only takes 24 to 48 hours and has a low fixed fee (approximately $1)
  • unlike credit card payments, which can be disputed and reversed, boleto cannot be reversed. Refunds are handled by bank transfer
  • The information is filled out on a form, and then the recipient enters the details online to receive the payment
  • Brian Krebs was shown a botnet that was lying in wait on infected computers, and as the user entered the details of a boleto, it would quickly change the recipient as the transfer was submitted, allowing the botnet controllers to receive the money, instead of the intended recipient
  • “Thieves had hijacked some 383 boleto transactions between February 2014 and the end of June, but had stolen the equivalent of nearly USD $250,000 during that time”
  • Researchers at RSA Security (part of EMC) found an even larger botnet
  • “RSA says the fraud ring it is tracking — known as the “Bolware” operation — affects more than 30 different banks in Brazil, and may be responsible for up to $3.75 billion USD in losses. RSA arrived at this estimate based on the discovery of a similar botnet control panel that tracked nearly a half-million fraudulent transactions.”
  • “Most Brazilian banks require online banking customers to install a security plug-in that hooks into the user’s browser. The plug-ins are designed to help block malware attacks. But according to RSA, the Bolware gang’s malware successfully disables those security plug-ins, leaving customers with a false sense of security when banking online.”
  • “RSA notes that the miscreants responsible for the Bolware operation appear to have used just over 8,000 separate accounts to receive the stolen funds.”
  • The botnet Krebs discovered was much less sophisticated, using only 3 destination bank accounts

Dealing with encrypted streams

  • Adam Langley (of Google Security, and one of the authors behind BoringSSL) posts on his blog about how many file encryption systems, including gnupg, get it “wrong”
  • Specifically, when encrypting large messages they often use a single MAC (Message Authentication Code) at the end of the message
  • A MAC is used to ensure that the ciphertext has not been modified or corrupted before attempting to decrypt it
  • The problem is, if you do something like this: gpg -d your_archive.tgz.gpg | tar -xz
  • It will decrypt the contents of the gpg encrypted file and spit them out to the pipe, and not until it reaches the MAC at the end of the message, will it realize that the file was corrupted, and should not have been used. At this point it is too late, tar has already processed the invalid stream
  • An attacker may be able to use this to cause tar to overwrite a file the user did not intend, or otherwise create corrupted files or exploit a vulnerability in tar
  • The correct way to handle this situation is to not return the data until it has been authenticated, however this may require an impossibly large buffer
  • The author discusses the reasonably low overhead (0.1%) of breaking the message into 16 KiB chunks, each with a 16 byte MAC. This would allow gpg to authenticate each small chunk before writing it to the pipe.
  • However, with that approach “Although safer in general, when chunking one has to worry that an attacker hasn’t reordered chunks, hasn’t dropped chunks from the start and hasn’t dropped chunks from the end”
  • Ted Unangst (of OpenBSD/LibreSSL) posts his thoughts
  • Ted clarifies that OpenBSD’s ‘signify’ system in newer OpenBSD installers download the archive, verify the downloaded temporary archive before passing it to tar to be extracted, as opposed the the old design before signify, where the file was piped to tar directly from the ftp client, not requiring the temporary storage space
  • Ted also mentions his ‘reop’ (Reasonable Expectation Of Privacy) tool, a light weight (incompatible) replacement for GnuPG, “However, the entire message must decrypt and authenticate successfully before any output is produced, so it’s actually safer than a small packet streaming program which may produce partial output. (reop cheats a bit by imposing a message size limit; it simply can’t encrypt large files, for large values of large.)”

Android keystore stack overflow flaw could allow key-theft

  • The vulnerability could allow attackers to steal cryptographic keys from the device, including those for some banking services, virtual private networks, and PINs or patterns used to unlock vulnerable devices
  • The flaw is fixed in Android 4.4
  • Originally incorrectly reported as affecting 86% of devices, it only affects ~ 10.3% as it only affects Android 4.3
  • The vulnerability requires a malicious app be installed on the targeted handset, but we have seen legitimate apps be bought or hijacked before, and it is often fairly easy to trick people into installing apps
  • “Generally speaking this is how apps are going to store their authentication credentials, so if you can compromise the KeyStore, you can log in as the phone’s user to any service where they’ve got a corresponding app, or, at least, an app that remembers who you are and lets you log back in without typing a password. This means that most banking apps, which force you to type your password every time, are probably safe against this particular attack.”
  • Researcher Post


Round Up:

Question? Comments? Contact us here!