Normal view

There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Hunting for Blues – the WSL Plan 9 Protocol BSOD

23 July 2020 at 14:53

Windows Subsystem for Linux Plan 9 Protocol Research Overview

This is the final blog in the McAfee research series trilogy on the Windows Subsystem for Linux (WSL) implementation – see The Twin Journey (part 1) and Knock, Knock–Who’s There (part 2). The previous research discussed file evasion attacks when the Microsoft P9 server can be hijacked with a malicious P9 (Plan 9 File System Protocol) server. Since Windows 10 version 1903, it is possible to access Linux files from Windows by using the P9 protocol. The Windows 10 operating system comes with the P9 server as part of the WSL install so that it can communicate with a Linux filesystem. In this research we explore the P9 protocol implementation within the Windows kernel and whether we could execute code in it from a malicious P9 server. We created a malicious P9 server by hijacking the Microsoft P9 server and replacing it with code we can control.

In a typical attack scenario, we discovered that if WSL is enabled on Windows 10, then a non-privileged local attacker can hijack the WSL P9 communication channel to cause a local Denial of Service (DoS) or Blue Screen of Death (BSOD) in the Windows kernel. It is not possible to achieve escalation of privilege (EoP) within the Windows kernel due to this vulnerability; the BSOD appears to be as designed by Microsoft within their legitimate fail flow, if malformed P9 server communication packets are received by the Windows kernel. A non-privileged user should not be able to BSOD the Windows kernel, from a local or remote perspective. If WSL is not enabled (disabled by default on Windows 10), the attack can still be executed but requires the attacker to be a privileged user to enable WSL as a pre-requisite.

There have recently been some critical, wormable protocol vulnerabilities within the RDP and SMB protocols in the form of Bluekeep and SMBGhost. Remotely exploitable vulnerabilities are very high risk if they are wormable as they can spread across systems without any user interaction. Local vulnerabilities are lower risk since an attacker must first have a presence on the system; in this case they must have a malicious P9 server executing. The P9 protocol implementation runs locally within the Windows kernel so the objective, as with most local vulnerability hunting, is to find a vulnerability that allows an escalation of privilege (EoP).

In this blog we do a deep dive into the protocol implementation and vulnerability hunting process. There is no risk to WSL users from this research, which has been shared with and validated by Microsoft. We hope this research will help improve understanding of the WSL P9 communications stack and that additional research would be more fruitful further up the stack.

There have been some exploits on WSL such as here and here but there appears to be no documented research of the P9 protocol implementation other than this.

P9 Protocol Overview

The Plan 9 File System Protocol server allows a client to navigate its file system to create, remove, read and write files. The client sends requests (T-messages) to the server and the server responds with R-messages. The P9 protocol has a header consisting of size, type and tag fields which is followed by a message type field depending on the request from the client. The R-message type sent by the server must match the T-message type initiated from the client. The maximum connection size for the data transfer is decided by the client during connection setup; in our analysis below, it is 0x10000 bytes.

P9 protocol header followed by message type union (we have only included the subset of P9 message types which are of interest for vulnerability research):

struct P9Packet {

u32                         size;

u8                           type;

u16                         tag;

union {

struct p9_rversion rversion;

struct p9_rread rread;

struct p9_rreaddir rreaddir;

struct p9_rwalk rwalk;

} u

} P9Packet

The P9 T-message and corresponding R-message numbers for the types we are interested in (the R-message is always T-message+1):

enum p9_msg_t {

P9_TREADDIR = 40,

P9_RREADDIR = 41,

P9_TVERSION = 100,

P9_RVERSION = 101,

P9_TWALK = 110,

P9_RWALK = 111,

P9_TREAD = 116,

P9_RREAD = 117,

}

At the message type layer, which follows the P9 protocol header, you can see the fields, which are of variable size, highlighted below:

struct p9_rwalk {

u16 nwqid;

struct p9_qid wqids[P9_MAXWELEM];

}

 

struct p9_rread {

u32 count;

u8 *data;

}

 

struct p9_rreaddir {

u32 count;

u8 *data;

}

 

struct p9_rversion {

u32 msize;

struct p9_str version;

}

 

struct p9_str {

u16 len;

char *str;

}

Based on the packet structure of the P9 protocol we need to hunt for message type confusion and memory corruption vulnerabilities such as out of bounds read/write.

So, what will a packet structure look like in memory? Figure 1 shows the protocol header and message type memory layout from WinDbg. The message size (msize) is negotiated to 0x10000 and the version string is “9P2000.W”.

Figure 1. P9 packet for rversion message type

Windows WSL P9 Communication Stack and Data Structures

Figure 2. Windows Plan 9 File System Protocol Implementation within WSL

The p9rdr.sys network mini-redirector driver registers the “\\Device\\P9Rdr” device with the Redirected Drive Buffering Subsystem (RDBSS) using the RxRegisterMinirdr API as part of the p9rdr DriverEntry routine. During this registration, the following P9 APIs or driver routines are exposed to the RDBSS:

P9NotImplemented

P9Start

P9Stop

P9DevFcbXXXControlFile

P9CreateSrvCall

P9CreateVNetRoot

P9ExtractNetRootName

P9FinalizeSrvCall

P9FinalizeVNetRoot

P9Create

P9CheckForCollapsibleOpen

P9CleanupFobx

P9CloseSrvOpen

P9ForceClosed

P9ExtendFile

P9Flush

P9QueryDirectoryInfo

P9QueryVolumeInfo

P9QueryFileInfo

P9SetFileInfo

P9IsValidDirectory

P9Read

P9Write

The p9rdr driver is not directly accessible from user mode using the DeviceIoControl API and all calls must go through the RDBSS.

As seen in Figure 2, when a user navigates to the WSL share at “\\wsl$” from Explorer, the RDBSS driver calls into the P9 driver through the previously registered APIs.

DIOD is a file server implementation, that we modified to be a “malicious” P9 server, where we claim the “fsserver” socket name prior to the Windows OS in a form of squatting attack. Once we replaced the Microsoft P9 server with the DIOD server, we modified the “np_req_respond” function (explained in the fuzzing constraints section) so that we could control P9 packets to send malicious responses to the Windows kernel. Our malicious P9 server and socket hijacking have been explained in detail here.

So now we know how data travels from Explorer to the P9 driver but how does the P9 driver communicate with the malicious P9 server? They communicate over AF_UNIX sockets.

There are two important data structures used for controlling data flow within the P9 driver called P9Client and P9Exchange.

The P9Client and P9Exchange data structures, when reverse engineered to the fields relevant to this research, look like the following (fields not relevant to this analysis have been labelled as UINT64 for alignment):

typedef struct P9Client {
PVOID * WskTransport_vftable
PVOID * GlobalDevice
UNINT64 RunRef
WskSocket *WskData
UINT64
UINT64
UINT_PTR
PVOID *MidExchangeMgr_vftable
PRDBSS_DEVICE_OBJECT *RDBSS
UINT64
PVOID **WskTransport_vftable
PVOID **MidExchangeMgr_vftable
P9Packet *P9PacketStart
UINT64 MaxConnectionSize
UINT64 Rmessage_size
P9Packet *P9PacketEnd
UINT_PTR
UINT64
UINT64
UINT_PTR
UINT64
UINT64
PVOID * Session_ReconnectCallback
PVOID ** WskTransport_vftable
UINT64
UINT_PTR
UINT_PTR
UINT64
UINT_PTR
UINT64
UINT64
UINT64
} P9Client

P9Client data structure memory layout in WinDbg:

typedef struct P9Exchange {
UINT64
UINT64
P9Client *P9Client
UINT64 Tmessage_type
UINT64
UINT_PTR
PVOID *Lambda_PTR1
PVOID *Lambda_PTR2
PRX_CONTEXT *RxContextUINT64 Tmessage_size
UINT64
UINT64
UINT64
UINT64
UINT64
UINT64
} P9Exchange

The P9Exchange data structure layout in WinDbg:

To communicate with the P9 server, the P9 driver creates an I/O request packet (IRP) to receive data from the Winsock Kernel (WSK). An important point to note is that the Memory Descriptor List (MDL) used to hold the data passed between the P9 server and Windows kernel P9 client is 0x10000 bytes (the max connection size mentioned earlier).

virtual long WskTransport::Receive(){

UNINT64 MaxConnectionSize = 0x10000;

P9_IRP_OBJECT = RxCeAllocateIrpWithMDL(2, 0, 0i64);

P9_MDL = IoAllocateMdl(P9Client->P9PacketStart, MaxConnectionSize, 0, 0, 0i64);
void MmBuildMdlForNonPagedPool(P9_MDL);
P9_IRP_OBJECT->IoStackLocation->Parameters->MDL = &P9_MDL;

P9_IRP_OBJECT->IoStackLocation->Parameters->P9Client = &P9Client;

P9_IRP_OBJECT->IoStackLocation->Parameters->DataPath = &P9Client::ReceiveCallback;
P9_IRP_OBJECT->IoStackLocation->CompletionRoutine = p9fs::WskTransport::SendReceiveComplete
WskProAPIReceive (*WskSocket, *P9_MDL, 0, *P9_IRP_OBJECT);
}

