Category: Email

Cisco Talos shares insights related to recent cyber attack on Cisco

UPDATE HISTORY

DATEDESCRIPTION OF UPDATES
Aug. 10th 2022Adding clarifying details on activity involving active directory.
Aug. 10th 2022Update 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 

ATT&CK Technique : Phishing (T1566)

ATT&CK Technique : Valid Accounts (T1078)

Execution 

ATT&CK Technique : System Services: Service Execution (T1569.002)

Persistence 

ATT&CK Technique : Create Account: Local Account (T1136.001)

ATT&CK Technique : Account Manipulation: Device Registration (T1098.005)

Privilege Escalation 

ATT&CK Technique : Event Triggered Execution: Image File Execution Options Injection (T1546.012)

Defense Evasion 

ATT&CK Technique : Indicator Removal on Host (T1070)

ATT&CK Technique : Indicator Removal on Host: Clear Windows Event Logs (T1070.001)

ATT&CK Technique : Masquerading: Match Legitimate Name or Location (T1036.005)

ATT&CK Technique : Impair Defenses: Disable or Modify System Firewall (T1562.004)

ATT&CK Technique : Modify Registry (T1112)

Credential Access 

ATT&CK Technique : OS Credential Dumping: LSASS Memory (T1003.001)

ATT&CK Technique : OS Credential Dumping: Security Account Manager (T1003.002)

ATT&CK Technique : OS Credential Dumping: NTDS (T1003.003)

ATT&CK Technique : Multi-Factor Authentication Request Generation (T1621)

Lateral Movement 

ATT&CK Technique : Remote Services (T1021)

Discovery 

ATT&CK Technique : Query Registry (T1012)

Command and Control 

ATT&CK Technique : Application Layer Protocol: Web Protocols (T1071.001)

ATT&CK Technique : Remote Access Software (T1219)

ATT&CK Technique: Encrypted Channel: Asymmetric Cryptography (T1573.002)

ATT&CK Technique : Proxy: Multi-hop Proxy (T1090.003)

Exfiltration 

ATT&CK Technique : Exfiltration Over Alternative Protocol (T1048)

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 

POSTED BY NICK BIASINI AT 3:30 PM

Source :
https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html

Open Port Vulnerabilities List

Insufficiently protected open ports can put your IT environment at serious risk. Threat actors often seek to exploit open ports and their applications through spoofing, credential sniffing and other techniques. For example, in 2017, cybercriminals spread WannaCry ransomware by exploiting an SMB vulnerability on port 445. Other examples include the ongoing campaigns targeting Microsoft’s Remote Desktop Protocol (RDP) service running on port 3389.

Handpicked related content:

Read on to learn more about the security risks linked to ports, vulnerable ports that need your attention and ways to enhance the security of open ports.

A Refresher on Ports

Ports are logical constructs that identify a specific type of network service. Each port is linked to a specific protocol, program or service, and has a port number for identification purposes. For instance, secured Hypertext Transfer Protocol (HTTPS) messages always go to port 443 on the server side, while port 1194 is exclusively for OpenVPN.

The most common transport protocols that have port numbers are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is a connection-oriented protocol with built-in re-transmission and error recovery. UDP is a connectionless protocol that doesn’t recover or correct errors in messages; it’s faster  and has less network overhead traffic than TCP. Both TCP and UDP sit at the transport layer of the TCP/IP stack and use the IP protocol to address and route data on the internet. Software and services are designed to use TCP or UDP, depending on their requirements.

TCP and UDP ports are in one of these three states:

  • Open — The port responds to connection requests.
  • Closed — The port is unreachable, indicating that there is no corresponding service running.
  • Filtered — The firewall is monitoring traffic and blocking certain connection requests to the port.

Security Risks Linked to Ports

Numerous incidents have demonstrated that open ports are most vulnerable to attack when the services listening to them are unpatched or insufficiently protected or misconfigured, which can lead to compromised systems and networks. In these cases, threat actors can use open ports to perform various cyberattacks that exploit the lack of authentication mechanisms in the TCP and UDP protocols. One common example is spoofing, where a malicious actor impersonates a system or a service and sends malicious packets, often in combination with IP spoofing and man-in-the-middle-attacks. The campaign against RDP Pipe Plumbing is one of the latest to employ such a tactic. In addition, ports that have been opened on purpose (for instance, on a web server) can be attacked via that port using application-layer attacks such as SQL injection, cross-site request forgery and directory traversal.

Another common technique is the denial of service (DoS) attack, most frequently used in the form of distributed denial of service (DDoS), where attackers send massive numbers of connection requests from various machine to the service on the target in order to deplete its resources.

Vulnerable Ports that Need Your Attention

Any port can be targeted by threat actors, but some are more likely to fall prey to cyberattacks because they commonly have serious shortcomings, such as application vulnerabilities, lack of two-factor authentication and weak credentials.

Here are the most vulnerable ports regularly used in attacks:

Ports 20 and 21 (FTP)

Port 20 and (mainly) port 21 are File Transfer Protocol (FTP) ports that let users send and receive files from servers.

FTP is known for being outdated and insecure. As such, attackers frequently exploit it through:

  • Brute-forcing passwords
  • Anonymous authentication (it’s possible to log into the FTP port with “anonymous” as the username and password)
  • Cross-site scripting
  • Directory traversal attacks

Port 22 (SSH)

Port 22 is for Secure Shell (SSH). It’s a TCP port for ensuring secure access to servers. Hackers can exploit port 22 by using leaked SSH keys or brute-forcing credentials.

