🔒
There are new articles available, click to refresh the page.
Before yesterdayMain stream

Hackers behind Twilio data breach also targeted Cloudflare employees

10 August 2022 at 13:48

Cloudflare revealed that at least 76 employees and their family members were targeted by smishing attacks similar to the one that hit Twilio.

The content delivery network and DDoS mitigation company Cloudflare revealed this week that at least 76 employees and their family members received text messages on their personal and work phones.

According to the company, the attack is very similar to the one that recently targeted the Communications company Twilio.

“Yesterday, August 8, 2022, Twilio shared that they’d been compromised by a targeted phishing attack. Around the same time as Twilio was attacked, we saw an attack with very similar characteristics also targeting Cloudflare’s employees.” reads the announcement published by Cloudflare. While individual employees did fall for the phishing messages, we were able to thwart the attack through our own use of Cloudflare One products, and physical security keys issued to every employee that are required to access all our applications.”

cloudflare smishing

Cloudflare pointed out that its systems were not compromised, it also added that its Cloudforce One threat intelligence team was able to perform additional analysis of the attack.

The experts believe that this is a sophisticated attack targeting employees and systems of multiple organizations,

On July 20, 2022, the company received reports of employees receiving text messages containing links to what appeared to be a Cloudflare Okta login page. The company uses Okta as its identity provider and messages include a link to a phishing page that was designed to look identical to a legitimate Okta login page.  The attackers sent the messages to at least 76 employees in less than 1 minute, but the company security team was not able to determine how the threat actors obtained the list of employees’ phone numbers.

“They came from four phone numbers associated with T-Mobile-issued SIM cards: (754) 268-9387, (205) 946-7573, (754) 364-6683 and (561) 524-5989. They pointed to an official-looking domain: cloudflare-okta.com.” continues the report. “That domain had been registered via Porkbun, a domain registrar, at 2022-07-20 22:13:04 UTC — less than 40 minutes before the phishing campaign began.”

Once the recipient of the message has provided his credentials through the phishing page, the credentials were immediately sent to the attacker via the messaging service Telegram. Experts states that the real-time relay was crucial for the attackers because the phishing page would also prompt for a Time-based One Time Password (TOTP) code. Once obtained this info the attackers can access the victim company’s actual login page.

According to Cloudflare, only three employees fell for the phishing message and entered their credentials. However, the company does not use TOTP codes, instead, its employees use a FIDO2-compliant security YubiKey key. This means that without the hardware key, attackers cannot access the company systems even knowing the credentials.

Researchers also discovered that in some cases the phishing page was used to deliver the malicious payloads, including AnyDesk’s remote access software. The software would allow an attacker to control the victim’s machine remotely.

“We confirmed that none of our team members got to this step. If they had, however, our endpoint security would have stopped the installation of the remote access software.” concludes Cloudflare.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, smishing)

The post Hackers behind Twilio data breach also targeted Cloudflare employees appeared first on Security Affairs.

The Security Pros and Cons of Using Email Aliases

10 August 2022 at 15:10

One way to tame your email inbox is to get in the habit of using unique email aliases when signing up for new accounts online. Adding a “+” character after the username portion of your email address — followed by a notation specific to the site you’re signing up at — lets you create an infinite number of unique email addresses tied to the same account. Aliases can help users detect breaches and fight spam. But not all websites allow aliases, and they can complicate account recovery. Here’s a look at the pros and cons of adopting a unique alias for each website.

What is an email alias? When you sign up at a site that requires an email address, think of a word or phrase that represents that site for you, and then add that prefaced by a “+” sign just to the left of the “@” sign in your email address. For instance, if I were signing up at example.com, I might give my email address as [email protected] Then, I simply go back to my inbox and create a corresponding folder called “Example,” along with a new filter that sends any email addressed to that alias to the Example folder.

Importantly, you don’t ever use this alias anywhere else. That way, if anyone other than example.com starts sending email to it, it is reasonable to assume that example.com either shared your address with others or that it got hacked and relieved of that information. Indeed, security-minded readers have often alerted KrebsOnSecurity about spam to specific aliases that suggested a breach at some website, and usually they were right, even if the company that got hacked didn’t realize it at the time.

Alex Holden, founder of the Milwaukee-based cybersecurity consultancy Hold Security, said many threat actors will scrub their distribution lists of any aliases because there is a perception that these users are more security- and privacy-focused than normal users, and are thus more likely to report spam to their aliased addresses.

Holden said freshly-hacked databases also are often scrubbed of aliases before being sold in the underground, meaning the hackers will simply remove the aliased portion of the email address.

“I can tell you that certain threat groups have rules on ‘+*@’ email address deletion,” Holden said. “We just got the largest credentials cache ever — 1 billion new credentials to us — and most of that data is altered, with aliases removed. Modifying credential data for some threat groups is normal. They spend time trying to understand the database structure and removing any red flags.”

According to the breach tracking site HaveIBeenPwned.com, only about .03 percent of the breached records in circulation today include an alias.

Email aliases are rare enough that seeing just a few email addresses with the same alias in a breached database can make it trivial to identify which company likely got hacked and leaked said database. That’s because the most common aliases are simply the name of the website where the signup takes place, or some abbreviation or shorthand for it.

Hence, for a given database, if there are more than a handful of email addresses that have the same alias, the chances are good that whatever company or website corresponds to that alias has been hacked.

That might explain the actions of Allekabels, a large Dutch electronics web shop that suffered a data breach in 2021. Allekabels said a former employee had stolen data on 5,000 customers, and that those customers were then informed about the data breach by Allekabels.

But Dutch publication RTL Nieuws said it obtained a copy of the Allekabels user database from a hacker who was selling information on 3.6 million customers at the time, and found that the 5,000 number cited by the retailer corresponded to the number of customers who’d signed up using an alias. In essence, RTL argued, the company had notified only those most likely to notice and complain that their aliased addresses were suddenly receiving spam.

“RTL Nieuws has called more than thirty people from the database to check the leaked data,” the publication explained. “The customers with such a unique email address have all received a message from Allekabels that their data has been leaked – according to Allekabels they all happened to be among the 5000 data that this ex-employee had stolen.”

HaveIBeenPwned’s Hunt arrived at the conclusion that aliases account for about .03 percent of registered email addresses by studying the data leaked in the 2013 breach at Adobe, which affected at least 38 million users. Allekabels’s ratio of aliased users was considerably higher than Adobe’s — .14 percent — but then again European Internet users tend to be more privacy-conscious.

While overall adoption of email aliases is still quite low, that may be changing. Apple customers who use iCloud to sign up for new accounts online automatically are prompted to use Apple’s Hide My Email feature, which creates the account using a unique email address that automatically forwards to a personal inbox.

What are the downsides to using email aliases, apart from the hassle of setting them up? The biggest downer is that many sites won’t let you use a “+” sign in your email address, even though this functionality is clearly spelled out in the email standard.

Also, if you use aliases, it helps to have a reliable mnemonic to remember the alias used for each account (this is a non-issue if you create a new folder or rule for each alias). That’s because knowing the email address for an account is generally a prerequisite for resetting the account’s password, and if you can’t remember the alias you added way back when you signed up, you may have limited options for recovering access to that account if you at some point forget your password.

What about you, Dear Reader? Do you rely on email aliases? If so, have they been useful? Did I neglect to mention any pros or cons? Feel free to sound off in the comments below.

Former Twitter Employee Found Guilty of Spying for Saudi Arabia

10 August 2022 at 15:12
A former Twitter employee has been pronounced guilty for his role in digging up private information pertaining to certain Twitter users and turning over that data to Saudi Arabia. Ahmad Abouammo, 44, was convicted by a jury after a two-week trial in San Francisco federal court, Bloomberg reported Tuesday. He faces up to 20 years in prison when sentenced. The verdict comes nearly three years

Experts found 10 malicious packages on PyPI used to steal developers’ data

10 August 2022 at 15:14

10 packages have been removed from the Python Package Index (PyPI) because they were found harvesting data.

Check Point researchers have discovered ten malicious packages on the Python Package Index (PyPI). The packages install info-stealers that allow threat actors to steal the private data and personal credentials of the developers.

The researchers provide details about the malicious packages:

  • Ascii2text is a malicious package that mimics the popular art package by name and description. The code on the __init__.py file downloads and executes a malicious script that searches for local passwords and uploads them using a discord web hook.
  • Pyg-utilsPymocks and PyProto2 are malicious packages to that allows attackers to steal users’ AWS credentials.
  • Free-net-vpn and Free-net-vpn2 are malicious packages developed to target environment variables.
  • Test-async downloads and executes malicious payloads.
  • Zlibsrc downloads and executes malicious payloads.
  • Free-net-vpn and Free-net-vpn2 are malicious packages that target environment variables.
  • WINRPCexploit a malicious package that steals users’ credentials as part of its setup.py installation script.
  • Browserdiv is able to steal the installers credentials by collecting and sending them to a predefined discord webhook.
PyPI 2
Ascii2Text The malicious snippet inside the __init__.py

Unfortunately, in recent months, many other malicious packages have been found on the official PyPI repository.

In June 2022, Sonatype researchers discovered multiple Python packages in the official PyPI repository that have been developed to steal secrets (i.e. AWS credentials and environment variables) and also upload these to a publicly exposed endpoint.

In November 2021, JFrog researchers discovered 11 malicious Python packages in the Python Package Index (PyPI) repository that can steal Discord access tokens, passwords, and even carry out dependency confusion attacks.

Supply chain attacks are designed to exploit trust relationships between an organization and external parties. These relationships could include partnerships, vendor relationships, or the use of third-party software. Cyber threat actors will compromise one organization and then move up the supply chain, taking advantage of these trusted relationships to gain access to other organizations’ environments.” concludes the report. “Such attacks became more frequent and grew in impact in recent years, therefore it is essential developers make sure are keeping their actions safe, double checking every software ingredient in use and especially such that are being downloaded from different repositories, especially ones which were not self-created.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, PyPI)

The post Experts found 10 malicious packages on PyPI used to steal developers’ data appeared first on Security Affairs.

Micropatches For "KrbRelay" Local Privilege Escalation Vulnerability (Wontfix/0day)

10 August 2022 at 15:42


 

by Mitja Kolsek, the 0patch Team


"KrbRelay" is a tool for forced authentication issue in Windows that can be used by a low-privileged domain user to take over a Windows computer, potentially becoming a local or domain admin within minutes. The tool, based on James Forshaw's research, was developed by security researcher cube0x0, and was later wrapped by Mor Davidovich into another tool called "KrbRelayUp" that further automated attack steps for escalating privileges.

KrbRelay provides various options to launch different versions of attack; some of these options were already known under the name RemotePotato0, for which we already had patches before. What was new for us with KrbRelay was its capability to launch a local service (running in session 0) via RPC and exploit it for leaking Local System credentials through forced authentication. In order to be exploitable, a service must allow authentication over the network, and just two such services were identified on affected Windows versions:

  1. ActiveX Installer Service, identified by CLSID 90f18417-f0f1-484e-9d3c-59dceee5dbd8; and
  2. RemoteAppLifetimeManager.exe, identified by CLSID 0bae55fc-479f-45c2-972e-e951be72c0c1.


Microsoft does not fix forced authentication issues unless an attack can be mounted anonymously. Our customers unfortunately can't all disable relevant services or implement mitigations without breaking production, so it is on us to provide them with such patches.

For the purpose of identifying vulnerabilities we decided to name the vulnerability exposing the above services "KrbRelay", as other attack vectors provided by the tool were already blocked by our existing patches for RemotePotato0. We decided to inject our patch logic at the point where a local unprivileged attacker launches the exploitable service, because such patch would be fairly simple - and we like it simple: it's harder to make mistakes.

Our patch, source code shown below, resides in rpcss.dll and checks whether someone is trying to launch one of the above services via RPC; in such case, if the requestor's token is elevated, we allow it, otherwise not. This is the same approach as we used with patching RemotePotato0.



