A vulnerability in the binding configuration of Cisco SD-WAN vManage Software containers could allow an unauthenticated, adjacent attacker who has access to the VPN0 logical network to also access the messaging service ports on an affected system.This vulnerability exists because the messaging server container ports on an affected system lack sufficient protection mechanisms. An attacker could exploit this vulnerability by connecting to the messaging service ports of the affected system. To exploit this vulnerability, the attacker must be able to send network traffic to interfaces within the VPN0 logical network. This network may be restricted to protect logical or physical adjacent networks, depending on device deployment configuration. A successful exploit could allow the attacker to view and inject messages into the messaging service, which can cause configuration changes or cause the system to reload.Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.This advisory is available at the following link: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-msg-serv-AqTup7vs
Affected Products
Vulnerable ProductsThis vulnerability affects Cisco devices if they are running a vulnerable release of Cisco SD-WAN vManage Software.For information about which Cisco software releases are vulnerable, see the Fixed Software section of this advisory.Products Confirmed Not VulnerableOnly products listed in the Vulnerable Products section of this advisory are known to be affected by this vulnerability.Cisco has confirmed that this vulnerability does not affect the following Cisco products:
IOS XE SD-WAN Software
SD-WAN vBond Orchestrator Software
SD-WAN vEdge Cloud Routers
SD-WAN vEdge Routers
SD-WAN vSmart Controller Software
Workarounds
There is a workaround that addresses this vulnerability.Administrators can use access control lists (ACLs) to block ports 4222, 6222, and 8222, which are used by Cisco SD-WAN vManage Software messaging services. They may be configured in the following ways depending on deployment:
Cisco Cloud Controllers ACLs (Inbound Rules allowed list) are managed through the Self-Service Portal. Customers will have to review their ACL configurations on the Self-Service Portal to ensure that they are correct. This does not involve updating the controller version. By default, Cisco-hosted devices are protected against the issue described in the advisory unless the customer has explicitly allowed access. For more information, see Cisco SD-WAN Cloud Hosted Controllers Provisioning.
While these workarounds have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.
Fixed Software
Cisco has released free software updates that address the vulnerability described in this advisory. Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license: https://www.cisco.com/c/en/us/products/end-user-license-agreement.htmlAdditionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.When considering software upgrades, customers are advised to regularly consult the advisories for Cisco products, which are available from the Cisco Security Advisories page, to determine exposure and a complete upgrade solution.In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.Customers Without Service ContractsCustomers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco TAC: https://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.htmlCustomers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.Fixed ReleasesCustomers are advised to upgrade to an appropriate fixed software release as indicated in the following table(s):Cisco SD-WAN vManage Software ReleaseFirst Fixed ReleaseEarlier than 20.3Migrate to a fixed release.20.3Migrate to a fixed release.20.620.6.420.7Migrate to a fixed release.20.8Migrate to a fixed release.20.920.9.1Note: It is the customer’s responsibility to upgrade their cloud controllers to the latest version in which this vulnerability is fixed.The Cisco Product Security Incident Response Team (PSIRT) validates only the affected and fixed release information that is documented in this advisory.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.
Source
Cisco would like to thank Orange Business for reporting this vulnerability.
VersionDescriptionSectionStatusDate1.1Added cloud information.Workarounds and Fixed SoftwareFinal2022-SEP-091.0Initial public release.-Final2022-SEP-07
The issue in question is CVE-2022-22536, which has received the highest possible risk score of 10.0 on the CVSS vulnerability scoring system and was addressed by SAP as part of its Patch Tuesday updates for February 2022.
Described as an HTTP request smuggling vulnerability, the shortcoming impacts the following product versions –
SAP Web Dispatcher (Versions – 7.49, 7.53, 7.77, 7.81, 7.85, 7.22EXT, 7.86, 7.87)
“An unauthenticated attacker can prepend a victim’s request with arbitrary data, allowing for function execution impersonating the victim or poisoning intermediary web caches,” CISA said in an alert.
“A simple HTTP request, indistinguishable from any other valid message and without any kind of authentication, is enough for a successful exploitation,” Onapsis, which discovered the flaw, notes. “Consequently, this makes it easy for attackers to exploit it and more challenging for security technology such as firewalls or IDS/IPS to detect it (as it does not present a malicious payload).”
Aside from the SAP weakness, the agency added new flaws disclosed by Apple (CVE-2022-32893, and CVE-2022-32894) and Google (CVE-2022-2856) this week as well as previously documented Microsoft-related bugs (CVE-2022-21971 and CVE-2022-26923) and a remote code execution vulnerability in Palo Alto Networks PAN-OS (CVE-2017-15944, CVSS score: 9.8) that was disclosed in 2017.
CVE-2022-21971 (CVSS score: 7.8) is a remote code execution vulnerability in Windows Runtime that was resolved by Microsoft in February 2022. CVE-2022-26923 (CVSS score: 8.8), fixed in May 2022, relates to a privilege escalation flaw in Active Directory Domain Services.
“An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege to System,” Microsoft describes in its advisory for CVE-2022-26923.
The CISA notification, as is traditionally the case, is light on technical details of in-the-wild attacks associated with the vulnerabilities so as to avoid threat actors taking further advantage of them.
To mitigate exposure to potential threats, Federal Civilian Executive Branch (FCEB) agencies are mandated to apply the relevant patches by September 8, 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.
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:
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.
New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.
As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.
Here are the 5 key things we learned from 200 responses:
1 — Remote Work Has Accelerated the Use of EDR Technologies
In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.
2 — 90% of CISOs Use an MDR Solution
There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.
3 — Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams
The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.
4 — Small Security Teams Are Ignoring More Alerts
Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.
5 — 96% of CISOs Are Planning to Consolidate Security Platforms
Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.
The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.
Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.
The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:
The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:
Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
LLVM has the -mretpoline option
MSVC has the /Qspectre option
Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.↩
Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am
Cybersecurity firm Checkmarx has published details on a high-severity vulnerability in the Amazon Photos Android application that could have allowed malicious apps to steal an Amazon access token.
With more than 50 million downloads, Amazon Photos offers cloud storage, allowing users to store photos and videos at their original quality, as well as to print and share photos, and to display them on multiple Amazon devices.
In November 2021, Checkmarx researchers identified an issue in the application that could have leaked the Amazon access token to malicious applications on the user’s device, potentially exposing the user’s personal information. The bug was addressed in December 2021.
The leaked Amazon access token is used for user authentication across Amazon APIs, including some that contain personal information such as names, addresses, and emails. Through the Amazon Drive API, for example, the attacker could access the user’s files, Checkmarx says.
The issue, the researchers explain, resided in a misconfigured component that was “exported in the app’s manifest file, thus allowing external applications to access it.”
The issue resulted in the access token being sent in the header of a HTTP request, but the most important aspect was the fact that an attacker could control the server receiving this request.
“The activity is declared with an intent-filter used by the application to decide the destination of the request containing the access token. Knowing this, a malicious application installed on the victim’s phone could send an intent that effectively launches the vulnerable activity and triggers the request to be sent to a server controlled by the attacker,” Checkmarx notes.
The leaked token could provide the attacker with access to all of the user information available through the Amazon API. Using the Amazon Drive API, the attacker could access users’ files and read, re-write, or delete their contents.
The researchers also explain that the access token could have allowed anyone to modify files and erase their history, to prevent recovery, or could have completely deleted files and folders from the user’s Amazon Drive account.
“With all these options available for an attacker, a ransomware scenario was easy to come up with as a likely attack vector. A malicious actor would simply need to read, encrypt, and re-write the customer’s files while erasing their history,” the researchers say.
The vulnerability might have had a wider impact, given that the potentially affected APIs that the researchers identified represent only a small subset of the entire Amazon ecosystem, Checkmarx also notes.
Cisco advises owners of end-of-life Small Business RV routers to upgrade to newer models after disclosing a remote code execution vulnerability that will not be patched.
The vulnerability is tracked as CVE-2022-20825 and has a CVSS severity rating of 9.8 out of 10.0.
According to a Cisco security advisory, the flaw exists due to insufficient user input validation of incoming HTTP packets on the impacted devices.
An attacker could exploit it by sending a specially crafted request to the web-based management interface, resulting in command execution with root-level privileges.
Impact and remediation
The vulnerability impacts four Small Business RV Series models, namely the RV110W Wireless-N VPN Firewall, the RV130 VPN Router, the RV130W Wireless-N Multifunction VPN Router, and the RV215W Wireless-N VPN Router.
This vulnerability only affects devices with the web-based remote management interface enabled on WAN connections.
While the remote management feature is not enabled in the default configuration, brief searches using Shodan found exposed devices.
To determine whether remote management is enabled, admins should log in to the web-based management interface, navigate to “Basic Settings > Remote Management,” and verify the state of the relevant check box.
Cisco states that they will not be releasing a security update to address CVE-2022-20825 as the devices are no longer supported. Furthermore, there are no mitigations available other than to turn off remote management on the WAN interface, which should be done regardless for better overall security.
Users are advised to apply the configuration changes until they migrate to Cisco Small Business RV132W, RV160, or RV160W Routers, which the vendor actively supports.
Cisco warned last year that admins should upgrade to newer models after disclosing that they would not fix a critical vulnerability in Universal Plug-and-Play (UPnP) service.
This week, Cisco patched a critical vulnerability in Cisco Secure Email that could allow attackers to bypass authentication and login into the web management interface of the Cisco email gateway.
This month, the Cisco Umbrella team – in conjunction with Talos – has witnessed the rise of complex cyberattacks. In today’s edition of the Cybersecurity Threat Spotlight, we unpack the tactics, techniques, and procedures used in these attacks.
Want to see how Cisco Umbrella can protect your network? Sign up for a free trial today!
BlackCat Ransomware
Threat Type: Ransomware
Attack Chain:
Description: BlackCat – also known as “ALPHV”- is a ransomware which uses ransomware-as-a-service model and double ransom schema (encrypted files and stolen file disclosure). It first appeared in November 2021 and, since then, targeted companies have been hit across the globe.
BlackCat Spotlight: BlackCat ransomware has quickly gained notoriety for being used in double ransom (encrypted files and stolen file disclosure) attacks against companies. While it targets companies across the globe, more than 30% of the compromises happened to companies based in the U.S.
There is a connection between the BlackCat, BlackMatter and DarkSide ransomware groups, recently confirmed by the BlackCat representative. Attack kill chain follows the blueprint of other human-operated ransomware attacks: initial compromise, followed by an exploration and data exfiltration phase, then attack preparation and finally, the ransomware execution. The key aspect of such attacks is that adversaries take time exploring the environment and preparing it for a successful and broad attack before launching the ransomware. Some of the attacks took up to two weeks from the initial to final stage, so it is key to have capabilities to detect such activities to counter them.
Target Geolocations: U.S., Canada, EU, China, India, Philippines, Australia Target Data: Sensitive Information, Browser Information Target Businesses: Any Exploits: N/A
Mitre ATT&CK for BlackCat
Initial Access: Valid Accounts: Local Accounts
Discovery: Account Discovery System Information Discovery Network Service Discovery File and Directory Discovery Security Software Discovery ADrecon Sofperfect Network Scanner
Which Cisco Products Can Block: Cisco Secure Endpoint Cisco Secure Firewall/Secure IPS Cisco Secure Malware Analytics Cisco Umbrella
ZingoStealer
Threat Type: Information Stealer
Attack Chain:
Description: ZingoStealer is an information stealer released by a threat actor known as “Haskers Gang.” The malware leverages Telegram chat features to facilitate malware executable build delivery and data exfiltration. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. ZingoStealer has the ability to download additional malware such as RedLine Stealer and the XMRig cryptocurrency mining malware.
ZingoStealer Spotlight: Cisco Talos recently observed a new information stealer, called “ZingoStealer” that has been released for free by a threat actor known as “Haskers Gang.” This information stealer, first introduced to the wild in March 2022, is currently undergoing active development and multiple releases of new versions have been observed recently. In many cases, ZingoStealer is being distributed under the guise of game cheats, cracks and code generators.
The stealer is an obfuscated .NET executable which downloads files providing core functionality an attacker-controlled server. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. The malware is also used as a loader for other malware payloads, such as RedLine Stealer and the XMRig cryptocurrency mining malware.
Target Geolocations: CIS Target Data: User Credentials, Browser Data, Financial and Personal Information, Cryptocurrency Wallets, Data From Browser Extensions Target Businesses: Any Exploits: N/A
Mitre ATT&CK for ZingoStealer
Initial Access: Trojanized Applications
Credential Access: Credentials from Password Stores Steal Web Session Cookie Unsecured Credentials Credentials from Password Stores: Credentials from Web Browsers
Discovery: Account Discovery Software Discovery Process Discovery System Time Discovery System Service Discovery System Location Discovery
Persistence: Registry Run Keys/Startup Folder Scheduled Task/Job: Scheduled Task
Privilege Escalation: N/A
Execution: User Execution Command and Scripting Interpreter: PowerShell
Evasion: Obfuscated Files or Information
Collection: Archive Collected Data: Archive via Utility Data Staged: Local Data Staging
Command and Control: Application Layer Protocol: Web Protocols
Which Cisco Products Can Block: Cisco Secure Endpoint Cisco Secure Email Cisco Secure Firewall/Secure IPS Cisco Secure Malware Analytics Cisco Umbrella Cisco Secure Web Appliance
BumbleBee Loader
Threat Type: Loader
Attack Chain:
Description: BumbleBee is a loader that has anti-virtualization checks and loader capabilities. The goal of the malware is to take a foothold in the compromised system to download and execute additional payloads. BumbleBee was observed to load Cobalt Strike, shellcode, Sliver and Meterpreter malware.
BumbleBee Spotlight: Security researchers noticed the appearance of the new malware being used by Initial Access Brokers, which previously relied on BazaLoader and IcedID malware. Dubbed BumbleBee due to presence of unique User-Agent “bumblebee” in early campaigns, this malware appears to be in active development.
It already employs complex anti-virtualization techniques, as well as uses asynchronous procedure call (APC) injection to launch the shellcode and LOLBins to avoid detections. Delivery chain relies on user interaction to follow the links and open malicious ISO or IMG file. Loader achieves persistence via scheduled task which launches Visual Basic Script to load BumbleBee DLL. Afterwards, the execution malware communicates with the Command-and-Control server and downloads additional payloads such as Cobalt Strike, shellcode, Sliver and Meterpreter. Threat actors using such payloads have been linked to ransomware campaigns.
Target Geolocations: Canada, U.S., Japan Target Data: N/A Target Businesses: Any Exploits: N/A
Mitre ATT&CK for BumbleBee
Initial Access: Malspam
Persistence: Scheduled Task/Job
Execution: Scheduled Task/Job: Scheduled Task Command and Scripting Interpreter: Virtual Basic User Execution: Malicious File
Evasion: System Binary Proxy Execution: Rundll32 Virtualization/Sandbox Evasion: System Checks Process Injection: Asynchronous Procedure Call
Discovery: System Information Discovery System Network Configuration Discovery System Network Connections Discovery
SC Awards from SC Media are known for honoring the best people, products and companies in cybersecurity. One of the industry’s most respected media outlets, SC Media enlists a select pool of experts from the information security community to review more than 800 entries in 35+ categories.
Last year Cisco Umbrella took home SC’s top award for Best SME Security Solution, and we are thrilled to be a finalist again this year – with the winner to be announced in August.
Small and mid-size enterprises need an effective, easy-to-deploy security solution
We firmly believe small and medium-sized businesses deserve big protection. The chilling statistic that 60% of small- and medium-sized businesses go out of business within six months of a cyberattack1 underscores the need for an effective and easy to implement security solution for companies that are likely to have little or no dedicated IT staff.
Blocking threats before they reach the network, endpoints, and end users, Umbrella enables even small IT teams to monitor and respond to threats effectively – like it does for Cape Air.
Cape Air uses Cisco Umbrella to simplify operations and improve security
Headquartered in Hyannis, Massachusetts, Cape Air is a regional airline that provides service to some of the world’s most beautiful destinations. But when frequent malware infections disrupt core services and the customer experience, the brand reputation suffers. For Cape Air, service delays due to malware infections became a common challenge.
Brett Stone, Cape Air’s network operations manager needed to stop threats before they caused service outages. He recognized that Cisco Umbrella could help Cape Air reduce infections since it blocks malware, phishing, command-and-control requests, and other threats at the DNS layer before a connection is even established.
He configured Umbrella within 30 minutes — and saw immediate results:
“From the moment we deployed Umbrella, it was like night and day in the number of tickets we had open because of infections and PCs that kept getting compromised in the past. We were amazed because the next day we didn’t have to fix these problems anymore. Then we could do all those other things that were important to us; we finally had time for them.” – Brett Stone
Stone recalls how malware remediation used to consume all of Cape Air’s network technicians’ time. “Before Umbrella, I had three technicians working 40 hours a week, and all they did for a year was fix malware infections and reimage computers,” Stone recalls. “Thankfully, those days are gone. Now we have zero, or rarely one, malware infection. I don’t remember the last time something got through Cisco Umbrella within the last year or two.”
Want to learn more about how Cisco Umbrella serves small-to-midsize businesses?
Threats are never going to stop coming. But with simple deployment and powerful protection, visibility, and performance, Cisco Umbrella can provide the big protection you need.
Check out our ebook Big Threats to Small Business to learn more about how we meet the unique cybersecurity needs of small and medium sized businesses. And if you’re ready to see our solution in action, check out a free Cisco Umbrella Live Demo.
Thanks to the Malwarebytes Threat Intelligence Team for the information they provided for this article.
Understandably, a lot of cybersecurity research and commentary focuses on the act of breaking into computers undetected. But threat actors are often just as concerned with the act of breaking out of computers undetected too.
Malware with the intent of surveillance or espionage needs to operate undetected, but the chances are it also needs to exfiltrate data or exchange messages with its command and control infrastructure, both of which could reveal its presence to threat hunters.
One of the stealthy communication techniques employed by malware trying to avoid detection is DNS Tunnelling, which hides messages inside ordinary-looking DNS requests.
The Malwarebytes Threat Intelligence team recently published research about an attack on the Jordanian government by the Iranian Advanced Persistent Threat (APT) group APT34 that used its own innovative version of this method.
The payload in the attack was a backdoor called Saitama, a finite state machine that used DNS to communicate. Our original article provides an educational deep dive into the operation of Saitama and is well worth a read.
Here we will expand on the tricks that Saitama used to keep its DNS tunelling hidden.
Saitama’s DNS tunnelling
DNS is the Internet’s “address book” that allows computers to lookup human-readable domain names, like malwarebytes.com, and find their IP addresses, like 54.192.137.126.
DNS information isn’t held in a single database. Instead it’s distributed, and each domain has name servers that are responsible for answering questions about them. Threat actors can use DNS to communicate by having their malware make DNS lookups that are answered by name servers they control.
DNS is so important it’s almost never blocked by corporate firewalls, and the enormous volume of DNS traffic on corporate networks provides plenty of cover for malicious communication.
Saitama’s messages are shaped by two important concerns: DNS traffic is still largely unencrypted, so messages have to be obscured so their purpose isn’t obvious; and DNS records are often cached heavily, so identical messages have to look different to reach the APT-controlled name servers.
Saitama’s messages
In the attack on the Jordanian foreign ministry, Saitama’s domain lookups used the following syntax:
domain = message, counter'.'root domain
The root domain is always one of uber-asia.com, asiaworldremit.com or joexpediagroup.com, which are used interchangeably.
The sub-domain portion of each lookup consists of a message followed by a counter. The counter is used to encode the message, and is sent to the command and control (C2) server with each lookup so the C2 can decode the message.
Four types of message can be sent:
1. Make contact
The first time it is executed, Saitama starts its counter by choosing a random number between 0 and 46655. In this example our randomly-generated counter is 7805.
The DNS lookup derived from that counter is:
nbn4vxanrj.joexpediagroup.com
The counter itself is encoded using a hard-coded base36 alphabet that is shared by the name server. In base36 each digit is represented by one of the 36 characters 0-9 and A-Z. In the standard base36, alphabet 7805 is written 60t (6 x 1296 + 0 x 36 + 30 x 1). However, in Saitama’s custom alphabet 7805 is nrj.
The counter is also used to generate a custom alphabet that will be used to encode the message using a simple substitution. The first message sent home is the command 0, base36-encoded to a, which tells the server it has a new victim, prepended to the string haruto, making aharuto.
A simple substitution using the alphabet generated by the counter yields the message nbn4vxa.
a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9
↓ ↓ ↓ ↓ ↓ ↓
n j 1 6 9 k p b h d 0 7 y i a 2 g 4 u xv 3 e s w f 5 8 r o c q t l z m
The C2 name server decodes the counter using the shared, hard-coded alphabet, and then uses the counter to derive the alphabet used to encode aharuto.
It responds to the contact request with an IP address that contains an ID for Saitama to use in future communications. The first three octets can be anything, and Saitama ignores them. The final octet contains the ID. In our example we will use the ID 203:
75.99.87.203
2. Ask for a command
Now that it has an ID from the C2 server, Saitama increments its counter to 7806 and signals its readiness to receive a command as follows: The counter is used to generate a new custom alaphabet, which encodes the ID, 203, as ao. The counter itself is encoded using the malware’s hard-coded base36 alphabet, to nrc, and one of Saitama’s three root domains is chosen at random, resulting in:
aonrc.uber-asia.com
The C2 server responds to the request with the size of the payload Saitama should expect. Saitama will use this to determine how many requests it will need to make to retrieve the full payload.
The first octet of the IP address the C2 responds with is any number between 129 and 255, while the second, third and fourth octets signify the first, second, and third bytes of the size of the payload. In this case the payload will be four bytes.
129.0.0.4
3. Get a command
Now that it knows the size of the payload it will receive, Saitama makes one or more RECEIVE requests to the server to get its instructions. It increments its counter by one each time, starting at 7807. Multiple requests may be necessary in this step because some command names require more than the four bytes of information an IP address can carry. In this case it has been told to retrieve four bytes of information so it will only need to make one request.
The message from Saitama consists of three parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the payload is required. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7807, giving us the message k7myyy.
The counter is encoded using the hard-coded alphabet to nr6, and one of Saitama’s three root domains is chosen at random, giving us:
k7myyynr6.asiaworldremit.com
The C2 indicates which function it wants to run using two-digit integers. It can ask Saitama to run any of five different functions:
C2
Saitama
43
Static
70
Cmd
71
CompressedCmd
95
File
96
CompressedFile
Saitama functions
In this case the C2 wants to run the command ver using Saitama’s Cmd function. (In the previous request the C2 indicated that it would be sending Saitama a four byte payload: One byte for 70, and three bytes for ver.)
In its response, the C2 uses the first octet of the IP address to indicate the function it wants to run, 70, and then the remaining three octets to spell out the command name ver using the ASCII codepoints for the lowercase characters “v”, “e”, and “r”:
70.118.101.114
4. Run the command
Saitama runs the command it has been given and sends the resulting output to the C2 server in one or more DNS requests. The counter is incremented by one each time, starting at 7808 in our example. Multiple requests may be necessary in this step because some command names require more than the four bytes an IP address can carry.
The counter is encoded using the hard-coded alphabet to nrb, and one of Saitama’s three root domains is chosen at random.
In this case the message consists of five parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the response is being sent; the size of the buffer; and a twelve-byte chunk of the output. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7808, giving us the message p6yqqqqp0b67gcj5c2r3gn3l9epzt.
