xorl %eax, %eax

SharkFest’17 Europe

leave a comment »

This was my first time in SharkFest Europe, a conference that aims in knowledge and experience sharing among Wireshark developers and power users. The event took place in the second week of November 2017 in Estoril, Portugal. An truly beautiful location with interesting history.



The event was split in three simultaneous sessions but unfortunately, only one of the three conference rooms were recording the talks. You can find those recordings as well as some of the slides from other presentations here and here. Below is a list of the ones that I attended.

  • Keynote: Wireshark: Past, Preent & Future – Gerald Combs & Friends
  • Using Wireshark to Solve Real Problems for Real People: Step-by-Step Case Studies in Packet Analysis – Kary Rogers
  • Troubleshooting WLANs (Part 1): Layer 1 & 2 Analysis Using AirPcap, Wi-Spy & Other Tools – Rolf Leutert
  • Troubleshooting WLANs (Part 2): Using 802.11 Management & Control Frames – Rolf Leutert
  • SMB Handshake: The Devil Lies in the Detail – Eduard Blenkers
  • SSL/TLS Decryption: uncovering secrets – Peter Wu
  • extcap – Packet Capture beyond libpcap/winpcap: Bluetooth sniffing, Android dumping & other fun stuff – Ronald Knall
  • Turning Wireshark into a Traffic Monitoring Tool: Moving from packet details to the big picture – Luca Deri
  • The Network is Slow! Finding the Root Cause of Slow Application Performance – Lorna Robertshaw
  • How Did They Do That? Network Forensic Case Studies – Phill Shade
  • Developer Bytes Lightning Talks-Usage Track – Wireshark Core Developers
  • Real World Troubleshooting Tales – Graeme Bailey
  • Sneaking in by the Back Door – Hacking the Non-Standard Layers with Wireshark – Phill Shade



Both the location and the event were great. Some of the attendees were network analysts with decades of experience. If you are interested in network analysis (including security as the exact same principles apply there too), SharkFest is a very nice conference to attend (hint: it is taking place on different place every year).

Written by xorl

November 19, 2017 at 17:42

Posted in conferences

Threat Analysis: How fraudsters avoid fingerprinting/detection

leave a comment »

For most online businesses nowadays there is at least some method of fraud. Most companies are trying to mitigate that by implementing “smart” fingerprinting based on the web browsers or clients. Unfortunately, not many of them are actually researching to find out what “bad guys” are using out there. This will be a gentle introduction to a couple of anti-detection tools used by cyber-criminals.



The, so-called, anti-detect web browsers have been around for at least the past few years. Those are typically web browser profile generators that randomize the variables that the majority of the fraud detection engines use (user agents, plugins, version, language, platform, timezone, etc.). An easy way to test your organization against this is to simply use it and see how your fraud engine behaves. Using the most popular one, the “AntiDetect”, it is relatively easy to do so due to the business model of its author. The threat actor behind “AntiDetect” web browser offers older versions for free while asking for $399 for buying the latest or a $99/month subscription model.



Before moving to the other anti-detection methods, it is worth noting that “AntiDetect” is a very popular software among Russian speaking threat actors and it has been active since May 2014. Until recently, the servers hosting this software were based in Russia but recently moved to Belize. Below you can see some screen captures of this from the community edition of RiskIQ.



In a recent (a few months ago) research on this topic I observed a switch of fraudsters from tools like “AntiDetect” to fully customized virtual machines (VM) like “FraudFox”. This one, “FraudFox”, is a Windows based VM that includes an anti-detection web browser profile generator (just like the one described above), but also some system settings and pre-installed tools to reduce detection. Furthermore, the authors of this tool say that it should be used as “software in a briefcase” by starting it when doing some fraud activity and then destroying the VM along with all of its evidence. Unlike “AntiDetect” this one is offered in a subscription based model only for $99/month.



And “FraudFox” is not the only such VM, there are more and more being sold out in the underground for different systems and configurations. All of them, though, follow similar techniques and anti-detection tools. Here you can see another one which is less popular than the above.



The past 1.5 years there was also a rise of mobile applications that offer similar services, usually exclusively to Android platform. You can see a (censored) example of such an application below.



