ClearMind Central Blog

Discussing data solutions and technology security, with occasional digressions

Ransomware trends – all towards more crime

Feb 9, 2015 | Security

There has always been a question of “what is malware for?”  What’s the point of either planting or automating the planting of malware on a computer that isn’t yours?  Many answers are relevant:

  • For fun, laughs, or by accident
  • To spy or grab data (keylogging, banking trojans)
  • To use the computer’s resources to attack or gain something else (DDoS bots, Bitcoin mining, spam)
  • To damage the person or company whose computer has been penetrated (viruses which delete data, or exfiltrate data to embarrass Sony)

However, there’s an emerging and straightforward model for malware: Make money directly from the target via extortion.

Ransomware has grown at a high rate over 2014, and all the trends are now moving towards increased prevalence.  The recent growth is the confluence of several trends:

  • The maturity of encryption algorithms
  • The wider availability of anonymizing networks like Tor and I2P
  • The wider availability of anonymous digital currencies like Bitcoin and Litecoin
  • The maturity of a worldwide market in “Zero-Day” exploits for common software packages like Flash or web server software

Combine those trends, and it is not just possible, but likely, that criminals will try to extort money from computer users who need their digital files back.  They’ll be able to attack the users (Zero-day exploits and garden-variety phishing), encrypt files (with mature uncrackable algorithms), connect to the user anonymously (via Tor or I2P), and receive payment (anonymously with Bitcoin or Litecoin).

With the existing cash flow, criminals have begun to bid for advertisements on websites like huffingtonpost.com, dailymotion.com, and mapquest.com.  Ransomware now has a marketing budget.

There’s a lot of money already in this, but it is in ClearMind’s opinion an untapped criminal market.  There is no reason to think that this won’t get worse – as in a lot worse.

The main prophylactic steps are:

  • Go mentally and procedurally through a CryptoWall, CryptoLocker, or similar infection.  What would happen?  Imagine it in detail.  Note all your attached drives and mapped drives.  Then:
  • Have proper, versioned backups of your necessary files
  • Have a solid frequently rotated offline backup of necessary files
  • Surf the web in a non-privileged account
  • Patch all software and be scrupulous about it
  • Have some endpoint security and keep it updated
  • If you can live without Adobe plugins like Flash or PDF, or Oracle plugins like Java, then by all means remove them when possible

Buckle in.  These trends will only become more pronounced.  The internet draws us all closer – including drawing you closer to people who would extort money.

CryptoLocker and Bitcoin

Nov 18, 2013 | Uncategorized

The thoroughly expected “CryptoLocker” malware has attained prominence over the last two months, properly encrypting files and requiring a difficult-to-track ransom in order to receive back the decryption key.

At the same time, there has been a large run-up in the price of Bitcoin.

Most commentators have focused on the Chinese market for the Bitcoin run-up.  However, finally there is some attention to how the Bitcoin ransoms may be helping to inflate this tiny market:

http://ftalphaville.ft.com/2013/11/18/1696832/a-crypto-crisis-or-a-crypto-triumph/

2) A sinister cryptlocker virus has been spreading aggressively for more than a month. It hijacks computer systems and threatens to delete data unless a bitcoin ransom is handed over. Also, reports abound of a rush of purchases byunsophisticated and distressed buyers who are presumably ready to pay any price, and thus can be squeezed by more sophisticated players in the market.

Kaminska makes this reason #2, ahead of the Chinese market and below the Silk Road seizure – but the Silk Road incidents should have lowered the price, not raised it.

Combine that with how it might be difficult to buy a MoneyPak, and you’ve got the recipe for a squeeze.

Backdoor found in OpenX open source version 2.8.10 – some thoughts

Aug 8, 2013 | Uncategorized

Two days ago, Heise (the German news and IT firm) reported that a backdoor was found in the prominent advertising platform OpenX.  (German link here, and I leave translation to the reader.)  The backdoor itself was injected into a somewhat obscure flowplayer javascript file, with obfuscated php hiding the fact that it was a remote code execution bit of php.  With this code there, it would be trivial for a solid hacker to build a shell for the server and completely compromise it.

The question which immediately came up for me was, Huh?  Since when is a webserver interpreting a javascript file as a php file?  I doubted that it is typical for web servers to be configured to have .js files interpreted by the .php interpreter first, then sent to the browser.  However, none of the technology reporting said anything about how the OpenX backdoor was getting the .js file to be executed as .php.