Port 23 (Telnet)

Port 23 is a TCP protocol that connects users to remote computers. For the most part, Telnet has been superseded by SSH, but it’s still used by some websites. Since it’s outdated and insecure, it’s vulnerable to many attacks, including credential brute-forcing, spoofing and credential sniffing.

Port 25 (SMTP)

Port 25 is a Simple Mail Transfer Protocol (SMTP) port for receiving and sending emails. Without proper configuration and protection, this TCP port is vulnerable to spoofing and spamming.

Port 53 (DNS)

Port 53 is for Domain Name System (DNS). It’s a UDP and TCP port for queries and transfers, respectively. This port is particularly vulnerable to DDoS attacks.

Ports 137 and 139 (NetBIOS over TCP) and 445 (SMB)

Server Message Block (SMB) uses port 445 directly and ports 137 and 139 indirectly. Cybercriminals can exploit these ports through:

  • Using the EternalBlue exploit, which takes advantage of SMBv1 vulnerabilities in older versions of Microsoft computers (hackers used EternalBlue on the SMB port to spread WannaCry ransomware in 2017)
  • Capturing NTLM hashes
  • Brute-forcing SMB login credentials

Ports 80, 443, 8080 and 8443 (HTTP and HTTPS)

HTTP and HTTPS are the hottest protocols on the internet, so they’re often targeted by attackers. They’re especially vulnerable to cross-site scripting, SQL injections, cross-site request forgeries and DDoS attacks.

Ports 1433,1434 and 3306 (Used by Databases)

These are the default ports for SQL Server and MySQL. They are used to distribute malware or are directly attacked in DDoS scenarios. Quite often, attackers probe these ports to find unprotected database with exploitable default configurations.

Port 3389 (Remote Desktop)

This port is used in conjunction with various vulnerabilities in remote desktop protocols and to probe for leaked or weak user authentication. Remote desktop vulnerabilities are currently the most-used attack type; one example is the BlueKeep vulnerability.

Tips for Strengthening the Security of Open Ports

Luckily, there are ways to enhance the security of open ports. We highly recommend the following six strategies:

1. Patch firewalls regularly.

Your firewall is the gatekeeper to all the other systems and services in your network. Patching keeps your firewalls up to date and repairs vulnerabilities and flaws in your firewall system that cybercriminals could use to gain full access to your systems and data.

2. Check ports regularly.

You should also regularly scan and check your ports. There are three  main ways to do this:

  • Command-line tools — If you have the time to scan and check ports manually, use command-line tools to spot and scan open ports. Examples include Netstat and Network Mapper, both of which can be installed on a wide range of operating systems, including Windows and Linux.
  • Port scanners — If you want faster results, consider using a port scanner. It’s a computer program that checks if ports are open, closed or filtered. The process is simple: The scanner transmits a network request to connect to a specific port and captures the response.
  • Vulnerability scanning tools — Solutions of this type can also be used to discover ports that are open or configured with default passwords.
  1. Track service configuration changes.

Many services on your network connect to various ports, so it is important to monitor the running states of installed services and continuously track changes to service configuration settings. Services can be vulnerable when they are unpatched or misconfigured.

Using Netwrix Change Tracker, you can harden your systems by tracking unauthorized changes and other suspicious activities. In particular, it provides the following functionality:

  • Actionable alerting about configuration changes
  • Automatic recording, analyzing, validating and verifying of every change
  • Real-time change monitoring
  • Constant application vulnerability monitoring

4. Use IDP and IPS tools.

Intrusion detection systems (IDS) and intrusion prevention systems (IPS) can help you prevent attackers from exploiting your ports. They monitor your network, spot possible cybersecurity incidents, log information about them and report the incidents to security administrators. IPS complements your firewalls by identifying suspicious incoming traffic and logging and blocking the attack.

5. Use SSH Keys.

Another option is to use SSH keys. These access credentials are more secure than passwords because decrypting SSH is very difficult, if not impossible. There are two types of SSH keys:

  • Private or identity keys, which identify users and give them access
  • Public or authorized keys, which determine who can access your system

You can use public-key cryptographic algorithms and key generation tools to create SSH keys.

6. Conduct penetration tests and vulnerability assessments.

Consider conducting penetration tests and vulnerability assessments to protect your ports. Although both of these techniques are used to spot vulnerabilities in IT infrastructure, they are quite different. Vulnerability scans only identify and report vulnerabilities, while penetration tests exploit security gaps to determine how attackers can gain unauthorized access to your system.

FAQs

What is an open port vulnerability?

An open port vulnerability is a security gap caused by an open port. Without proper configuration and protection, attackers can use open ports to access your systems and data.

Which ports are most vulnerable?

Certain ports and their applications are more likely to be targeted because they often have weaker credentials and defenses. Common vulnerable ports include:

  • FTP (20, 21)
  • SSH (22)
  • Telnet (23)
  • SMTP (25)
  • DNS (53)
  • NetBIOS over TCP (137, 139)
  • SMB (445)
  • HTTP and HTTPS (80, 443, 8080, 8443)
  • Ports 1433, 1434 and 3306
  • Remote desktop (3389)

Is port 80 a security risk?

Port 80 isn’t inherently a security risk. However, if you leave it open and don’t have the proper configurations in place, attackers can easily use it to access your systems and data. Unlike port 443 (HTTPS), port 80 is unencrypted, making it easy for cybercriminals to access, leak and tamper with sensitive data.