Regardless of the above tooling that fraudsters use to evade fraud engines, it is important to continuously monitor and study the TTPs (tactics, techniques, and procedures) that those cyber-criminals employ. After studying them for a while you will definitely see some patterns that could be employed in your counter-fraud detection mechanisms. For example here are some common ones.

  • Most fraudsters will login to a stolen account, check the location of the victim and re-login via SOCKS, RDP, or VPN from the same location as the victim before committing any fraudulent activity
  • Most fraudsters will change the contact details of a stolen account, and then make a very small price transaction with a stolen credit card
  • The fingerprinting of the fraudsters will vary a lot compared to legitimate users due to the randomization of all the parameters

The above are just a couple of examples. Each business should do their own independent research on how fraudsters attack them and abuse their services to understand what preventive and detective controls they can implement to reduce their attack surface.

Written by xorl

November 18, 2017 at 17:30

CVE-2017-15306: Linux kernel KVM PowerPC NULL pointer dereference

leave a comment »

This vulnerability was reported by Greg Kurz on September 2017. The vulnerability is specific to PowerPC KVM (Kernel-based Virtual Machine) with its code being in arch/powerpc/kvm/powerpc.c source code file. Below is the vulnerable IOCTL (Input/Output Control) function from this file.

int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
    ...
	/* Assume we're using HV mode when the HV module is loaded */
	int hv_enabled = kvmppc_hv_ops ? 1 : 0;

	if (kvm) {
		/*
		 * Hooray - we know which VM type we're running on. Depend on
		 * that rather than the guess above.
		 */
		hv_enabled = is_kvmppc_hv_enabled(kvm);
	}
    ...
	switch (ext) {
    ...
	case KVM_CAP_PPC_HTM:
		r = cpu_has_feature(CPU_FTR_TM_COMP) &&
		    is_kvmppc_hv_enabled(kvm);
		break;
    ...
}

What Greg Kurz discovered was that if the file descriptor of the global KVM was used (that is, /dev/kvm) then “kvm” pointer is NULL. This means that the first “if” condition will fail but if the IOCTL is called with “KVM_CAP_PPC_HTM” then “kvm” will be invoked by is_kvmppc_hv_enabled() resulting in a NULL pointer dereference. You can see the equivalent code from arch/powerpc/include/asm/kvm_ppc.h here.

static inline bool is_kvmppc_hv_enabled(struct kvm *kvm)
{
	return kvm->arch.kvm_ops == kvmppc_hv_ops;
}

extern int kvmppc_hwrng_present(void);

Greg Kurz also included a simple PoC trigger code that basically opens the global KVM file descriptor and then calls the above IOCTL with the “KVM_CAP_PPC_HTM” extension. You can see that PoC code below.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/kvm.h>

main()
{
    int fd = open("/dev/kvm", O_RDWR);
    ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
}

As you can easily guess, the patch for this vulnerability was to reuse the “hv_enabled” variable which is set with the same value but only if “kvm” is not NULL as we saw above. You can see the patch here.

 	case KVM_CAP_PPC_HTM:
-		r = cpu_has_feature(CPU_FTR_TM_COMP) &&
-		    is_kvmppc_hv_enabled(kvm);
+		r = cpu_has_feature(CPU_FTR_TM_COMP) && hv_enabled;
 		break;

Written by xorl

November 18, 2017 at 00:43

Posted in vulnerabilities

OPSEC fail: GearBank International

leave a comment »

In this post we will explore a case of an operational security mistake reported by x0rz in September. This one is for an illegal performance enhancing drugs darkweb site called GearBank International (abbreviated as GBI). Okay, so let’s see how you can discover the real address and details of this cyber-crime website.



Following the same technique and using Censys.io as described in “OPSEC fail: TanieRC”, when looking for gearbankbaesqqv7[.]onion you discover that the web server was accessible from clearnet too, leaking the real IP address of the server.



Below you can see the information that we learned from this operational security failure. That information can be very valuable for law enforcement agencies working on cyber-crime.

IP address      : 195.189.227.135
Hostname        : testgb
Onion address   : gearbankbaesqqv7.onion
Hosting provider: Omnilance Ukraine
Web server      : Apache 2.2.22
Email address   : gearbankintl@tutanota.com

 
By pivoting on the contact email address we can collect even more information on this cyber-criminal. Using basic OSINT methodologies, we quickly identified that the same email address has been used in the following domains which were pointing to the same illegal website (this time hosted in Cloudflare).

  • gearbankintl[.]cc
  • gearbankintl[.]pw

In addition, a second email address was used in there, it was the gearbakintl@countermail.com. Pivoting with that email did not reveal any other domains or information. Moving to RiskIQ community edition platform, we can see that the earliest date for those domains is 15 November 2015. The most notable discovery however was the historical data on WHOIS for that domain. Since the very beginning it was registered by Dimitry Pshyck using gbi@tuta.io email address.



