Blog

Archive for May, 2021

Ransomware Defenses, (Mon, May 17th)

Ransomware attacks continue to be in the headlines everywhere, and are also an almost weekly reoccurring subject in the SANS Newsbites. As useful as many of the reports are that security firms and researchers publish on the subject, they often focus heavily on one particular incident or type of ransomware, and the associated “indicators of compromise” (IOCs). We already covered before how IOCs can turn into IOOI’s (Indicators of Outdated Intelligence), and how to try to elevate the defense work from detecting IOCs to detecting TTPs (Tactics Techniques and Procedures).

While IOCs change quickly and often, a good TTP detection will still trigger on attack variants that look different. But it’s still “detection”, and therefore reactive and after the fact. Detection is best used to catch instances where the prevention failed, and should not be misused as a stand-in or replacement for preventive measures that we know we should have, but never got around to implement, enable or configure properly.

For Ransomware Prevention, most advice starts with “Have backups” and “Test your incident response”. Both are true and valid. But the CISA.gov Ransomware Guide published last September has a decent list of additional advice that is worth reading.

From what became known of recent successful attacks, it looks like lack of 2-factor authentication (2FA) is still the most prevalent root cause. If you still have any remote access or remote desktop connections that rely on userid/password only, switch them to 2FA now!  And if you still have any webmail or the like without 2FA, make the change there as well.

For most avenues of infection, the attackers first have to establish a foothold on the compromised system, and find a mechanism to maintain remote access or command&control to the affected machine. These two phases (MITRE ATT&CK calls them “Execution” and “Persistence”) provide additional chances to intercept or at least detect an ongoing compromise. Not so if that initial compromise occurs through exposed remote desktop – in that case, the bad guys basically score a home run, obtain interactive remote access from the get-go, and can get busy right away.  

As for webmail, your users WILL get successfully phished eventually, if not today then tomorrow. Absence of 2FA allows the attacker to impersonate your phished user, both towards your other employees, but also towards all your customers, clients and business partners. To those recipients, the email will look like it came from a known and trusted source, which increases the damage potential. Don’t be the company that emails ransomware to others – activate 2FA for all your email users!

If you are in an industry that is considered to be part of “critical infrastructure” and are based in the US, you can apply to receive vulnerability scanning and security assessment support from CISA, *for free*. Check out https://www.cisa.gov/cyber-hygiene-services .

Further resources from SANS include a recent webcast, and a compilation of anti-ransomware resources. There is also an upcoming SANS Training, currently in Beta Test, titled “FOR528: Ransomware for Incident Responders”, see https://www.sans.org/blog/for528-ransomware-for-incident-responders/ for more information.

 

(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) →

"Open" Access to Industrial Systems Interface is Also Far From Zero, (Fri, May 14th)

Jan’s last diary about the recent attack against the US pipeline[1] was in perfect timing with the quick research I was preparing for a few weeks. If core components of industrial systems are less exposed in the wild, as said Jan, there is another issue with such infrastructures: remote access tools. Today, buildings, factories, farms must be controlled remotely or sometimes managed by third parties. If Microsoft RDP is common on many networks (and is often the weakest link in a classic attack like ransomware), there is another protocol that is heavily used to remote control industrial systems: VNC (“Virtual Network Computing”)[2]. This protocol works with many different operating systems (clients and servers), is simple and efficient. For many companies developing industrial systems, It is a good candidate to offer remote access. 

To give you an idea of the VNC popularity on the Internet, Shodan report this number of available systems:

  • Port 5900: 907.387 hosts
  • Port 5901: 738.545 hosts

Note: VNC uses by default the port 5900+n, where n is the display number (usually :0 for a physical display).

I had a look at open port 5900 & 5901 and captured 655K exposed VNC servers. Don’t take me wrong, I don’t say that VNC is bad. I still use it almost weekly but, like all tools, it must be configured and used in a proper way. Read: access must be restricted (passwords, access-lists) and traffic encrypted. My next step was to hunt for open VNC console (without any authentication). I did not brute force passwords or tried even simple passwords like “admin”. I used the tool vncsnapshot[3] to take screenshots of non-protected systems through the Tor Network. 

Based on the sample screenshots below, you realize that many organizations are at risk, and many bad stories like the US pipeline attack will continue to raise in the news…

[1] https://isc.sans.edu/forums/diary/Number+of+industrial+control+systems+on+the+internet+is+lower+then+in+2020but+still+far+from+zero/27412/
[2] https://en.wikipedia.org/wiki/Virtual_Network_Computing
[3] https://github.com/IDNT/vncsnapshot

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Number of industrial control systems on the internet is lower then in 2020…but still far from zero, (Wed, May 12th)

