The past few days Hawaii Emergency Management Agency became popular in the news due to a false emergency alert which was a result of human error along with badly designed UI. This media attention brought to light some bad OPSEC practices from this agency.

News agencies start digging for content for the Hawaii Emergency Management Agency and brought up a news article from 22 July 2017 titled “North Korea Missile Threat ‘Unlikely,’ But Hawaii Prepares”. This news article from Associated Press included some high resolution photos. One of them was the following which shows Jeffrey Wong, the Hawaii Emergency Management Agency’s current operations officer and it was taken at the agency’s headquarters in Honolulu on 21 July 2017.

The photo reveals various details about the agency including the software used, internal discussion board, naming conventions, etc. However, the following close up gives some really interesting insights.

On the far right in the above photo we have a paper with the SWP (State Warning Points) call list that includes phone numbers per region. Then each of the two monitors has a Post-It note. The right one (WP2) says “Sign out” and the left one (WP1) says “Password Warningpoint2”. So, multiple operational security failures in this agency as well as the AP photographers and journalists that did not censor all those sensitive details from the photos before publishing them.

2018 started with some unique low-level exploitation techniques disclosure. People that never cared about processor architecture suddenly explain how speculative execution, advanced side-channel analysis, and cache level works in modern high-performance processors, others confuse the different architecture design flaws, media and software vendors are heavily controlled by big processor manufacturers, Linus accepts patches with up to 30% performance impact without a question, and within that chaos we still miss some crucial details. In this post, I will give my thoughts on the following five domains regarding the Meltdown & Spectre exploitation.

Real-world impact

The victims/targets

Media manipulation

Nation-state

Mitigations

Real-world impact
For any of the disclosed exploitation methods, there is very limited real-world impact (yes, even for the JavaScript one on browsers with SharedArrayBuffer). The reason for this is that those attacks cannot be easily automated. They are definitely feasible, but they require manual intervention to provide any value to the attacker. Consequently, their use would only be useful on targeted attacks. But even in this case, why would an attacker prefer to read arbitrary memory using this extremely slow technique instead of exploitation a privilege escalation vulnerability and get much faster access to all system resources? One could argue because it is more covert. Well, there are some actual attack use cases and this is my next domain.

The victims/targets
The only real victim that this attack is more valuable than privilege escalation attacks is shared hosting providers. Whether that is virtual machines, containers, or anything similar. Those exploitation techniques break the sole business model of those companies. Huge players like Amazon, Google, Microsoft, etc. are selling exactly what Meltdown & Spectre proved that it doesn’t exist, high quality isolation between shared resources. And that brings us to the next domain.

Media manipulation
All of those big players, including manufacturers such as Intel, AMD, and the rest of the affected vendors, did a first-class crisis management when it comes to managing the reputation impact and press statements. They should probably be giving trainings on how to do this. You would expect that an attack that obliterates your core business selling point would result in massive stock price drops, media chasing the board all over the world, people moving away from those vendors, executives getting fired… Yet, nothing happened. From the business perspective this is a remarkable work of crisis management, but from the consumer perspective this is an alarming level of media manipulation power.

Nation-state
Talking about power, let’s talk about nation-states. Those attacks were not really new. Dave Aitel released this Immunity paper from 2014 that pretty much implements a variant of those exploitation techniques. If we move even further back, we have this paper from 1995 which goes through multiple security flaws of the x86 architecture, including the pre-fetching one. The latter document also contains an interesting sentence in its introduction.

“This analysis is being performed under the auspices of the National Security Agency’s Trusted Product Evaluation Program (TPEP).”

So, we know that NSA knew about those design flaws for at least 23 years. Realistically speaking, it is safe to assume that they would have tried to exploit them. Recently after the public disclosure of the attack the ShadowBrokers started offering some (allegedly) 0day exploits for those flaws claiming to be part of NSA’s toolkit.

Just to be clear, I totally endorse NSA, or any other nation-state for that matter, not disclosing them. They had already disclosed the research paper so the entire world knew about them (including Intel, AMD, and the rest). A tool that allows you to bypass the false sense of memory isolation a cloud provider offers would be extremely valuable for any offensive security team. It is the companies’ fault that they did not fix it. Nevertheless, it was worth mentioning. And talking about fixing…

Mitigations
There are a few different mitigations being proposed or already implemented. Let’s briefly go through them…

