cryptolocker
Hi all! After a successful news digest covering the entire 2014 year, we decided to make this kind of column regular – or, rather, monthly. Today we discuss the most important news on information security from January. The method by which these were picked is a bit different this time. We still take the most viewed news stories from Threatpost.com and try to comprehend how and why they have drawn that much attention. But in the monthly digest there will be just five news stories. Let me first remind you that Threatpost accumulates all IT security industry news, while Kaspersky Lab’s own research is published on Securelist.
Summary: GLIBC flaw, physics don’t get along well with lyrists, North Korea browser, keylogging charger and keyboard vulnerabilities, Cryptowall ransomware and cracking WiFi. Alright, let’s go.
5. Wifiphisher: WiFi cracking under the thick layer of social engineering
The story. A discussion on Stackexchange, where the problem had been highlighted as far back as three years ago.
In a previous post, we told you that the Internet was broken. Of all that is ‘broken’ in computer networks, wireless is broken most severely. We’ve survived the ‘prelapsarian naivety’ of WEP protocol, been convinced a few times that unprotected public wireless networks are bad and gazed into the security abyss named WPS. Now there is a tsunami of bugs in routers’ firmware – default passwords embedded into the firmware (or something like this), miscoded NAT or something else. As if social engineering was all that we wanted.
You want it? You got it. It’s easy: all that it takes is to create a new hotspot with the same SSID as the legitimate one within the victim’s acceptance area. As soon as the victim tries to access it, we request the password to the ‘real’ hotspot and secure it for ourselves. That’s all it takes, now we can do a MITM attack. Ah, maybe not yet. First we need to talk the victim’s PC or mobile device into accessing ‘our’ hotspot. This we’ll do by spamming the area with de-authentication packets. They disconnect the legitimate clients so that they can connect to the fake hotspot.
Yet another thread on Stackexchange implies that the problem is long-known about and that it is either barely treatable (as with deauth packets) or unfixable completely. So what’s the news? – This method of stealing passwords has been just automated, with a utility named Wifiphisher, made available on Github. The first moral of the story: if someone is asking you for your password, no matter where, think twice before entering it. The second moral of the story: there’s no way to get protected from man-in-the-middle attacks by excluding the very possibility that they happen. There’s no way to exclude it, not in this state of the Internet.
By the way, Marriott Hotels’ networks dallied with deauth packets, using them to block out the visitors’ own hotspots. The FCC fined Marriott hard for this.
4. Cryptolockers. How is the phantom menace different from the apparent one?
The story. One more story. Detailed research on cryptolockers as a malware species.
Earlier I wrote that if we poll companies on the cyberthreats that they encounter the most often, that spam would most likely be in first place. But spam is something that doesn’t inflict any apparent damage. It does exist, but it’s hard to calculate. And if it’s hard to calculate, it’s not easy to evaluate how sensible the expenses are to fight it either. Besides, antispam technologies are mature, widely available and affordable.
Cryptolockers are a different story. The damage they inflict is rather easy to calculate: your company is attacked, important data is encrypted and becomes inaccessible and then the ransom is demanded. You lose money. You lose time. A single incident can bury your business completely (here’s an example). It’s clear that protection from cryptolockers is necessary.
For criminals, cryptolockers are easy money. It’s not a botnet that should be built first and then sold to someone. That’s why cryptolockers, unfortunately, are actively developed, and continue to grow in number and distribution.
So what’s the news? Ah, nothing peculiar! We’ve described the main trends of cryptolockers’ evolution during the summer of last year (and we keep researching them). Next to all security vendors are doing the same, including Microsoft and Cisco, for instance. The job is large enough for everyone. For instance, ransomware comprises all modern technologies for concealing the criminal conduct: Bitcoin payment, Tor and I2P communications, obfuscations, etc.
ut that’s not the main point. Most interesting are the technologies used by malware to get onto the victim’s PC. Cisco’s research in February shows that creators of one of the Cryptowall variants bet on exploit-kits. For businesses, this means that the weakest point of the infrastructure is vulnerable software. This may not be the discovery of the ages, but it is an important topic, nevertheless, and the fact that almost every news story on cryptolockers draws an immense interest, proves it.
3. USB wall charger with a built-in keylogger
Here is yet another story on how difficult it is to control wireless communications. It began with the work of three researchers who decided to analyze the security of Microsoft’s wireless keyboards. In the marketing materials for these keyboards there are likely a few lines on how securely encrypted the data exchange is between the device and USB-receiver. It is indeed encrypted, but there are doubts on how “securely” it is actually done.
In a nutshell, the MAC-address of the keyboard serves as the key to the encrypted symbols; it can be ‘snooped’, first, and second it can be used to steal remotely, using some peculiarities of the chip used for data transmission (also in quite a few devices, including some medical equipment – oops!). Then again, stealing it isn’t even necessary: the first byte of the MAC-address is the same for all keyboards which makes bruteforcing a cakewalk.
The only problem left is how to get close enough to the keyboard to continuously keylog it. Here comes Sami Kamkar, offering an original proof of concept. Take a common USB wall charger used for smartphones and tablets, beef it up with Arduino, a specifically crafted firmware, and get an electric Trojan horse. Which, by the way, remains operational even if the charger isn’t plugged into the AC outlet, a small rechargeable battery is there as well. The device itself costs $10; it’s very good that this is just a proof of concept (for now).
Microsoft refused to comment on the problem, merely saying that it ‘explores the problem.’ Yet the problem is very interesting: it’s barely fixable with firmware upgrades (if it is at all possible), only device replacement. Now, what if a similarly ‘untreatable’ bug was found, not in a $40 keyboard, but in a $70,000 luxury car? That’s a different story.
2. A backdoor in a North Korea browser
Impressed with the story on Sony Pictures Entertainment’s megahack, researcher Robert Hansen decided to take a look at the North Korean Internet. Let me remind you that N. Korea probably (still not proven reliably) was behind the attack carried out due to hard feelings towards the film about its leader’s assassination – probably, the dumbest comedy of 2014.
N. Korea uses its own Linux-based operating system known as Red Star OS (Pulgŭnbyŏl). As for a browser, it uses a Firefox fork titled Naenara (“My Country”). While exploring the browser, Hansen detected that at every launch, Naenara connects to a local IP-address within an isolated N. Korean network. Moreover, the entire country’s network is built the same way that local business area networks are constructed: internal addresses, almost totally isolated from the outside world and all communications via proxy. Probably, all traffic, including encrypted traffic, can be tapped: the browser accepts only one certificate – the state-issued one. It probably also has some romantic name.
In other words, all the tools needed to track users in the country with a single provider is already embedded into the only available OS. And that happens now, in North Korea! Wow! Breaking news!
This story is probably only popular due to the attack on Sony Pictures Entertainment and the possible involvement of North Korea. Additionally, Robert Hansen indeed uncovered a couple of tricks devised by the folks who really know how to limit and prohibit everything, not just Internet. Take a read!
1. GLIBC flaw or Why Patching Matters
The Story. CVE record. RedHat Advisory.
A lyrical digression. Among the most important events in 2014 was the OpenSSL flaw, currently known as Heartbleed. It was quite interesting to watch the development—how a completely technical topic was first discussed on tech forums and editions, then came out to the completely non-tech media outlets. And with good reason! The problem indeed affected everyone: business owners, admins, developers and users alike. In other words – a lot of people and businesses. It became necessary to explain to ‘non-techy’ people, such as business owners, again, or top managers, what the buzz was about and what should be done, in simple and plain language.
Now, you come to such a ‘non-tech’ person and say, Heartbleed is important because the OpenSSL where the bug was found is used everywhere. Your website may be vulnerable, your environment may be vulnerable, even your Yahoo mail may be flawed. What does “flawed” mean? It means that they can steal your password and mail and they can plant some malware on your side. They can also steal your sensitive data. So what is there to do? Patch and check everything, change all passwords and improve your infrastructure’s defenses, since it’s neither the first nor the last time you will see such a flaw.
And the person who has no knowledge of science gets impressed, comprehends everything and asks you: where in blazes were you, techies, before? Why were you not sounding the alarm? Why were there no announcements in “Times” and on CNN? Then it appears in most cases that everything was there: alarms, announcements, discussions and research. Technical ones. Seriously, in order to evaluate the scope of a certain flaw, we need to know what makes the bug, the attack scenarios, and be able to calculate possible damage (or, simply put, what can be stolen and how much).
Now, these are tasks so different that in most cases different people work on them, and even if they find a way to join forces, they don’t care about explaining the nature of the problem to a wide audience.
That’s why for non-tech people, problems like Heartbleed seem to appear out of the blue.
Now, the GNU C Library flaw is in the “techy” stage right now. The vulnerability had been discovered, its influence on the security is proven, even some attack scenarios have been envisioned already. But it’s still unclear how it can turn out in real life, within a real infrastructure and what scope the damage could have.
An unprepared person will most likely see the problem’s description this way:
I’ll try to explain what happened to GLIBC as easily as possible. First of all, I have to state I’m not a coder. My job is to popularize complex things to a wider audience. This blog is barely a place where the GLIBC technical details are appropriate. I’d like to see your comment below the text. How would you solve the task “explain it simply”? What would you say differently? Have I explained everything properly? Marketing people use an easy tool; they write an important concept thrice, making a short text, then a longer one, and then the longest one. Finally, according to the situation, they will use one of them. I’ll try it that way.
For non-tech people, problems like #Heartbleed seem to appear out of the blue. In fact they don’t.
Tweet
The short version:
Update the software on a PC and servers regularly. It improves the security. Recently there was a serious bug in Linux found, and it should be patched as well, if you are using Linux.
The longer one:
The GLIBC flaw affects almost all Linux-based systems; in theory, it allows the running of an arbitrary code, so it is quite dangerous. There are no menacing real life attack scenarios yet, but it doesn’t mean they will not be appearing in the future. So the software should be updated regularly.
The longest variant:
GLIBC is a standard C library for all Linux-based operating systems. It contains a large number of programs performing standard tasks like displaying something to monitor, allocating an area in memory for an application, etc. It is used by those who write Linux programs; instead of writing a unique code for every task, they “take” a certain program from the GNU C Library. Thus developers save on time and provide a standardized approach to performing typical tasks.
So what is most important here is to understand that GLIBC affects a huge number of programs: if there is an error in the code within this library, it can affect the performance of a program that contains this code. And if the code is vulnerable, so are the programs using it. See?
Let’s move on. This vulnerability had been discovered in the function family, gethostbyname. These are small programs from the GLIBC collection that perform a single simple task: getting a website name on input (www.kaspersky.com). They yield its IP address in the form: 123.123.123.123. If your program needs to perform such a task (and almost every network program needs it), you’re addressing this function.
The problem is that the function isn’t checking the input well enough. How is it going usually? A program receives some data on input and wants to write it into the specifically allocated area in memory, an area of a certain size. It does not check, at all, whether the data is going to fit there. So what? Data is also written outside of the allocated zone. Why is this bad? First, other data related to this or some other program can be contained there already, so that program may stop working. This is the best-case scenario. At worst, the data can replace the code which is supposed to be executed. And if we manage to “feed” the buggy program a piece of code and make sure it is written the right way to the right place, we can run our own program (an arbitrary code) on a PC without asking anyone.
Now, we’ve shown the problem. What are the attack scenarios? The Qualys researchers have shown how an arbitrary code can be run exploiting this flaw, using this flaw, when Exim (a mail client) addresses gethostbyname functions. Theoretically we can attack the mail server of a company using Exim and run an arbitrary code there that way. Can we steal corporate mail or access important documents or inflict some other real damage? Theoretically, we can. But considering all details and provisions (not mentioned here), we can’t evaluate the danger level of using this bug to still the real-world data. For now.
And that’s how GLIBC is different from Heartbleed. With that bug we had an obvious and well-defined peril. This current threat is purely theoretic. While describing the vulnerability, I omitted a number of important provisions: the gethostbyname functions are obsolete already, the conditions needed to create the buffer overflow situation here are extremely specific and when we try to fit the flaw to the programs using this function, things get really complicated.
Again, for now. There is a possibility that someone (hopefully, a security researcher and not a criminal) will find a way to crack the Linux servers in droves using this vulnerability. Then this vulnerability will be covered by Forbes, US Weekly and CNN, while Fox News will run a talk show on the matter. Predictably, everyone will say, how come that bug has existed since 2000 and nobody noticed? But it will be too late. Hence the conclusion: Get things patched in time. The discovered vulnerabilities should be covered even if the menace looks ‘phantom’ – for now.
Tips