MODULE_PATH "..\Affected_Modules\rpcss.dll_10.0.17763.3113_Srv2019_64-bit_u202207\rpcss.dll"
PATCH_ID 992
PATCH_FORMAT_VER 2
VULN_ID 7416
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x6674
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT Advapi32.dll!GetTokenInformation,ntdll!_strnicmp,rpcss.dll!0x68ccd
    ; memory representation:    17 84 f1 90 f1 f0 4e 48 9d 3c 59 dc ee e5 db d8
    ; clsid:                    90f18417-f0f1-484e-9d3c-59dceee5dbd8

    code_start
        call VAR                       
        dd 0x90f18417                 ; CIeAxiInstallerService Class
        dw 0xf0f1, 0x484e
        db 0x9d, 0x3c, 0x59, 0xdc, 0xee, 0xe5, 0xdb, 0xd8
    VAR:
        pop rcx                       ; rcx => clsid in memory respresentation
        mov rdx, [rbx]                ; ClientToken hadle
        mov r8, 16                    ; length to compare
        call PIT__strnicmp            ; Compares the specified number of characters
                                      ; of two strings without regard to case
        cmp rax, 0                    ; rax == 0 string are equal
        jne CONTINUE                  ; if rax != 0 continue normal code flow

        mov rdx, [rbx+8]
        mov rdx, [rdx]
        mov rcx, [rdx+40h]            ; current session token, TokenHandle
        mov rdx, 14h                  ; TokenInformationClass, TokenElevation
        sub rsp, 30h                  ; home space + vars
        lea r8, [rsp+30h]             ; TokenInformation
        mov qword[rsp+30h], 0         ; memset
        mov r9, 4                     ; TokenInformationLength
        lea rax, [rsp+28h]            ; ReturnLength address
        mov [rsp+20h], rax            ; pointer to address
        call PIT_GetTokenInformation  ; The GetTokenInformation function retrieves a
                                      ; specified type of information about an access token
        add rsp, 30h                  ; restore stack pointer
        cmp byte[rsp], 0              ; token elevated?
        je PIT_0x68ccd                ; if elevated(1) continue normal code flow

    CONTINUE:
       
    code_end
patchlet_end


 

Micropatch Availability

While this vulnerability has no official vendor patch and could be considered a "0day", Microsoft seems determined not to fix relaying issues such as this one; therefore, this micropatch is not provided in the FREE plan but requires a PRO or Enterprise license.

The micropatch was written for the following Versions of Windows with all available Windows Updates installed: 

  1. Windows 10 v21H2
  2. Windows 10 v21H1
  3. Windows 10 v20H2
  4. Windows 10 v2004
  5. Windows 10 v1909
  6. Windows 10 v1903
  7. Windows 10 v1809
  8. Windows 10 v1803
  9. Windows 7 (no ESU, ESU year 1, ESU year 2)
  10. Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
  11. Windows Server 2012
  12. Windows Server 2012 R2
  13. Windows Server 2016
  14. Windows Server 2019 
  15. Windows Server 2022 
 
This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank James Forshaw and cube0x0 for sharing details about this vulnerability and sharing a tool, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

Risky Business: Enterprises Can’t Shake Log4j flaw

10 August 2022 at 17:17

70% of Large enterprises that previously addressed the Log4j flaw are still struggling to patch Log4j-vulnerable assets.

INTRODUCTION

In December 2021 security teams scrambled to find Log4j-vulnerable assets and patch them. Eight months later many Global 2000 firms are still fighting to mitigate the digital assets and business risks associated with Log4j. The ease of Log4j vulnerability exploitation coupled with the critical nature of the bug, which allows attackers to run arbitrary code inside cloud and company networks, is driving a business-risk imperative to find vulnerable assets and patch them fast.  

Log4j CVE-2021-44832

An examination by CyCognito of large enterprise external attack surfaces found 70% of firms that previously addressed Log4j in their attack surface are still struggling to patch Log4j-vulnerable assets and prevent new instances of Log4j from resurfacing within their IT stack.

Our research highlights business continuity risks such as digital asset sprawl, subsidiary risk and the importance of reducing the time it takes to identify a vulnerable Log4j asset and patch it.

Log4j: Analysis of Current and Lasting Legacy

On Dec. 9, 2021 the Log4j critical vulnerability (CVE-2021-44228) was first identified and was assigned a severity rating of 10 out of 10. It is a remote code execution class flaw found in the Apache Log4j library (part of the Apache Logging Project). This Log4j vulnerability is considered extremely dangerous because it is easy to exploit and soon after its discovery a public proof-of-concept became available.

Eight months later, Log4j has proven to be one of the worst vulnerabilities of the last few years, if not decade.

A July report (PDF) by the U.S. Department of Homeland Security stated: “The Log4j event is not over. Log4j remains deeply embedded in systems, and even within the short period available for our review, community stakeholders have identified new compromises, new threat actors, and new learnings.”

Report Highlights:

Our exclusive analysis of Log4j examines the external attack surfaces of three dozen Global 2000 companies, securely protected by CyCognito solutions. This report underscores the Log4j cybersecurity risks facing non-CyCognito customers and the at large cybersecurity community.

Incidents of vulnerable Log4j assets discovered by the CyCognito platform are based on simulated adversarial scans of exposed assets in the wild. These instances of Log4j (now mitigated) represented briefly exposed assets that, if overlooked, could have allowed an attacker access to the cloud or on-premises assets and networks of these organizations.   

Top Log4j Takeaways for July 2022:  

  • Instances of Log4j-vulnerable assets are growing, not shrinking within a subset of companies examined.
  • Some firms are seeing a doubling of Log4j-vulnerable digital assets within their external attack surface – not a decrease.
  • Only 30% of firms with at least one past Log4j issue had no Log4j-vulnerable assets at the time of our analysis.
  • Of those exposed Log4j-vulnerable assets, the most common were web applications.

Drilling Down on Data Points

Growing not Shrinking: After eradicating an external attack surface of Log4j-vulnerable digital assets, new instances of Log4j-vulnerable systems have come back online. 

Of those firms with at least one Log4j vulnerability discovered in January 2022, 62% continued to report one or more Log4j-vulnerable assets exposed in July. Research did not indicate whether those were new or existing exposures.

Of the firms that did have an exposed asset in July, 38% experienced a gain of one or more Log4j-vulnerable assets. Data indicates that, for many companies, instances of new Log4j exposed assets remains a growing problem.   

Double the Log4j Trouble: An examination of organizations revealed 21% of those with vulnerable assets in July experienced a triple-digit percentage growth in the number of exposed Log4j-vulnerable assets compared to January.

While the initial number of vulnerable assets were small within each organization examined, over a half-dozen are seeing a steady increase in the number of Log4j-vulnerable assets. One firm, with seven exposed assets in February of 2022 had 39 exposed assets in July.

Success Rates Rare: The number of organizations that experienced a drop in vulnerable assets was 38%. In each of those instances, CyCognito found zero instances of Log4J in their internet exposed attack surface in July.

Thirty-four percent of those firms with over one vulnerable asset in January had the same number of assets exposed in July.

Web App Worries: Breaking down the numbers even more, data reveals those firms with vulnerable assets had a greater number of web applications vulnerable to a Log4j exploit versus other types of systems.

This is concerning given web apps are high risk for business and their users alike because they often access or contain sensitive financial, confidential, or personally identifiable information.

Why Businesses are Struggling to Quash Log4j  

A CyCognito analysis of why companies are struggling to squelch Log4j vulnerabilities once and for all are multifold.

First, organizations have underestimated the deep-rooted prevalence of Log4j software, and software vendors have not yet rid their products of the vulnerable Log4j code. The battle to mitigate Log4j-vulnerable assets is exacerbated by new instances of exploitable Log4j being introduced to an attack surface.

Further driving this trend is attack surface sprawl, subsidiary and business-unit risk, mergers and acquisitions (M&A) and a lag in the time to remediate vulnerabilities (known as mean-time-to-remediate, or MTTR). 

CyCognito found that among Global 2000 companies, M&A activity is growing or shrinking an organization’s attack surface by 5.5% each month (PDF). Organizations were initially unaware of 10-to-30% of their subsidiaries, according to separate CyCognito research published in June.

(See related CyCognito June report: “Anybody Got a Map?”)

The global consultancy Bain & Company reports that M&A activity in 2022 is likely to reach US$4.7 trillion in deal value, making it the second-largest year on record. That kind of business change combined with emergent risks and poor IT ecosystem visibility make it extremely difficult for security and IT managers to have a 360-degree view of their entire external attack surface. This increases the odds of security gaps in their attack surface going unseen, opening them up to dangerous and preventable risks such as Log4j.  

Why a Focus on Risk, Versus Vulnerability, is Paramount to Log4j Exposures  

Trends in the growth of external attack surface sprawl are making it harder for security teams to reduce the mean time to remediate vulnerabilities – including Log4j.

In June 2021, the average time to fix a high-risk application vulnerability was estimated at 246 days (8.2 months), soaring from 194 days (6.5 months) at the start of that year, according to a study from Synopsys.

A CyCognito-sponsored research report by Informa Tech found security teams are suffering from cybersecurity debt issues. That’s when new cybersecurity issues outpace a security teams’ ability to mitigate existing ones.

Compounding the problem is inadequate and incomplete security scanning of external attack surfaces for vulnerabilities and other risks. CyCognito found competing discovery tools can leave between 10-to-50% of digital assets undiscovered and therefore untested and ignored.  

Informa Tech found the majority of security teams only have the bandwidth to remediate about 50 vulnerabilities in an average month. Considering the deluge of new vulnerabilities discovered each month, current remediation rates are insufficient to keep pace with high and critical risk vulnerabilities such as Log4j issues. 

That’s why CyCognito advocates a business-risk-first management approach to cybersecurity that focuses on identifying and addressing the most urgent risks (such as Log4j) immediately within an attack surface.  

If you want to have info on how CyCognito can help organizations find and remediate Log4j business risks with its unmatched ability to continuously discover the external attack surfaces of its customers give a look at the original analysis of the company:  

https://www.cycognito.com/blog/log4j_risky-business?hs_preview=SXnnXKfC-81448195746

About the author: TOM SPRING, MEDIA MANAGER

Tom Spring, Media Manager, is a seasoned technology reporter and editor who has helped bring stories to life for over three decades.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Log4j flaw)

The post Risky Business: Enterprises Can’t Shake Log4j flaw appeared first on Security Affairs.

Cisco Talos shares insights related to recent cyber attack on Cisco

10 August 2022 at 19:30

Update History


Date Description of Updates
Aug. 10th 2022 Adding clarifying details on activity involving active directory.
Aug. 10th 2022 Update made to the Cisco Response and Recommendations section related to MFA.

 Executive summary


  • On May 24, 2022, Cisco became aware of a potential compromise. Since that point, Cisco Security Incident Response (CSIRT) and Cisco Talos have been working to remediate. 
  • During the investigation, it was determined that a Cisco employee’s credentials were compromised after an attacker gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized. 
  • The attacker conducted a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications initiated by the attacker. The attacker ultimately succeeded in achieving an MFA push acceptance, granting them access to VPN in the context of the targeted user. 
  • CSIRT and Talos are responding to the event and we have not identified any evidence suggesting that the attacker gained access to critical internal systems, such as those related to product development, code signing, etc. 
  • After obtaining initial access, the threat actor conducted a variety of activities to maintain access, minimize forensic artifacts, and increase their level of access to systems within the environment. 
  • The threat actor was successfully removed from the environment and displayed persistence, repeatedly attempting to regain access in the weeks following the attack; however, these attempts were unsuccessful. 
  • We assess with moderate to high confidence that this attack was conducted by an adversary that has been previously identified as an initial access broker (IAB) with ties to the UNC2447 cybercrime gang, Lapsus$ threat actor group, and Yanluowang ransomware operators. 
  • For further information see the Cisco Response page here.


Initial vector


Initial access to the Cisco VPN was achieved via the successful compromise of a Cisco employee’s personal Google account. The user had enabled password syncing via Google Chrome and had stored their Cisco credentials in their browser, enabling that information to synchronize to their Google account. After obtaining the user’s credentials, the attacker attempted to bypass multifactor authentication (MFA) using a variety of techniques, including voice phishing (aka "vishing") and MFA fatigue, the process of sending a high volume of push requests to the target’s mobile device until the user accepts, either accidentally or simply to attempt to silence the repeated push notifications they are receiving. Vishing is an increasingly common social engineering technique whereby attackers try to trick employees into divulging sensitive information over the phone. In this instance, an employee reported that they received multiple calls over several days in which the callers – who spoke in English with various international accents and dialects – purported to be associated with support organizations trusted by the user.  

Once the attacker had obtained initial access, they enrolled a series of new devices for MFA and authenticated successfully to the Cisco VPN. The attacker then escalated to administrative privileges, allowing them to login to multiple systems, which alerted our Cisco Security Incident Response Team (CSIRT), who subsequently responded to the incident. The actor in question dropped a variety of tools, including remote access tools like LogMeIn and TeamViewer, offensive security tools such as Cobalt Strike, PowerSploit, Mimikatz, and Impacket, and added their own backdoor accounts and persistence mechanisms. 


Post-compromise TTPs


Following initial access to the environment, the threat actor conducted a variety of activities for the purposes of maintaining access, minimizing forensic artifacts, and increasing their level of access to systems within the environment. 

Once on a system, the threat actor began to enumerate the environment, using common built-in Windows utilities to identify the user and group membership configuration of the system, hostname, and identify the context of the user account under which they were operating. We periodically observed the attacker issuing commands containing typographical errors, indicating manual operator interaction was occurring within the environment. 

After establishing access to the VPN, the attacker then began to use the compromised user account to logon to a large number of systems before beginning to pivot further into the environment. They moved into the Citrix environment, compromising a series of Citrix servers and eventually obtained privileged access to domain controllers.  