By pivoting on the email address that was used for the registration of those domains, we can see that it was also used to register saizin[.]cc in July 2016. You can see this below.



This website was also used for selling illegal performance enhancing drugs. Although the website is no longer live, using Archive.org we can find a snapshot from 17 November 2016. It doesn’t include most of the content but we can see some interesting details such as that it was using OpenCart, and it was affiliated with Eroids and MuscleGurus websites. Exactly like GBI.



Looking for the name, phone, and address did not result in any notable discovery. However, from this very basic OSINT collection, we were able to associate all of the following data with a cyber-criminal that has been selling illegal performance enhancing drugs since 2015.

IP address      : 195.189.227.135
Hostname        : testgb
Onion address   : gearbankbaesqqv7.onion
Hosting provider: Omnilance Ukraine

Email address   : gearbankintl@tutanota.com
Email address   : gearbakintl@countermail.com
Email address   : gbi@tuta.io
DNS name        : gearbankintl.cc
DNS name        : gearbankintl.pw
DNS name        : saizin.cc
Name            : Dimitry Pshyck
Phone number    : +380.957026548
Address         : 7 Kryshatic #30 Kiev 010020 Ukraine

Written by xorl

November 16, 2017 at 23:32

Posted in opsec

Cyber Security Week 2017

leave a comment »

From 25 until 29 September 2017 the Netherlands had its second international Cyber Security Week (abbreviated as CSW2017). It was a huge event that took place in multiple locations within the Hague and included over 80 security related presentations, trainings, and workshops. Unfortunately, I was able to be there just for the last day. So, here is what I attended in that last day and how it went… Note that all of the events I attended where in the HSD (Hague Security Delta).



As expected, the audience was more business and less technical oriented. For this reason the talks were also adjusted accordingly. So, here is a quick summary of the events I attended at CSW2017.

  • Cyber Threat Intelligence – Innovating Towards a Mature CTI Capability (TNO)
  • Cyber Threat Intelligence in practice: insights from a community-driven approach (EclecticIQ)
  • I Stopped Being Surprised, and Started Being Prepared (RedSocks Security)
  • SOC maturity as a weapon in fighting cyber crime (De Volksbank)
  • Multinational Cyber Defence Capability Development: NATO Communications and Information Agency: Introduction to MNCD2 program (NATO Communications and Information Agency)
  • Introduction to Dynamic Network Enumeration (DyNE) (NATO Communications and Information Agency)
  • Introduction to Semi-automatic response (SAR) (NATO Communications and Information Agency)
  • Learn How to Eliminate Insider Threats (Dtex)



The HSD was really nice and I got to meet a few very interesting people. The events themselves had some promotion parts, but nothing extreme. It was not really technical but definitely had useful information, especially if you are a security professional. Also, considering that this was a free event, the organization and content was very good. So, if you wanted some in-depth technical content or advanced attack/defense techniques, then don’t go to CSW. If you want to get an idea of where the security industry is moving towards, what’s going on in the enterprise, military, and government security sectors, then you should go.

Written by xorl

November 16, 2017 at 20:47

Posted in conferences

CVE-2017-16650: Linux kernel WWAN (3G/LTE/?) devices DoS

leave a comment »

This is another vulnerability that was discovered by Google’s unsupervised kernel fuzzer (syzkaller). The vulnerability was reported by Andrey Konovalov to the Linux kernel project. The source code for the Linux kernel driver for WWAN (3G/LTE/?) devices is using the QMI (Qualcomm MSM Interface) along with AT management commands and it is located at drivers/net/usb/qmi_wwan.c.

static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
{
    ...
	struct usb_cdc_ether_desc *cdc_ether;
    ...
	struct usb_cdc_parsed_header hdr;
    ...
	/* and a number of CDC descriptors */
	cdc_parse_cdc_header(&hdr, intf, buf, len);
	cdc_union = hdr.usb_cdc_union_desc;
	cdc_ether = hdr.usb_cdc_ether_desc;
    ...
	/* errors aren't fatal - we can live with the dynamic address */
	if (cdc_ether) {
		dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
		usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
	}
    ...
}

What you see above is the bind function for the WWAN/QMI devices. The value of “cdc_ether->wMaxSegmentSize” is derived from “hdr.usb_cdc_ether_desc”. CDC (Communication Device Class) is a USB device communication class and “usb_cdc_ether_desc” is the implementation of the “Ethernet Networking Functional Descriptor” from CDC 5.2.3.16 specification.