The MDL is mapped to the P9PacketStart field address within the P9Client data structure.

On IRP completion, the WskTransport::SendReceiveComplete completion routine is called to retrieve the P9Client structure from the IRP to process the P9 packet response from the server:

int static WskTransport::SendreceiveComplete(IRP *P9_IRP_OBJECT){

P9Client = &P9_IRP_OBJECT->IoStackLocation->Parameters->P9Client;

P9Client::ReceiveCallback(P9Client* P9Client);

}

The P9Client data structure is used within an IRP to receive the R-message data but what is the purpose of the P9Exchange data structure?

  1. When the P9 driver sends a T-message to the server, it must create an exchange so that it can track the state between the message type sent (T-message) and that returned by the server (R-Message).
  2. It contains lambda functions to execute on the specific message type. The Tmessage_type field within the P9Exchange data structure ensures that the server can only send R-messages to the same T-message type it received from the P9 driver.
  3. PRX_CONTEXT * RxContext structure is used to transfer data between Explorer and the p9rdr driver via the RDBSS driver.

The flow of a WALK T-message can be seen below:

Within the P9Client::CreateExchange function, the MidExchangeManager::RegisterExchange is responsible for registering the P9Exchange data structure with the RDBSS using a multiplex ID (MID) to distinguish between concurrent server and client requests.

MidExchangeManager::RegisterExchange (*P9Client, *P9Exchange){

NTSTATUS RxAssociateContextWithMid (PRX_MID_ATLAS P9Client->RDBSS, PVOID P9Exchange, PUSHORT NewMid);

}

The important fields within the P9Client and P9Exchange data structures which we will discuss further during the analysis:

  1. PClient->MaxConnectionSize – set at the start of the connection and cannot be controlled by an attacker
  2. P9Client->P9PacketStart – points to P9 packet received and can be fully controlled by an attacker
  3. P9Client->Rmessage_size –can be fully controlled by an attacker
  4. P9Exchange->Tmessage_type – set during T-message creation and cannot be controlled by an attacker
  5. P9Exchange->RxContext – used to pass data from P9 driver through the RDBSS to Explorer

Now that we know how the protocol works within the Windows kernel, the next stage is vulnerability hunting.

Windows Kernel P9 Server Vulnerability Hunting

P9 Packet Processing Logic

From a vulnerability perspective we want to audit the Windows kernel logic within p9rdr.sys, responsible for parsing traffic from the malicious P9 server. Figure 3 shows the source of the P9 packet and the sink, or where the packet processing completes within the p9rdr driver.

Figure 3. Windows Kernel Processing layers for the P9 protocol malicious server response parsing

Now that we have identified the code for parsing the P9 protocol message types of interest we need to audit the code for message type confusion and memory corruption vulnerabilities such as out of bounds read/write and overflows.

Fuzzing constraints

There were a number of constraints which made deploying automated fuzzing logic difficult:

  1. The R-message type sent from the malicious P9 server must match the T-message type sent by the Windows kernel
  2. Timeouts in higher layers of the WSL stack

The above challenges could, however, be overcome but since the protocol is relatively simple we decided to focus on reversing the processing logic validation. To verify the processing logic validation, we created some manual fuzzing capability within the malicious P9 server to test the variable length packet field boundaries identified from the protocol overview.

Below is an example RREAD R-message type which sends a malicious P9 packet in response to an RREAD T-message where we control the count and data variable length fields.

srv.c

void

np_req_respond(Npreq *req, Npfcall *rc)

{

NP_ASSERT (rc != NULL);

xpthread_mutex_lock(&req->lock);

 

u32 count = 0xFFFFFFFF;

Npfcall *fake_rc;

u8 *data = malloc(0xFFF0);

memset(data, “A”, 0xFFF0);

 

if (!(fake_rc = np_alloc_rread1(count)))

return NULL;

if (fake_rc->u.rread.data)

memmove(fake_rc->u.rread.data, data, count);

 

if(rc->type == 0x75){

fprintf (stderr, “RREAD Packet Reply”);

req->rcall = fake_rc;

}

else{

req->rcall =rc;

}

if (req->state == REQ_NORMAL) {

np_set_tag(req->rcall, req->tag);

np_conn_respond(req);

}

xpthread_mutex_unlock(&req->lock);

}

Validation Checks

The data passed to the P9 driver is contained within a connection memory allocation of 0x10000 bytes (P9Client->P9PacketStart) and most of the processing is done within this memory allocation, with two exceptions where memmove is called within the P9Client::FillData and P9Client::Lambda_2275 functions (discussed below).

A message-type confusion attack is not possible since the P9Exchange data structure tracks the R-message to its corresponding T-message type.

In addition, the P9 driver uses a span reader to process message type fields of static length. The P9Exchange structure stores the message type which is used to determine the number of fields within a message during processing.

While we can control the P9 packet size we cannot control the P9Client->MaxConnectionSize which means messages greater than or equal to 0x10000 will be dropped.

All variable size field checks within the message type layer of the protocol are checked against the P9Packet size field ensuring that a malicious field will not result in out of bounds read or write access outside of the 0x10000 connection memory allocation.

The processing logic functions identified previously were reverse engineered to understand the validation on the protocol’s fields, with specific focus on the variable length fields within message types rversion, rwalk and rread.

By importing the P9Client and P9Exchange data structures into IDA Pro, the reverse engineering process relatively straight forward to understand the packet validation logic. The functions below have been reversed to the level required for understanding the validation and are not representative of the entire function code base.

P9Client::ReceiveCallback validates that the Rmessage_size does not exceed the max connection size of 0x10000