After obtaining access to the domain controllers, the attacker began attempting to dump NTDS from them using “ntdsutil.exe” consistent with the following syntax:
powershell ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\users\public' q q 
They then worked to exfiltrate the dumped NTDS over SMB (TCP/445) from the domain controller to the VPN system under their control.

After obtaining access to credential databases, the attacker was observed leveraging machine accounts for privileged authentication and lateral movement across the environment. 

Consistent with activity we previously observed in other separate but similar attacks, the adversary created an administrative user called “z” on the system using the built-in Windows “net.exe” commands. This account was then added to the local Administrators group. We also observed instances where the threat actor changed the password of existing local user accounts to the same value shown below. Notably, we have observed the creation of the “z” account by this actor in previous engagements prior to the Russian invasion of Ukraine. 
C:\Windows\system32\net user z Lh199211* /add 
C:\Windows\system32\net localgroup administrators z /add
This account was then used in some cases to execute additional utilities, such as adfind or secretsdump, to attempt to enumerate the directory services environment and obtain additional credentials. Additionally, the threat actor was observed attempting to extract registry information, including the SAM database on compromised windows hosts.  
reg save hklm\system system 
reg save hklm\sam sam 
reg save HKLM\security sec
On some systems, the attacker was observed employing MiniDump from Mimikatz to dump LSASS. 
tasklist | findstr lsass 
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump [LSASS_PID] C:\windows\temp\lsass.dmp full
The attacker also took steps to remove evidence of activities performed on compromised systems by deleting the previously created local Administrator account. They also used the “wevtutil.exe” utility to identify and clear event logs generated on the system. 
wevtutil.exe el 
wevtutil.exe cl [LOGNAME]
In many cases, we observed the attacker removing the previously created local administrator account.  
net user z /delete
To move files between systems within the environment, the threat actor often leveraged Remote Desktop Protocol (RDP) and Citrix. We observed them modifying the host-based firewall configurations to enable RDP access to systems. 
netsh advfirewall firewall set rule group=remote desktop new enable=Yes
We also observed the installation of additional remote access tools, such as TeamViewer and LogMeIn. 
C:\Windows\System32\msiexec.exe /i C:\Users\[USERNAME]\Pictures\LogMeIn.msi
The attacker frequently leveraged Windows logon bypass techniques to maintain the ability to access systems in the environment with elevated privileges. They frequently relied upon PSEXESVC.exe to remotely add the following Registry key values:  
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\narrator.exe /v Debugger /t REG_SZ /d C:\windows\system32\cmd.exe /f 
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe /v Debugger /t REG_SZ /d C:\windows\system32\cmd.exe /f
This enabled the attacker to leverage the accessibility features present on the Windows logon screen to spawn a SYSTEM level command prompt, granting them complete control of the systems. In several cases, we observed the attacker adding these keys but not further interacting with the system, possibly as a persistence mechanism to be used later as their primary privileged access is revoked.  

Throughout the attack, we observed attempts to exfiltrate information from the environment. We confirmed that the only successful data exfiltration that occurred during the attack included the contents of a Box folder that was associated with a compromised employee’s account and employee authentication data from active directory. The Box data obtained by the adversary in this case was not sensitive.  

In the weeks following the eviction of the attacker from the environment, we observed continuous attempts to re-establish access. In most cases, the attacker was observed targeting weak password rotation hygiene following mandated employee password resets. They primarily targeted users who they believed would have made single character changes to their previous passwords, attempting to leverage these credentials to authenticate and regain access to the Cisco VPN. The attacker was initially leveraging traffic anonymization services like Tor; however, after experiencing limited success, they switched to attempting to establish new VPN sessions from residential IP space using accounts previously compromised during the initial stages of the attack. We also observed the registration of several additional domains referencing the organization while responding to the attack and took action on them before they could be used for malicious purposes. 

After being successfully removed from the environment, the adversary also repeatedly attempted to establish email communications with executive members of the organization but did not make any specific threats or extortion demands. In one email, they included a screenshot showing the directory listing of the Box data that was previously exfiltrated as described earlier. Below is a screenshot of one of the received emails. The adversary redacted the directory listing screenshot prior to sending the email.



Backdoor analysis


The actor dropped a series of payloads onto systems, which we continue to analyze. The first payload is a simple backdoor that takes commands from a command and control (C2) server and executes them on the end system via the Windows Command Processor. The commands are sent in JSON blobs and are standard for a backdoor. There is a “DELETE_SELF” command that removes the backdoor from the system completely. Another, more interesting, command, “WIPE”, instructs the backdoor to remove the last executed command from memory, likely with the intent of negatively impacting forensic analysis on any impacted hosts. 

Commands are retrieved by making HTTP GET requests to the C2 server using the following structure: 
/bot/cmd.php?botid=%.8x
The malware also communicates with the C2 server via HTTP GET requests that feature the following structure: 
/bot/gate.php?botid=%.8x
Following the initial request from the infected system, the C2 server responds with a SHA256 hash. We observed additional requests made every 10 seconds.  

The aforementioned HTTP requests are sent using the following user-agent string: 
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36 Edg/99.0.1150.36 Trailer/95.3.1132.33
The malware also creates a file called “bdata.ini” in the malware’s current working directory that contains a value derived from the volume serial number present on the infected system. In instances where this backdoor was executed, the malware was observed running from the following directory location:  
C:\users\public\win\cmd.exe
The attacker was frequently observed staging tooling in directory locations under the Public user profile on systems from which they were operating.  

Based upon analysis of C2 infrastructure associated with this backdoor, we assess that the C2 server was set up specifically for this attack. 


Attack attribution


Based upon artifacts obtained, tactics, techniques, and procedures (TTPs) identified, infrastructure used, and a thorough analysis of the backdoor utilized in this attack, we assess with moderate to high confidence that this attack was conducted by an adversary that has been previously identified as an initial access broker (IAB) with ties to both UNC2447 and Lapsus$. IABs typically attempt to obtain privileged access to corporate network environments and then monetize that access by selling it to other threat actors who can then leverage it for a variety of purposes. We have also observed previous activity linking this threat actor to the Yanluowang ransomware gang, including the use of the Yanluowang data leak site for posting data stolen from compromised organizations. 

UNC2447 is a financially-motivated threat actor with a nexus to Russia that has been previously observed conducting ransomware attacks and leveraging a technique known as “double extortion,” in which data is exfiltrated prior to ransomware deployment in an attempt to coerce victims into paying ransom demands. Prior reporting indicates that UNC2447 has been observed operating  a variety of ransomware, including FIVEHANDS, HELLOKITTY, and more. 

Apart from UNC2447, some of the TTPs discovered during the course of our investigation match those of the Lapsus$. Lapsus$ is a threat actor group that is reported to have been responsible for several previous notable breaches of corporate environments. Several arrests of Lapsus$ members were reported earlier this year. Lapsus$ has been observed compromising corporate environments and attempting to exfiltrate sensitive information. 

While we did not observe ransomware deployment in this attack, the TTPs used were consistent with “pre-ransomware activity,” activity commonly observed leading up to the deployment of ransomware in victim environments. Many of the TTPs observed are consistent with activity observed by CTIR during previous engagements. Our analysis also suggests reuse of server-side infrastructure associated with these previous engagements as well. In previous engagements, we also did not observe deployment of ransomware in the victim environments. 


Cisco response and recommendations


Cisco implemented a company-wide password reset immediately upon learning of the incident. CTIR previously observed similar TTPs in numerous investigations since 2021. Our findings and subsequent security protections resulting from those customer engagements helped us slow and contain the attacker’s progression. We created two ClamAV signatures, which are listed below.  

  • Win.Exploit.Kolobko-9950675-0  
  • Win.Backdoor.Kolobko-9950676-0 

Threat actors commonly use social engineering techniques to compromise targets, and despite the frequency of such attacks, organizations continue to face challenges mitigating those threats. User education is paramount in thwarting such attacks, including making sure employees know the legitimate ways that support personnel will contact users so that employees can identify fraudulent attempts to obtain sensitive information. 

Given the actor’s demonstrated proficiency in using a wide array of techniques to obtain initial access, user education is also a key part of countering MFA bypass techniques. Equally important to implementing MFA is ensuring that employees are educated on what to do and how to respond if they get errant push requests on their respective phones. It is also essential to educate employees about who to contact if such incidents do arise to help determine if the event was a technical issue or malicious. 

For Duo it is beneficial to implement strong device verification by enforcing stricter controls around device status to limit or block enrollment and access from unmanaged or unknown devices. Additionally, leveraging risk detection to highlight events like a brand-new device being used from unrealistic location or attack patterns like logins brute force can help detect unauthorized access.

Prior to allowing VPN connections from remote endpoints, ensure that posture checking is configured to enforce a baseline set of security controls. This ensures that the connecting devices match  the security requirements present in the environment. This can also prevent rogue devices that have not been previously approved from connecting to the corporate network environment. 

Network segmentation is another important security control that organizations should employ, as it provides enhanced protection for high-value assets and also enables more effective detection and response capabilities in situations where an adversary is able to gain initial access into the environment.  

Centralized log collection can help minimize the lack of visibility that results when an attacker take active steps to remove logs from systems. Ensuring that the log data generated by endpoints is centrally collected and analyzed for anomalous or overtly malicious behavior can provide early indication when an attack is underway.  

In many cases, threat actors have been observed targeting the backup infrastructure in an attempt to further remove an organization’s ability to recover following an attack. Ensuring that backups are offline and periodically tested can help mitigate this risk and ensure an organization’s ability to effectively recover following an attack. 

Auditing of command line execution on endpoints can also provide increased visibility into actions being performed on systems in the environment and can be used to detect suspicious execution of built-in Windows utilities, which is commonly observed during intrusions where threat actors rely on benign applications or utilities already present in the environment for enumeration, privilege escalation, and lateral movement activities.  


Mitre ATT&CK mapping


All of the previously described TTPs that were observed in this attack are listed below based on the phase of the attack in which they occurred. 

Initial Access 


Execution 


Persistence 


Privilege Escalation 


Defense Evasion 


Credential Access 


Lateral Movement 


Discovery 


Command and Control 


Exfiltration 




Indicators of compromise


The following indicators of compromise were observed associated with this attack. 

Hashes (SHA256) 

184a2570d71eedc3c77b63fd9d2a066cd025d20ceef0f75d428c6f7e5c6965f3 
2fc5bf9edcfa19d48e235315e8f571638c99a1220be867e24f3965328fe94a03 
542c9da985633d027317e9a226ee70b4f0742dcbc59dfd2d4e59977bb870058d 
61176a5756c7b953bc31e5a53580d640629980a344aa5ff147a20fb7d770b610 
753952aed395ea845c52e3037f19738cfc9a415070515de277e1a1baeff20647 
8df89eef51cdf43b2a992ade6ad998b267ebb5e61305aeb765e4232e66eaf79a 
8e5733484982d0833abbd9c73a05a667ec2d9d005bbf517b1c8cd4b1daf57190 
99be6e7e31f0a1d7eebd1e45ac3b9398384c1f0fa594565137abb14dc28c8a7f 
bb62138d173de997b36e9b07c20b2ca13ea15e9e6cd75ea0e8162e0d3ded83b7 
eb3452c64970f805f1448b78cd3c05d851d758421896edd5dfbe68e08e783d18 

IP Addresses 

104.131.30[.]201 
108.191.224[.]47 
131.150.216[.]118 
134.209.88[.]140 
138.68.227[.]71 
139.177.192[.]145 
139.60.160[.]20 
139.60.161[.]99 
143.198.110[.]248 
143.198.131[.]210 
159.65.246[.]188 
161.35.137[.]163 
162.33.177[.]27 
162.33.178[.]244 
162.33.179[.]17 
165.227.219[.]211 
165.227.23[.]218 
165.232.154[.]73 
166.205.190[.]23 
167.99.160[.]91 
172.56.42[.]39 
172.58.220[.]52 
172.58.239[.]34 
174.205.239[.]164 
176.59.109[.]115 
178.128.171[.]206 
185.220.100[.]244 
185.220.101[.]10 
185.220.101[.]13 
185.220.101[.]15 
185.220.101[.]16 
185.220.101[.]2 
185.220.101[.]20 
185.220.101[.]34 
185.220.101[.]45 
185.220.101[.]6 
185.220.101[.]65 
185.220.101[.]73 
185.220.101[.]79 
185.220.102[.]242 
185.220.102[.]250 
192.241.133[.]130 
194.165.16[.]98 
195.149.87[.]136 
24.6.144[.]43 
45.145.67[.]170 
45.227.255[.]215 
45.32.141[.]138 
45.32.228[.]189 
45.32.228[.]190 
45.55.36[.]143 
45.61.136[.]207 
45.61.136[.]5 
45.61.136[.]83 
46.161.27[.]117 
5.165.200[.]7 
52.154.0[.]241 
64.227.0[.]177 
64.4.238[.]56 
65.188.102[.]43 
66.42.97[.]210 
67.171.114[.]251 
68.183.200[.]63 
68.46.232[.]60 
73.153.192[.]98 
74.119.194[.]203 
74.119.194[.]4 
76.22.236[.]142 
82.116.32[.]77 
87.251.67[.]41 
94.142.241[.]194 
 

