Tag Archives: Malware

Amazonian Trojans and Marketing Fear-Mongering

Hello there, welcome back to our scheduled programming on how to drum up clicks and views on your website “Powered by Fear Uncertainty and Doubt”.

As most marketing organizations know, sometimes you need to be a little creative when coming up with news and research. You draw a target for your security researchers to hit, and hope they come back with meaningful data that’ll make it to the next news cycle. And sometimes it actually works.

This time it didn’t. Recently, when reviewing my Twitter/Facebook feeds, I ran across “news” that state that Amazon (OMG – our trusted Amazon) are selling Rooted Android tablets, preinstalled with Trojans. Most of the public probably goes: “Hide your Nexus and shoot your Kindles!” in response. How dare Amazon sell us trojaned tablets?

But worry not, only after actually reading the details of the article (http://www.net-security.org/malware_news.php?id=3152) and the original research report (http://www.cmcm.com/blog/en/security/2015-11-09/842.html) you’ll understand that:

  1. Amazon has nothing to do with this. Just like you and I can set up shop on Amazon and start selling backdoored laptops, Amazon wouldn’t have anything to do with said backdoored laptops.
  2. It’s not about your usual tablet. So you can pull back your Nexus, brush up your Kindle, and keep using your Asus/Samsung/LG/[brand] Android tablet.
  3. It’s not even really an Android issue. One could have jailbroken an iPad, install a backdoor/trojan on it, and sell it online. The Android part is relates more to the price point and the ability to sell really cheap tablets.
  4. I dare you to recognize any of the “brands” of tablets sold with these trojans. Funny, the top “brand” is actually, wait for it, “NO BRAND”. I kid you not.

brands

So after sorting out the FUD, we are left with no much of a scare. Suspiciously cheap tablets, marketed mostly as “no brand” (or other brands which at least I’ve never heard of), are filled with questionable software. Kind’a reminds me of even “big name” manufacturers who load their phones/tablets/laptops with assorted unwanted software (officially dubbed “bloatware”). Wow. How did this not make headline news across the nation?

Bottom line – it’s pretty sad that we end up running research on the fringe areas of consumer devices and shopping behaviors. Yes, there’s a technical merit to analyzing a Chinese backdoor, but marketing it as “OMGWTFBBQ!” by sprinkling in Amazon and Android in the headline is pure marketing alchemy. Let’s get back to two things:

  1. Educating that when the deal seems too good, it probably is.
  2. Focusing our research efforts on more meaningful things. Yes, this also applies to stunt hacking, or junk hacking of sorts. There’s a lot of brainpower that could be diverted to solving problems that we have been dealing with for ages, yet would probably yield less media buzz.

Relying on AV? Really?

I tried to hold back on this one, but if you’ve read this blog (or met me in person) you know it’s hard… Another amazing research coming out of your favorite AV vendor – uncovering ground breaking security implications. Take a minute to read this:
http://www.symantec.com/connect/blogs/simple-njrat-fuels-nascent-middle-east-cybercrime-scene

Admittedly, I have stopped reading any AV vendor’s blog ever since I didn’t need to (for marketing or competitive reasons). The main reason is that they are riddled with old information, mostly FUD and scare tactics, self promotion, and subtle competitor bashing. So yes, I might be missing on more gems like this…
Nevertheless, this specific post came to my attention as it was quoted in a blog dedicated to security in the middle east written by Tal Pavel who I highly respect as a researcher that focuses on regional issues (warning – Hebrew only site): http://middleeasternet.com/?p=9999

So, a new RAT that caters for and was written by Arabic speakers. njRAT. That name rang a bell, and of course, after a couple of minutes of digging through my notes, there it was. OLD as nicely aged single malt whiskey (in “cyber” terms…).
The original Symantec article claimed it first saw the light of day sometime in 2013. That’s pretty fresh. Too bad that this thing has been around probably since early 2012 (might be even earlier – I haven’t really looked into it that much). How can I say that? Well, I’ve used it as an example (yes – and example! wasn’t even the main topic of what I was talking about) in a presentation I first gave publicly in April 2012 at Source Boston. Which means it was seen, analyzed, used (and, ahem, somewhat abused), much earlier in 2012. I also presented this as part of my SexyDefense talk at BlackHat USA, DerbyCon, HashDays, and SecurityZone later that year.
They did get one thing right – the focus on Arabic speaking threat communities. I’ve seen njRAT back then when working on a defensive posture project for a client who’s threat communities were heavily into the Arabic speaking world (vagueness intentional).


(skip to slide 68 for the specific example concerning njRAT)

The question remains though – are you still relying on AV vendors to have your back, when their “breaking grounds research” deals with malware that’s over 2 years old? And I’m not picking on Symantec here either (they did a great job of analyzing the 3 year old Stuxnet back at the time!). All AV vendors can feel free to include themselves here (yes, even if you no longer call yourself an “AV Vendor”, you still are. I’m looking at all of you…).

Think again…
Oh, and here’s a late edition just to top it off: http://mincore.c9x.org/breaking_av_software.pdf (Breaking AV Software – from Syscan 2014).

And guess what, perfect timing – next week I’m going to be in Boston again for Source – where this post basically all began 🙂 See you there!

On BadBIOS and Bad Behavior

So, unless you are in the security industry and have been living under a rock in the last couple of weeks, you probably know what this #BadBIOS thing refers to.

It started when Dragos Ruiu, a highly respected researcher and the founder and organizer of CanSecWest (and PacSec, and EuSecWest) started posting about his exxperience with what seems to be a targeted attack on some of his computing environment:

It started with this post:

IMHO Copernicus BIOS verification tool, (From John Butterworth / MITRE – presenting at PacSec) is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it. And that isn’t even the interesting part, the malware seems to have a hypervisor and some kind of SDR (software defined radio) that bridges air gaps, even in laptops with the wifi and Bluetooth cards physically removed. It’s also OS specific, the one we found targets Windows… Time to recheck the OSX boxes too.

Followed by more specific mention of the audio issues that were related to the malware behavior:

So it turns out that annoying high frequency whine in my soundsystem isn’t crappy electrical noise that has been plaguing my wiring for years. It is actually high frequency ultrasonic transmissions that malware has been using to communicate to airgapped computers… one “ghost” located at least. And now we know how the “hypervisor” functions, its probably stored in the realtek firmware, and thats one of the ways it survives reinstalls and BIOS reflashing. Off to find tools to dump the RealTek audio chips, and to try to find clean firmware to compare it to. Haven’t ruled out video firmware yet, either.

And a more comprehensive post circling back to the USB infection vector, and the TTF font files:

More on my ongoing chase of #badBIOS malware. It’s been difficult to confirm this as I’m down to a precious few reference systems that are clean. I lost another one yesterday confirming that simply plugging in a USB device from an infected system into a clean one is sufficient to infect. This was on a BSD system, so this is definitely not a Windows issue.- and it’s a low level issue, I didn’t even mount the volume and it was infected. Could this be an overflow in the way bios ids the drive?

Infected systems seem to reprogram the flash controllers on USB sticks (and cd drives, more on that later) to attack the system (bios?). There are only like ten different kinds of flash controllers used in all the different brands of memory sticks and all of them are reprogrammable, so writing a generic attack is totally feasible. Coincidentally the only sites I’ve found with flash controller reset software, are .ru sites, and seem to 404 on infected systems.

The tell is still that #badBIOS systems refuse to boot CDs (this is across all oses, including my Macs) there are other more esoteric problems with partition tables and devices on infected systems. Also USB cd drives are affected, I’ve bricked a few plugging and unplugging them too fast (presumably as they were being reflashed) on infected systems. Unsafely ejecting USB memory sticks has also bricked them a few times on #badBIOS systems for clean systems, though mysteriously they are “fixed” and reset by just simply replugging them into an infected system. Extracting data from infected systems is VERY tricky. Yesterday I watched as the malware modified some files on a cd I was burning to extract data from an infected system, don’t know what it was yet, I have to set up a system to analyze that stuff.

On windows my current suspicion is that they use font files to get up to some nastiness, I found 246 extra ttf and 150 fon files on a cleanly installed windows 8 system, and three stand out, meiryo, meiryob, and malgunnb, that are 8mb, instead of the 7 and 4mb sizes one would expect. Unfortunately ttf files are executable and windows “previews” them… These same files are locked by trusted installer and inaccessible to users and administrators on infected systems, and here comes the wierd part, they mysteriously disappeared from the cd I tried to burn on a completely new system (a laptop that hadn’t been used in a few years) that my friend brought over which had just been freshly installed with win 8.1 from msdn, with the install media checksum verified on another system.

I’m still analyzing, but I’m certain we’ll ALL have a large problem here. I have more data and info I can share with folks that are interested.

Up to this point, all that was available were Dragos’ accounts of what he’s going through and the assumptions and forensic efforts made in order to uncover what was going on. Shortly after that an article by Dan Goodin was published on ArsTechnica which went through the incident and also mentioned the different assumptions made so far. It’s important to remember that there weren’t any real insights there yet, as the forensic process was not completed.

Nevertheless, the industry exploded. From more sensible breakdowns of the elements mentioned by Dragos – such as Errata’s Robert Graham’s post, to the more popular reaction which was to simply call bullshit on the whole thing and dub it as a marketing effort.

Then came the naysayers, with more elaborate explanations of why this can’t happen, focusing specifically on the parts they felt they had the most experience with – and while at it, completely ignoring what was reported and the context of that part, for example – a great post by Phillip Jaenke focusing on how it would be impossible to deploy a fully functional malwae of this sort solely through BIOS – especially not while utilizing audio functionality straight from BIOS code (of course…).

Now, don’t get me wrong – I’m still the annoying sarcastic skeptical engineer at heart that I am, but seriously – this is still work in progress. Details are emerging as they become available, and frankly I do think that Dragos is doing the best he can to make these available (it’s his reputation on the line after all). Why can’t we either focus on working with empirical data, or just hold on until the entire picture becomes clear? In an industry that is supposed to be highly scientific (I know – I’m also holding on from bursting out laughing when I think of some of the people that made it into the industry when I mention scientific here…), and analytical, there is no room for too much emotions. Definitely not the school-yard bullying kind that some people show (again – love comments such as “i call bull”, and “it’s a fake”. The rigor of these arguments is just awesome). And no – I don’t expect Anti-Virus companies to be able to deal with this (or talk about it yet – at least not until they have their signatures in place…). They can’t deal with simple tools that are being used for pentesting, do you really think they can handle an actual attack?

1401132_10151680012450588_1416577247_n

And yes – this is especially interesting for me, if not only for one (yes, just one) element of this which involves the use of audio to communicate between machines. As if that is anything new – we’ve been doing this with acoustic couplers since the 60’s. I’ve personally been employing similar techniques in red teaming since 2009-2010 (and also published this) – hence my continued interest in tracking down more examples of such uses.

Bottom line – I’m going to keep waiting for more details and data to work with. My personal familiarity with Dragos’ body of work allows me to speculate, but that’s not for sharing publicly. I’m sure that like myself, there are others with narrower and specific interests in other elements of this who have been working on the assumptions surrounding this (either to approve or disprove), and for the love of science – if you don’t have something intelligent to say, just keep quiet.

update: more data keeps coming in for examination from Drags on his Google+

Guest post: Why you need patch management

Today we have another guest post from our friends at GFI – this time on patch management (which unfortunately is one of the reasons that so many pentests are so easy to succeed in…)

Every organization uses several types of software such as operating systems, servers, clients and many other third party applications. Every software package is a complicated piece of engineering. Programs are created from hundreds of thousands to millions of lines of code and each line of code is further converted by the compiler into many low level instructions that a computer needs to execute. With all this complexity, it is not surprising that issues will arise affecting the smooth running of the system on which the software is installed.

Be it a coding mishap, a combination of inputs that the developer didn’t foresee, or even an unexpected interaction between the billions of low level instructions, an application can have a vulnerability that would allow someone to maliciously exploit in order to perform some undesired action.

Malicious hackers are constantly looking for these software deficiencies both for fame and profit. A zero-day vulnerability in a popular application may be sold for hundreds of thousands of dollars on the black market. Such vulnerabilities could be used to infect a large number of computers before vendors get a chance to detect and address the problem.

At the other end of the spectrum, security researchers are in a daily race with malicious hackers to find vulnerabilities themselves. When they do come across these vulnerabilities, vendors are notified and given time to fix the issue before making their findings public.

How does all this affect your need for patch management?

Malware like the Code Red worm and Sasser exploited software vulnerabilities to deliver their malicious payload, therefore failing to patch software would leave your systems open to such attacks. Payloads can be anything from BotNet software which will waste bandwidth and computer resources to send spam, to spyware software designed to steal credentials, financial details and intellectual property.

While security researchers play an important role in discovering vulnerabilities, disclosing them to the public indirectly increases the risk for organizations because even though a patch will be available, not all organizations are organized and address the problem immediately.

Hackers are aware that many IT admins take their time to patch their systems, sometimes waiting months to deploy a released patch. Code Red is a perfect example. While Code Red exploited a vulnerability for which a patch had been available for over a month, countless systems were compromised by the malware because many had not yet deployed the critical patch.

One also needs to take a holistic approach to patch management.  As in all security cases, it is the weakest link in the system that is exploited. An attacker does not need to compromise all your systems’ vulnerabilities, they only need to compromise one vulnerability to get access to your systems. That is why selective patch management is not recommended. While operating system patch management is essential and easiest to perform, that alone will not protect you against vulnerabilities in third-party products such as a PDF file exploiting a vulnerability in a PDF reader.

It is obviously preferable to do operating system patch management exclusively rather than having no patch management at all, but the more applications you keep up to date the more effective your security will be.


This guest post was provided by Emmanuel Carabott on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs.

Find out more about what should be included in your patch management.