With the recent ransomware attack that impacted operation of one of the major US pipelines[1], I thought it might be a good time to revisit the old topic of internet-connected industrial systems. Since operational technologies are generally used to support/control processes that directly impact the physical world, the danger of successful attacks on them should be self-evident, as should the need to protect them.

While it is true that not all ICS, Industrial IoT devices and other similar systems are made equal, since some of them support highly critical processes, while others only control minor functions such as central heating in private residences, compromise of any of them would certainly not be desirable. One would therefore hope that – if nothing else – most such systems would not be directly accessible from the internet, especially since they are usually controlled with the help of specialized industrial protocols, that lack any kind of inbuilt security controls or even authentication and authorization checks.

As you have probably guessed, however, the number of internet-connected industrial systems is unfortunately much higher than one might wish.

Since (especially) many of the Industrial IoT devices are controlled only through web interfaces, it would be difficult to count all such systems on the internet. We may, however, at least look at the number of the public IPs where devices that communicate using different industrial protocols recognized by Shodan and Censys are/were accessible.

 

At the time of writing, Shodan detects approximately 80.8k public IP addresses where some sort of industrial system is accessible[2], while Censys sees about 74.2k such IPs[3]. Although this is hardly a “good” result, the numbers are significantly lower then they were 12 months ago, as the following chart based on data collected from Shodan using TriOp[4] shows.

While the overall situation seems to be slowly getting better, it is still far from ideal.

Although it would probably be too optimistic to expect it to improve significantly in the near future, perhaps the attention that the recent attacks on the pipeline and a water treatment plant in Florida[5] have gotten will have some positive effect in this area, as it may provide an impulse for organizations to at least check whether some their public IPs don’t allow direct access to their critical OT systems to anyone connected to the internet. Since such a check could be as simple as an nmap scan of relevant public IP ranges, it wouldn’t necessarily even cost that much in terms of time.

We can, however, only hope…

[1] https://www.bleepingcomputer.com/news/security/largest-us-pipeline-shuts-down-operations-after-ransomware-attack/
[2] https://www.shodan.io/search?query=tag%3Aics
[3] https://censys.io/ipv4?q=tags.raw%3A+%22scada%22
[4] https://isc.sans.edu/diary/27034
[5] https://www.bleepingcomputer.com/news/security/hackers-tried-poisoning-town-after-breaching-its-water-facility/

———–
Jan Kopriva
@jk0pr
Alef Nula

(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) →

Microsoft May 2021 Patch Tuesday, (Tue, May 11th)

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

One of the critical vulnerabilities which requires special attention this month is a remote code execution (RCE) on HTTP Protocol Stack (CVE-2021-31166). An unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets. This vulnerability requires no user authentication or interaction – thus, it is considered a wormable vulnerability. The vulnerability affects different versions of Windows 10, Windows Server 2004 and Windows Server 20H2 and has a CVSS score of 9.8.

A second critical vulnerabilities addressed this month is RCE affecing Hyper-V on virtually all supported Windows versions (CVE-2021-28476). Microsoft’s advisory states that the issue a guest VM to force the Hyper-V host’s kernel to read from an arbitrary, potentially invalid address. In most circumstances, this would result in a denial of service of the Hyper-V host due to reading an unmapped address, but it may also could lead to other types of compromise of the Hyper-V host’s security. The CVSS for this vulnerability is 9.9