Domains 

cisco-help[.]cf 
cisco-helpdesk[.]cf 
ciscovpn1[.]com 
ciscovpn2[.]com 
ciscovpn3[.]com 
devcisco[.]com 
devciscoprograms[.]com 
helpzonecisco[.]com 
kazaboldu[.]net 
mycisco[.]cf 
mycisco[.]gq 
mycisco-helpdesk[.]ml 
primecisco[.]com 
pwresetcisco[.]com  
 

Email Addresses 

costacancordia[@]protonmail[.]com 





Cisco was hacked by the Yanluowang ransomware gang

10 August 2022 at 21:20

Cisco discloses a security breach, the Yanluowang ransomware group breached its corporate network in late May and stole internal data.

Cisco disclosed a security breach, the Yanluowang ransomware group breached its corporate network in late May and stole internal data.

The investigation conducted by Cisco Security Incident Response (CSIRT) and Cisco Talos revealed that threat actors compromised a Cisco employee’s credentials after they gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized. 

Once obtained the credentials, the attackers launched voice phishing attacks in an attempt to trick the victim into accepting the MFA push notification started by the attacker.

Upon achieving an MFA push acceptance, the attacker had access to the VPN in the context of the targeted user.

“Initial access to the Cisco VPN was achieved via the successful compromise of a Cisco employee’s personal Google account. The user had enabled password syncing via Google Chrome and had stored their Cisco credentials in their browser, enabling that information to synchronize to their Google account.” reads the analysis published by Cisco Talos. “After obtaining the user’s credentials, the attacker attempted to bypass multifactor authentication (MFA) using a variety of techniques, including voice phishing (aka “vishing”) and MFA fatigue, the process of sending a high volume of push requests to the target’s mobile device until the user accepts, either accidentally or simply to attempt to silence the repeated push notifications they are receiving.”

The attacker conducted a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications initiated by the attacker. The attacker ultimately succeeded in achieving an MFA push acceptance, granting them access to VPN in the context of the targeted user. 

According to Talos, once the attacker had obtained initial access, they enrolled a series of new devices for MFA and authenticated successfully to the Cisco VPN. Then the threat actors escalated to administrative privileges before logging into multiple systems. The attackers were able to drop multiple tools in the target network, including remote access tools like LogMeIn and TeamViewer, Cobalt Strike, PowerSploit, Mimikatz, and Impacket.

Talos researchers added that the attackers were not able to steal sensitive data from the IT giant.

“We confirmed that the only successful data exfiltration that occurred during the attack included the contents of a Box folder that was associated with a compromised employee’s account. The data obtained by the adversary in this case was not sensitive.” continues the analysis.

Cisco said that the Yanluowang gang did not deploy any ransomware on its network during the attack.

The Yanluowang ransomware group is attempting to extort the company and published a list of files stolen from the company threatening to leak all stolen data if Cisco will not pay the ransom.

#yanluowang ransomware has posted #Cisco to its leaksite. #cybersecurity #infosec #ransomware pic.twitter.com/kwrfjbwbkT

— CyberKnow (@Cyberknow20) August 10, 2022

Cisco said that the Yanluowang gang did not deploy any ransomware on its network during the attack.

“While we did not observe ransomware deployment in this attack, the TTPs used were consistent with “pre-ransomware activity,” activity commonly observed leading up to the deployment of ransomware in victim environments. Many of the TTPs observed are consistent with activity observed by CTIR during previous engagements.” Talos experts conclude. “Our analysis also suggests reuse of server-side infrastructure associated with these previous engagements as well. In previous engagements, we also did not observe deployment of ransomware in the victim environments.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Yanluowang ransomware)

The post Cisco was hacked by the Yanluowang ransomware gang appeared first on Security Affairs.

The quantum state of Linux kernel garbage collection CVE-2021-0920 (Part I)

10 August 2022 at 23:00

A deep dive into an in-the-wild Android exploit

Guest Post by Xingyu Jin, Android Security Research

This is part one of a two-part guest blog post, where first we'll look at the root cause of the CVE-2021-0920 vulnerability. In the second post, we'll dive into the in-the-wild 0-day exploitation of the vulnerability and post-compromise modules.

Overview of in-the-wild CVE-2021-0920 exploits

A surveillance vendor named Wintego has developed an exploit for Linux socket syscall 0-day, CVE-2021-0920, and used it in the wild since at least November 2020 based on the earliest captured sample, until the issue was fixed in November 2021.  Combined with Chrome and Samsung browser exploits, the vendor was able to remotely root Samsung devices. The fix was released with the November 2021 Android Security Bulletin, and applied to Samsung devices in Samsung's December 2021 security update.

Google's Threat Analysis Group (TAG) discovered Samsung browser exploit chains being used in the wild. TAG then performed root cause analysis and discovered that this vulnerability, CVE-2021-0920, was being used to escape the sandbox and elevate privileges. CVE-2021-0920 was reported to Linux/Android anonymously. The Google Android Security Team performed the full deep-dive analysis of the exploit.

This issue was initially discovered in 2016 by a RedHat kernel developer and disclosed in a public email thread, but the Linux kernel community did not patch the issue until it was re-reported in 2021.

Various Samsung devices were targeted, including the Samsung S10 and S20. By abusing an ephemeral race condition in Linux kernel garbage collection, the exploit code was able to obtain a use-after-free (UAF) in a kernel sk_buff object. The in-the-wild sample could effectively circumvent CONFIG_ARM64_UAO, achieve arbitrary read / write primitives and bypass Samsung RKP to elevate to root. Other Android devices were also vulnerable, but we did not find any exploit samples against them.

Text extracted from captured samples dubbed the vulnerability “quantum Linux kernel garbage collection”, which appears to be a fitting title for this blogpost.

Introduction

CVE-2021-0920 is a use-after-free (UAF) due to a race condition in the garbage collection system for SCM_RIGHTS. SCM_RIGHTS is a control message that allows unix-domain sockets to transmit an open file descriptor from one process to another. In other words, the sender transmits a file descriptor and the receiver then obtains a file descriptor from the sender. This passing of file descriptors adds complexity to reference-counting file structs. To account for this, the Linux kernel community designed a special garbage collection system. CVE-2021-0920 is a vulnerability within this garbage collection system. By winning a race condition during the garbage collection process, an adversary can exploit the UAF on the socket buffer, sk_buff object. In the following sections, we’ll explain the SCM_RIGHTS garbage collection system and the details of the vulnerability. The analysis is based on the Linux 4.14 kernel.

What is SCM_RIGHTS?

Linux developers can share file descriptors (fd) from one process to another using the SCM_RIGHTS datagram with the sendmsg syscall. When a process passes a file descriptor to another process, SCM_RIGHTS will add a reference to the underlying file struct. This means that the process that is sending the file descriptors can immediately close the file descriptor on their end, even if the receiving process has not yet accepted and taken ownership of the file descriptors. When the file descriptors are in the “queued” state (meaning the sender has passed the fd and then closed it, but the receiver has not yet accepted the fd and taken ownership), specialized garbage collection is needed. To track this “queued” state, this LWN article does a great job explaining SCM_RIGHTS reference counting, and it's recommended reading before continuing on with this blogpost.

Sending

As stated previously, a unix domain socket uses the syscall sendmsg to send a file descriptor to another socket. To explain the reference counting that occurs during SCM_RIGHTS, we’ll start from the sender’s point of view. We start with the kernel function unix_stream_sendmsg, which implements the sendmsg syscall. To implement the SCM_RIGHTS functionality, the kernel uses the structure scm_fp_list for managing all the transmitted file structures. scm_fp_list stores the list of file pointers to be passed.

struct scm_fp_list {

        short                   count;

        short                   max;

        struct user_struct      *user;

        struct file             *fp[SCM_MAX_FD];

};