Source :
https://blog.netwrix.com/2022/08/04/open-port-vulnerabilities-list/

Apple Releases Security Patches for all Devices Fixing Dozens of New Vulnerabilities

Apple on Wednesday rolled out software fixes for iOS, iPadOS, macOS, tvOS, and watchOS to address a number of security flaws affecting its platforms.

This includes at least 37 flaws spanning different components in iOS and macOS that range from privilege escalation to arbitrary code execution and from information disclosure to denial-of-service (DoS).

Chief among them is CVE-2022-2294, a memory corruption flaw in the WebRTC component that Google disclosed earlier this month as having been exploited in real-world attacks aimed at users of the Chrome browser. There is, however, no evidence of in-the-wild zero-day exploitation of the flaw targeting iOS, macOS, and Safari.

Besides CVE-2022-2294, the updates also address several arbitrary code execution flaws impacting Apple Neural Engine (CVE-2022-32810, CVE-2022-32829, and CVE-2022-32840), Audio (CVE-2022-32820), GPU Drivers (CVE-2022-32821), ImageIO (CVE-2022-32802), IOMobileFrameBuffer (CVE-2022-26768), Kernel (CVE-2022-32813 and CVE-2022-32815), and WebKit (CVE-2022-32792).

Also patched is a Pointer Authentication bypass affecting the Kernel (CVE-2022-32844), a DoS bug in the ImageIO component (CVE-2022-32785), and two privilege escalation flaws in AppleMobileFileIntegrity and File System Events (CVE-2022-32819 and CVE-2022-32826).

What’s more, the latest version of macOS resolves five security vulnerabilities in the SMB module that could be potentially exploited by a malicious app to gain elevated privileges, leak sensitive information, and execute arbitrary code with kernel privileges.

Users of Apple devices are recommended to update to iOS 15.6, iPadOS 15.6, macOS Monterey 12.5 (Big Sur 11.6.8 or 2022-005 Catalina for older generation Macs), tvOS 15.6, and watchOS 8.7 to obtain the latest security protections.

Source :
https://thehackernews.com/2022/07/apple-releases-security-patches-for-all.html

DNS-over-HTTP/3 in Android

Posted by Matthew Maurer and Mike Yu, Android team

To help keep Android users’ DNS queries private, Android supports encrypted DNS. In addition to existing support for DNS-over-TLS, Android now supports DNS-over-HTTP/3 which has a number of improvements over DNS-over-TLS.

Most network connections begin with a DNS lookup. While transport security may be applied to the connection itself, that DNS lookup has traditionally not been private by default: the base DNS protocol is raw UDP with no encryption. While the internet has migrated to TLS over time, DNS has a bootstrapping problem. Certificate verification relies on the domain of the other party, which requires either DNS itself, or moves the problem to DHCP (which may be maliciously controlled). This issue is mitigated by central resolvers like Google, Cloudflare, OpenDNS and Quad9, which allow devices to configure a single DNS resolver locally for every network, overriding what is offered through DHCP.

In Android 9.0, we announced the Private DNS feature, which uses DNS-over-TLS (DoT) to protect DNS queries when enabled and supported by the server. Unfortunately, DoT incurs overhead for every DNS request. An alternative encrypted DNS protocol, DNS-over-HTTPS (DoH), is rapidly gaining traction within the industry as DoH has already been deployed by most public DNS operators, including the Cloudflare Resolver and Google Public DNS. While using HTTPS alone will not reduce the overhead significantly, HTTP/3 uses QUIC, a transport that efficiently multiplexes multiple streams over UDP using a single TLS session with session resumption. All of these features are crucial to efficient operation on mobile devices.

DNS-over-HTTP/3 (DoH3) support was released as part of a Google Play system update, so by the time you’re reading this, Android devices from Android 11 onwards1 will use DoH3 instead of DoT for well-known2 DNS servers which support it. Which DNS service you are using is unaffected by this change; only the transport will be upgraded. In the future, we aim to support DDR which will allow us to dynamically select the correct configuration for any server. This feature should decrease the performance impact of encrypted DNS.

Performance

DNS-over-HTTP/3 avoids several problems that can occur with DNS-over-TLS operation:

  • As DoT operates on a single stream of requests and responses, many server implementations suffer from head-of-line blocking3. This means that if the request at the front of the line takes a while to resolve (possibly because a recursive resolution is necessary), responses for subsequent requests that would have otherwise been resolved quickly are blocked waiting on that first request. DoH3 by comparison runs each request over a separate logical stream, which means implementations will resolve requests out-of-order by default.
  • Mobile devices change networks frequently as the user moves around. With DoT, these events require a full renegotiation of the connection. By contrast, the QUIC transport HTTP/3 is based on can resume a suspended connection in a single RTT.
  • DoT intends for many queries to use the same connection to amortize the cost of TCP and TLS handshakes at the start. Unfortunately, in practice several factors (such as network disconnects or server TCP connection management) make these connections less long-lived than we might like. Once a connection is closed, establishing the connection again requires at least 1 RTT.In unreliable networks, DoH3 may even outperform traditional DNS. While unintuitive, this is because the flow control mechanisms in QUIC can alert either party that packets weren’t received. In traditional DNS, the timeout for a query needs to be based on expected time for the entire query, not just for the resolver to receive the packet.