The other two critical vulnerabilities are a RCE on OLE Automation (CVE-2021-31194) associated with a CVSS of 7.50 and a Scripting Engine Memory Corruption Vulnerability (CVE-2021-26419) affecting Internet Explorer 11 with a CVSS of 6.40. None of four critical vulnerabilities was previously disclosed. 

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

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET and Visual Studio Elevation of Privilege Vulnerability
%%cve:2021-31204%% Yes No Less Likely Less Likely Important 7.3 6.4
Common Utilities Remote Code Execution Vulnerability
%%cve:2021-31200%% Yes No Less Likely Less Likely Important 7.2 6.7
Dynamics Finance and Operations Cross-site Scripting Vulnerability
%%cve:2021-28461%% No No Less Likely Less Likely Important 6.1 5.5
HTTP Protocol Stack Remote Code Execution Vulnerability
%%cve:2021-31166%% No No More Likely More Likely Critical 9.8 8.5
Hyper-V Remote Code Execution Vulnerability
%%cve:2021-28476%% No No Less Likely Less Likely Critical 9.9 8.6
Microsoft Accessibility Insights for Web Information Disclosure Vulnerability
%%cve:2021-31936%% No No Less Likely Less Likely Important 7.4 6.7
Microsoft Bluetooth Driver Spoofing Vulnerability
%%cve:2021-31182%% No No Less Likely Less Likely Important 7.1 6.2
Microsoft Excel Information Disclosure Vulnerability
%%cve:2021-31174%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-31195%% No No Less Likely Less Likely Important 6.5 5.7
%%cve:2021-31198%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Exchange Server Security Feature Bypass Vulnerability
%%cve:2021-31207%% Yes No Less Likely Less Likely Moderate 6.6 5.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-31209%% No No Less Likely Less Likely Important 6.5 5.7
Microsoft Jet Red Database Engine and Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2021-28455%% No No Less Likely Less Likely Important 8.8 7.7
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-31180%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Office Information Disclosure Vulnerability
%%cve:2021-31178%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2021-31175%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31176%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31177%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31179%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2021-31171%% No No Less Likely Less Likely Important 4.1 3.6
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2021-31181%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-31173%% No No Less Likely Less Likely Important 5.3 4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-28474%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Spoofing Vulnerability
%%cve:2021-31172%% No No Less Likely Less Likely Important 7.1 6.2
%%cve:2021-28478%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-26418%% No No Less Likely Less Likely Important 4.6 4.0
Microsoft Windows Infrared Data Association (IrDA) Information Disclosure Vulnerability
%%cve:2021-31184%% No No Less Likely Less Likely Important 5.5 4.8
OLE Automation Remote Code Execution Vulnerability
%%cve:2021-31194%% No No Less Likely Less Likely Critical 8.8 7.7
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-26419%% No No More Likely More Likely Critical 6.4 5.8
Skype for Business and Lync Remote Code Execution Vulnerability
%%cve:2021-26422%% No No Less Likely Less Likely Important 7.2 6.3
Skype for Business and Lync Spoofing Vulnerability
%%cve:2021-26421%% No No Less Likely Less Likely Important 6.5 5.7
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2021-31211%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31214%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Code Remote Containers Extension Remote Code Execution Vulnerability
%%cve:2021-31213%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2021-27068%% No No Less Likely Less Likely Important 8.8 7.7
Web Media Extensions Remote Code Execution Vulnerability
%%cve:2021-28465%% No No Less Likely Less Likely Important 7.8 6.8
Windows CSC Service Information Disclosure Vulnerability
%%cve:2021-28479%% No No Less Likely Less Likely Important 5.5 4.8
Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability
%%cve:2021-31190%% No No Less Likely Less Likely Important 7.8 6.8
Windows Container Manager Service Elevation of Privilege Vulnerability
%%cve:2021-31165%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31167%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31168%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31169%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31208%% No No Less Likely Less Likely Important 7.8 6.8
Windows Desktop Bridge Denial of Service Vulnerability
%%cve:2021-31185%% No No Less Likely Less Likely Important 5.5 4.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2021-31170%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-31188%% No No More Likely More Likely Important 7.8 6.8
Windows Media Foundation Core Remote Code Execution Vulnerability
%%cve:2021-31192%% No No Less Likely Less Likely Important 7.3 6.4
Windows Projected File System FS Filter Driver Information Disclosure Vulnerability
%%cve:2021-31191%% No No Less Likely Less Likely Important 5.5 4.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2021-31186%% No No Less Likely Less Likely Important 7.4 6.4
Windows SMB Client Security Feature Bypass Vulnerability
%%cve:2021-31205%% No No Less Likely Less Likely Important 4.3 3.8
Windows SSDP Service Elevation of Privilege Vulnerability
%%cve:2021-31193%% No No Less Likely Less Likely Important 7.8 6.8
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2021-31187%% No No Less Likely Less Likely Important 7.8 6.8
Windows Wireless Networking Information Disclosure Vulnerability
%%cve:2020-24587%% No No Less Likely Less Likely Important 6.5 5.7
Windows Wireless Networking Spoofing Vulnerability
%%cve:2020-24588%% No No Less Likely Less Likely Important 6.5 5.7
%%cve:2020-26144%% No No Less Likely Less Likely Important 6.5 5.7


Renato Marinho
Morphus Labs| LinkedIn|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) →

Correctly Validating IP Addresses: Why encoding matters for input validation., (Mon, May 10th)

Recently, a number of libraries suffered from a very similar security flaw: IP addresses expressed in octal were not correctly interpreted. The result was that an attacker was able to bypass input validation rules that restricted IP addresses to specific subnets. 

