Tag Archives: Security

Security

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

Leave a comment
This post was originally published on this site

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.

Security

Identity Theft

Leave a comment
This post was originally published on this site

Identity theft is when someone steals information about you and then uses that information to pretend to be you and commit crimes, such as credit card fraud. One of the key steps to protecting yourself is monitoring your financial, credit score and credit card accounts. The sooner you detect fraud in any of these accounts, the sooner you can minimize the damage.

Security

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

Leave a comment
This post was originally published on this site

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.

Security

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

Leave a comment
This post was originally published on this site

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.

Security

AA21-131A: DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks

Leave a comment
This post was originally published on this site

Original release date: May 11, 2021

Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of a ransomware attack affecting a critical infrastructure (CI) entity—a pipeline company—in the United States. Malicious cyber actors deployed DarkSide ransomware against the pipeline company’s information technology (IT) network.[1] At this time, there is no indication that the entity’s operational technology (OT) networks have been directly affected by the ransomware.

CISA and FBI urge CI asset owners and operators to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this Joint Cybersecurity Advisory, including implementing robust network segmentation between IT and OT networks; regularly testing manual controls; and ensuring that backups are implemented, regularly tested, and isolated from network connections. These mitigations will help CI owners and operators improve their entity’s functional resilience by reducing their vulnerability to ransomware and the risk of severe business degradation if impacted by ransomware.

Click here for a PDF version of this report.

Technical Details

Note: the analysis in this Joint Cybersecurity Advisory is ongoing, and the information provided should not be considered comprehensive. CISA and FBI will update this advisory as new information is available.

After gaining initial access to the pipeline company’s network, DarkSide actors deployed DarkSide ransomware against the company’s IT network. In response to the cyberattack, the company has reported that they proactively disconnected certain OT systems to ensure the systems’ safety.[2] At this time, there are no indications that the threat actor moved laterally to OT systems.

DarkSide is ransomware-as-a-service (RaaS)—the developers of the ransomware receive a share of the proceeds from the cybercriminal actors who deploy it, known as “affiliates.” According to open-source reporting, since August 2020, DarkSide actors have been targeting multiple large, high-revenue organizations, resulting in the encryption and theft of sensitive data. The DarkSide group has publicly stated that they prefer to target organizations that can afford to pay large ransoms instead of hospitals, schools, non-profits, and governments.[3],[4]

According to open-source reporting, DarkSide actors have previously been observed gaining initial access through phishing and exploiting remotely accessible accounts and systems and Virtual Desktop Infrastructure (VDI) (Phishing [T1566], Exploit Public-Facing Application [T1190], External Remote Services [T1133]).[5],[6] DarkSide actors have also been observed using Remote Desktop Protocol (RDP) to maintain Persistence [TA0003].[7]

After gaining access, DarkSide actors deploy DarkSide ransomware to encrypt and steal sensitive data (Data Encrypted for Impact [T1486]). The actors then threaten to publicly release the data if the ransom is not paid.[8],[9] The DarkSide ransomware uses Salsa20 and RSA encryption.[10]

DarkSide actors primarily use The Onion Router (TOR) for Command and Control (C2) [TA0011] (Proxy: Multi-hop Proxy [1090.003]).[11],[12] The actors have also been observed using Cobalt Strike for C2.[13]

Mitigations

CISA and FBI urge CI owners and operators to apply the following mitigations to reduce the risk of compromise by ransomware attacks.

  • Require multi-factor authentication for remote access to OT and IT networks.
  • Enable strong spam filters to prevent phishing emails from reaching end users. Filter emails containing executable files from reaching end users.
  • Implement a user training program and simulated attacks for spearphishing to discourage users from visiting malicious websites or opening malicious attachments and re-enforce the appropriate user responses to spearphishing emails.
  • Filter network traffic to prohibit ingress and egress communications with known malicious IP addresses. Prevent users from accessing malicious websites by implementing URL blocklists and/or allowlists.
  • Update software, including operating systems, applications, and firmware on IT network assets, in a timely manner. Consider using a centralized patch management system; use a risk-based assessment strategy to determine which OT network assets and zones should participate in the patch management program.
  • Limit access to resources over networks, especially by restricting RDP. After assessing risks, if RDP is deemed operationally necessary, restrict the originating sources and require multi-factor authentication.
  • Set antivirus/antimalware programs to conduct regular scans of IT network assets using up-to-date signatures. Use a risk-based asset inventory strategy to determine how OT network assets are identified and evaluated for the presence of malware.
  • Implement unauthorized execution prevention by: 
    • Disabling macro scripts from Microsoft Office files transmitted via email. Consider using Office Viewer software to open Microsoft Office files transmitted via email instead of full Microsoft Office suite applications.
    • Implementing application allowlisting, which only allows systems to execute programs known and permitted by security policy. Implement software restriction policies (SRPs) or other controls to prevent programs from executing from common ransomware locations, such as temporary folders supporting popular internet browsers or compression/decompression programs, including the AppData/LocalAppData folder.
    • Monitor and/or block inbound connections from Tor exit nodes and other anonymization services to IP addresses and ports for which external connections are not expected (i.e., other than VPN gateways, mail ports, web ports). For more guidance, refer to Joint Cybersecurity Advisory AA20-183A: Defending Against Malicious Cyber Activity Originating from Tor.
    • Deploy signatures to detect and/or block inbound connection from Cobalt Strike servers and other post exploitation tools.