Field measurements during the initial limited rollout of this feature show that DoH3 significantly improves on DoT’s performance. For successful queries, our studies showed that replacing DoT with DoH3 reduces median query time by 24%, and 95th percentile query time by 44%. While it might seem suspect that the reported data is conditioned on successful queries, both DoT and DoH3 resolve 97% of queries successfully, so their metrics are directly comparable. UDP resolves only 83% of queries successfully. As a result, UDP latency is not directly comparable to TLS/HTTP3 latency because non-connection-oriented protocols have a different notion of what a “query” is. We have still included it for rough comparison.

Memory Safety

The DNS resolver processes input that could potentially be controlled by an attacker, both from the network and from apps on the device. To reduce the risk of security vulnerabilities, we chose to use a memory safe language for the implementation.

Fortunately, we’ve been adding Rust support to the Android platform. This effort is intended exactly for cases like this — system level features which need to be performant or low level (both in this case) and which would carry risk to implement in C++. While we’ve previously launched Keystore 2.0, this represents our first foray into Rust in Mainline Modules. Cloudflare maintains an HTTP/3 library called quiche, which fits our use case well, as it has a memory-safe implementation, few dependencies, and a small code size. Quiche also supports use directly from C++. We considered this, but even the request dispatching service had sufficient complexity that we chose to implement that portion in Rust as well.

We built the query engine using the Tokio async framework to simultaneously handle new requests, incoming packet events, control signals, and timers. In C++, this would likely have required multiple threads or a carefully crafted event loop. By leveraging asynchronous in Rust, this occurs on a single thread with minimal locking4. The DoH3 implementation is 1,640 lines and uses a single runtime thread. By comparison, DoT takes 1,680 lines while managing less and using up to 4 threads per DoT server in use.

Safety and Performance — Together at Last

With the introduction of Rust, we are able to improve both security and the performance at the same time. Likewise, QUIC allows us to improve network performance and privacy simultaneously. Finally, Mainline ensures that such improvements are able to make their way to more Android users sooner.

Acknowledgements

Special thanks to Luke Huang who greatly contributed to the development of this feature, and Lorenzo Colitti for his in-depth review of the technical aspects of this post.

  1. Some Android 10 devices which adopted Google Play system updates early will also receive this feature. ↩
  2. Google DNS and Cloudflare DNS at launch, others may be added in the future. ↩
  3. DoT can be implemented in a way that avoids this problem, as the client must accept server responses out of order. However, in practice most servers do not implement this reordering. ↩
  4. There is a lock used for the SSL context which is accessed once per DNS server, and another on the FFI when issuing a request. The FFI lock could be removed with changes to the C++ side, but has remained because it is low contention. ↩

    Source :
    https://security.googleblog.com/2022/07/dns-over-http3-in-android.html

Microsoft Teams outage also takes down Microsoft 365 services

What initially started like a minor Microsoft Teams outage has also taken down multiple Microsoft 365 services with Teams integration, including Exchange Online, Windows 365, and Office Online.

“We’ve received reports of users being unable to access Microsoft Teams or leverage any features,” the company revealed on its official Microsoft 365 Status Twitter account more than 8 hours ago.

Two hours later, Redmond said the issue causing the connection problems was a recent deployment that featured a broken connection to an internal storage service.

However, Teams was not the only product impacted by the outage since users also began reporting failures to connect to various Microsoft 365 services.

Microsoft confirmed the issues saying that the subsequent Microsoft 365 outage only affected services that came with Teams integration.

“We’ve identified downstream impact to multiple Microsoft 365 services with Teams integration, such as Microsoft Word, Office Online and SharePoint Online,” Microsoft explained.

Microsoft Teams outage tweet

As the company further detailed on its Microsoft 365 Service health status page, affected customers experienced issues with one or more of the following services:

  • Microsoft Teams (Access, chat, and meetings)
  • Exchange Online (Delays sending mail)
  • Microsoft 365 Admin center (Inability to access)
  • Microsoft Word within multiple services (Inability to load)
  • Microsoft Forms (Inability to use via Teams)
  • Microsoft Graph API (Any service relying on this API may be affected)
  • Office Online (Microsoft Word access issues)
  • SharePoint Online (Microsoft Word access issues)
  • Project Online (Inability to access)
  • PowerPlatform and PowerAutomate (Inability to create an environment with a database)
  • Autopatches within Microsoft Managed Desktop
  • Yammer (Impact to Yammer experiments)
  • Windows 365 (Unable to provision Cloud PCs)

After redirecting traffic to a healthy service to mitigate the impact, Redmond said its telemetry indicates that Microsoft Teams functionality started to recover.

“Service availability has mostly recovered with only a few service features still requiring attention,” Microsoft added on the service health status page and on Twitter two hours ago, at 4 AM EST.

“We’ll continue to monitor the service as new regions enter business hours to ensure the service health does not fluctuate while the remaining actions are completed.”

Source :
https://www.bleepingcomputer.com/news/microsoft/microsoft-teams-outage-also-takes-down-microsoft-365-services/

Uncovering a macOS App Sandbox escape vulnerability: A deep dive into CVE-2022-26706

Microsoft uncovered a vulnerability in macOS that could allow specially crafted codes to escape the App Sandbox and run unrestricted on the system. We shared these findings with Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) in October 2021. A fix for this vulnerability, now identified as CVE-2022-26706, was included in the security updates released by Apple on May 16, 2022. Microsoft shares the vulnerability disclosure credit with another researcher, Arsenii Kostromin (0x3c3e), who discovered a similar technique independently.