The vulnerability was documented in (this list is unlikely to be complete):

  • Node.js netmask package [1]
  • Perl (various packages) [2]
  • Python stdlib ipaddress module [3]

All of these vulnerabilities were caused by a similar problem: These libraries attempted to parse IP addresses as a string. Later, standard-based “socket” libraries were used to establish the actual connection. The socket libraries have their own “inet_aton” function to convert an IP address string to a long unsigned integer.

It isn’t an accident that security researchers started to look at these libraries right now. More and more of our applications have surrendered data to cloud services and implement APIs to access the data. Server-Side Request Forgery (SSRF) is becoming more of an issue as a result. And to restrict which IP address a particular application may connect to, we often use the libraries above.

As a simple test string, use “010.010.010.010”. The leading “0” indicates that the address is octal. In “dotted decimal,” the address translates to Google’s name server 8.8.8.8.

So if you have to validate an IP address: How to do it? First of all: Try to stick to one of the (hopefully now fixed) standard libraries. But in general, it can be helpful to stick to the same library for input validation and to establish the connection. This way, the IP address is not interpreted differently. There is also an argument to be made to just not allow octal. I leave that decision up to you. Standards do allow that notation.

For example, most languages under the hood rely on the C “Sockets” library to establish connections [4]. This library also includes functions to convert IP addresses expressed as a string into an unsigned 32-bit integer (inet_aton) and back (inet_ntoa)  [5]. Take a look if your language is implementing these functions.  Part of the problem of the node.js vulnerability was that node.js implemented its own “ip2long” function. 

So how do you verify if an IP address is inside a subnet? Well, there is a reason netmasks are called netmasks: They are bitmasks. Bitmasking is a very efficient and simple way to verify IP addresses.

First of all: Is this IP address a valid IPv4 address?

My favorite “trick” is to convert the address to an integer with inet_aton. Next, convert it back to a string with inet_ntoa. If the string didn’t change: You got a valid address. This will work nicely if you only allow dotted decimal notation. If not: just convert the string with inet_aton and keep it an integer. Not all languages may use the Sockets library for “inet_aton.” Some may use their own (buggy?) implementation. So best to check quickly:

010.010.010.010 = 8.8.8.8 = 134744072 .

If you get 168430090, then you got it wrong (that would be 10.10.10.10). MySQL/MariaDB, for example, will get you the wrong answer:

MariaDB [(none)]> select inet_aton('10.10.10.10')-inet_aton('010.010.010.010');
+-------------------------------------------------------+
| inet_aton('10.10.10.10')-inet_aton('010.010.010.010') |
+-------------------------------------------------------+
|                                                     0 |
+-------------------------------------------------------+

Output encoding matters for proper input validation!

So now, how do we verify if IP address “A” is in subnet B/Z ?

“z” is the number of bits that need to be the same. So let’s create a mask:

mask = 2^32-2^(32-Z)

next, let’s do a bitwise “AND” before comparing the result:

If ( A & mask == B & mask ) {
    IP Address A is in B/Z
} 

So in short:

  1. Try to use the same library to validate the IP address and to establish connections. That is probably the easiest way to avoid issues. Sadly, modern languages add additional layers, and it isn’t always clear what happens in the background. 
  2. Test! inet_aton(‘010.010.010.010’) != inet_aton(‘10.10.10.10’).
  3. IPs are long integers, not strings.

So why do I sometimes see IP addresses like “010.123.123.123” on isc.sans.edu?

Remember, we started collecting data 20 years ago. I have learned since 🙂 But some of my early sins still haunt me. Over the last few years, we moved to store the IP addresses as 32-bit unsigned integers, but “back in the day,” we used 15 digit strings and zero-padded them for easy sorting… sorry. should be mostly gone by now and if you find a case where this is still happening, let me know.

What about IPv6?

That will be a different diary 🙂

What about hex notation?

There are a number of additional formats that can be used for IP addresses. For a complete collection of different representations of IP addresses [6]. Test them. Let me know what you find 🙂 .

 

[1] https://nvd.nist.gov/vuln/detail/CVE-2021-29418
[2] https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/
[3] https://nvd.nist.gov/vuln/detail/CVE-2021-29921
[4] https://www.gnu.org/software/libc/manual/html_node/Sockets.html
[5] https://www.gnu.org/software/libc/manual/html_node/Host-Address-Functions.html
[6] https://www.hacksparrow.com/networking/many-faces-of-ip-address.html


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 4 of 6 «...23456