On the OS side we have we the KAISER/KPTI implementation which basically separates the kernel and user-space pages requiring TLB flushes (reloading of CR3 register or the use of Process Context Identifier (PCID) where available). Depending on the application, this can have major performance impact but, on the other hand, it also prevents a large number of exploitation techniques that were already used in the wild. So, security wise it is great, but business wise it will require extra funding for scaling for most companies. And guess what? The manufacturers of those processors are not held accountable for this (they should in my opinion as it was a known issue for decades).

The other proposed mitigation was the use of LFENCE instruction to literally stop speculative execution on specific code paths. A clever approach which however is hard to implement and deploy in the real world if you don’t want to have massive performance impact.

Intel issued a microcode update that also adds some new capabilities. Those are the IBRS (Indirect Branch Restricted Speculation), STITBP (Single Thread Indirect Branch Prediction), and IBPB (Indirect Branch Predictor Barrier). All can be used to control when branch prediction and indirect jumps are allowed. However, it brings another interesting attack vector… If Intel can dynamically reprogram their processors via a UEFI channel, maybe attackers can too. Sounds like an interesting research area now that the updates are out.

The last one is to recompile the code with a compiler that adds the concept of “return trampolines” (retpoline) which ensures that indirect near jumps and call instructions are bundled with some details about the target of the branch to avoid the cases of branch target injection attacks of Spectre. Again, good idea but expecting to recompile all binaries using this is not a trivial operation.

As a conclusion, the Meltdown & Spectre exploitation techniques sound like one of the biggest cover-up stories of the infosec community. Known for 20+ years, breaking core business models, nation-states researching them for decades… And yet… No repercussions or even media pressure to any of the involved parties behind them.

A few days ago I posted a blog post about a cryptominer that is becoming very popular. Yesterday I had a look at two new samples (this and this) which are slightly different. Here is the downloader of the first one.

It uses a slightly more clever logic that will execute either “wget” or “curl” instead of both, and it is going to start four processes of the cryptominer from /tmp/x, /dev/shm/x, /var/tmp/x, and ./x. All of them pointing to 206.253.164.158 (privpool.mone.ro.lt) for Monero (XMR) mining. The cryptominer used was uploaded on a server at .x/xmrt.priv and it is the “Tiny XMR mooner” which is only about 500KB in size. Below you can see its command line options.

The downloader of the second sample is a combination of the above and the one shown in my previous post. The cleanup code in the beginning is similar to the old sample but the execution is more like the one listed above. Also, it is worth noting that it is using exactly the same miner from an identically named location on a web server and uses the same Monero (XMR) server for mining. This however, starts three processes from /tmp/systemd, /dev/shm/systemd, and ./systemd as you see below.

The expected response is a JSON encoded string that includes the job that the miner will start mining. You can see how this response typically looks like below.

{"jsonrpc":"2.0","result":{"job":{"blob":"<HASH OF THE JOB>","target":"<TARGET HASH>","job_id":"<UUID IF THE JOB>","time_to_live":5},"status":"OK","id":"<HASHED ID>"},"id":1,"error":null}

The miner is a 32-bit statically linked stripped ELF binary. On startup it copies itself using clone() to start a new miner background process which (for this sample) was hardcoded to always be named “sh”. The miner also checks if the “/tmp/.xmrt” file exists, this is the lock file of the miner. If it’s already there, no new process will start. Just like I did in the previous cryptominer post, here is a YARA rule that you can use to scan your system for the existence of the Monero cryptominer described here.

Cyber-crime is a massive ecosystem and social media plays a key role in it. One way to stop them would be to disrupt their supply chain and this is what this post is about. Most cyber-crime groups utilize verified social media accounts to operate below the radar while executing their illegal activities. Namely, here are a few common reasons why cyber-criminals buy and use verified social media accounts.

Anonymously set up marketplaces on social media platforms like Facebook

The above are quite clear indicators that this area of cyber-crime will keep on growing. Some will be developing verified social media accounts and others will be buying them for uses like the ones described.

This underground market has been expanding so rapidly that many threat actors are developing and selling malicious tooling known as “Turboer”. This type of software is designed to exploit popular social media platforms in order to claim high-value account names, and assign them to a verified account. Typically, cyber-criminals subsequently sell those verified accounts for much higher prices.

The reason I made this post was my initial comment, if we would like to disrupt the supply chain of cyber-criminals this is an area we need to target. As more and more cyber-criminals utilize those verified social media accounts for malicious purposes, the demand increases, and the ecosystem keeps on growing.