We encourage macOS users to install these security updates as soon as possible. We also want to thank the Apple product security team for their responsiveness in fixing this issue.

The App Sandbox is Apple’s access control technology that application developers must adopt to distribute their apps through the Mac App Store. Essentially, an app’s processes are enforced with customizable rules, such as the ability to read or write specific files. The App Sandbox also restricts the processes’ access to system resources and user data to minimize the impact or damage if the app becomes compromised. However, we found that specially crafted codes could bypass these rules. An attacker could take advantage of this sandbox escape vulnerability to gain elevated privileges on the affected device or execute malicious commands like installing additional payloads.

We found the vulnerability while researching potential ways to run and detect malicious macros in Microsoft Office on macOS. For backward compatibility, Microsoft Word can read or write files with an “~$” prefix. Our findings revealed that it was possible to escape the sandbox by leveraging macOS’s Launch Services to run an open –stdin command on a specially crafted Python file with the said prefix.

Our research shows that even the built-in, baseline security features in macOS could still be bypassed, potentially compromising system and user data. Therefore, collaboration between vulnerability researchers, software vendors, and the larger security community remains crucial to helping secure the overall user experience. This includes responsibly disclosing vulnerabilities to vendors.

In addition, insights from this case study not only enhance our protection technologies, such as Microsoft Defender for Endpoint, but they also help strengthen the security strategies of software vendors and the computing landscape at large. This blog post thus provides details of our research and overviews of similar sandbox escape vulnerabilities reported by other security researchers that helped enrich our analysis.

How macOS App Sandbox works

In a nutshell, macOS apps can specify sandbox rules for the operating system to enforce on themselves. The App Sandbox restricts system calls to an allowed subset, and the said system calls can be allowed or disallowed based on files, objects, and arguments. Simply put, the sandbox rules are a defense-in-depth mechanism that dictates the kind of operations an application can or can’t do, regardless of the type of user running it. Examples of such operations include:

  • the kind of files an application can or can’t read or write;
  • whether the application can access specific resources such as the camera or the microphone, and;
  • whether the application is allowed to perform inbound or outbound network connections.
Diagram comparing how user data and system resources access an app without and with App Sandbox.Without App Sandbox, all user data and system resources will have unrestricted access to the app.With App Sandbox, only the data and resources confined within the said sandbox will have unrestricted access to the app. All other user data and resources won't have access.
Figure 1. Illustration of a sandboxed app, from the App Sandbox documentation (photo credit: Apple)

Therefore, the App Sandbox is a useful tool for all macOS developers in providing baseline security for their applications, especially for those that have large attack surfaces and run user-provided code. One example of these applications is Microsoft Office.

Sandboxing Microsoft Office in macOS

Attackers have targeted Microsoft Office in their attempts to gain a foothold on devices and networks. One of their techniques is abusing Office macros, which they use in social engineering attacks to trick users into downloading malware and other payloads.

On Windows systems, Microsoft Defender Application Guard for Office helps secure Microsoft Office against such macro abuse by isolating the host environment using Hyper-V. With this feature enabled, an attacker must first be equipped with a Hyper-V guest-to-host vulnerability to affect the host system—a very high bar compared to simply running a macro. Without a similar isolation technology and default setting on macOS, Office must rely on the operating system’s existing mitigation strategies. Currently, the most promising technology is the macOS App Sandbox.

Viewing the Microsoft sandbox rules is quite straightforward with the codesign utility. Figure 2 below shows the truncated sandbox rules for Microsoft Word:

Partial screenshot of a command line interface showing different keys and values related to the App Sandbox rules for Microsoft Word in macOS.
Figure 2. Viewing the Microsoft Word sandbox rules with the codesign utility

One of the rules dictates the kind of files the application is allowed to read or write. As seen in the screenshot of the syntax below, Word is allowed to read or write files with filenames that start with the “~$” prefix. The reason for this rule is rooted in the way Office works internally and remains intact for backward compatibility.

Partial screenshot of a command line interface showing the read/write App Sandbox rule for Microsoft Word in macOS.
Figure 3. File read and write sandbox rule for Microsoft Word

Despite the security restrictions imposed by the App Sandbox’s rules on applications, it’s possible for attackers to bypass the said rules and let malicious codes “escape” the sandbox and execute arbitrary commands on an affected device. These codes could be hidden in a specially crafted Word macro, which, as mentioned earlier, is one of the attackers’ preferred entry points.

Previously reported Office-specific sandbox escape vulnerability

For example, in 2018, MDSec reported a vulnerability in Microsoft Office on macOS that could allow an attacker to bypass the App Sandbox. As explained in their blog post, MDSec’s proof-of-concept (POC) exploit took advantage of the fact that Word could drop files with arbitrary contents to arbitrary directories (even after passing traditional permission checks), as long as these files’ filenames began with a “~$” prefix. This bypass was relatively straightforward: have a specially crafted macro drop a .plist file in the user’s LaunchAgents directory.

The LaunchAgents directory is a well-known persistence mechanism in macOS. PLIST files that adhere to a specific structure describe (that is, contain the metadata of) macOS launch agents initiated by the launchd process when a user signs in. Since these launch agents will be the children of launchd, they won’t inherit the sandbox rules enforced onto Word, and therefore will be out of the Office sandbox.

Shortly after the above vulnerability was reported, Microsoft deployed a fix that denied file writes to the LaunchAgents directory and other folders with similar implications. The said disclosure also prompted us to look into different possible sandbox escapes in Microsoft Word and other applications.