void P9Client::ReceiveCallback ( P9Client *P9Client){
struct p9packet;uint64 MaxConnectionSize;uint64 Rmessage_size;MaxConnectionSize = P9Client-> MaxConnectionSize;
Rmessage_size = P9Client->Rmessage_size;if(MaxConnectionSize) {
P9Packet = (struct p9packet *) P9Client-> P9PacketStart;if (MaxConnectionSize < 0 || !P9Packet) terminate(P9Packet);}if (Rmessage_size >=0 && P9Client->MaxConnectionSize >= Rmessage_size)
{
P9Client::HandleReply (*P9Client)
} else{

terminate(P9Packet);

}

P9Client::HandleReply – there are multiple local DoS here which result in a Blue Screen Of Death (BSOD) depending on the size of P9Client->Rmessage_size and P9Client->P9PacketEnd->size, e.g. when P9Client->P9PacketEnd->size is zero terminate() is called which is BSOD.

void P9Client::HandleReply(P9Client *P9Client){

uint64 P9PacketHeaderSize = 7;

uint64 Rmessage_size = P9Client->Rmessage_size;

if (Rmessage_size >=7){
while(1){

P9PacketEnd = P9Client->P9PacketEnd;

if(!P9PacketEnd) break;

uint64 P9PacketSize = P9Client->P9PacketEnd->size;
if (P9PacketSize > P9Client->MaxConnectionSize); HandleIoError();

if (Rmessage_size < P9PacketSize); P9Client::FillData();

if(Rmessage_size < 4) terminate(); // checking a P9 header size field exists in packet

if(Rmessage_size > 5) fastfail(); // checking a P9 header type field exists in packet

int message_type = P9PacketEnd->type;

if(Rmessage_size < 7) fastfail(); // checking a P9 header tag field exists in packet

uint64 tag = P9PacketEnd->tag;

uint64 P9message_size = P9PacketSize – P9PacketHeaderSize; //getting size of message

if (Rmessage_size – 7 < 0) terminate(); // checking message layer exists after P9 header

if (Rmessage_size – 7 < P9message_size); terminate();  //BSOD here as when set P9PacketSize = 0 then subtracting 7 wraps around so P9message_size becomes greater than Rmessage_size.

void P9Client::ProcessReply(P9Client *P9Client, Rmessage_type, tag, &P9message_size);

}

}

else {

P9Client::FillData();

}

P9Client::FillData – we cannot reach this function with a large Rmessage_size to force an out of bounds write.

int P9Client::FillData (P9Client *P9Client){
uint64 Rmessage_size = P9Client-> Rmessage_size;uint_ptr P9PacketEnd = P9Client->P9PacketEnd;
uint_ptr P9PacketStart = P9Client->P9PacketStart;if (P9PacketEnd != P9PacketStart) {
memmove (P9PacketStart, P9PacketEnd, Rmessage_size);
}

ProcessReply checks the R-message type with that from the T-message within the P9Exchange data structure.

void P9Client::ProcessReply(P9Client *P9Client, Rmessage_type, tag, &P9message_size){
P9Exchange *P9Exchange = MidExchangeManager::FindAndRemove(*P9Client, &P9Exchange);if (P9Packet->tag > 0) {
int message_type_size = GetMessageSize (P9Exchange->Tmessage_type);
if (P9message_size >= message_type_size) {int rmessage_type = P9Exchange->MessageType;int rmessage_type = rmessage_type +1;}
if(rmessage_type > 72){
Switch (MessageType){
case 100:
P9Client::ProcessVersionReply(P9Client *P9Client, P9Exchange, &P9message_size);
case 110:
P9Client::ProcessWalkreply(Rmessage_type, P9Exchange, &P9message_size);}
}else {
P9Client::ProcessReadReply(rmessage_type, P9Exchange, &P9message_size);
}}

During the P9Client::ProcessReply function it calls MidExchangeManager::FindAndRemove to fetch the P9Exchange data structure associated with the R-messages corresponding T-message.

MidExchangeManager::FindAndRemove (*P9Client, &P9Exchange){

NTSTATUS RxMapAndDissociateMidFromContext(PRX_MID_ATLAS P9Client->RDBSS_RxContext, USHORT Mid, &P9Exchange);

}

ProcessVersionReply checks the version sent by Client “P92000.L” which is 8 characters and checks the same length on return so the rversionlen does not affect the tryString function.

void P9Client::ProcessVersionReply (*P9Client, *P9Exchange, & P9message_size) {

char * rversion;
int rversionlen = 0;

rversion = P9Client->P9PacketStart.u.rversion->version->str;

rversionlen = P9Client->P9PacketStart.u.rversion->version->len;

tryString (messagesize, &rversion)

strcmp (Tversion, Rversion);
}

ProcessWalkReply checks that the total number of rwalk structures does not exceed the P9message_size

void P9Client::ProcessWalkReply(rmessage_type, *P9Exchange, &P9message_size){

uint16 nwqid = p9packet.rwalk.nwqid;

uint64 rwalkpacket_size = &P9message_size – 2; // 2 bytes of rwalk header for nwqid field

unit_ptr rwalkpacketstart = &P9Client->P9PacketStart.u.rwalk->wqids;
uint64 error_code = 0x0C0000186;
uint64 rwalk_message_size = nwqid * 13; // 0xd is size of an rwalk struct

if (rwalk_message_size <= P9message_size) {

P9Exchange->Lambda_8972 (int, nwqid, &rwalk_message_size, P9Exchange-> RxContext, & rwalkpacketstart); // Lambda_8972 is Lambda_PTR1 for rwalk message type

} else {

P9Exchange->P9Client::SyncContextErrorCallback (error_code, P9Exchange-> RxContext) // SyncContextErrorCallback is Lambda_PTR2 for rwalk message type

}
}

ProcessReadReply checks the size of the count field does not exceed 0x8000 and writes it into an MDL within P9Exchange-> RxContext to pass back up the RDBSS stack to view file contents within Explorer.

void P9Client::ProcessReadReply (rmessage_type, *P9Exchange, &P9message_size){
unint64 count = P9Client->P9PacketStart.u.rread->count;
P9Exchange->Lambda_2275 (count, P9Exchange-> RxContext, &P9message_size);}

 

Lambda_2275 (count, P9Exchange-> RxContext, &P9message_size) {

uint64 maxsize = P9Exchange-> RxContext+offset; //max_size = 0x8000

unint64 MDL = P9Exchange-> RxContext+offset;

if (count > maxsize) terminate();

memmove (&MDL, P9Client->P9PacketStart.u.rread->data, count);

}

Conclusion

Through this research, we discovered a local Denial of Service (DoS) within the Windows kernel implementation of the P9 protocol. As explained, the vulnerability cannot be exploited to gain code execution within the Windows kernel so there is no risk to users from this specific vulnerability. As a pre-requisite to malicious P9 server attacks, an attacker must hijack the P9 server socket “fsserver”. Therefore, we can mitigate this attack by detecting and preventing hijacking of the socket “fsserver”. McAfee MVISION Endpoint and EDR can detect and prevent coverage against P9 server socket “fsserver” hijacking which you can read more about here.

We hope this research provides insights into the following:

  1. The vulnerability hunting process for new features such as the WSL P9 protocol on the Windows 10 OS
  2. Provide support for future research higher up the WSL communications stack which increases in complexity due to the implementation of a virtual Linux file system on Windows
  3. The value of McAfee Advanced Threat Research (ATR) working closely with our product and innovation teams to provide protection for our customers

Finally, a special thanks to Leandro Costantino and Cedric Cochin for their initial Windows 10 WSL P9 server research.

The post Hunting for Blues – the WSL Plan 9 Protocol BSOD appeared first on McAfee Blog.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 1

1 October 2020 at 04:01

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland

The essence of Space 4.0 is the introduction of smaller, cheaper, faster-to-the-market satellites in low-earth-orbit into the value chain and the exploitation of the data they provide. Space research and communication prior to Space 4.0 was primarily focused on astronomy and limited to that of governments and large space agencies. As technology and society evolves to consume the “New Big Data” from space, Space 4.0 looks set to become the next battleground in the defense against cybercriminals. Space 4.0 data can range from earth observation sensing to location tracking information and applied across many vertical uses cases discussed later in this blog. In the era of Space 4.0 the evolution of the space sector is rapidly changing with a lower cost of launching, combined with public and private partnerships that open a whole new dimension of connectivity. We are already struggling to secure our data on earth, we must now understand and secure how our data will travel through space constellations and be stored in cloud data centers on earth and in space.

Low Earth Orbit (LEO) satellites are popular for scientific usage but how secure are they? The Internet of Things (IoT) introduced a myriad of insecure devices onto the Internet due to the low cost of processors and high-speed connectivity, but the speed in its adoption resulted in a large fragmentation of insecure hardware and software across business verticals.

Space 4.0 is now on course for a similar rapid adoption with nanosats as we prepare to see a mass deployment of cheap satellites into LEO. These small satellites are being used across government, academic and commercial sectors for different use cases that require complex payloads and processing. Many nanosats can coexist on a single satellite. This means that the same satellite backbone circuit infrastructure can be shared, reducing build and launch costs and making space data more accessible.

To date, satellites have typically been relay type devices repeating signals to and from different locations on earth in regions with poor internet connectivity, but that is all set to change with a mass deployment of smarter satellite devices using inter-satellite links (ISL) in  constellations like Starlink which aim to provide full high speed broadband global coverage. As the Space 4.0 sector is moving from private and government sectors to general availability, this makes satellites more accessible from a cost perspective, which will attract threat actors other than nation states, such as cyber criminals. Space 4.0 also brings with it new service delivery models such as Ground Station as a Service (GSaaS) with AWS and Azure Orbital and Satellite as a Service (SataaS). With the introduction of these, the satellite will become another device connecting to the cloud.

In our research we analyze the ecosystem to understand the latest developments and threats in relation to cybersecurity in space and whether we are ready to embrace Space 4.0 securely.

Space 4.0 Evolution

What is the Industrial 4th Revolution? The original industrial revolution started with the invention of steam engines then electricity, computers and communication technology. Industry 4.0 is about creating a diverse, safe, healthy, just world with clean air, water, soil and energy, as well as finding a way to pave the path for the innovations of tomorrow.

The first space era, or Space 1.0, was the study of astronomy, followed by the Apollo moon landings and then the inception of the International Space Station (ISS). Space 4.0  is analogous to Industry 4.0, which is considered as the unfolding fourth industrial revolution of manufacturing and services. Traditionally, access to space has been the domain of governments and large space agencies (such as NASA or the European Space Agency) due to the large costs involved in the development, deployment and operation of satellites. In recent years, a new approach to using space for commercial, economic and societal good has been driven by private enterprises in what is termed New Space. When combined with the more traditional approach to space activity, the term “Space 4.0” is used. Space 4.0 is applicable across a wide range of vertical domains, including but not limited to:

  • Ubiquitous broadband
  • Autonomous vehicles
  • Earth observation
  • Disaster mitigation/relief
  • Human spaceflight
  • Exploration

Cyber Threat Landscape Review

The Cyber Threat Landscape has evolved greatly over the past 20 years with the convergence of Information Technology (IT), Operational Technology (OT) and IoT. Protecting consumers, enterprises and critical infrastructure with the rapid parallel innovation of technology and cybercriminals is a constant challenge. While technology and attacks evolve rapidly the cybercriminal motive remains a constant; make money and maximize profit by exploiting a combination of users and technology.

Cybercriminals have much more capabilities now than they did 10 years ago due to the rise of Cybercrime as a Service (CaaS). Once an exploit for a vulnerability has been developed, it can then be weaponized into an exploit kit or ransomware worm, such as WannaCry. Cybercriminals will follow the path of least resistance to achieve their goal of making money.

Nearly every device class across the business verticals, ranging from medical devices to space Very-small-aperture terminals (VSAT), have been hacked by security researchers, as evident from Blackhat and Defcon trends.

From a technology stack perspective (hardware and software) there have been vulnerabilities discovered and exploits developed across all layers where we seek to establish some form of trustworthiness when connected to the internet; browsers, operating systems, protocols, hypervisors, enclaves, cryptographic implementations, system on chips (SoC) and processors.

Not all these vulnerabilities and exploits become weaponized by cybercriminals, but it does highlight the fact that the potential exists. Some notable weaponized exploits are:

  1. Stuxnet worm
  2. WannaCry ransomware worm
  3. Triton malware
  4. Mirai Botnet

Some recent major industry vulnerabilities were: BlueKeep (Windows RDP Protocol), SMBGhost (Windows SMB Protocol), Ripple20 (Treck embedded TCP/IP library), Urgent 11 (VxWorks TCP/IP library), Heartbleed (OpenSSL library), Cloudbleed (Cloudflare), Curveball (Microsoft Crypto API), Meltdown and Spectre (Processor side channels).

Cybercriminals will adapt quickly to maximize their profit as we saw with the COVID-19 pandemic and the mass remote workforce. They will quickly understand the operating environment changes and how they can reach their goals by exploiting users and technology, whichever is the weakest link. The easiest entry point into an organization will be through identity theft or weak passwords being used in remote access protocols such as RDP.

Cybercriminals moved to the Dark Web to hide identity and physical location of servers or using bullet-proof providers to host their infrastructure. What if these services are hosted in space? Who is the legal entity and who is responsible?

McAfee Enterprise Supernova Cloud analysis reports that:

  • Nearly one in 10 files shared in the cloud with sensitive data have public access, an increase of 111% year over year
  • One in four companies have had their sensitive data downloaded from the cloud to an unmanaged personal device, where they cannot see or control what happens to the data
  • 91% of cloud services do not encrypt data at rest
  • Less than 1% of cloud services allow encryption with customer-managed keys

The transition to the cloud, when done securely, is the right business decision. However, when not done securely it can leave your services and data/data lakes accessible to the public through misconfigurations (shared responsibility model), insecure APIs, and identity and access management issues. Attackers will always go for the low hanging fruit such as open AWS buckets and credentials through vendors in the supply chain.

One of the key initiatives, and now industry benchmark, is the MITRE ATT&CK framework which enumerates the TTPs from real word incidents across Enterprise (Endpoint and Cloud), Mobile and ICS. This framework has proved to be very valuable in enabling organizations to understand adversary TTPs and the corresponding protect, detect and response controls required in their overall defense security architecture. We may well see a version of MITRE ATT&CK evolve for Space 4.0.

Space Cyber Threat Landscape Review

Threat actors know no boundaries as we have seen criminals move from traditional crime to cybercrime using whatever means necessary to make money. Likewise, technology communication traverses many boundaries across land, air, sea and space. With the reduced costs to entry and the commercial opportunities with Space 4.0 big data, we expect to see cybercriminals innovating within this huge growth area. The Cyber Threat Landscape can be divided into vulnerabilities discovered by security researchers and actual attacks reported in the wild. This allows us to understand the technologies within the space ecosystem that are known to contain vulnerabilities and what capabilities threat actors have and are using in the wild.

Vulnerabilities discovered to date have been within VSAT terminal systems and intercepting communications. There have been no vulnerabilities disclosed on actual satellites from figure 1 below.

Figure 1 – Security Researcher space vulnerability disclosures

To date, satellites have mostly been controlled by governments and the military so little information is available as to whether an actual satellite has been hacked. We do expect to see that change with Space 4.0 as these satellites will be more accessible from a hardware and software perspective to do security analysis. Figure 2 below highlights reported attacks in the wild

Figure 2 – Reported Attacks in the Wild

In McAfee’s recent threat research, “Operation North Star”, we observed an increase in malicious cyber activity targeting the Aerospace and Defense industry. The objective of these campaigns was to gather information on specific programs and technologies.

Since the introduction of the cloud, it appears everything has become a device that interacts with a service. Even cybercriminals have been adapting to the service model. Space 4.0 is no different as we start to see the adoption of the Ground Station as a Service (GSaaS) and Satellite as a Service (SataaS) models per figure 3 below. These services are opening in the space sector due to the acceleration of vendors into Space 4.0 to help keep their costs down. Like any new ecosystem this will bring new attack surfaces and challenges which we will discuss in the Threat Modelling section.

Figure 3 – New Devices and Services for Space 4.0


So, with the introduction of cheap satellites using commercial off-the-shelf (COTS) components and new cloud services is it just a matter of time before we see mass satellite attacks and compromise?

Space 4.0 Data Value

The global space industry grew at an average rate of 6.7% per year between 2005 and 2017 and is projected to rise from its current value of $350 billion to $1.3 trillion per annum by 2030. This rise is driven by new technologies and business models which have increased the number of stakeholders and the application domains which they service in a cost-effective way. The associated increase in data volume and complexity has, among other developments, resulted in increasing concerns over the security and integrity of data transfer and storage between satellites, and between ground stations and satellites.

The McAfee Supernova report shows that data is exploding out of enterprises and into the cloud. We are now going to see the same explosion from Space 4.0 to the cloud as vendors race to innovate and monetize data from low cost satellites in LEO.

According to Microsoft the processing of data collected from space at cloud-scale to observe the Earth will be “instrumental in helping address global challenges such as climate change and furthering of scientific discovery and innovation”. The value of data from space must be viewed from the perspective of the public and private vendors who produce and consume such data. Now that satellite launch costs have reduced, producing this data becomes more accessible to commercial markets, so we are going to see much innovation in data analytics to improve our lives, safety and preservation of the earth. This data can be used to improve emergency response times to save lives, monitoring illegal trafficking, aviation tracking blind spots, government scientific research, academic research, improving supply chains and monitoring the earth’s evolution, such as climate change effects. Depending on the use case, this data may need to be confidential, may have privacy implications when tracking and may have substantial value in the context of new markets, innovation and state level research. It is very clear that data from space will have much value as new markets evolve, and cybercriminals will most certainly target that data with the intent to hold organizations to ransom or sell data/analytics innovation to competitors to avoid launch costs. Whatever the use case and value of the data traveling through space may be, we need to ensure that it moves securely by providing a trustworthy end to end ecosystem.

As we progress towards the sixth digital era, our society, lives and connectivity will become very dependent on off-planet data and technology in space, starting with SataaS.

In Part 2 we will discuss remote computers in Space, the Space 4.0 threat model and what we must do to secure Space 4.0 moving forward.

McAfee would like to thank Cork Institute of Technology (CIT) and their Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to securing Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 1 appeared first on McAfee Blog.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 2

1 October 2020 at 04:01

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center in Cork, Ireland

In the first of this two-part blog series we introduced Space 4.0, its data value and how it looks set to become the next battleground in the defense against cybercriminals. In part two we discuss the architectural components of Space 4.0 to threat model the ecosystem from a cybersecurity perspective and understand what we must do to secure Space 4.0 moving forward.

Nanosats: Remote Computers in Space

A satellite is composed of a payload and a bus. The payload is the hardware and software required for the mission or satellite’s specific function, such as imaging equipment for surveillance. The bus consists of the infrastructure or platform that houses the payload, such as thermal regulation and command and control. Small satellites are space craft typically weighing less than 180 kilograms and, within that class of satellites, is what we call nanosatellites or nanosats which typically weigh between 1-10 kilograms. Cubesats are a class of nanosat so you will often hear the term used interchangeably, and for the context of Space 4.0 security, we can assume they are the same device. Nanosats significantly reduce launch costs due to their small size and the fact that many of these devices can be mounted on board a larger single satellite for launch.

Commercial off-the-shelf (COTS) Cubesats typically use free open source software such as FreeRTOS or KubOS for the on-board operating system. However, other systems are possible, with drivers available for most of the hardware on Linux and Windows OS. KubOS is an open source flight software framework for satellites and has cloud-based mission control software, Major Tom, to operate nanosats or a constellation. We mention KubOS here as it is a good example of what the current Space 4.0 operating model looks like today. While we have not reviewed KubOS from a security perspective, developing a secure framework for satellites is the right path forward, allowing mission developers to focus on the payload.

Some of the use cases available with Cubesats are:

  1. File transfers
  2. Remote communication via uplink/downlink
  3. Intra-satellite and inter-satellite communications
  4. Payload services such as camera and sensors telemetry
  5. Software Updates

KubOS is “creating a world where you can operate your small satellite from your web browser or iPhone”. KubOSobjective is to allow customers to send bits and not rockets to space and it is defining a new era of software-designed satellites. The satellite model is changing from relay type devices to remote computers in space using COTS components and leveraging TCP/IP routing capabilities. This model shift also means that there is more software executing on these satellites and more complex payload processing or interaction with the software stack and hence more attack surface.

To date, attacks on satellite systems from a cybersecurity perspective have typically been in the context of VSAT terminals, eavesdropping and hijacking. While there have been vulnerabilities found in the VSAT terminal software and its higher-level custom protocols, there seems to have been no focus and vulnerabilities discovered within the network software stack of the satellite itself. This may be since satellites are very expensive, as well as closed source, so not accessible to security researchers or cybercriminals, but this security by obscurity will not provide protection with the new era of nanosats. Nanosats use COTS components which will be accessible to cybercriminals.

Due to the closed nature of satellites there has not been much published on their system hardware and software stack. However, the Consultative Committee for Space Data Systems (CCSDS), which develops standards and specifications including protocols for satellite communications, does give some insight. The CCSDS technical domains are:

  1. Space Internetworking Services
  2. Mission Ops. And Information Management Services
  3. Spacecraft Onboard Interface Services
  4. System Engineering
  5. Cross Support Services
  6. Space Link Services

The CCSDS standards are divided into color codes to represent recommended standards and practices versus informational and experimental. This is a very large source of data communications for satellite designers to aid them in a reference for implementation. However, as we have observed over the cyber threat landscape of the past few decades, secure standards and specifications for hardware, software and protocols do not always translate to secure implementation. The CCSDS defines a TCP/IP stack suitable for transmission over space datalinks as per figure 1 below. Satellites that become more connected, just like any other device on the internet, their network and protocol software stack will become more accessible and targeted. As we discussed in part 1 <insert link> of our Space 4.0 blog series, there have been many TCP/IP and remote protocol related vulnerabilities in both embedded devices and even state of the art operating systems such as Windows 10. The TCP/IP stack and remote protocol implementations are a common source of vulnerabilities due to the complexities of parsing in unsafe memory languages such as C and C++. There does not appear to be any open source implementations of the CCSDS TCP/IP protocol stack.

Figure 1 – CCSDS Space communications protocols reference model

The CubeSat Protocol (CSP) is a free open source TCP/IP stack implementation for communication over space datalinks, similar to the CCSDS TCP/IP stack. The CSP protocol library is implemented in C, open source and implemented in many Cubesats that have been deployed to space. The protocol can be used for communication from ground station to satellite, inter-satellite and the intra-satellite communication bus. There have been 3 vulnerabilities to date reported in this protocol.

Figure 2 below shows what a Cubesat architecture looks like from a trust boundary perspective relative to the satellite and other satellites within the constellation and the earth.

Figure 2 – Space LEO Cubesat architecture trust boundaries

No hardware, software, operating system or protocol is completely free of vulnerabilities. What is important from a security perspective is:

  1. The accessibility of the attack surface
  2. The motives and capabilities of the adversary to exploit an exposed vulnerability if present in the attack surface

As these low-cost satellites get launched in our LEO and become more connected, any exposed technology stack will become increasingly targeted by cybercriminals.

Space 4.0 Threat Modeling

This Space 4.0 threat model focuses on the cybercriminal and how they can exploit Space 4.0 data for monetization. The following Space 4.0 factors will make it more accessible to cybercriminals:

  1. Mass deployment of small satellites to LEO
  2. Cheaper satellites with COTS components and increased satellite on board software processing (no longer relay devices)
  3. Satellite service models, Ground Station-as-a-Service (GSaaS) and Satellite-as-a-Service (SataaS) and shared infrastructure across government, commercial and academic
  4. Satellite connectivity and networks in space (ISL – inter-satellite links)
  5. Space 4.0 data value

Space security has typically been analyzed from the perspective of ground segment, communications or datalink and space segment. Additionally, the attack classes have been categorized as electronic (jamming), eavesdropping, hijacking and control. Per figure 3 below, we need to think about Space 4.0 with a cybersecurity approach due to the increased connectivity and data, as opposed to the traditional approach of ground, communication and space segments. Cybercriminals will target the data and systems as opposed to the RF transmission layer.

Figure 3 – Space 4.0 threat modeling architecture

It is important to consider the whole interconnectivity of the Space 4.0 ecosystem as cybercriminals will exploit any means possible, whether that be direct or indirect access (another trusted component). Open source networked ground stations such as SatNOGs and the emerging NyanSat are great initiatives for space research but we should consider these in our overall threat model as they provide mass connectivity to the internet and space.

The traditional space security model has been built on a foundation of cost as a barrier to entry and perimeter-based security due to lack of physical access and limited remote access to satellites. However, once a device is connected to the internet the threat model changes and we need to think about a satellite as any other device which can be accessed either directly or indirectly over the internet.

In addition, if a device can be compromised in space remotely or through the supply chain, then that opens a new attack class of space to cloud/ground attacks.

Users and trusted insiders will always remain a big threat from a ground station perspective, just like enterprise security today, as they can potentially get direct access to the satellite control.

The movement of ground services to the cloud is a good business model if designed and implemented securely, however a compromise would impact many devices in space being controlled from the GSaaS. It is not quite clear where the shared responsibility starts and ends for the new SataaS and GSaaS Space 4.0 service models but the satellite key management system (KMS), data, GSaaS credentials and analytics intellectual property (this may reside in the user’s environment, the cloud or potentially the satellite but for the purposes of this threat model we assume the cloud) will be much valued assets and targeted.

From the Cyber and Space Threat Landscape review in part 1 <insert link>, combined with our understanding of the Space 4.0 architecture and attack surfaces, we can start to model the threats in Table 1 below.

Table 1 – Space 4.0 threats, attack classes and layers, and attack vectors

Based on the above threat model, let’s discuss a real credible threat and attack scenario. From our Space cyber threat landscape review in part 1 of this blog series, there were attacks on ground stations in 2008 at the Johnson Space Center and for a Nasa research satellite. In a Space 4.0 scenario, the cybercriminal attacks the ground station through phishing to get access to satellite communications (could also be a supply chain attack to get a known vulnerable satellite system into space). The cybercriminal uses an exploit being sold on the underground to exploit a remote wormable vulnerability within the space TCP/IP stack or operating system of the satellite in space, just like we saw EternalBlue being weaponized by WannaCry. Once the satellite has been compromised the malware can spread between satellite vendors using their ISL communication protocol to propagate throughout the constellation. Once the constellation has been compromised the satellite vendor can be held to ransom, causing major disruption to Space 4.0 data and/or critical infrastructure.

Moving Forward Securely for a Trustworthy Space 4.0 Ecosystem

Establishing a trustworthy Space 4.0 ecosystem is going to require strong collaboration between cyber threat research teams, government, commercial and academia in the following areas:

  1. Governance and regulation of security standards implementation and certification/validation of satellite device security capabilities prior to launch
  2. Modeling the evolving threat landscape against the Space 4.0 technology advancements
  3. Secure reference architectures for end to end Space 4.0 ecosystem and data protection
  4. Security analysis of the CCSDS protocols
  5. Design of trustworthy platform primitives to thwart current and future threats must start with a security capable bill of materials (BOM) for both hardware and software starting with the processor then the operating system, frameworks, libraries and languages. Hardware enabled security to achieve confidentiality, integrity, availability and identity so that satellite devices may be resilient when under attack
  6. Visibility, detection and response capabilities within each layer defined in our Space 4.0 architecture threat model above
  7. Development of a MITRE ATT&CK specifically for Space 4.0 as we observe real world incidents so that it can be used to strengthen the overall defensive security architecture using TTPs and threat emulation

Space 4.0 is moving very fast with GSaaS, SataaS and talk of space data centers and high-speed laser ISL; security should not be an inhibitor for time to market but a contributor to ensure that we have a strong security foundation to innovate and build future technology on with respect to the evolving threat landscape. Space communication predates the Internet so we must make sure any legacy limitations which would restrict this secure foundation are addressed. As software complexity for on board processing and connectivity/routing capability increases by moving to the edge (space device) we will see vulnerabilities within the Space 4.0 TCP/IP stack implementation.

This is a pivotal time for the secure advancement of Space 4.0 and we must learn from the mistakes of the past with IoT where the rush to adopt new and faster technology resulted in large scale deployment of insecure hardware and software. It has taken much effort and collaboration between Microsoft and the security research community since Bill Gates announced the Trustworthy Computing initiative in 2002 to arrive at the state-of-the-art Windows 10 OS with hardware enabled security. Likewise, we have seen great advancements on the IoT side with ARM Platform Security Architecture and Azure Sphere. Many security working groups and bodies have evolved since 2002, such as the Trust Computing Group, Confidential Computing Consortium, Trusted Connectivity Alliance and Zero Trust concept to name a few. There are many trustworthy building block primitives today to help secure Space 4.0, but we must leverage at the concept phase of innovation and not once a device has been launched into space; the time is now to secure our next generation infrastructure and data source. Space security has not been a priority for governments to date but that seems all set to change with the “Memorandum on Space Policy Directive-5—Cybersecurity Principles for Space Systems”.

We should pause here for a moment and recognize the recent efforts from the cybersecurity community to secure space, such as the Orbital Security Alliance, S-ISAC, Mantech and Defcon Hack-a-Sat.

KubOS is being branded as the Android of space systems and we are likely to see a myriad of new software and hardware emerge for Space 4.0. We must work together to ensure Space 4.0 connectivity does not open our global connectivity and infrastructure dependency to the next Mirai botnet or WannaCry worm on LEO.

McAfee would like to thank Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to secure Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 2 appeared first on McAfee Blog.

CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server

10 November 2020 at 18:29

CVSS Score: 9.8 

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C 

Overview 

Microsoft released a patch today for a critical vulnerability (CVE-2020-17051) in the Windows NFSv3 (Network File System) server. NFS is typically used in heterogenous environments of Windows and Unix/Linux for file sharing. The vulnerability can be reproduced to cause an immediate BSOD (Blue Screen of Death) within the nfssvr.sys driver. Interestingly, the November patches from Microsoft also include a remote kernel data read vulnerability in the same nfssvr.sys driver (CVE-2020-17056), which leads to a potential ASLR (address space layout randomizationbypass. The combination of these two vulnerabilities dramatically increases the likelihood of a remote exploit when used on Windows Server to bypass exploit mitigations.  CVE-2020-17051 is the first known vulnerability which has been disclosed within the Windows implementation of the NFSv3 protocol to the best of our knowledge.  

Threat Surface 

The vulnerability is believed to impact all versions of Windows Server when: 

  1. An authenticated user has write access to any NFS share. 
  2. An NFS share has been configured with anonymous write access (no authentication required) 

A Shodan query reported 38,893 servers with port 2049 exposed to the internet; however, it is unknown what percentage of these servers are actually NFS shares and actuallconfigured with anonymous write access. The network share discovery technique is typically used by an adversary within the discovery phase of the MITRE ATT&CK framework with the objective to gain further privileges. CVE-2020-17051 would give adversaries the ability to spread wormlike within heterogenous Windows and Unix/Linux environments using anonymous write access file shares over NFSv3. 

Mitigation 

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to limit Windows NFSv3 server share write access internally and block any external access to vulnerable servers. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of this vulnerability. 

NSP Attack ID: 0x40c01200 – NFS Microsoft Windows Network File System Remote Code Execution Vulnerability (CVE-2020-17051) 

The post CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server appeared first on McAfee Blog.

The Cloning of The Ring – Who Can Unlock Your Door?

7 January 2020 at 05:01

Steve Povolny contributed to this report.

McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring can be used to interact with NFC-enabled door locks which conform to the ISO/IEC 14443A NFC card type. Once the NFC Ring has been paired with the NFC enabled door lock, the user can access their house by simply placing the NFC Ring within NFC range of the door lock.

McLear originally invented the NFC Ring to replace traditional keys with functional jewelry. The NFC Ring uses near field communication (NFC) for access control, to unlock and control mobile devices, share and transfer information, link people and much more. McLear NFC Ring aims to redefine and modernize access control to bring physical household security through convenience. Their latest ring also supports payment capability with McLear Smart Payment Rings, which were not in scope for this research.

Identity is something which uniquely identifies a person or object; an NFC tag is a perfect example of this. Authentication can be generally classified into three types; something you know, something you have and something you are. A NFC Ring is different from the general NFC access tag devices (something you have) as the Ring sits on your finger, so it is a hybrid authentication type of something you have and something you are. This unique combination, as well as the accessibility of a wearable Ring with NFC capabilities sparked our interest in researching this product as an NFC-enabled access control device. Therefore, the focus of our research was on NFC Ring protection against cloning as opposed to the door lock, since NFC access control tags and door locks have been well-researched.

The research and findings for this flaw were reported to McLear on September 25, 2019. To date, McAfee Advanced Threat Research has not received a response from the vendor.

Duplicating Keys Beyond the Hardware Store

In the era of Internet of Things (IoT), the balance between security and convenience is an important factor to get right during the concept phase of a new product and the bill of materials (BOM) selection. The hardware selection is critical as it often determines the security objectives and requirements that can be fulfilled during design and implementation of the product lifecycle. The NFC Ring uses an NFC capable Integrate Circuit (IC) which can be easily cloned and provides no security other than NFC proximity. The NFC protocol does not provide authentication and relies on its operational proximity as a form of protection. The problem with NFC Tags is that they automatically transmit their UID when in range of NFC device reader without any authentication.

Most consumers today use physical keys to secure access to their household door. The physical key security model requires an attacker to get physical access to the key or break the door or door lock. The NFC Ring, if designed securely, would provide equal or greater security than the physical key security model. However, since the NFC Ring can be easily cloned without having to attain physical access to the Ring, it makes the product’s security model less secure than a consumer having a physical key.

In this blog we discuss cloning of the NFC Ring and secure design recommendations to improve its security to a level equal to or greater than existing physical keys.

NFC Ring Security Model and Identity Theft

All McLear non-payment NFC Rings using NTAG216 ICs are impacted by this design flaw. Testing was performed specifically on the OPN which has an NTAG216 IC. The NFC Ring uses the NTAG 216 NFC enabled Integrated Circuit (IC) to provide secure access control by means of NFC communication.

The NFC protocol provides no security as it’s just a transmission mechanism.  The onus is on product owners to responsibly design and implement a security layer to meet the security objectives, capable of thwarting threats identified during the threat modeling phase at concept commit.

The main threats against an NFC access control tag are physical theft and tag cloning by NFC. At a minimum, a tag should be protected against cloning by NFC; with this research, it would ensure the NFC Ring provides the same level of security as a physical key. Ideal security would also protect against cloning even when the NFC Ring has been physically stolen which would provide greater security than that of a physical key.

The NTAG216 IC provide the following security per the NFC Ring spec:

  1. Manufacturer programmed 7-byte UID for each device
  2. Pre-programmed capability container with one-time programmable bits
  3. Field programmable read-only locking function
  4. ECC based originality signature
  5. 32-bit password protection to prevent unauthorized memory operations

The NFC Ring security model is built on the “Manufacturer programmed 7-byte UID for each device” as the Identity and Authentication with the access control principle or door lock. This 7-byte UID (unique identifier) can be read by any NFC enabled device reader such as a proxmark3 or mobile phone when within NFC communication range.

The NFC Ring security model can be broken by any NFC device reader when they come within NFC communication range since the static 7-byte UID is automatically transmitted without any authentication. Once the 7-byte UID has been successfully read, a magic NTAG card can be programmed with the UID, which forms a clone of the NFC Ring and allows an attacker to bypass the secure access control without attaining physical access to the NFC Ring.

The NFC Ring is insecure by design as it relies on the static 7-byte UID programmed at manufacture within the NTAG216 for device identity and authentication purposes. The NFC Ring security model relies on NFC proximity and a static identifier which can be cloned.

In addition, we discovered that the UIDs across NFC Rings maybe predictable (this was a very small sample size of three NFC Rings):

  • NFC Ring#1 UID 04d0e722993c80
  • NFC Ring#2 UID 04d24722993c80
  • NFC Ring#3 UID 04991c4a113c80

There is only a 22-byte difference between the UID of NFC Ring#1 and NFC Ring#2 (0x24-0x0e). By social engineering when a victim purchased their NFC Ring, an attacker could purchase a significant sample size of NFC Rings around the same time and possibly brute force their NFC Ring UID.

Social Engineering

Social Engineering consists of a range of techniques which can be used through human interaction for many malicious purposes such as identity theft. In the case of the NFC Ring the goal is to steal the user’s identity and gain access to their home. Reconnaissance can be performed online to gain background information such as what type of technology is being used by the victim for their home access.

One of the most common exchanges of technology today has become the passing of a phone between two untrusted parties to take a picture. The NFC Ring social engineering attack could be as simple as requesting the victim to take a picture with the attacker-supplied phone. The victim-as-helpful-photographer holds the attacker’s phone, which can read NFC tags and could be equipped with a custom Android app to read the NFC Ring UID, all transparent to the victim while they are snapping away. There is no sign to the victim that their NFC Ring is being read by the phone. It is recorded in the system log and cannot be viewed until a USB cable is attached with required software. Once the Ring is compromised, it can be reprogrammed on a standard writable card, which can be used to unlock smart home locks that partner with this product. The victim’s home is breached.

How It’s Done: NFC Ring Cloning

To successfully clone an NFC Tag, one must first identify the Tag type. This can be done by looking up the product specifications in some cases, or verifying by means of an NFC device reader such as a proxmark3.

From the NFC Ring specs we can determine most of the required tag characteristics:

  1. IC Model: NTAG216
  2. Operating Frequency: 13.56Mhz
  3. ISO/IEC: 14443A
  4. User writable space: 888 bytes
  5. Full specifications

In addition, by communicating with a proxmark3 attackers can physically verify the NFC Tag characteristics and obtain the UID which is required for cloning.

The most straightforward method to stealing the unique identifier of the Ring would be through a mobile phone. The following steps were taken in the below demo:

  1. Reading of NFC Ring with proxmark3 and cloning NTAG21x emulator card
  2. Setting attacker’s phone to silent to prevent NFC Tag detection sound
  3. Running our customized Android app to prevent Android activity popup when NFC Tag detected and read.

Mitigation Secure Design Recommendations

Lock the door. The existing insecure design can be mitigated by using NFC Doorlock password protection in combination with the NFC Ring for two factor authentication.

Authenticate. NFC Ring designers must mandate a secure PKI design with an NFC Tag which contains a crypto module that provides TAG authentication. The NFC Ring secure design must mandate a security layer on top of NFC to access control device manufacturers to ensure secure and trustworthy operation.

Randomize UIDs. In addition, the NFC designers must ensure they are not manufacturing NFC Rings with sequential UIDs which may be predictable with purchase date.

Consumer Awareness

To make customers aware of the security risks associated with products available on the market, product manufacturers should clearly state the level of security which their product provides in comparison with the technology or component they claim to be advancing. Are customers holding the master key to unlock their door, and are there duplicates?

In the case of the NFC Ring, while convenient, it clearly does not provide the same level of security to consumers as a physical key. This decrease in security model from a physical key to a NFC Ring is not due to technology limitations but due to an insecure design.

 

The post The Cloning of The Ring – Who Can Unlock Your Door? appeared first on McAfee Blog.

SMBGhost – Analysis of CVE-2020-0796

13 March 2020 at 02:44

The Vulnerability

The latest vulnerability in SMBv3 is a “wormable” vulnerability given its potential ability to replicate or spread over network shares using the latest version of the protocol (SMB 3.1.1). As of this writing, Microsoft have just released a patch for CVE-2020-0796 on the morning of March 12th. The bug was introduced very recently, in the decompression routines for SMBv3 data payloads. The code implementing this was deployed in April 2019 for Version 1903 and November 2019 for version 1909.

The vulnerability occurs during the processing of a malformed compressed message. The header of the message follows this format: (from [MS-SMB2])

  • There are two parameters in the header that are of interest: OriginalCompressedSegmentSize and Offset/Length
  • The Srv2DecompressData (srv2.sys) function allocates a buffer of size OriginalCompressedSegmentSize + Offset/Length
  • This is not checking the signedness of these values, and as the addition is signed an attacker can allocate a buffer smaller than intended
  • Data is being decompressed at buffer + offset, using data from packet+0x10+offset
  • OriginalCompressedSegmentSize is used as the UncompressedBufferSize parameter passed to SmbCompressionDecompression which is a wrapper for RtlDecompressBufferEx2
  • This routine assumes the uncompressed buffer size to be an unsigned long so a negative value gets cast into a large unsigned number
  • Because of this, the decompression routine decompresses the buffer and can go well beyond the original size, as it is assuming it has a very large buffer to work with

Here’s an annotated disassembly of the relevant function on the server side:

This flaw can affect both client and server in SMB negotiations in a compressed message sent after the Negotiate Protocol Responses. The server vulnerability is within srv2.sys and the client vulnerability is within mrxsmb.sys which both end up calling the same code in SmbCompressDecompress.

Here’s an annotated disassembly of the relevant function on the client side – unlike the server side the OriginalCompressedSegmentSize is bounds checked but there is no check on offset/length before they are combined and passed to ExAllocatePoolWithtag. We have confirmed the BSOD crash from both client->server AND server-client using this vulnerability.

If a computer allows inbound SMB3 traffic over port 445, by default compression is supported and the client and server will negotiate the “terms” of this compression and then the client will proceed to transfer a compressed payload.

The flaw is present in the SMB Compression Transform Header, prior to any kind of authentication.

We can see the very large OriginalSize used for attacker-controlled data (4294967295 is 0xFFFFFFFF in hex which is also -1 if viewed as a signed long). This is copied into a smaller fixed buffer and results in a classic buffer overflow. Of note is the ProtocolID of \xfcSMB, which must be present and represents the magic bytes used to indicate the message must be decompressed per the spec.

However, it is not just the server-side which is vulnerable to this attack. If a client connects to a malicious SMB server, both sides run the same vulnerable code and a malicious server can respond to client requests in the same way to trigger the overflow on the initiator/client side. In this scenario, the Windows Powershell command referenced here will not be effective in stopping this attack against the SMB client. It will only be useful when implemented on the SMB server/recipient side pre-authentication.

Exposure

As always, this kind of patch should be applied as soon as possible, subject to organizational policy. While there are currently no known exploits in the wild, as you will see, causing a BSOD (blue screen of death), is quite trivial, and remains a highly effective attack method for disruption if an attacker can gain access to an internal network.

More dangerous yet are any systems exposing port 445 to the Internet, as we have seen the damage possible through similar bugs such as WannaCry. As of the time of this writing and just prior to Microsoft releasing its patch, Shodan.io appears to have just over 35,000 Windows computers reporting the vulnerable versions of software as searched by: port:445 os: “Windows” + os: “18362” for example. Many of these will likely be patched quickly now that a fix is out.

Patch Analysis

Looking at the patched version, we can see the code is now using RtlULongAdd to add  OriginalCompressedSegmentSize and the Offset/Length value. There also seem to be an extra test to make sure the size is not bigger than the whole packet plus 0x134.

Looking a little further, we can also see the usage of RtULongSub for computing the size of the compressed buffer while accounting for the offset field.

Finally, we can also notice the usage of WPP tracing code in case an error occurs (tracing was already occurring throughout the driver, but this specific function was not previously instrumented in such a way).

Impact – BSOD vs. RCE

Getting a Blue Screen of Death or BSOD is a straightforward exercise. Pivoting from that to full remote code execution will likely be more challenging, as additional bugs will likely be required to bypass Windows’ latest mitigation techniques, such as Kernel ASLR or KASLR. For this bug, the attacker will have easy primitives for the allocation of data and can control the size of the data used to trigger the overflow. On the flip side, the objects allocated in memory to store the attacker input are freed relatively quickly, making exploitation more difficult.

Product Detection/Mitigation

McAfee has released NSP ID 0x43c0e600 – NETBIOS-SS: Samba Remote Code Execution Vulnerability (CVE-2020-0796) to address exploitation of the vulnerability. We are working on developing additional signatures to complement or replace this coverage.

 

The post SMBGhost – Analysis of CVE-2020-0796 appeared first on McAfee Blog.

Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting

7 April 2020 at 13:01

While not a new practice, the sheer volume of people required to adhere to social distancing best practices means we now have a mass workforce working remotely. Most enterprises and SMBs can support working remotely today but many IT departments are not equipped to scale to the numbers currently required. In this blog we discuss the threats to enterprises and SMBs through this increased remote workforce and how to mitigate the risk.

Cybercriminals seek opportunities to achieve their goals and will follow the path of least resistance. The initial access vectors enumerated in MITRE ATT&CK typically used by cyber criminals are phishing or exploitation of vulnerabilities to gain access to an organization, and are used to act on their malicious objectives. Now that employees have migrated to their homes to work remotely, cybercriminals will target the insecurities of consumer systems and networks to gain access to corporations. As Raj Samani highlighted in a previous post, targeted ransomware attacks are fueling the increased demand in the underground for compromised corporate networks. If employees access corporate networks from pre-infected unmanaged machines without adequate security measures, it creates a much larger attack surface for cybercriminals. This increases the risk of an organization falling victim to a potential breach and ransomware lockdown.

COVID-19 social distancing restrictions came into effect very rapidly, giving organizations little time to prepare for securely managing their workforce remotely. It is important that organizations continue to do business during this tough time, but they must also do it securely to prevent an attack such as ransomware. To protect organizations in this current climate we must approach this from two perspectives:

  1. Know your environment and users
  2. Know your business and real threats

To understand the threats of telecommuting at scale, we must understand the technologies typically used by remote workers to execute their work and access the organization.

Know Your Environment and Users

Per figure 1 below, it is important to understand the architecture and technologies being used by your employees within your business environment. This gives you visibility into your potential exposure based on vulnerabilities being actively exploited by threat actors so that you can protect your remote workers and business infrastructure/assets.

 

Trust boundaries, common technologies and use cases in telecommuter deployments

Know Your Business and Real Threats

Adversary Opportunities

Adversaries need an initial access vector to gain a foothold within an organization. They will typically seek out corporate usernames and passwords using techniques enumerated in MITRE ATT&CK, such as phishing or remote exploitation of software vulnerabilities. The telecommuter technology increases the attack surface significantly and is being exploited/researched as evident below:

Controls

Minimum technical controls for remote worker machines:

  • Secure configuration and strong passwords to prevent router compromise
  • Keep all software layers patched, VPNs and telecommuter applications
  • Do not reuse passwords across personal and work systems
  • Robust endpoint security software

Minimum technical controls for enterprise/SMBs:

  • Security hygiene best practices
  • MFA/2FA and logging for VPN accounts
  • VPN patching
  • Secure RDP access
  • Segmentation of critical business assets
  • Data backups
  • User and device identity for employees and 3rd parties/suppliers

Policies:

  • Data loss prevention
  • Strong passwords
  • SaaS security
  • Managed vs unmanaged device access

Training:

  • Phishing and social engineering training based on the current climate context – “verify before trusting”
  • Keep employees informed of phishing campaigns relative to your environment and business

Conclusion

Strong technical controls are a must to protect telecommuters in the current climate and there is also no substitute for employee phishing and social engineering training as a successful phish can negate technical controls. Even MFA/2FA can be bypassed in some cases, using advanced phishing techniques, so we must all stay vigilant, starting with ourselves to protect our organizations by adopting a “verify before trusting” approach.

The post Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting appeared first on McAfee Blog.

Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates

9 March 2021 at 18:13
how to run a virus scan

Overview

For the March 2021 Patch Tuesday, Microsoft released a set of seven DNS vulnerabilities. Five of the vulnerabilities are remote code execution (RCE) with critical CVSS (Common Vulnerability Scoring Standard) scores of 9.8, while the remaining two are denial of service (DoS). Microsoft shared detection guidance and proofs of concept with MAPP members for two of the RCE vulnerabilities, CVE-2021-26877 and CVE-2021-26897, which we have confirmed to be within the DNS Dynamic Zone Update activity. Microsoft subsequently confirmed that all seven of the DNS vulnerabilities are within the Dynamic Zone Update activity.

We confirmed from our analysis of CVE-2021-26877 and CVE-2021-26897, in addition to further clarification from Microsoft, that none of the five DNS RCE vulnerabilities are wormable.

RCE vulnerabilities
CVE-2021-26877, CVE-2021-26897 (exploitation more likely)
CVE-2021-26893, CVE-2021-26894, CVE-2021-26895 (exploitation less likely)

DoS vulnerabilities
CVE-2021-26896, CVE-2021-27063 (exploitation less likely)

A critical CVSS score of 9.8 means that an attacker can remotely compromise a DNS server with no authentication or user interaction required. Successful exploitation of these vulnerabilities would lead to RCE on a Primary Authoritative DNS server. While CVSS is a great tool for technical scoring, it needs to be taken in context with your DNS deployment environment to understand your risk which we discuss below.

We highly recommend you urgently patch your Windows DNS servers if you are using Dynamic Updates. If you cannot patch, we recommend you prioritize evaluating your exposure. In addition, we have developed signatures for CVE-2021-26877 and CVE-2021-26897 which are rated as “exploitation more likely” by Microsoft.

DNS Dynamic Updates, Threats and Deployment

Per the NIST “Secure Domain Name System (DNS) Deployment Guide”, DNS threats can be divided into Platform and Transaction Threats. The platform threats can be classed as either DNS Host Platform or DNS Software Threats. Per Table 1 below, Dynamic Update is one of the four DNS Transaction types. The seven DNS vulnerabilities are within the Dynamic Update DNS transaction feature of Windows DNS Software.

Table 1: DNS Transaction Threats and Security Objectives

The DNS Dynamic Zone Update feature allows a client to update its Resource Records (RRs) on a Primary DNS Authoritative Server, such as when it changes its IP address; these clients are typically Certificate Authority (CA) and DHCP servers. The Dynamic Zone Update feature can be deployed on a standalone DNS server or an Active Directory (AD) integrated DNS server. Best practice is to deploy DNS integrated with (AD) so it can avail itself of Microsoft security such as Kerberos and GSS-TSIG.

When creating a Zone on a DNS server there is an option to enable or disable DNS Dynamic Zone Updates. When DNS is deployed as a standalone server, the Dynamic Zone Update feature is disabled by default but can be enabled in secure/nonsecure mode. When DNS is deployed as AD integrated, the Dynamic Zone Update feature is enabled in secure mode by default.

Secure Dynamic Zone Update verifies that all RR updates are digitally signed using GSS-TSIG from a domain-joined machine. In addition, more granular controls can be applied on what principal can perform Dynamic Zone Updates.

Insecure Dynamic Zone Update allows any machine to update RRs without any authentication (not recommended).

Attack Pre-requisites

  • AD Integrated DNS Dynamic Updates (default config of secure updates)
    • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this)
    • Domain-joined machine
    • Attacker must craft request to DNS server and supply a target Zone in request
  • Standalone DNS Server (secure/nonsecure config)
    • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this) 
    • Attacker must craft request to DNS server and supply a target Zone in request 

From a Threat Model perspective, we must consider Threat Actor motives, capabilities, and access/opportunity, so you can understand the risk relative to your environment. We are not aware of any exploitation in the wild of these vulnerabilities so we must focus on the access capabilities, i.e., close the door on the threat actor opportunity. Table 2 summarizes DNS Dynamic Update deployment models relative to the opportunity these RCE vulnerabilities present.

Table 2: Threat Actor access relative to deployment models and system impact

The highest risk deployment would be a DNS server in Dynamic Update insecure mode exposed to the internet; this is not best security practice and based on our experience, we do not know of a use case for such deployment.

Deploying AD integrated DNS Dynamic Update in secure mode (default) mitigates the risk of an unauthenticated attacker but still has a high risk of a compromised domain computer or trusted insider being able to achieve RCE.

Vulnerability Analysis

All the vulnerabilities are related to the processing of Dynamic Update packets in dns.exe. The goal of our vulnerability analysis, as always for critical industry vulnerabilities, is to ensure we can generate accurate signatures to protect our customers.

Analysis of CVE-2021-26877

  • The vulnerability is triggered when a Zone is updated with a TXT RR that has a “TXT length” greater than “Data length” per Wireshark below:

Figure 1: Wireshark view of exploit packet classifying the DNS packet as malformed

  • The vulnerability is in the File_PlaceStringInFileBuffer() function as you can see from WinDbg output below:

Figure 2: WinDbg output of crash while attached to dns.exe

  • The vulnerability is an Out of bounds (OOB) read on the heap when the “TXT length” field of DNS Dynamic Zone Update is not validated relative to “Data length”. This could allow an attacker to read up to 255 bytes of memory. Microsoft states this vulnerability can be used to achieve RCE; this would require a further OOB write primitive.
  • The memory allocation related to the OOB read is created within the CopyWireRead() function. Relevant pseudo code for this function is below:

  • The File_PlaceStringInFileBuffer() function copies data from TXT_data allocated from CopyWireRead() function previously. However, the UpdateRR->TXT length value from Wireshark is not validated and used to copy from *UpdateRR->Data length. Because UpdateRR->TXT length is not validated relative to UpdateRR->Data length it results in a OOB read from heap memory.

Analysis of CVE-2021-26897

  • The vulnerability is triggered when many consecutive Signature RRs Dynamic Updates are sent
  • The vulnerability is an OOB write on the heap when combining the many consecutive Signature RR Dynamic Updates into base64-encoded strings before writing to the Zone file
  • Microsoft states this vulnerability can be used to achieve RCE

Figure 3: Packet containing many consecutive Signature RR dynamic updates. Pay special attention to the length field of the reassembled flow.

Exploitability

Exploiting these vulnerabilities remotely requires both read and write primitives in addition to bypassing Control Flow Guard (CFG) for execution. The DNS protocol has significant remote unauthenticated attack surface to facilitate generating such primitives which has been researched as part of CVE-2020-1350 (SigRed). In addition, per the RR_DispatchFuncForType() function, there are read and write functions as part of its dispatch table.

Figure 4: Path of DNS RR update packet

Figure 5: Dispatch functions for reading and writing

Mitigations

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to audit your DNS deployment configuration to limit Dynamic Zone Updates to trusted servers only. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of both vulnerabilities, CVE-2021-26877 and CVE-2021-26897 

NSP Attack ID: 0x4030e700 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26877)
NSP Attack ID: 0x4030e800 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26897)

In addition, NIST “Secure Domain Name System (DNS) Deployment Guide” provides best practices for securing DNS deployment such as:

  1. DNS Primary Server should restrict clients that can update RRs
  2. Secure Dynamic Update using GSS-TSIG
  3. Secondary DNS Server Dynamic Update forwarding restrictions using GSS-TSIG
  4. Fine-grained Dynamic Update restrictions using GSS-TSIG

The post Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates appeared first on McAfee Blog.

❌
❌