While reading through Linux kernel’s ChangeLog I came across this one. I was unable to find any CVE ID for this vulnerability reported by Håkon Bugge on 6 December 2017. The vulnerability was discovered by Google’s syzkaller kernel fuzzer and reported in syzkaller719569. The vulnerable code starts in the setsockopt() system call implementation for RDS (Reliable Datagram Sockets). This code is located at net/rds/af_rds.c and here is the code path we are interested in.

Before we check those two options, it is important to see some specific value in “rds_sock” structure. This structure is defined in net/rds/rds.h header file. The key here is that “rs_transport” pointer in “rds_sock” structure can be NULL.

Back in rds_setsockopt(), there are two options with very similar code. The RDS_GET_MR and RDS_GET_MR_FOR_DES which will both result in a code that uses copy_from_user() to copy the “rds_get_mr_args” or “rds_get_mr_for_dest_args” structure to the kernel space, and then invoke __rds_rdma_map() routine to do the mapping.

If we now move to __rds_rdma_map() in net/rds/rdma.c we will quickly notice what’s the issue that triggers the vulnerability. The code will try to access the get_mr() callback function from the “rs_transport” pointer which as mentioned earlier can be unset (NULL), resulting in a NULL pointer dereference. This code path can be reached from the previously described setsockopt() system call options.

Most JavaScript malware authors try to obfuscate their code by adding a lot of unused code as well as randomized variable names and simple encoding and decoding fucntions. Lastly, they typically remove all spaces and newlines. For example, “Сопроводительные.xls.js” is a JavaScript malware sample uploaded to VirusTotal about 2 hours ago. In this malware sample the code was obfuscated using Dean Edwards JavaScript packer. The malware is pretending to be a Microsoft Excel file but it is actually a JavaScript file. Here is how the sample looks like.

We can try to understand what it does and probably spend hours of analysis or we can do something much simpler. Run the obfuscated code through some prettifier, for example something like jsbeautifier.org. Then, just scrolling through the prettified JavaScript code you can easily see some variable that contains a some large string. In this case, just by looking at it it looks like a Base64 encoded string.

If we just copy this Base64 encoded string and decode it, we will get the following malicious PowerShell script that downloads and executes a variant of Smoke Loader malware from microdocs.ru.

So, when reverse engineering a JavaScript malware, before trying to understand the whole obfuscated code, look for any large strings that are standing out. In this case the above analysis took me less than 5 minutes and as you can probably guess trying to de-obfuscate the entire obfuscated code would have taken at least a couple of hours. Hope that you found this trick useful. :)

I recently saw this interesting malware sample. The uploaded file is nothing more than a downloader for a cryptocoin miner. The downloader (logo.sh) starts by removing “/var/tmp/fyvxsztqix.conf” and “/var/tmp/sshd” which means that it is probably previously installed malware.

#!/bin/sh
rm -rf /var/tmp/fyvxsztqix.conf
rm -rf /var/tmp/sshd

After this it runs a series of cleanups to ensure that the system not running another instance of the miner. After it kills all of the running miner processes, it will start the downloader as you can see below.

The code will first attempt to download the configuration file (kworker.conf) and store it in “/var/tmp/mwyumwdbpq.conf” file. Note that it will try to do it both using wget and curl to ensure that it will work even if one of the tools is not available.

After this the downloader will check “/proc/cpuinfo” and depending if the processor supports AES-NI (Advanced Encryption Standard New Instructions) or not, it will download either “kworker” or “kworker_na”. The downloaded file will be stored in “/var/tmp/atd” file.

Lastly, the downloader will discover the amount of available cores and it will start the downloaded file using arguments “-c” for the configuration file and “-t” for the number of threads to start in order to utilize the CPU resources of all the available cores.

Inspecting the binaries makes it obvious really fast that this is cpuminer version 2.3.3. An open source miner available on GitHub. It is worth noting that although the latest release of cpuminer is 2.5.0 (released in 22 June 2017), those two samples were compiled on 29 October 2017 (kworker_na) and 31 October 2017 (kworker) respectively, using version 2.3.3 which was released on 27 February 2014. Below is the help message of the cpuminer version 2.3.3 (kworker).

There were no modifications in either of the binaries. They were just compiled versions of this open source miner software. According to some sources this is a result of malware infections based on exploitation of the CVE-2017-5638 (Apache 2 Struts remote code execution) vulnerability. Regarding the network indicators, there is no clear correlation among them. Here is a brief overview of them.