Exploring Launch Services as means of escaping the sandbox

In 2020, several blog posts described a generic sandbox escape vulnerability in macOS’s /usr/bin/open utility, a command commonly used to launch files, folders, and applications just as if a user double-clicked them. While open is a handy command, it doesn’t create child processes on its own. Instead, it performs an inter-process communication (IPC) with the macOS Launch Services, whose logic is implemented in the context of the launchd process. Launch Services then performs the heavy lifting by resolving the handler and launching the right app. Since launchd creates the process, it’s not restricted by the caller’s sandbox, similar to how MDSec’s POC exploit worked in 2018.

However, using open for sandbox escape purposes isn’t trivial because the destination app must be registered within Launch Services. This means that, for example, one couldn’t run files like osascript outside the sandbox using open. Our internal offensive security team therefore decided to reassess the open utility for sandbox escape purposes and use it in a larger end-to-end attack simulation.

Our obvious first attempt in creating a POC exploit was to create a macro that launches a shell script with the Terminal app. Surprisingly, the POC didn’t work because files dropped from within the sandboxed Word app were automatically given the extended attribute com.apple.quarantine (the same one used by Safari to keep track of internet-downloaded files, as well as by Gatekeeper to block malicious files from executing), and Terminal simply refused to run files with that attribute. We also tried using Python scripts, but the Python app had similar issues running files having the said attribute.

Our second attempt was to use application extensibility features. For example, Terminal would run the default macOS shell (zsh), which would then run arbitrary commands from files like ~/.zshenv before running its own command line. This meant that dropping a .zshenv file in the user’s home directory and launching the Terminal app would cause the sandbox escape. However, due to Word’s sandbox rules, dropping a .zshenv file wasn’t straightforward, as the rules only allowed an application to write to files that begin with the “~$” prefix.

However, there is an interesting way of writing such a file indirectly. macOS was shipped with an application called Archive Utility responsible of extracting archive files (such as ZIP files). Such archives were extracted without any user interaction, and the files inside an archive were extracted in the same directory as the archive itself. Therefore, our second POC worked as follows:

  1. Prepare the payload by creating a .zshenv file with arbitrary commands and placing it in a ZIPfile. Encode the ZIPfile contents in a Word macro and drop those contents into a file “~$exploit.zip” in the user’s home directory.
  2. Launch Archive Utility with the open command on the “~$exploit.zip” file. Archive Utility ran outside the sandbox (since it’s the child process of /usr/bin/open) and was therefore permitted to create files with arbitrary names. By default, Archive Utility extracted the files next to the archive itself—in our case, the user’s home directory. Therefore, this step successfully created a .zshenv file with arbitrary contents in the user’s home directory.
  3. Launch the Terminal app with the open command. Since Terminal hosted zsh and zsh ran commands from the .zshenv file, the said file could escape the Word sandbox successfully.
Screenshot of a command line interface showing proof-of-concept exploit code.
Figure 4. Preparing a Word macro with our sandbox escape for an internal Red Team operation

Perception Point’s CVE-2021-30864

In October 2021, Perception Point published a blog post that discussed a similar finding (and more elegant, in our opinion). In the said post, Perception Point released details about their sandbox escape (now identified as CVE-2021-30864), which used the following facts:

  1. Every sandboxed process had its own container directory that’s used as a “scratch space.” The sandboxed process could write arbitrary files, including arbitrary filenames, to that directory unrestricted.
  2. The open command had an interesting –env option that could set or override arbitrary environment variables for the launched app.

Therefore, Perception Point’s POC exploit was cleverly simple:

  1. Drop a .zshenv file in the container directory. This was allowed because sandbox rules weren’t enforced on that directory.
  2. Launch Terminal with the open command but use the –env option to override the HOME environment variable to point to the container directory. This made zsh consider the user’s home directory to be the container directory, and run commands from the planted .zshenv file.

Apple has since patched the vulnerability Perception Point reported in the latest version of macOS, Monterey. While we could still create the “~$exploit.zip” file in the user’s home directory, using open to launch the Archive Utility on the ZIP file now resulted in it being extracted to the Downloads folder. While this is an interesting behavior, we could no longer use it for sandbox escape purposes.

Final exploit attempt: Revisiting the ‘open’ command

After discovering that Apple has fixed both variants that abuse .zshenv, , we decided to examine all the command line options of the open command. Soon after, we came across the following:

Screenshot of a command line interface with the following text:--stdin PATH Launches the application with stdin connected to PATH.
Figure 5. The –stdin option in the open utility as presented by its manual entry

As mentioned earlier, we couldn’t run Python with a dropped .py file since Python refuses to run files with the “com.apple.quarantine” extended attribute. We also considered abusing the PYTHONSTARTUP environment variable, but Apple’s fix to CVE-2021-30864 apparently prevented that option, too. However, –stdin bypassed the “com.apple.quarantine” extended attribute restriction, as there was no way for Python to know that the contents from its standard input originated from a quarantined file.

Our POC exploit thus became simply as follows:

  1. Drop a “~$exploit.py” file with arbitrary Python commands.
  2. Run open –stdin=’~$exploit.py’ -a Python, which runs the Python app with our dropped file serving as its standard input. Python happily runs our code, and since it’s a child process of launchd, it isn’t bound to Word’s sandbox rules.
Screenshot of a proof-of-concept exploit code.
Figure 6. Sample minimal POC exploit code