CISA and FBI urge CI owners and operators to apply the following mitigations now to reduce the risk of severe business or functional degradation should their CI entity fall victim to a ransomware attack in the future.

  • Implement and ensure robust network segmentation between IT and OT networks to limit the ability of adversaries to pivot to the OT network even if the IT network is compromised. Define a demilitarized zone that eliminates unregulated communication between the IT and OT networks.
  • Organize OT assets into logical zones by taking into account criticality, consequence, and operational necessity. Define acceptable communication conduits between the zones and deploy security controls to filter network traffic and monitor communications between zones. Prohibit industrial control system (ICS) protocols from traversing the IT network.
  • Identify OT and IT network inter-dependencies and develop workarounds or manual controls to ensure ICS networks can be isolated if the connections create risk to the safe and reliable operation of OT processes. Regularly test contingency plans such as manual controls so that safety critical functions can be maintained during a cyber incident. Ensure that the OT network can operate at necessary capacity even if the IT network is compromised. 
  • Regularly test manual controls so that critical functions can be kept running if ICS or OT networks need to be taken offline.
  • Implement regular data backup procedures on both the IT and OT networks. Backup procedures should be conducted on a frequent, regular basis. The data backup procedures should also address the following best practices:
    • Ensure that backups are regularly tested.
    • Store your backups separately. Backups should be isolated from network connections that could enable the spread of ransomware. It is important that backups be maintained offline as many ransomware variants attempt to find and encrypt or delete accessible backups. Maintaining current backups offline is critical because if your network data is encrypted with ransomware, your organization can restore systems to its previous state. Best practice is to store your backups on a separate device that cannot be accessed from a network, such as on an external hard drive. (See the Software Engineering Institute’s page on ransomware).
    • Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt. This entails maintaining image “templates” that include a preconfigured operating system (OS) and associated software applications that can be quickly deployed to rebuild a system, such as a virtual machine or server.
    • Retain backup hardware to rebuild systems in the event rebuilding the primary system is not preferred. Hardware that is newer or older than the primary system can present installation or compatibility hurdles when rebuilding from images.
    • Store source code or executables. It is more efficient to rebuild from system images, but some images will not install on different hardware or platforms correctly; having separate access to needed software will help in these cases.
  • Ensure user and process accounts are limited through account use policies, user account control, and privileged account management. Organize access rights based on the principles of least privilege and separation of duties.

If your organization is impacted by a ransomware incident, CISA and FBI recommend the following actions:

  • Isolate the infected system. Remove the infected system from all networks, and disable the computer’s wireless, Bluetooth, and any other potential networking capabilities. Ensure all shared and networked drives are disconnected, whether wired or wireless.  
  • Turn off other computers and devices. Power-off and segregate (i.e., remove from the network) the infected computer(s). Power-off and segregate any other computers or devices that shared a network with the infected computer(s) that have not been fully encrypted by ransomware. If possible, collect and secure all infected and potentially infected computers and devices in a central location, making sure to clearly label any computers that have been encrypted. Powering-off and segregating infected computers and computers that have not been fully encrypted may allow for the recovery of partially encrypted files by specialists. (See Before You Connect a New Computer to the Internet for tips on how to make a computer more secure before you reconnect it to a network.)
  • Secure your backups. Ensure that your backup data is offline and secure. If possible, scan your backup data with an antivirus program to check that it is free of malware.
  • Refer to Joint Cybersecurity Advisory: AA20-245A: Technical Approaches to Uncovering and Remediating Malicious Activity for more best practices on incident response.

Note: CISA and the FBI do not encourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. CISA and FBI urge you to report ransomware incidents to your local FBI field office.