A couple examples of the simple explanation that .js files just obviously might house some .php and invoke it:

But web servers don’t do that.  So there must be something else in the OpenX code which allows javascript to be interpreted as php.  One clue was that the original Heise article said:

Die Datei wird durch einen Aufruf von require_once() aktiviert

which means, basically, that the rogue PHP function in the flowplayer js would be called and activated by a require_once() call.  But where is that call?

The second clue is that there were actually three files involved in the intrusion, not one, and all three are critical to the intrusion.  The somewhat unhelpful post from OpenX says to md5sum the following files:

558c80e601fb996e5f6bbc99a9ee0051  plugins/deliveryLog/vastServeVideoPlayer/flowplayer/3.1.1/flowplayer-3.1.1.min.js
fa4991d5fd3bf4a947b6ab0b15ce10b2  plugins/deliveryLog/vastServeVideoPlayer/player.delivery.php
5014c31b479094c0b32221ae1f1473ac  lib/max/Delivery/common.php

The question then is: what is special about the other two files, and why would changing them be related to closing the backdoor?

player.delivery.php ver 2.8.10 has this line:

MAX_commonReadFile( $pwd . ‘/’ . $file_to_serve);

whereas vers 2.8.9 and 2.8.11 have:

echo file_get_contents( $pwd . ‘/’ . $file_to_serve);

The latter would simply send the javascript without interpreting it.  But… what does MAX_commonReadFile do?

Cue lib/max/Delivery/common.php:

Versions 2.8.9 and 2.8.11 don’t have this function, so it was also injected.  Here is the function in 2.8.10, nestled between MAX_commonConvertEncoding and MAX_commonSendContentTypeHeader:

/**
* A function to read a contents of SWF file
* @param string $file The path to SWF file to read
*/
function MAX_commonReadFile($arg)
{
if($conf[‘debug’][‘read’]){
echo file_get_contents($arg);
}
require_once($arg);

}

Bingo.  There is the invoker of the backdoor: require_once($arg), which in this case would be to the path.  All this stuff about “SWF file” is obfuscation – the attacker was actually doing a javascript read, and frankly, there never would be a reason to require_once a file if it is a non-php asset like a SWF.

I’m puzzled currently about the [‘debug’][‘read’] item – it seems to be a way of throwing admins who are trying to trace problems with the site and thus who are in debug mode.  Anyone else have an idea?

So, a few final thoughts:

  • Currently we have no idea how the code got in there.  I am looking forward to the article which traces the evolution of the code tree and speculates about the account(s) involved in these three code updates.
  • Javascript doesn’t invoke PHP, but it might be a convenient place to hide invokeable code in another language.  Think about all the other files which might contain backdoor code – an .HTML template?  A README file, or a documentation file in a usually uninteresting directory?  An image which is unused in the site but isn’t deleted, and so no one knows it is not displaying properly?  This case is of a static asset which was turned into backdoor code elsewhere by a sink (require_once).
  • Heise articles suggest that OpenX might be involved in some issues for a long time, including before this event.  This backdoor was discovered only after 7 months.  +1 for the person who finds any more problems in the codebase.

 

 

Adventures in Live Linux CDs

Jul 9, 2013 | Uncategorized

Recently I’ve needed to use Live CDs for a client, when nothing could be saved on disk.  I’ve used:

* Knoppix (best)

* Xubuntu (has problems with the wireless card in this laptop)

* Tails (security overkill)

It is time to take a look at Puppy again, just to see if it is compatible with the wireless card in this server.

Incidentally, the idea of routinely using a hard-drive-free Linux live CD is becoming more appealing.  The idea is to have a computer with no connection between current and past sessions.  If you are dealing with information covered by privacy regulations, like student info, health information, or financial information, this can help you meet regulations in short interactions with websites.

“When Patents Attack!” on This American Life

Jun 4, 2013 | Uncategorized

Intellectual property concerns are paramount in the technology world.  Once the Supreme Court opened the door for patenting computer programs and technical processes, the economic incentive to patent technologies of all kinds became large.

Pair that with a potentially less-than-precise Patent Office, which frequently allows patents which are either obvious or have significant overlap with other patents (and frequently both!), then you get a recipe for litigation over the most simple of computer techniques (say, one-click ordering, pop-up windows on mobile, or cloud storage of files).

This American Life put together a fantastic exploration of this topic.  Check it out.  http://www.thisamericanlife.org/radio-archives/episode/441/when-patents-attack

Recent Comments