We also came up with a version that’s short enough to be a Twitter post:

Screenshot of a proof-of-concept exploit code.
Figure 7. “Tweetable” POC exploit

Detecting App Sandbox escapes with Microsoft Defender for Endpoint

Since our initial discovery of leveraging Launch Services in macOS for generic sandbox escapes, we have been using our POC exploits in Red Team operations to emulate end-to-end attacks against Microsoft Defender for Endpoint, improve its capabilities, and challenge our detections. Shortly after our Red Team used our first POC exploit, our Blue Team members used it to train artificial intelligence (AI) models to detect our exploit not only in Microsoft Office but also on any app used for a similar Launch Services-based sandbox escape.

After we learned of Perception Point’s technique and created our own new exploit technique (the Python POC), our Red Team saw another opportunity to fully test our own detection durability. Indeed, the same set of detection rules that handled our first sandbox escape vulnerability still turned out to be durable—even before the vulnerability related to our second POC exploit was patched.

Partial screenshot of Microsoft Defender for Endpoint detecting an Office sandbox escape vulnerability.The left panel shows the Alert Story with timestamps. The right panel shows the Alert details, including category, MITRE ATT&CK techniques, detection source, service source, detection status, and other information.
Figure 8. Microsoft Defender for Endpoint detecting Office sandbox escape

For Defender for Endpoint customers, such detection durability feeds into the product’s threat and vulnerability management capabilities, which allows them to quickly discover, prioritize, and remediate misconfigurations and vulnerabilities—including those affecting non-Windows devices—through a unified security console.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution across all platforms.

Jonathan Bar Or
Microsoft 365 Defender Research Team

Source :
https://www.microsoft.com/security/blog/2022/07/13/uncovering-a-macos-app-sandbox-escape-vulnerability-a-deep-dive-into-cve-2022-26706/

A Simple Formula for Getting Your IT Security Budget Approved

Although there is a greater awareness of cybersecurity threats than ever before, it is becoming increasingly difficult for IT departments to get their security budgets approved. Security budgets seem to shrink each year and IT pros are constantly being asked to do more with less. Even so, the situation may not be hopeless. There are some things that IT pros can do to improve the chances of getting their security budgets approved.

Presenting the Problem in a Compelling Way

If you want to get your proposed security budget approved, you will need to present security problems in a compelling way. While those who are in charge of the organization’s finances are likely aware of the need for good security, they have probably also seen enough examples of “a security solution in search of a problem” to make them skeptical of security spending requests. If you want to persuade those who control the money, then you will need to convince them of three things:

  1. You are trying to protect against a real issue that presents a credible threat to the organization’s wellbeing.
  2. Your proposed solution will be effective and that it isn’t just a “new toy for the IT department to play with”
  3. Your budget request is both realistic and justified.

Use Data to Your Advantage

One of the best ways to convince those who are in charge that there is a credible cyber threat against the organization is to provide them with quantifiable metrics. Don’t resort to gathering statistics from the Internet. Your organization’s financial staff is probably smart enough to know that most of those statistics are manufactured by security companies who are trying to sell a product or service. Instead, gather your own metrics from inside your organization by using tools that are freely available for download.

Specops for example, offers a free Password Auditor that can generate reports demonstrating the effectiveness of your organization’s password policy and existing password security vulnerabilities. This free tool can also help you to identify other vulnerabilities, such as accounts that are using passwords that are known to have been leaked or passwords that do not adhere to compliance standards or industry best practices.

Example of Specops Password Auditor results in an Active Directory environment

Of course, this is just one of the many free security tools that are available for download. In any case, it is important to use metrics from within your own organization to demonstrate the fact that the security problem that you are trying to solve is real.

Highlight What a Solution Would Do

Once you demonstrate the problem to those who are in charge of the organization’s finances, do not make the mistake of leaving them guessing as to how you are planning on solving the problem. Be prepared to clearly explain what tools you are planning on using, and how those tools will solve the problem that you have demonstrated.

It’s a good idea to use visuals to demonstrate the practicality of your proposed solution. Be sure to explain how the problem is solved in non-technical language and enhance your argument with examples that are specific to your organization.

Estimated Time of Implementation and Seeing Results

We have probably all heard horror stories of IT projects that have gone off the rails. Organizations sometimes spend millions of dollars and invest years of planning into IT projects that never ultimately materialize. That being the case, it is important to set everyone’s mind at ease by showing them exactly how long it will take to get your proposed solution up and running and then how much additional time will be needed in order to achieve the desired result.

When you are making these projections, be careful to be realistic and not to make promises based on an overly ambitious implementation schedule. You should also be prepared to explain how you arrived at your projection. Keep in mind upcoming projects, company-wide goals, and fiscal year ideals when factoring in timing.

Demonstrate the Estimated Savings

Although security is of course a concern for most organizations, those who are in charge of an organization’s finances typically want to see some sort of return on investment. As such, it is important to consider how your proposed solution might save the company money. A few ideas might include:

  • Saving the IT department time, thereby reducing the number of overtime hours worked
  • Avoiding a regulatory penalty that could cost the organization a lot of money
  • Bringing down insurance premiums because data is being better protected

Of course, these are just ideas. Every situation is different, and you will need to consider how your security project can produce a return on investment given your own unique circumstances. It is important to include a cost-saving element for clarity sake, even if it is citing the average cost of a data breach in your industry.

Show You’ve Done Your Homework with a Pricing Comparison