/* "Ethernet Networking Functional Descriptor" from CDC spec 5.2.3.16 */
struct usb_cdc_ether_desc {
	__u8	bLength;
	__u8	bDescriptorType;
	__u8	bDescriptorSubType;

	__u8	iMACAddress;
	__le32	bmEthernetStatistics;
	__le16	wMaxSegmentSize;
	__le16	wNumberMCFilters;
	__u8	bNumberPowerFilters;
} __attribute__ ((packed));

In the CDC 5.2.3.16 specification, “wMaxSegmentSize” is defined as “The maximum segment size that the Ethernet device is capable of supporting. This is typically 1514 bytes, but could be extended (e.g., 802.1d VLAN)”. However, setting this to 0 will result in a division by zero that will consequently cause a kernel crash as shown below, making this a kernel DoS vulnerability.

divide error: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bef5c00 task.stack: ffff88006bf60000
RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
RSP: 0018:ffff88006bf67508 EFLAGS: 00010246
RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34
RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34
RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881
R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003
R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0
Call Trace:
 usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x522/0x740 drivers/base/dd.c:557
---[ end trace 834034903d6f2b37 ]--- 

The vulnerability was that in case of “cdc_ether->wMaxSegmentSize” being zero, “dev->hard_mtu” would also be initialized with 0. Then, once usbnet_update_max_qlen() is invoked to update the “dev->hard_mtu” value on the kernel’s USB speed, it will attempt to divide it with “MAX_QUEUE_MEMORY” leading to a division by zero.

/*
 * Nineteen USB 1.1 max size bulk transactions per frame (ms), max.
 * Several dozen bytes of IPv4 data can fit in two such transactions.
 * One maximum size Ethernet packet takes twenty four of them.
 * For high speed, each frame comfortably fits almost 36 max size
 * Ethernet packets (so queues should be bigger).
 *
 * The goal is to let the USB host controller be busy for 5msec or
 * more before an irq is required, under load.  Jumbograms change
 * the equation.
 */
#define	MAX_QUEUE_MEMORY	(60 * 1518)
    ...
/* must be called if hard_mtu or rx_urb_size changed */
void usbnet_update_max_qlen(struct usbnet *dev)
{
	enum usb_device_speed speed = dev->udev->speed;

	switch (speed) {
	case USB_SPEED_HIGH:
		dev->rx_qlen = MAX_QUEUE_MEMORY / dev->rx_urb_size;
		dev->tx_qlen = MAX_QUEUE_MEMORY / dev->hard_mtu;
		break;
	case USB_SPEED_SUPER:
	case USB_SPEED_SUPER_PLUS:
		/*
		 * Not take default 5ms qlen for super speed HC to
		 * save memory, and iperf tests show 2.5ms qlen can
		 * work well
		 */
		dev->rx_qlen = 5 * MAX_QUEUE_MEMORY / dev->rx_urb_size;
		dev->tx_qlen = 5 * MAX_QUEUE_MEMORY / dev->hard_mtu;
		break;
	default:
		dev->rx_qlen = dev->tx_qlen = 4;
	}
}

As you can easily guess, the fix for this vulnerability was to simply check that “cdc_ether->wMaxSegmentSize” contains a non-zero value before updating “dev->hard_mtu” with that value. You can see the patch here.

 	/* errors aren't fatal - we can live with the dynamic address */