CISA offers a range of no-cost cyber hygiene services to help CI organizations assess, identify and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.

Resources

Contact Information

Victims of ransomware should report it immediately to CISA at https://us-cert.cisa.gov/report, a local FBI Field Office, or U.S. Secret Service Field Office. To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

References

Revisions

  • May 11, 2021: Initial Version

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

Security

Virtual Private Networks

Leave a comment
This post was originally published on this site

Virtual Private Networks (VPN) create encrypted tunnels when you connect to the Internet. They are a fantastic way to protect your privacy and data, especially when traveling and connecting to untrusted or unknown networks, such as at hotels or coffee shops. Use a VPN whenever possible, both for work and personal use.

Security

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

Leave a comment
This post was originally published on this site

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.

Security

Who is Probing the Internet for Research Purposes?, (Sat, May 8th)

Leave a comment
This post was originally published on this site

Shodan[1] is one of the most familiar site for research on what is on the internet. In Oct 2020 I did a diary on Censys [2][3], another site collecting similar information like Shodan. The next two sites are regularly scanning the internet for data which isn't shared with the security community at large.

Net Systems Research [4] probe the internet for research, but none of the data is accesible or published on the site. This is part of the message About Us: "Net Systems Research was founded in 2015 by a group of security data researchers who wanted to utilize a global view of the internet to study these difficult and emerging internet security challenges and understand the resulting implications."

Security IPIP [5] has no information beside a banner: "Our company engaged in the researching and data collecting of IP location, internet infrastructure and network security, we need to detect the internet (Ping/ Traceoute Mainly); For network security research, we need to obtain the IP location Banner and fingerprint information, we detecting the common port openly or not by ZMap, and collecting opened Banner data by our own code. Any questions please do not hesitate to contact with us: frk@ipip.net."

Over the past 3 years, my honeypot has logged information at various point in times from these 4 different research organizations. Here are some typical logs and their top 10 IPs. Shodan uses IP range 71.6.128.0-71.6.255.255 to run its scans but unlike other scanners, it doesn't include a banner in the captured logs.

Activity first noticed 4 June 2018. This is a sample log:

20210507-171447: 192.168.25.9:80-71.6.158.166:34476 data
GET / HTTP/1.1
Accept-Encoding: identity
Host: xxxxxx.xxx.ca
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Activity first noticed 19 Aug 2020. This is a sample log:

20210506-011443: 192.168.25.9:80-162.142.125.38:46726 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8080
User-Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)
Accept: */*
Accept-Encoding: gzip

Activity first noticed 15 Feb 2019. This is a sample log:

20210506-013155: 192.168.25.9:8443-92.118.160.5:47195 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8443
User-Agent: NetSystemsResearch studies the availability of various services across the internet. Our website is netsystemsresearch.com

Activity first noticed 14 Oct 2018 data. This is a sample log:

20210506-082116: 192.168.25.9:81-172.104.67.101:42966
GET / HTTP/1.1
Host: 70.55.XX.XXX:81
User-Agent: HTTP Banner Detection (https://security.ipip.net)
Connection: close

Since the data is already out there, why not use Shodan or Censys to explore what services a home router is sharing to the internet. Here is an example of list of services recorded and audited by Shodan which also includes SSL certificate information, banner version, etc.

 

[1] https://www.shodan.io
[2] https://censys.io/ipv4
[3] https://isc.sans.edu/forums/diary/An+Alternative+to+Shodan+Censys+with+UserAgent+CensysInspect11/26718
[4] http://www.netsystemsresearch.com
[5] https://security.ipip.net/
[6] https://isc.sans.edu/ipinfo.html?ip=71.6.158.166 (Shodan RESEARCHER: THIS IP IS USED FOR INTERNET WIDE RESEARCH SCANS)

———–
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.

Security

Alternative Ways To Perform Basic Tasks, (Thu, May 6th)

Leave a comment
This post was originally published on this site

I like to spot techniques used by malware developers to perform basic tasks. We know the lolbins[1] that are pre-installed tools used to perform malicious activities. Many lolbins are used, for example, to download some content from the Internet. Some tools are so powerful that they can also be used to perform unexpected tasks. I found an interesting blog article[2] describing how to use curl to copy files!

C:UsersREM> curl file://c:testtest.txt -o newfile.txt

Do you want another example? Some tools can be diverted from their regular use like ping.exe:

C:UsersREMDesktop>ping -n 5 127.0.0.1

This command will send five Echo-Request ICMP packets at an interval of one second so it will complete after approximately five seconds. Using ping.exe is not very discreet because a new process will be launched and can be spotted by a tool like Sysmon. Do you know a lot of non-tech people that use ping on their corporate computer? 

But ping.exe can be very useful for malware to detect if the computer can resolve hostnames and has Internet connectivity. Instead of using the ping command, you can use Powershell to achieve this:

Yesterday, I found a malicious PowerShell script that uses another technique that I never saw before. This time, the technique is based on a WMI query!

Conclusion: Keep in mind that attackers can use multiple techniques to perform simple tasks and defeat your detection rules and/or controls.

If you already met other techniques, please share!

[1] https://lolbas-project.github.io
[2] https://www.hexacorn.com/blog/2021/05/02/curo-bin/

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.

Security

Quick and dirty Python: masscan, (Tue, May 4th)

Leave a comment
This post was originally published on this site

Those who know me are aware that I am a recovering shell programmer.  I have 35+ years of various shell scripts involving complicated code pipelines with grep, cut, sort, uniq, awk, input files, output files, redirects, pipes etc…cobbled together to get jobs done. None of it is elegant and little of it could be called pretty. The last couple of years I have been trying to ramp up on Python and am increasingly finding that these complicated shell code scripts can be elegantly implemented in Python. The resulting code is way easier to read and way more supportable.

A simple example of this is the various scripts I have around as simple port scanners used to scan large swaths of IP address ranges for vulnerabilities. Since nmap is too slow for large numbers of IPs, my tool of choice for initial scanning of swaths of IPs and ports is the very speedy masscan.  masscan will find the open ports and then typically I will write the results to a file, manipulate the masscan output file to create an input file that nmap will read and then launch nmap to do the detailed scanning on the smaller set of IPs sending that output to even more files which then need to be manipulated and analyzed to extract the information I need.

Just recently I discovered there is a Python module for both masscan and nmap.   So far I have only spent time on the masscan module.  

Suppose you needed a script which will find all the web servers (port 80, 443)  in an address range.  It took me about 5 minutes to code up scan_web.py.

#!/usr/local/bin/python3
import sys,getopt,argparse
import masscan
import pprint

def main():
   # read in the IP parameter
   parser = argparse.ArgumentParser()
   parser.add_argument('IP', help="IP address or range")
   args=parser.parse_args()
   ip=args.IP

   #scan address(es) using Masscan
   try:
      mas = masscan.PortScanner()
      mas.scan(ip, ports='80,443')
   except:
      print("Error:", sys.exc_info()[0])
      sys.exit(1)

   # output result
   pprint.pprint(mas.scan_result)

if __name__ == "__main__":
    main()

The script takes IP address(es) as an input and then scans those IPs using masscan to check if port 80 or 443 are open.

Running the script results in:

# ./scan_web.py 45.60.103.0,45.60.31.34
[2021-05-04 20:05:28,652] [DEBUG] [masscan.py 10 line] Scan parameters: "masscan -oX - 45.60.103.0,45.60.31.34 -p 80,443"
{'masscan': {'command_line': 'masscan -oX - 45.60.103.0,45.60.31.34 -p 80,443',
             'scanstats': {'downhosts': '0',
                           'elapsed': '12',
                           'timestr': '2021-05-04 20:05:41',
                           'totalhosts': '4',
                           'uphosts': '4'}},
 'scan': {'45.60.103.0': {'tcp': {80: {'endtime': '1620158730',
                                       'reason': 'syn-ack',
                                       'reason_ttl': '53',
                                       'services': [],
                                       'state': 'open'},
                                  443: {'endtime': '1620158730',
                                        'reason': 'syn-ack',
                                        'reason_ttl': '53',
                                        'services': [],
                                        'state': 'open'}}},
          '45.60.31.34': {'tcp': {80: {'endtime': '1620158730',
                                       'reason': 'syn-ack',
                                       'reason_ttl': '61',
                                       'services': [],
                                       'state': 'open'},
                                  443: {'endtime': '1620158730',
                                        'reason': 'syn-ack',
                                        'reason_ttl': '61',
                                        'services': [],
                                        'state': 'open'}}}}}

The result is a Python dictionary that can be easily be parsed and fed into python-nmap (an exercise for another day).

 

Caveat1: Never scan an IP range you don't have permission to scan.  While port scanning is not illegal in most jurisdictions it is questionable ethically to scan things you don't own or have permission to scan.

Caveat2: I am not a professional Python programmer.  My scripting gets the job done that I need it to do.  I know there are many smart people out there who can write way better code than I can. 

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – Twitter:namedeplume (Protected)

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