As you pitch your proposed solution, stakeholders are almost certain to ask whether there might be a less expensive product that would accomplish your objectives. As such, it’s important to spend some time researching the solutions offered by competing vendors. Here are a few things that you should be prepared to demonstrate:

  • The total cost for implementing each potential solution (this may include licensing, labor, support, and hardware costs)
  • Why you are proposing a particular solution even if it is not the least expensive
  • If your solution is the least expensive, then be prepared to explain what you might be giving up by using the cheapest vendor.
  • What each vendor offers relative to the others

A Few Quick Tips

As you make your budgetary pitch, keep in mind that those to whom you are presenting likely have a limited understanding of IT concepts. Avoid using unnecessary technical jargon and be prepared to clearly explain key concepts, but without sounding condescending in the process.

It’s also smart to anticipate any questions that may be asked of you and have answers to those questions ready to go. This is especially true if there is a particular question that makes you a little bit uncomfortable.

Present your information clearly, confidently, and in a concise manner (I.e., make it quick!) so you can make your case without wasting time.

Source:
https://thehackernews.com/2022/07/a-simple-formula-for-getting-your-it.html

Mantis – the most powerful botnet to date

In June 2022, we reported on the largest HTTPS DDoS attack that we’ve ever mitigated — a 26 million request per second attack – the largest attack on record. Our systems automatically detected and mitigated this attack and many more. Since then, we have been tracking this botnet, which we’ve called “Mantis”, and the attacks it has launched against almost a thousand Cloudflare customers.

Cloudflare WAF/CDN customers are protected against HTTP DDoS attacks including Mantis attacks. Please refer to the bottom of this blog for additional guidance on how to best protect your Internet properties against DDoS attacks.

Have you met Mantis?

We named the botnet that launched the 26M rps (requests per second) DDoS attack “Mantis” as it is also like the Mantis shrimp, small but very powerful. Mantis shrimps, also known as “thumb-splitters”, are very small; less than 10 cm in length, but their claws are so powerful that they can generate a shock wave with a force of 1,500 Newtons at speeds of 83 km/h from a standing start. Similarly, the Mantis botnet operates a small fleet of approximately 5,000 bots, but with them can generate a massive force — responsible for the largest HTTP DDoS attacks we have ever observed.

Image of the Mantis shrimp from Wikipedia
Mantis shrimp. Source: Wikipedia.

The Mantis botnet was able to generate the 26M HTTPS requests per second attack using only 5,000 bots. I’ll repeat that: 26 million HTTPS requests per second using only 5,000 bots. That’s an average of 5,200 HTTPS rps per bot. Generating 26M HTTP requests is hard enough to do without the extra overhead of establishing a secure connection, but Mantis did it over HTTPS. HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection. This stands out and highlights the unique strength behind this botnet.

Graph of the 26 million requests per second DDoS attack

As opposed to “traditional” botnets that are formed of Internet of Things (IoT) devices such as DVRs, CC cameras, or smoke detectors, Mantis uses hijacked virtual machines and powerful servers. This means that each bot has a lot more computational resources — resulting in this combined thumb-splitting strength.

Mantis is the next evolution of the Meris botnet. The Meris botnet relied on MikroTik devices, but Mantis has branched out to include a variety of VM platforms and supports running various HTTP proxies to launch attacks. The name Mantis was chosen to be similar to “Meris” to reflect its origin, and also because this evolution hits hard and fast. Over the past few weeks, Mantis has been especially active directing its strengths towards almost 1,000 Cloudflare customers.

Graphic design of a botnet

Who is Mantis attacking?

In our recent DDoS attack trends report, we talked about the increasing number of HTTP DDoS attacks. In the past quarter, HTTP DDoS attacks increased by 72%, and Mantis has surely contributed to that growth. Over the past month, Mantis has launched over 3,000 HTTP DDoS attacks against Cloudflare customers.

When we take a look at Mantis’ targets we can see that the top attacked industry was the Internet & Telecommunications industry with 36% of attack share. In second place, the News, Media & Publishing industry, followed by Gaming and Finance.

When we look at where these companies are located, we can see that over 20% of the DDoS attacks targeted US-based companies, over 15% Russia-based companies, and less than five percent included Turkey, France, Poland, Ukraine, and more.

How to protect against Mantis and other DDoS attacks

Cloudflare’s automated DDoS protection system leverages dynamic fingerprinting to detect and mitigate DDoS attacks. The system is exposed to customers as the HTTP DDoS Managed Ruleset. The ruleset is enabled and applying mitigation actions by default, so if you haven’t made any changes, there is no action for you to take — you are protected. You can also review our guides Best Practices: DoS preventive measures and Responding to DDoS attacks for additional tips and recommendations on how to optimize your Cloudflare configurations.

If you are only using Magic Transit or Spectrum but also operate HTTP applications that are not behind Cloudflare, it is recommended to onboard them to Cloudflare’s WAF/CDN service to benefit from L7 protection.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you’re looking for a new career direction, check out our open positions.

Source:
https://blog.cloudflare.com/mantis-botnet/

5 Key Things We Learned from CISOs of Smaller Enterprises Survey

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.

Download 2022 CISO Survey of Small Cyber Security Teams to see all the results.

Source :
https://thehackernews.com/2022/07/5-key-things-we-learned-from-cisos-of.html

Spectre and Meltdown Attacks Against OpenSSL

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
  1. 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

Source :
https://www.openssl.org/blog/blog/2022/05/13/spectre-meltdown/