-	if (cdc_ether) {
+	if (cdc_ether && cdc_ether->wMaxSegmentSize) {
 		dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
 		usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
 	}

Written by xorl

November 15, 2017 at 21:19

Posted in vulnerabilities

Threat Analysis: Account Takeovers & Cyber-Crime

leave a comment »

Account Takeover (ATO) is a simple type of attack that has tremendously increased over the last few of years. Here we will be focusing on the ATO using credential stuffing as it is the most common method employed today. The reasons are the amount of insecure systems available over the internet as well as the constantly increasing amount of data breaches of large user databases. In this post, I will try to guide you through account takeover/credential stuffing attacks from the cyber-crime perspective. But let’s start with one of my favorite quotes from “The Art of War” by Sun Tzu.

If you know the enemy and know yourself, you need not fear the result of a hundred battles.
If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.
If you know neither the enemy nor yourself, you will succumb in every battle.


Today most enterprises are good on the first part of this (knowing themselves) and this is what they are using to drive their security initiatives and controls. However, they fail when it comes to knowing their enemy. The aim of this post is to help you learn your enemy when it comes to ATO.

Compromised accounts during the first three months of 2016-2017.
Source: Microsoft Security Intelligence Report Volume 22


ATO is an attack where an adversary takes control of a victim’s account, typically by discovering the account’s credentials. Although this can be achieved via traditional bruteforcing, it is not very efficient. So, most cyber-criminals typically implement this attack using credential stuffing, and specifically, the following process.

  1. Collect valid credentials for real accounts
  2. Try to reuse those against the target website(s)
  3. Verify/check if those accounts include payment methods (e-wallets, credit cards, etc.)
  4. Sell the discovered accounts to black markets

Simple, right? Maybe too simple. And this is one of the reasons why it is so effective. It is simple and profitable. Now, we need to understand every single one of those four steps to see how our adversaries operate. This is what we will do next.

1. Collect valid credentials for real accounts
The terminology that cyber-criminals use when it comes to this stage include the following three terms.

  • Anti-public or private: A list of credentials that is not publicly available.
  • Public: A list of credentials that is publicly available, typically result of a major data breach.
  • Combo: This has two meanings depending on the context. In some cases it means that it is a list of a username/password combinations. And in other cases (most commonly) that it is a combination of multiple private and/or public lists.

Getting a, so-called, public list is relatively simple. Databases of high-profile data breaches are available on the internet to anyone. There is not much explanation required here.



But what about the private/anti-public ones? For those there is a very common workflow that cyber-criminals use. They are collecting actual credentials from insecure websites that suffer from simple vulnerabilities, typically SQL injections. Namely, one of the most popular underground tools for this is the “SQLi Dumper”.



Following the tabs from left to right, here is what cyber-criminals do using the above tool.

  1. Import a series of Google dorks that are searching for websites with parameters that potentially have SQL injection vulnerabilities.
  2. Collect the exploitable websites discovered.
  3. Select the interesting columns (typically username, password, and email).
  4. Dump the results of all of them to a list.



The above is just one method of creating a private/anti-public list but it is worth mentioning it as it is the most common method used nowadays. Furthermore, it is also worth noting that cyber-criminals are also exploiting this demand by identifying and selling to other cyber-criminals collections of Google dorks they can use for those list generations.



Some stop at this stage and they just sell the generated lists of credentials to other cyber-criminals. However, this is not as common as completing the entire lifecycle of an ATO attack.



2. Try to reuse those against the target website(s)
3. Verify/check if those accounts include payment methods (e-wallets, credit cards, etc.)

The reason why both steps are merged here is because the vast majority of the tools that cyber-criminals use for this are performing both actions. Typically, cyber-criminals collect on their own or buy from black markets a large amount of HTTP and/or SOCKS proxy servers which are required by those tools. Then they just import the lists of credentials and proxies and they initiate the attack. The tools will randomly select different proxy servers for each attempt bypassing throttling controls of most websites.



As you can see above (this was developed for Netflix), almost all of those tools are developed for specific target websites. Usually, most of them will try to verify parameters of the account (such as existence of credit card, balance, e-wallet, etc.). This is the reason why you will often see those being referred to as “checker”, “Brute & Checker”, or “B/C” software.



One of the most interesting such software is the UBC (Universal Brute Checker). This is a modular Russian ATO software which can be tuned to support any website with easily pluggable modules for additional functionalities.



4. Sell the discovered accounts to black markets
The last stage is of course the selling of the “verified” accounts that have been taken over using the credential stuffing methodology. There are multiple black markets for accounts of any imaginable website. However, depending on the data that those accounts grant you access to, their prices range from less than $1 to over $200 per account.



Buyers of those stolen accounts use them for a large variety of cyber-crime activities. For example, some common such activities are the following.

  • Stealing money (if the accounts are connected to some type of payment)
  • Spear-phising (using details derived from the accounts)
  • Identify theft (using details derived from the accounts)
  • Fraudulent transactions (since valid accounts are less restrictive than newly created ones)

Hopefully this introduction gave you some visibility on the enemy’s intention and capabilities. Going back to the Sun Tzu’s quote from the beginning, using this knowledge you can adjust your security controls and initiatives accordingly. But remember, this is just a gentle introduction to ATO via credential stuffing and cyber-crime. There is an entire cyber-crime ecosystem around this type of criminal activity.

Written by xorl

November 14, 2017 at 21:52