unix_stream_sendmsg invokes scm_send (af_unix.c#L1886) to initialize the scm_fp_list structure, linked by the scm_cookie structure on the stack.

struct scm_cookie {

        struct pid              *pid;           /* Skb credentials */

        struct scm_fp_list      *fp;            /* Passed files         */

        struct scm_creds        creds;          /* Skb credentials      */

#ifdef CONFIG_SECURITY_NETWORK

        u32                     secid;          /* Passed security ID   */

#endif

};

To be more specific, scm_send → __scm_send → scm_fp_copy (scm.c#L68) reads the file descriptors from the userspace and initializes scm_cookie->fp which can contain SCM_MAX_FD file structures.

Since the Linux kernel uses the sk_buff (also known as socket buffers or skb) object to manage all types of socket datagrams, the kernel also needs to invoke the unix_scm_to_skb function to link the scm_cookie->fp to a corresponding skb object. This occurs in unix_attach_fds (scm.c#L103):

/*

 * Need to duplicate file references for the sake of garbage

 * collection.  Otherwise a socket in the fps might become a

 * candidate for GC while the skb is not yet queued.

 */

UNIXCB(skb).fp = scm_fp_dup(scm->fp);

if (!UNIXCB(skb).fp)

        return -ENOMEM;

The scm_fp_dup call in unix_attach_fds increases the reference count of the file descriptor that’s being passed so the file is still valid even after the sender closes the transmitted file descriptor later:

struct scm_fp_list *scm_fp_dup(struct scm_fp_list *fpl)

{

        struct scm_fp_list *new_fpl;

        int i;

        if (!fpl)

                return NULL;

        new_fpl = kmemdup(fpl, offsetof(struct scm_fp_list, fp[fpl->count]),

                          GFP_KERNEL);

        if (new_fpl) {

                for (i = 0; i < fpl->count; i++)

                        get_file(fpl->fp[i]);

                new_fpl->max = new_fpl->count;

                new_fpl->user = get_uid(fpl->user);

        }

        return new_fpl;

}

Let’s examine a concrete example. Assume we have sockets A and B. The A attempts to pass itself to B. After the SCM_RIGHTS datagram is sent, the newly allocated skb from the sender will be appended to the B’s sk_receive_queue which stores received datagrams:

unix_stream_sendmsg creates sk_buff which contains the structure scm_fp_list. The scm_fp_list has a fp pointer points to the transmitted file (A). The sk_buff is appended to the receiver queue and the reference count of A is 2.

sk_buff carries scm_fp_list structure

The reference count of A is incremented to 2 and the reference count of B is still 1.

Receiving

Now, let’s take a look at the receiver side unix_stream_read_generic (we will not discuss the MSG_PEEK flag yet, and focus on the normal routine). First of all, the kernel grabs the current skb from sk_receive_queue using skb_peek. Secondly, since scm_fp_list is attached to the skb, the kernel will call unix_detach_fds (link) to parse the transmitted file structures from skb and clear the skb from sk_receive_queue:

/* Mark read part of skb as used */

if (!(flags & MSG_PEEK)) {

        UNIXCB(skb).consumed += chunk;

        sk_peek_offset_bwd(sk, chunk);

        if (UNIXCB(skb).fp)

                unix_detach_fds(&scm, skb);

        if (unix_skb_len(skb))

                break;

        skb_unlink(skb, &sk->sk_receive_queue);

        consume_skb(skb);

        if (scm.fp)

                break;

The function scm_detach_fds iterates over the list of passed file descriptors (scm->fp) and installs the new file descriptors accordingly for the receiver:

for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); i<fdmax;

     i++, cmfptr++)

{

        struct socket *sock;

        int new_fd;

        err = security_file_receive(fp[i]);

        if (err)

                break;

        err = get_unused_fd_flags(MSG_CMSG_CLOEXEC & msg->msg_flags

                                  ? O_CLOEXEC : 0);

        if (err < 0)

                break;

        new_fd = err;

        err = put_user(new_fd, cmfptr);

        if (err) {

                put_unused_fd(new_fd);

                break;

        }

        /* Bump the usage count and install the file. */

        sock = sock_from_file(fp[i], &err);

        if (sock) {

                sock_update_netprioidx(&sock->sk->sk_cgrp_data);

                sock_update_classid(&sock->sk->sk_cgrp_data);

        }

        fd_install(new_fd, get_file(fp[i]));

}

/*

 * All of the files that fit in the message have had their

 * usage counts incremented, so we just free the list.

 */

__scm_destroy(scm);

Once the file descriptors have been installed, __scm_destroy (link) cleans up the allocated scm->fp and decrements the file reference count for every transmitted file structure:

void __scm_destroy(struct scm_cookie *scm)

{

        struct scm_fp_list *fpl = scm->fp;

        int i;

        if (fpl) {

                scm->fp = NULL;

                for (i=fpl->count-1; i>=0; i--)

                        fput(fpl->fp[i]);

                free_uid(fpl->user);

                kfree(fpl);

        }

}

Reference Counting and Inflight Counting

As mentioned above, when a file descriptor is passed using SCM_RIGHTS, its reference count is immediately incremented. Once the recipient socket has accepted and installed the passed file descriptor, the reference count is then decremented. The complication comes from the “middle” of this operation: after the file descriptor has been sent, but before the receiver has accepted and installed the file descriptor.

Let’s consider the following scenario:

  1. The process creates sockets A and B.
  2. A sends socket A to socket B.
  3. B sends socket B to socket A.
  4. Close A.
  5. Close B.

Socket A and B form a reference count cycle.

Scenario for reference count cycle

Both sockets are closed prior to accepting the passed file descriptors.The reference counts of A and B are both 1 and can't be further decremented because they were removed from the kernel fd table when the respective processes closed them. Therefore the kernel is unable to release the two skbs and sock structures and an unbreakable cycle is formed. The Linux kernel garbage collection system is designed to prevent memory exhaustion in this particular scenario. The inflight count was implemented to identify potential garbage. Each time the reference count is increased due to an SCM_RIGHTS datagram being sent, the inflight count will also be incremented.

When a file descriptor is sent by SCM_RIGHTS datagram, the Linux kernel puts its unix_sock into a global list gc_inflight_list. The kernel increments unix_tot_inflight which counts the total number of inflight sockets. Then, the kernel increments u->inflight which tracks the inflight count for each individual file descriptor in the unix_inflight function (scm.c#L45) invoked from unix_attach_fds:

void unix_inflight(struct user_struct *user, struct file *fp)

{

        struct sock *s = unix_get_socket(fp);

        spin_lock(&unix_gc_lock);

        if (s) {

                struct unix_sock *u = unix_sk(s);

                if (atomic_long_inc_return(&u->inflight) == 1) {

                        BUG_ON(!list_empty(&u->link));

                        list_add_tail(&u->link, &gc_inflight_list);

                } else {

                        BUG_ON(list_empty(&u->link));

                }

                unix_tot_inflight++;

        }

        user->unix_inflight++;

        spin_unlock(&unix_gc_lock);

}

Thus, here is what the sk_buff looks like when transferring a file descriptor within sockets A and B:

When the file descriptor A sends itself to the file descriptor B, the reference count of the file descriptor A is 2 and the inflight count is 1. For the receiver file descriptor B, the file reference count is 1 and the inflight count is 0.

The inflight count of A is incremented

When the socket file descriptor is received from the other side, the unix_sock.inflight count will be decremented.

Let’s revisit the reference count cycle scenario before the close syscall. This cycle is breakable because any socket files can receive the transmitted file and break the reference cycle: 

The file descriptor A sends itself to the file descriptor B and vice versa. The inflight count of the file descriptor A and B is both 1 and the file reference count is both 2.

Breakable cycle before close A and B

After closing both of the file descriptors, the reference count equals the inflight count for each of the socket file descriptors, which is a sign of possible garbage:

The cycle becomes unbreakable after closing A and B. The reference count equals to the inflight count for A and B.

Unbreakable cycle after close A and B

Now, let’s check another example. Assume we have sockets A, B and 𝛼:

  1. A sends socket A to socket B.
  2. B sends socket B to socket A.
  3. B sends socket B to socket 𝛼.
  4. 𝛼 sends socket 𝛼 to socket B.
  5. Close A.
  6. Close B.

A, B and alpha form a breakable cycle.

Breakable cycle for A, B and 𝛼

The cycle is breakable, because we can get newly installed file descriptor B from the socket file descriptor 𝛼 and newly installed file descriptor A' from B’.

Garbage Collection

A high level view of garbage collection is available from lwn.net:

"If, instead, the two counts are equal, that file structure might be part of an unreachable cycle. To determine whether that is the case, the kernel finds the set of all in-flight Unix-domain sockets for which all references are contained in SCM_RIGHTS datagrams (for which f_count and inflight are equal, in other words). It then counts how many references to each of those sockets come from SCM_RIGHTS datagrams attached to sockets in this set. Any socket that has references coming from outside the set is reachable and can be removed from the set. If it is reachable, and if there are any SCM_RIGHTS datagrams waiting to be consumed attached to it, the files contained within that datagram are also reachable and can be removed from the set.

At the end of an iterative process, the kernel may find itself with a set of in-flight Unix-domain sockets that are only referenced by unconsumed (and unconsumable) SCM_RIGHTS datagrams; at this point, it has a cycle of file structures holding the only references to each other. Removing those datagrams from the queue, releasing the references they hold, and discarding them will break the cycle."

To be more specific, the SCM_RIGHTS garbage collection system was developed in order to handle the unbreakable reference cycles. To identify which file descriptors are a part of unbreakable cycles:

  1. Add any unix_sock objects whose reference count equals its inflight count to the gc_candidates list.
  2. Determine if the socket is referenced by any sockets outside of the gc_candidates list. If it is then it is reachable, remove it and any sockets it references from the gc_candidates list. Repeat until no more reachable sockets are found.
  3. After this iterative process, only sockets who are solely referenced by other sockets within the gc_candidates list are left.

Let’s take a closer look at how this garbage collection process works. First, the kernel finds all the unix_sock objects whose reference counts equals their inflight count and puts them into the gc_candidates list (garbage.c#L242):

list_for_each_entry_safe(u, next, &gc_inflight_list, link) {

        long total_refs;

        long inflight_refs;

        total_refs = file_count(u->sk.sk_socket->file);

        inflight_refs = atomic_long_read(&u->inflight);

        BUG_ON(inflight_refs < 1);

        BUG_ON(total_refs < inflight_refs);

        if (total_refs == inflight_refs) {

                list_move_tail(&u->link, &gc_candidates);

                __set_bit(UNIX_GC_CANDIDATE, &u->gc_flags);

                __set_bit(UNIX_GC_MAYBE_CYCLE, &u->gc_flags);

        }

}

Next, the kernel removes any sockets that are referenced by other sockets outside of the current gc_candidates list. To do this, the kernel invokes scan_children (garbage.c#138) along with the function pointer dec_inflight to iterate through each candidate’s sk->receive_queue. It decreases the inflight count for each of the passed file descriptors that are themselves candidates for garbage collection (garbage.c#L261):

/* Now remove all internal in-flight reference to children of

 * the candidates.

 */

list_for_each_entry(u, &gc_candidates, link)

        scan_children(&u->sk, dec_inflight, NULL);

After iterating through all the candidates, if a gc candidate still has a positive inflight count it means that it is referenced by objects outside of the gc_candidates list and therefore is reachable. These candidates should not be included in the gc_candidates list so the related inflight counts need to be restored.

To do this, the kernel will put the candidate to not_cycle_list instead and iterates through its receiver queue of each transmitted file in the gc_candidates list (garbage.c#L281) and increments the inflight count back. The entire process is done recursively, in order for the garbage collection to avoid purging reachable sockets:

/* Restore the references for children of all candidates,

 * which have remaining references.  Do this recursively, so

 * only those remain, which form cyclic references.

 *

 * Use a "cursor" link, to make the list traversal safe, even

 * though elements might be moved about.

 */

list_add(&cursor, &gc_candidates);

while (cursor.next != &gc_candidates) {

        u = list_entry(cursor.next, struct unix_sock, link);

        /* Move cursor to after the current position. */

        list_move(&cursor, &u->link);

        if (atomic_long_read(&u->inflight) > 0) {

                list_move_tail(&u->link, &not_cycle_list);

                __clear_bit(UNIX_GC_MAYBE_CYCLE, &u->gc_flags);

                scan_children(&u->sk, inc_inflight_move_tail, NULL);

        }

}

list_del(&cursor);

Now gc_candidates contains only “garbage”. The kernel restores original inflight counts from gc_candidates, moves candidates from not_cycle_list back to gc_inflight_list and invokes __skb_queue_purge for cleaning up garbage (garbage.c#L306).

/* Now gc_candidates contains only garbage.  Restore original

 * inflight counters for these as well, and remove the skbuffs

 * which are creating the cycle(s).

 */

skb_queue_head_init(&hitlist);

list_for_each_entry(u, &gc_candidates, link)

        scan_children(&u->sk, inc_inflight, &hitlist);

/* not_cycle_list contains those sockets which do not make up a

 * cycle.  Restore these to the inflight list.

 */

while (!list_empty(&not_cycle_list)) {

        u = list_entry(not_cycle_list.next, struct unix_sock, link);

        __clear_bit(UNIX_GC_CANDIDATE, &u->gc_flags);

        list_move_tail(&u->link, &gc_inflight_list);

}

spin_unlock(&unix_gc_lock);

/* Here we are. Hitlist is filled. Die. */

__skb_queue_purge(&hitlist);

spin_lock(&unix_gc_lock);

__skb_queue_purge clears every skb from the receiver queue:

/**

 *      __skb_queue_purge - empty a list

 *      @list: list to empty

 *

 *      Delete all buffers on an &sk_buff list. Each buffer is removed from

 *      the list and one reference dropped. This function does not take the

 *      list lock and the caller must hold the relevant locks to use it.

 */

void skb_queue_purge(struct sk_buff_head *list);

static inline void __skb_queue_purge(struct sk_buff_head *list)

{

        struct sk_buff *skb;

        while ((skb = __skb_dequeue(list)) != NULL)

                kfree_skb(skb);

}

There are two ways to trigger the garbage collection process:

  1. wait_for_unix_gc is invoked at the beginning of the sendmsg function if there are more than 16,000 inflight sockets
  2. When a socket file is released by the kernel (i.e., a file descriptor is closed), the kernel will directly invoke unix_gc.

Note that unix_gc is not preemptive. If garbage collection is already in process, the kernel will not perform another unix_gc invocation.

Now, let’s check this example (a breakable cycle) with a pair of sockets f00 and f01, and a single socket 𝛼:

  1. Socket f 00 sends socket f 00 to socket f 01.
  2. Socket f 01 sends socket f 01 to socket 𝛼.
  3. Close f 00.
  4. Close f 01.

Before starting the garbage collection process, the status of socket file descriptors are:

  • f 00: ref = 1, inflight = 1
  • f 01: ref = 1, inflight = 1
  • 𝛼: ref = 1, inflight = 0

f00, f01 and alpha form a breakable cycle.

Breakable cycle by f 00, f 01 and 𝛼

During the garbage collection process, f 00 and f 01 are considered garbage candidates. The inflight count of f 00 is dropped to zero, but the count of f 01 is still 1 because 𝛼 is not a candidate. Thus, the kernel will restore the inflight count from f 01’s receive queue. As a result, f 00 and f 01 are not treated as garbage anymore.

CVE-2021-0920 Root Cause Analysis

When a user receives SCM_RIGHTS message from recvmsg without the MSG_PEEK flag, the kernel will wait until the garbage collection process finishes if it is in progress. However, if the MSG_PEEK flag is on, the kernel will increment the reference count of the transmitted file structures without synchronizing with any ongoing garbage collection process. This may lead to inconsistency of the internal garbage collection state, making the garbage collector mark a non-garbage sock object as garbage to purge.

recvmsg without MSG_PEEK flag

The kernel function unix_stream_read_generic (af_unix.c#L2290) parses the SCM_RIGHTS message and manages the file inflight count when the MSG_PEEK flag is NOT set. Then, the function unix_stream_read_generic calls unix_detach_fds to decrement the inflight count. Then, unix_detach_fds clears the list of passed file descriptors (scm_fp_list) from the skb:

static void unix_detach_fds(struct scm_cookie *scm, struct sk_buff *skb)

{

        int i;

        scm->fp = UNIXCB(skb).fp;

        UNIXCB(skb).fp = NULL;

        for (i = scm->fp->count-1; i >= 0; i--)

                unix_notinflight(scm->fp->user, scm->fp->fp[i]);

}

The unix_notinflight from unix_detach_fds will reverse the effect of unix_inflight by decrementing the inflight count:

void unix_notinflight(struct user_struct *user, struct file *fp)

{

        struct sock *s = unix_get_socket(fp);

        spin_lock(&unix_gc_lock);

        if (s) {

                struct unix_sock *u = unix_sk(s);

                BUG_ON(!atomic_long_read(&u->inflight));

                BUG_ON(list_empty(&u->link));

                if (atomic_long_dec_and_test(&u->inflight))

                        list_del_init(&u->link);

                unix_tot_inflight--;

        }

        user->unix_inflight--;

        spin_unlock(&unix_gc_lock);

}

Later skb_unlink and consume_skb are invoked from unix_stream_read_generic (af_unix.c#2451) to destroy the current skb. Following the call chain kfree(skb)->__kfree_skb, the kernel will invoke the function pointer skb->destructor (code) which redirects to unix_destruct_scm:

static void unix_destruct_scm(struct sk_buff *skb)

{

        struct scm_cookie scm;

        memset(&scm, 0, sizeof(scm));

        scm.pid  = UNIXCB(skb).pid;

        if (UNIXCB(skb).fp)

                unix_detach_fds(&scm, skb);

        /* Alas, it calls VFS */

        /* So fscking what? fput() had been SMP-safe since the last Summer */

        scm_destroy(&scm);

        sock_wfree(skb);

}

In fact, the unix_detach_fds will not be invoked again here from unix_destruct_scm because UNIXCB(skb).fp is already cleared by unix_detach_fds. Finally, fd_install(new_fd, get_file(fp[i])) from scm_detach_fds is invoked for installing a new file descriptor.

recvmsg with MSG_PEEK flag

The recvmsg process is different if the MSG_PEEK flag is set. The MSG_PEEK flag is used during receive to “peek” at the message, but the data is treated as unread. unix_stream_read_generic will invoke scm_fp_dup instead of unix_detach_fds. This increases the reference count of the inflight file (af_unix.c#2149):

/* It is questionable, see note in unix_dgram_recvmsg.

 */

if (UNIXCB(skb).fp)

        scm.fp = scm_fp_dup(UNIXCB(skb).fp);

sk_peek_offset_fwd(sk, chunk);

if (UNIXCB(skb).fp)

        break;

Because the data should be treated as unread, the skb is not unlinked and consumed when the MSG_PEEK flag is set. However, the receiver will still get a new file descriptor for the inflight socket.

recvmsg Examples

Let’s see a concrete example. Assume there are the following socket pairs:

  • f 00, f 01
  • f 10, f 11

Now, the program does the following operations:

  • f 00 → [f 00] → f 01 (means f 00 sends [f 00] to f 01)
  • f 10 → [f 00] → f 11
  • Close(f 00)

f00, f01, f10, f11 forms a breakable cycle.

Breakable cycle by f 00, f 01, f 10 and f 11

Here is the status:

  • inflight(f 00) = 2, ref(f 00) = 2
  • inflight(f 01) = 0, ref(f 01) = 1
  • inflight(f 10) = 0, ref(f 10) = 1
  • inflight(f 11) = 0, ref(f 11) = 1

If the garbage collection process happens now, before any recvmsg calls, the kernel will choose f 00 as the garbage candidate. However, f 00 will not have the inflight count altered and the kernel will not purge any garbage.

If f 01 then calls recvmsg with MSG_PEEK flag, the receive queue doesn’t change and the inflight counts are not decremented. f 01 gets a new file descriptor f 00' which increments the reference count on f 00:

After f01 receives the socket file descriptor by MSG_PEEK, the reference count of f00 is incremented and the receive queue from f01 remains the same.

MSG_PEEK increment the reference count of f 00 while the receive queue is not cleared

Status:

  • inflight(f 00) = 2, ref(f 00) = 3
  • inflight(f 01) = 0, ref(f 01) = 1
  • inflight(f 10) = 0, ref(f 10) = 1
  • inflight(f 11) = 0, ref(f 11) = 1

Then, f 01 calls recvmsg without MSG_PEEK flag, f 01’s receive queue is removed. f 01 also fetches a new file descriptor f 00'':

After f01 receives the socket file descriptor without MSG_PEEK, the receive queue is cleared and file descriptor f00''' is obtained.

The receive queue of f 01 is cleared and f 01'' is obtained from f 01

Status:

  • inflight(f 00) = 1, ref(f 00) = 3
  • inflight(f 01) = 0, ref(f 01) = 1
  • inflight(f 10) = 0, ref(f 10) = 1
  • inflight(f 11) = 0, ref(f 11) = 1

UAF Scenario

From a very high level perspective, the internal state of Linux garbage collection can be non-deterministic because MSG_PEEK is not synchronized with the garbage collector. There is a race condition where the garbage collector can treat an inflight socket as a garbage candidate while the file reference is incremented at the same time during the MSG_PEEK receive. As a consequence, the garbage collector may purge the candidate, freeing the socket buffer, while a receiver may install the file descriptor, leading to a UAF on the skb object.

Let’s see how the captured 0-day sample triggers the bug step by step (simplified version, in reality you may need more threads working together, but it should demonstrate the core idea). First of all, the sample allocates the following socket pairs and single socket 𝛼:

  • f 00, f 01
  • f 10, f 11
  • f 20, f 21
  • f 30, f 31
  • sock 𝛼 (actually there might be even thousands of 𝛼 for protracting the garbage collection process in order to evade a BUG_ON check which will be introduced later).

Now, the program does the below operations:

Close the following file descriptors prior to any recvmsg calls:

  • Close(f 00)
  • Close(f 01)
  • Close(f 11)
  • Close(f 10)
  • Close(f 30)
  • Close(f 31)
  • Close(𝛼)

Here is the status:

  • inflight(f 00) = N + 1, ref(f 00) = N + 1
  • inflight(f 01) = 2, ref(f 01) = 2
  • inflight(f 10) = 3, ref(f 10) = 3
  • inflight(f 11) = 1, ref(f 11) = 1
  • inflight(f 20) = 0, ref(f 20) = 1
  • inflight(f 21) = 0, ref(f 21) = 1
  • inflight(f 31) = 1, ref(f 31) = 1
  • inflight(𝛼) = 1, ref(𝛼) = 1

If the garbage collection process happens now, the kernel will do the following scrutiny:

  • List f 00, f 01, f 10,  f 11, f 31, 𝛼 as garbage candidates. Decrease inflight count for the candidate children in each receive queue.
  • Since f 21 is not considered a candidate, f 11’s inflight count is still above zero.
  • Recursively restore the inflight count.
  • Nothing is considered garbage.

A potential skb UAF by race condition can be triggered by:

  1. Call recvmsg with MSG_PEEK flag from f 21 to get f 11’.
  2. Call recvmsg with MSG_PEEK flag from f 11 to get f 10’.
  3. Concurrently do the following operations:
  1. Call recvmsg without MSG_PEEK flag from f 11 to get f 10’’.
  2. Call recvmsg with MSG_PEEK flag from f 10

How is it possible? Let’s see a case where the race condition is not hit so there is no UAF:

Thread 0

Thread 1

Thread 2

Call unix_gc

Stage0: List f 00, f 01, f 10,  f 11, f 31, 𝛼 as garbage candidates.

Call recvmsg with MSG_PEEK flag from f 21 to get f 11

Increase reference count: scm.fp = scm_fp_dup(UNIXCB(skb).fp);

Stage0: decrease inflight count from the child of every garbage candidate

Status after stage 0:

inflight(f 00) = 0

inflight(f 01) = 0

inflight(f 10) = 0

inflight(f 11) = 1

inflight(f 31) = 0

inflight(𝛼) = 0

Stage1: Recursively restore inflight count if a candidate still has inflight count.

Stage1: All inflight counts have been restored.

Stage2: No garbage, return.

Call recvmsg with MSG_PEEK flag from f 11 to get f 10

Call recvmsg without MSG_PEEK flag from f 11 to get f 10’’

Call recvmsg with MSG_PEEK flag from f 10

Everyone is happy

Everyone is happy

Everyone is happy

However, if the second recvmsg occurs just after stage 1 of the garbage collection process, the UAF is triggered:

Thread 0

Thread 1

Thread 2

Call unix_gc

Stage0: List f 00, f 01, f 10,  f 11, f 31, 𝛼 as garbage candidates.

Call recvmsg with MSG_PEEK flag from f 21 to get f 11

Increase reference count: scm.fp = scm_fp_dup(UNIXCB(skb).fp);

Stage0: decrease inflight count from the child of every garbage candidates

Status after stage 0:

inflight(f 00) = 0

inflight(f 01) = 0

inflight(f 10) = 0

inflight(f 11) = 1

inflight(f 31) = 0

inflight(𝛼) = 0

Stage1: Start restoring inflight count.

Call recvmsg with MSG_PEEK flag from f 11 to get f 10

Call recvmsg without MSG_PEEK flag from f 11 to get f 10’’

unix_detach_fds: UNIXCB(skb).fp = NULL

Blocked by spin_lock(&unix_gc_lock)

Stage1: scan_inflight cannot find candidate children from f 11. Thus, the inflight count accidentally remains the same.

Stage2: f 00, f 01, f 10, f 31, 𝛼 are garbage.

Stage2: start purging garbage.

Start calling recvmsg with MSG_PEEK flag from f 10’, which would expect to receive f 00'

Get skb = skb_peek(&sk->sk_receive_queue), skb is going to be freed by thread 0.

Stage2: for, calls __skb_unlink and kfree_skb later.

state->recv_actor(skb, skip, chunk, state) UAF

GC finished.

Start garbage collection.

Get f 10’’

Therefore, the race condition causes a UAF of the skb object. At first glance, we should blame the second recvmsg syscall because it clears skb.fp, the passed file list. However, if the first recvmsg syscall doesn’t set the MSG_PEEK flag, the UAF can be avoided because unix_notinflight is serialized with the garbage collection. In other words, the kernel makes sure the garbage collection is either not processed or finished before decrementing the inflight count and removing the skb. After unix_notinflight, the receiver obtains f11' and inflight sockets don't form an unbreakable cycle.

Since MSG_PEEK is not serialized with the garbage collection, when recvmsg is called with MSG_PEEK set, the kernel still considers f 11 as a garbage candidate. For this reason, the following next recvmsg will eventually trigger the bug due to the inconsistent state of the garbage collection process.

 

Patch Analysis

CVE-2021-0920 was found in 2016

The vulnerability was initially reported to the Linux kernel community in 2016. The researcher also provided the correct patch advice but it was not accepted by the Linux kernel community:

Linux kernel developers: Why would I apply a patch that's an RFC, doesn't have a proper commit message, lacks a proper signoff, and also lacks ACK's and feedback from other knowledgable developers?

Patch was not applied in 2016

In theory, anyone who saw this patch might come up with an exploit against the faulty garbage collector.

Patch in 2021

Let’s check the official patch for CVE-2021-0920. For the MSG_PEEK branch, it requests the garbage collection lock unix_gc_lock before performing sensitive actions and immediately releases it afterwards:

+       spin_lock(&unix_gc_lock);

+       spin_unlock(&unix_gc_lock);

The patch is confusing - it’s rare to see such lock usage in software development. Regardless, the MSG_PEEK flag now waits for the completion of the garbage collector, so the UAF issue is resolved.

BUG_ON Added in 2017

Andrey Ulanov from Google in 2017 found another issue in unix_gc and provided a fix commit. Additionally, the patch added a BUG_ON for the inflight count:

void unix_notinflight(struct user_struct *user, struct file *fp)

        if (s) {

                struct unix_sock *u = unix_sk(s);

 

+               BUG_ON(!atomic_long_read(&u->inflight));

                BUG_ON(list_empty(&u->link));

 

                if (atomic_long_dec_and_test(&u->inflight))

At first glance, it seems that the BUG_ON can prevent CVE-2021-0920 from being exploitable. However, if the exploit code can delay garbage collection by crafting a large amount of fake garbage,  it can waive the BUG_ON check by heap spray.

New Garbage Collection Discovered in 2021

CVE-2021-4083 deserves an honorable mention: when I discussed CVE-2021-0920 with Jann Horn and Ben Hawkes, Jann found another issue in the garbage collection, described in the Project Zero blog post Racing against the clock -- hitting a tiny kernel race window.

\

Part I Conclusion

To recap, we have discussed the kernel internals of SCM_RIGHTS and the designs and implementations of the Linux kernel garbage collector. Besides, we have analyzed the behavior of MSG_PEEK flag with the recvmsg syscall and how it leads to a kernel UAF by a subtle and arcane race condition.

The bug was spotted in 2016 publicly, but unfortunately the Linux kernel community did not accept the patch at that time. Any threat actors who saw the public email thread may have a chance to develop an LPE exploit against the Linux kernel.

In part two, we'll look at how the vulnerability was exploited and the functionalities of the post compromise modules.

Cisco fixed a flaw in ASA, FTD devices that can give access to RSA private key

11 August 2022 at 05:47

Cisco addressed a high severity flaw, tracked as CVE-2022-20866, affecting Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software.

Cisco addressed a high severity vulnerability in its Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software.

The flaw, tracked as CVE-2022-20866, impacts the handling of RSA keys on devices running Cisco ASA Software and FTD Software, an unauthenticated, remote attacker can trigger it to retrieve an RSA private key. Once obtained the key, the attackers can impersonate a device that is running ASA/FTD Software or to decrypt the device traffic.

“This vulnerability is due to a logic error when the RSA key is stored in memory on a hardware platform that performs hardware-based cryptography. An attacker could exploit this vulnerability by using a Lenstra side-channel attack against the targeted device. A successful exploit could allow the attacker to retrieve the RSA private key.” reads the advisory published by the IT giant.

The advisory states that the following conditions may be observed on an affected device:

  • This issue will impact approximately 5 percent of the RSA keys on a device that is running a vulnerable release of ASA Software or FTD Software; not all RSA keys are expected to be affected due to mathematical calculations applied to the RSA key.
  • The RSA key could be valid but have specific characteristics that make it vulnerable to the potential leak of the RSA private key. 
  • The RSA key could be malformed and invalid. A malformed RSA key is not functional, and a TLS client connection to a device that is running Cisco ASA Software or Cisco FTD Software that uses the malformed RSA key will result in a TLS signature failure, which means a vulnerable software release created an invalid RSA signature that failed verification. If an attacker obtains the RSA private key, they could use the key to impersonate a device that is running Cisco ASA Software or Cisco FTD Software or to decrypt the device traffic.

The flaw impacts products running vulnerable Cisco ASA (9.16.1 and later) or Cisco FTD (7.0.0 and later) software that perform hardware-based cryptographic functions:

  • ASA 5506-X with FirePOWER Services
  • ASA 5506H-X with FirePOWER Services
  • ASA 5506W-X with FirePOWER Services
  • ASA 5508-X with FirePOWER Services
  • ASA 5516-X with FirePOWER Services
  • Firepower 1000 Series Next-Generation Firewall
  • Firepower 2100 Series Security Appliances
  • Firepower 4100 Series Security Appliances
  • Firepower 9300 Series Security Appliances
  • Secure Firewall 3100

Cisco recommends administrators of ASA/FTD devices to remove malformed or susceptible RSA keys and possibly revoke any certificates associated with those RSA keys, because it is possible that the RSA private key has been leaked to a malicious actor.

The flaw was reported by Nadia Heninger and George Sullivan of the University of California San Diego and Jackson Sippe and Eric Wustrow of the University of Colorado Boulder.

Cisco has credited Nadia Heninger and George Sullivan of the University of California San Diego and Jackson Sippe and Eric Wustrow of the University of Colorado Boulder for reporting the security flaw.

The Product Security Incident Response Team (PSIRT) is not aware of attacks in the wild exploiting this issue.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, ASA)

The post Cisco fixed a flaw in ASA, FTD devices that can give access to RSA private key appeared first on Security Affairs.

Ex Twitter employee found guilty of spying for Saudi Arabian government

11 August 2022 at 05:50

A former Twitter employee was found guilty of spying on certain Twitter users for Saudi Arabia.

A former Twitter employee, Ahmad Abouammo (44), was found guilty of gathering private information of certain Twitter users and passing them to Saudi Arabia.

“Ahmad Abouammo, a US resident born in Egypt, was found guilty by a jury Tuesday of charges including acting as an agent for Saudi Arabia, money laundering, conspiracy to commit wire fraud and falsifying records, following a two-week trial in San Francisco federal court.” reported Bloomberg.

The man faces from 10 up to 20 years in prison when he’s sentenced. 

In November 2019, the former Twitter employees Abouammo and the Saudi citizen Ali Alzabarah have been charged with spying on thousands of Twitter user accounts on behalf of the Saudi Arabian government. The two former Twitter employees operated for the Saudi Arabian government with the intent of unmasking dissidents using the social network.

Representatives of the Saudi Arabian government recruited the duo in 2014, their mission was to gather non-public information of Twitter accounts associated with known prominent critics of the Kingdom of Saudi Arabia and the Royal Family.

Abouammo and Alzabarah had unauthorized access to information associated with some profiles, including email addresses, devices used, user-provided biographical information, birth dates, logs that contained the user’s browser information, a log of all of a particular user’s actions on the Twitter platform at any given time, and other info that can be used to geo-locate a user such as IP addresses and phone numbers.

According to the indictment, Alzabarah joined Twitter in August 2013 as a “site reliability engineer,” he worked with the Saudi officials between May 21 and November 18, 2015. He is accused of allegedly spied on more than 6,000 Twitter accounts, including tens of users for which Saudi Arabian law enforcement had submitted emergency disclosure requests to Twitter.

Abouammo was charged with acting as a foreign agent on US soil, it also provided falsified records to feds to interfere with their investigation.

The man also deleted certain information from the social media platform and in some cases, he shut down Twitter accounts at the request of Saudi government officials. Of course, he was also able to unmask the identities of some users on behalf of the Saudi Arabian Government.

Saudi officials paid up to $300,000 to Abouammo for his work, the indictment explained that it was possible by masquerading the payments with faked invoices. The document also states that the man received a Hublot Unico Big Bang King Gold Ceramic watch.

According to an indictment, Abouammo lied to FBI agents saying the watch was a replica costing $500 and that the last $100,000 wire from Al-Asaker was for legitimate freelance consulting work.

US DoJ Department of Justice has also charged the Saudi national Ahmed al Mutairi, also known as Ahmed ALJBREEN, who directed a Saudi Saudi social media marketing company with ties to the royal family.

Ahmed al Mutairi, was acting as an intermediary between the two former Twitter employees and the officials of the Saudi Arabian Government.

Abouammo was arrested by the FBI in November 2019 in Seattle

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, cyberespionage)

The post Ex Twitter employee found guilty of spying for Saudi Arabian government appeared first on Security Affairs.

GitHub Dependabot Now Alerts Developers On Vulnerable GitHub Actions

11 August 2022 at 06:07
Cloud-based code hosting platform GitHub has announced that it will now start sending Dependabot alerts for vulnerable GitHub Actions to help developers fix security issues in CI/CD workflows. "When a security vulnerability is reported in an action, our team of security researchers will create an advisory to document the vulnerability, which will trigger an alert to impacted repositories,"

Kali Linux 2022.3 - Penetration Testing and Ethical Hacking Linux Distribution

11 August 2022 at 06:08
By: Zion3R

Time for another Kali Linux release! – Kali Linux 2022.3. This release has various impressive updates.

The highlights for Kali’s 2022.3’s release:

For more details, see the bug tracker changelog.


More info here.


Critical Flaws Disclosed in Device42 IT Asset Management Software

11 August 2022 at 09:23
Cybersecurity researchers have disclosed multiple severe security vulnerabilities asset management platform Device42 that, if successfully exploited, could enable a malicious actor to seize control of affected systems. "By exploiting these issues, an attacker could impersonate other users, obtain admin-level access in the application (by leaking session with an LFI) or obtain full access to the

What the Zola Hack Can Teach Us About Password Security

11 August 2022 at 10:10
Password security is only as strong as the password itself. Unfortunately, we are often reminded of the danger of weak, reused, and compromised passwords with major cybersecurity breaches that start with stolen credentials. For example, in May 2022, the popular wedding planning site, Zola, was the victim of a significant cybersecurity breach where hackers used an attack known as credential

Hackers Behind Cuba Ransomware Attacks Using New RAT Malware

11 August 2022 at 10:21
Threat actors associated with the Cuba ransomware have been linked to previously undocumented tactics, techniques and procedures (TTPs), including a new remote access trojan called ROMCOM RAT on compromised systems. The new findings come from Palo Alto Networks' Unit 42 threat intelligence team, which is tracking the double extortion ransomware group under the constellation-themed moniker 

Faraday Community - Open Source Penetration Testing and Vulnerability Management Platform

11 August 2022 at 12:30
By: Zion3R


Faraday was built from within the security community, to make vulnerability management easier and enhance our work. What IDEs are to programming, Faraday is to pentesting.

Offensive security had two difficult tasks: designing smart ways of getting new information, and keeping track of findings to improve further work.

This new update brings: New scanning, reporting and UI experience


Focus on pentesting

Get your work organized and focus on what you do best. With Faradaycommunity, you may focus on pentesting while we help you with the rest..

Check out the documentation here.

Installation

The easiest way to get faraday up and running is using our docker-compose

# Docker-compose

$ wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml

$ docker-compose up

Manage your findings

Manage, classify and triage your results through Faraday’s dashboard, designed with and for pentesters.

Get an overview of your vulnerabilities and ease your work.




By right clicking on any vulnerability, you may filter, tag and classify your results with ease. You may also add comments to vulnerabilities and add evidence with just a few clicks



In the asset tab, information on each asset is presented, for a detailed follow-up on every device in your network. This insight might be especially useful if you hold critical data on certain assets, so the impact of vulnerabilities may be assessed through this information. If responsibilities over each asset are clear, this view helps to organize and follow the work of asset owners too.

Here, you can obtain information about the OS, services, ports and vulnerabilities associated with each of your assets, which will give you a better understanding of your scope and help you to gain an overview of what you are assessing.




Use your favorite tools

Integrate scanners with Faraday Agents Dispatcher. This feature will allow you to orchestrate the most common used security tools and have averything available from your Faraday instance. Once your scan is finished, you will be able to see all the results in the main dashboard.


Choose the scanners that best fit your needs.



Share your results

Once you’re done, export your results in a CSV format.

Check out some of our features

Full centralization

With Faraday, you may oversee your cybersecurity efforts, prioritize actions and manage your resources from a single platform.

Elegant integration of scanning tools

Make sense of today’s overwhelming number of tools. Faraday’s technology aligns +80 key plugins with your current needs, normalizing and deduplicating vulnerabilities.

Powerful Automation

Save time by automating pivotal steps of Vulnerability Management. Scan, create reports, and schedule pipelines of custom actions, all following your requirements.

Intuitive dashboard

Faraday’s intuitive dashboard guides teams through vulnerability management with ease. Scan, analyze, automate, tag, and prioritize, each with just a few clicks.

Smart visibility

Get full visibility of your security posture in real-time. Advanced filters, navigation, and analytics help you strategize and focus your work.

Easier teamwork

Coordinate efforts by sending tickets to Jira, Gitlab, and ServiceNow directly from Faraday.

Planning ahead

Manage your security team with Faraday planner. Keep up by communicating with your peers and receiving notifications.

Work as usual, but better

Get your work organized on the run when pentesting with Faraday CLI.

Proudly Open Source

We believe in the power of teams, most of our integrations and core technologies are open source, allowing any team to build custom implementations and integrations.

For more information check out our website www.faradaysec.com


Cisco Confirms It's Been Hacked by Yanluowang Ransomware Gang

11 August 2022 at 15:04
Networking equipment major Cisco on Wednesday confirmed it was the victim of a cyberattack on May 24, 2022 after the attackers got hold of an employee's personal Google account that contained passwords synced from their web browser. "Initial access to the Cisco VPN was achieved via the successful compromise of a Cisco employee's personal Google account," Cisco Talos said in a detailed write-up.

Detecting DNS implants: Old kitten, new tricks – A Saitama Case Study 

11 August 2022 at 15:20

Max Groot & Ruud van Luijk

TL;DR

A recently uncovered malware sample dubbed ‘Saitama’ was uncovered by security firm Malwarebytes in a weaponized document, possibly targeted towards the Jordan government. This Saitama implant uses DNS as its sole Command and Control channel and utilizes long sleep times and (sub)domain randomization to evade detection. As no server-side implementation was available for this implant, our detection engineers had very little to go on to verify whether their detection would trigger on such a communication channel. This blog documents the development of a Saitama server-side implementation, as well as several approaches taken by Fox-IT / NCC Group’s Research and Intelligence Fusion Team (RIFT) to be able to detect DNS-tunnelling implants such as Saitama.

Introduction

For its Managed Detection and Response (MDR) offering, Fox-IT is continuously building and testing detection coverage for the latest threats. Such detection efforts vary across all tactics, techniques, and procedures (TTP’s) of adversaries, an important one being Command and Control (C2). Detection of Command and Control involves catching attackers based on the communication between the implants on victim machines and the adversary infrastructure.  

In May 2022, security firm Malwarebytes published a two1-part2 blog about a malware sample that utilizes DNS as its sole channel for C2 communication. This sample, dubbed ‘Saitama’, sets up a C2 channel that tries to be stealthy using randomization and long sleep times. These features make the traffic difficult to detect even though the implant does not use DNS-over-HTTPS (DoH) to encrypt its DNS queries.  

Although DNS tunnelling remains a relatively rare technique for C2 communication, it should not be ignored completely. While focusing on Indicators of Compromise (IOC’s) can be useful for retroactive hunting, robust detection in real-time is preferable. To assess and tune existing coverage, a more detailed understanding of the inner workings of the implant is required. This blog will use the Saitama implant to illustrate how malicious DNS tunnels can be set-up in a variety of ways, and how this variety affects the detection engineering process.  

To assist defensive researchers, this blogpost comes with the publication of a server-side implementation of Saitama. This can be used to control the implant in a lab environment. Moreover, ‘on the wire’ recordings of the implant that were generated using said implementation are also shared as PCAP and Zeek logs. This blog also details multiple approaches towards detecting the implant’s traffic, using a Suricata signature and behavioural detection. 

Reconstructing the Saitama traffic 

The behaviour of the Saitama implant from the perspective of the victim machine has already been documented elsewhere3. However, to generate a full recording of the implant’s behaviour, a C2 server is necessary that properly controls and instructs the implant. Of course, the source code of the C2 server used by the actual developer of the implant is not available. 

If you aim to detect the malware in real-time, detection efforts should focus on the way traffic is generated by the implant, rather than the specific domains that the traffic is sent to. We strongly believe in the “PCAP or it didn’t happen” philosophy. Thus, instead of relying on assumptions while building detection, we built the server-side component of Saitama to be able to generate a PCAP. 

The server-side implementation of Saitama can be found on the Fox-IT GitHub page. Be aware that this implementation is a Proof-of-Concept. We do not intend on fully weaponizing the implant “for the greater good”, and have thus provided resources to the point where we believe detection engineers and blue teamers have everything they need to assess their defences against the techniques used by Saitama.  

Let’s do the twist

The usage of DNS as the channel for C2 communication has a few upsides and quite some major downsides from an attacker’s perspective. While it is true that in many environments DNS is relatively unrestricted, the protocol itself is not designed to transfer large volumes of data. Moreover, the caching of DNS queries forces the implant to make sure that every DNS query sent is unique, to guarantee the DNS query reaches the C2 server.  

For this, the Saitama implant relies on continuously shuffling the character set used to construct DNS queries. While this shuffle makes it near-impossible for two consecutive DNS queries to be the same, it does require the server and client to be perfectly in sync for them to both shuffle their character sets in the same way.  

On startup, the Saitama implant generates a random number between 0 and 46655 and assigns this to a counter variable. Using a shared secret key (“haruto” for the variant discussed here) and a shared initial character set (“razupgnv2w01eos4t38h7yqidxmkljc6b9f5”), the client encodes this counter and sends it over DNS to the C2 server. This counter is then used as the seed for a Pseudo-Random Number Generator (PRNG). Saitama uses the Mersenne Twister to generate a pseudo-random number upon every ‘twist’. 

Function used by Saitama client to convert an integer into an encoded string

To encode this counter, the implant relies on a function named ‘_IntToString’. This function receives an integer and a ‘base string’, which for the first DNS query is the same initial, shared character set as identified in the previous paragraph. Until the input number is equal or lower than zero, the function uses the input number to choose a character from the base string and prepends that to the variable ‘str’ which will be returned as the function output. At the end of each loop iteration, the input number is divided by the length of the baseString parameter, thus bringing the value down. 

To determine the initial seed, the server has to ‘invert’ this function to convert the encoded string back into its original number. However, information gets lost during the client-side conversion because this conversion rounds down without any decimals. The server tries to invert this conversion by using simple multiplication. Therefore, the server might calculate a number that does not equal the seed sent by the client and thus must verify whether the inversion function calculated the correct seed. If this is not the case, the server literately tries higher numbers until the correct seed is found.   

Once this hurdle is taken, the rest of the server-side implementation is trivial. The client appends its current counter value to every DNS query sent to the server. This counter is used as the seed for the PRNG. This PRNG is used to shuffle the initial character set into a new one, which is then used to encode the data that the client sends to the server. Thus, when both server and client use the same seed (the counter variable) to generate random numbers for the shuffling of the character set, they both arrive at the exact same character set. This allows the server and implant to communicate in the same ‘language’. The server then simply substitutes the characters from the shuffled alphabet back into the ‘base’ alphabet to derive what data was sent by the client.  

Server-side implementation to arrive at the same shuffled alphabet as the client

Twist, Sleep, Send, Repeat

Many C2 frameworks allow attackers to manually set the minimum and maximum sleep times for their implants. While low sleep times allow attackers to more quickly execute commands and receive outputs, higher sleep times generate less noise in the victim network. Detection often relies on thresholds, where suspicious behaviour will only trigger an alert when it happens multiple times in a certain period.  

The Saitama implant uses hardcoded sleep values. During active communication (such as when it returns command output back to the server), the minimum sleep time is 40 seconds while the maximum sleep time is 80 seconds. On every DNS query sent, the client will pick a random value between 40 and 80 seconds. Moreover, the DNS query is not sent to the same domain every time but is distributed across three domains. On every request, one of these domains is randomly chosen. The implant has no functionality to alter these sleep times at runtime, nor does it possess an option to ‘skip’ the sleeping step altogether.  

Sleep configuration of the implant. The integers represent sleep times in milliseconds

These sleep times and distribution of communication hinder detection efforts, as they allow the implant to further ‘blend in’ with legitimate network traffic. While the traffic itself appears anything but benign to the trained eye, the sleep times and distribution bury the ‘needle’ that is this implant’s traffic very deep in the haystack of the overall network traffic.  

For attackers, choosing values for the sleep time is a balancing act between keeping the implant stealthy while keeping it usable. Considering Saitama’s sleep times and keeping in mind that every individual DNS query only transmits 15 bytes of output data, the usability of the implant is quite low. Although the implant can compress its output using zlib deflation, communication between server and client still takes a lot of time. For example, the standard output of the ‘whoami /priv’ command, which once zlib deflated is 663 bytes, takes more than an hour to transmit from victim machine to a C2 server. 

Transmission between server implementation and the implant

The implant does contain a set of hardcoded commands that can be triggered using only one command code, rather than sending the command in its entirety from the server to the client. However, there is no way of knowing whether these hardcoded commands are even used by attackers or are left in the implant as a means of misdirection to hinder attribution. Moreover, the output from these hardcoded commands still has to be sent back to the C2 server, with the same delays as any other sent command. 

Detection

Detecting DNS tunnelling has been the subject of research for a long time, as this technique can be implemented in a multitude of different ways. In addition, the complications of the communication channel force attackers to make more noise, as they must send a lot of data over a channel that is not designed for that purpose. While ‘idle’ implants can be hard to detect due to little communication occurring over the wire, any DNS implant will have to make more noise once it starts receiving commands and sending command outputs. These communication ‘bursts’ is where DNS tunnelling can most reliably be detected. In this section we give examples of how to detect Saitama and a few well-known tools used by actual adversaries.  

Signature-based 

Where possible we aim to write signature-based detection, as this provides a solid base and quick tool attribution. The randomization used by the Saitama implant as outlined previously makes signature-based detection challenging in this case, but not impossible. When actively communicating command output, the Saitama implant generates a high number of randomized DNS queries. This randomization does follow a specific pattern that we believe can be generalized in the following Suricata rule: 

alert dns $HOME_NET any -> any 53 (msg:"FOX-SRT - Trojan - Possible Saitama Exfil Pattern Observed"; flow:stateless; content:"|00 01 00 00 00 00 00 00|"; byte_test:1,>=,0x1c,0,relative; fast_pattern; byte_test:1,<=,0x1f,0,relative; dns_query; content:"."; content:"."; distance:1; content:!"."; distance:1; pcre:"/^(?=[0-9]+[a-z]\|[a-z]+[0-9])[a-z0-9]{28,31}\.[^.]+\.[a-z]+$/"; threshold:type both, track by_src, count 50, seconds 3600; classtype:trojan-activity; priority:2; reference:url, https://github.com/fox-it/saitama-server; metadata:ids suricata; sid:21004170; rev:1;) 

This signature may seem a bit complex, but if we dissect this into separate parts it is intuitive given the previous parts. 

Content Match  Explanation 
00 01 00 00 00 00 00 00  DNS query header. This match is mostly used to place the pointer at the correct position for the byte_test content matches. 
byte_test:1,>=,0x1c,0,relative;  Next byte should be at least decimal 25. This byte signifies the length of the coming subdomain 
byte_test:1,<=,0x1f,0,relative;  The same byte as the previous one should be at most 31. 
dns_query; content:”.”; content:”.”; distance:1; content:!”.”;  DNS query should contain precisely two ‘.’ characters 
pcre:”/^(?=[0-9][a-z]|[a-z][0-9])[a-z0-9] {28,31} 
\.[^.]\.[a-z]$/”; 
Subdomain in DNS query should contain at least one number and one letter, and no other types of characters.
threshold:type both, track by_src, count 50, seconds 3600  Only trigger if there are more than 50 queries in the last 3600 seconds. And only trigger once per 3600 seconds. 
Table one: Content matches for Suricata IDS rule

 
The choice for 28-31 characters is based on the structure of DNS queries containing output. First, one byte is dedicated to the ‘send and receive’ command code. Then follows the encoded ID of the implant, which can take between 1 and 3 bytes. Then, 2 bytes are dedicated to the byte index of the output data. Followed by 20 bytes of base-32 encoded output. Lastly the current value for the ‘counter’ variable will be sent. As this number can range between 0 and 46656, this takes between 1 and 5 bytes. 

Behaviour-based 

The randomization that makes it difficult to create signatures is also to the defender’s advantage: most benign DNS queries are far from random. As seen in the table below, each hack tool outlined has at least one subdomain that has an encrypted or encoded part. While initially one might opt for measuring entropy to approximate randomness, said technique is less reliable when the input string is short. The usage of N-grams, an approach we have previously written about4, is better suited.  

Hacktool  Example 
DNScat2  35bc006955018b0021636f6d6d616e642073657373696f6e00.domain.tld5 
Weasel  pj7gatv3j2iz-dvyverpewpnnu–ykuct3gtbqoop2smr3mkxqt4.ab.abdc.domain.tld 
Anchor  ueajx6snh6xick6iagmhvmbndj.domain.tld6 
Cobalt Strike  Api.abcdefgh0.123456.dns.example.com or   post. 4c6f72656d20697073756d20646f6c6f722073697420616d65742073756e74207175697320756c6c616d636f20616420646f6c6f7220616c69717569702073756e7420636f6d6d6f646f20656975736d6f642070726.c123456.dns.example.com 
Sliver  3eHUMj4LUA4HacKK2yuXew6ko1n45LnxZoeZDeJacUMT8ybuFciQ63AxVtjbmHD.fAh5MYs44zH8pWTugjdEQfrKNPeiN9SSXm7pFT5qvY43eJ9T4NyxFFPyuyMRDpx.GhAwhzJCgVsTn6w5C4aH8BeRjTrrvhq.domain.tld 
Saitama  6wcrrrry9i8t5b8fyfjrrlz9iw9arpcl.domain.tld 
Table two: Example DNS queries for various toolings that support DNS tunnelling

Unfortunately, the detection of randomness in DNS queries is by itself not a solid enough indicator to detect DNS tunnels without yielding large numbers of false positives. However, a second limitation of DNS tunnelling is that a DNS query can only carry a limited number of bytes. To be an effective C2 channel an attacker needs to be able to send multiple commands and receive corresponding output, resulting in (slow) bursts of multiple queries.  

This is where the second step for behaviour-based detection comes in: plainly counting the number of unique queries that have been classified as ‘randomized’. The specifics of these bursts differ slightly between tools, but in general, there is no or little idle time between two queries. Saitama is an exception in this case. It uses a uniformly distributed sleep between 40 and 80 seconds between two queries, meaning that on average there is a one-minute delay. This expected sleep of 60 seconds is an intuitive start to determine the threshold. If we aggregate over an hour, we expect 60 queries distributed over 3 domains. However, this is the mean value and in 50% of the cases there are less than 60 queries in an hour.  

To be sure we detect this, regardless of random sleeps, we can use the fact that the sum of uniform random observations approximates a normal distribution. With this distribution we can calculate the number of queries that result in an acceptable probability. Looking at the distribution, that would be 53. We use 50 in our signature and other rules to incorporate possible packet loss and other unexpected factors. Note that this number varies between tools and is therefore not a set-in-stone threshold. Different thresholds for different tools may be used to balance False Positives and False Negatives. 

In summary, combining detection for random-appearing DNS queries with a minimum threshold of random-like DNS queries per hour, can be a useful approach for the detection of DNS tunnelling. We found in our testing that there can still be some false positives, for example caused by antivirus solutions. Therefore, a last step is creating a small allow list for domains that have been verified to be benign. 

While more sophisticated detection methods may be available, we believe this method is still powerful (at least powerful enough to catch this malware) and more importantly, easy to use on different platforms such as Network Sensors or SIEMs and on diverse types of logs. 

Conclusion

When new malware arises, it is paramount to verify existing detection efforts to ensure they properly trigger on the newly encountered threat. While Indicators of Compromise can be used to retroactively hunt for possible infections, we prefer the detection of threats in (near-)real-time. This blog has outlined how we developed a server-side implementation of the implant to create a proper recording of the implant’s behaviour. This can subsequently be used for detection engineering purposes. 

Strong randomization, such as observed in the Saitama implant, significantly hinders signature-based detection. We detect the threat by detecting its evasive method, in this case randomization. Legitimate DNS traffic rarely consists of random-appearing subdomains, and to see this occurring in large bursts to previously unseen domains is even more unlikely to be benign.  

Resources

With the sharing of the server-side implementation and recordings of Saitama traffic, we hope that others can test their defensive solutions.  

The server-side implementation of Saitama can be found on the Fox-IT GitHub.  

This repository also contains an example PCAP & Zeek logs of traffic generated by the Saitama implant. The repository also features a replay script that can be used to parse executed commands & command output out of a PCAP. 

References

[1] https://blog.malwarebytes.com/threat-intelligence/2022/05/apt34-targets-jordan-government-using-new-saitama-backdoor/ 
[2] https://blog.malwarebytes.com/threat-intelligence/2022/05/how-the-saitama-backdoor-uses-dns-tunnelling/ 
[3] https://x-junior.github.io/malware%20analysis/2022/06/24/Apt34.html
[4] https://blog.fox-it.com/2019/06/11/using-anomaly-detection-to-find-malicious-domains/   

❌