Category Archives: Security

Update: mac-robber.py, (Sun, Jun 13th)

This post was originally published on this site

Almost 4 years ago, I wrote a python version of mac-robber. I use it fairly regularly at $dayjob. This past week, one of my co-workers was using it, but realized that it hashes large files a little too slowly. He decided to use mac-robber.py to collect the MAC times and do the hashing separately so he could limit the hashes to to files under a certain size. That sounded reasonable, so I've added a switch (-s or --size). If hashing is turned on the new switch will limit the hashing to files under the given size.

To see it in action, see the next figure.

I hope others find this new feature useful. If anyone has more suggestions for new features, you can let me know via comments here, e-mail, or our contact form. The tool can be found at the same place as before: 

https://github.com/att/docker-forensics/blob/master/mac-robber.py

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

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

Fortinet Targeted for Unpatched SSL VPN Discovery Activity, (Sat, Jun 12th)

This post was originally published on this site

Over the past 60 days, I have observed scanning activity to discover FortiGate SSL VPN unpatched services. Fortinet has fixed several critical vulnerabilities in SSL VPN and web firewall this year from Remote Code Execution (RCE) to SQL Injection, Denial of Service (DoS) which impact the FortiProxy SSL VPN and FortiWeb Web Application Firewall (WAF) products [1][2]. Two weeks ago, US-CERT [4] released an alert re-iterating that APT actors are looking for Fortinet vulnerabilities to gain access to networks. Additional information to look for signs of this activity available here.

Fortinet Scanning Activity


Here is a sample of what can be seen in the logs:

20210611-053716: 192.168.25.9:8443-203.159.80.226:58521 data
GET /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession
HTTP/1.1
Host: 70.XX.XXX.XXX:8443
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0rnAccept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1

[1] https://www.fortiguard.com/psirt?date=01-2021
[2] https://www.fortinet.com/blog/psirt-blogs/patch-vulnerability-management
[3] https://us-cert.cisa.gov/ncas/current-activity/2021/04/02/fbi-cisa-joint-advisory-exploitation-fortinet-fortios
[4] https://us-cert.cisa.gov/ncas/current-activity/2021/05/28/fbi-update-exploitation-fortinet-fortios-vulnerabilities
[5] https://www.ic3.gov/Media/News/2021/210527.pdf

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

Sonicwall SRA 4600 Targeted By an Old Vulnerability, (Fri, Jun 11th)

This post was originally published on this site

Devices and applications used to provide remote access are juicy targets. I've already been involved in many ransomware cases and most of the time, the open door was an unpatched VPN device/remote access solution or weak credentials. A good example, the recent attack against the Colonial Pipeline that started with a legacy VPN profile[1].

A group of attackers is targeting Sonicwall devices through the vulnerability described in %%cve:2019-7481%%. Yes, a vulnerability from 2019! It affects Sonicwall SRA ("Secure Remote Access") 4600 devices running firmware versions 8.x and 9.x. Crowdstrike published a nice blog post about this vulnerability[2].

If you run a Sonicwall device affected by this vulnerability, please review your current firmware and patch!

[1] https://www.hsgac.senate.gov/imo/media/doc/Testimony-Blount-2021-06-08.pdf
[2] https://www.crowdstrike.com/blog/how-ecrime-groups-leverage-sonicwall-vulnerability-cve-2019-7481/

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.

Keeping an Eye on Dangerous Python Modules, (Fri, Jun 11th)

This post was originally published on this site

With Python getting more and more popular, especially on Microsoft Operating systems, it's common to find malicious Python scripts today. I already covered some of them in previous diaries[1][2]. I like this language because it is very powerful: You can automate boring tasks in a few lines. It can be used for offensive as well as defensive purposes, and… it has a lot of 3rd party "modules" or libraries that extend its capabilities. For example, if you would like to use Python for forensics purposes, you can easily access the registry and extract data:

This snippet of code starts with an import line. First, I need to load a specific module (in this case winreg) that will add to Python all the required code to manipulate the OS registry hives.

Let's switch back to the "dark side". When an attacker needs to write a piece of code to perform specific tasks, he will search for existing modules and not reinvent the wheel. To search for Python modules, the best place is to visit pypi.org[3]. Let's take another example: injection of code. Python is able to use all the Windows API calls with the help of the ctypes module:

In this example, I'm using the ctypes modules to call the Windows API VirtualAlloc() and allocated 1KB of memory with the flag "0x04" (which means that the memory will be allowed to contain executable code).

ctypes is not a common module used in simple scripts to automate tasks like System Administrators could write. It could be categorized as "suspicious". Let's have another example. I found this malicious script that implements a keylogger. It uses another not common Python module:

The suspicious module is pyHook which "provides callbacks for global mouse and keyboard events in Windows" as the documentation says.

Want more? Let' use now wave and sounddevice to use the host microphone and record some conversations…

Other interesting modules?  Use pyscreenshot to take screenshots or pynput to build another type of keylogger.

The question is now, from a defender's perspective, how can we detect suspicious Python modules?

If you have access to the host, you can always use the "pip" command (the utility to manage modules):

pip will list the modules that have been installed "manually" (could be done by an attacker). To get a full list of modules, you can use the help() command in the Python interpreter:

As you can see, it's interesting to spot malicious Python code just by having a look at the imported modules! If you would like to hunt, you can create a YARA rule to search for interesting modules inside text files…

[1] https://isc.sans.edu/forums/diary/Python+and+Risky+Windows+API+Calls/26530
[2] https://isc.sans.edu/forums/diary/From+Python+to+Net/27366
[3] https://pypi.org

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.

Are Cookie Banners a Waste of Time or a Complete Waste of Time?, (Thu, May 20th)

This post was originally published on this site

Legislation, in particular in the European Union, has led to a proliferation of "Cookie Banners." Warning banners that either ask you for blanket permission to set cookies or, in some cases, provide you with some control as to what cookies you do allow. These regulations emerged after advertisers made excessive use of HTTP Cookies to track users across different sites. But in my opinion, these measures are often implemented poorly. Changes in browsers have made cookies far less menacing than they have been in the past due to changes made in browsers. Other tracking technologies are bound to replace cookies and, in some cases, already have.

There are very legitimate uses for cookies to track a user's session. In my opinion, a proper session cookie has the following properties:

  • It is restricted to a specific hostname (e.g., "isc.sans.edu")
  • It has the httponly and secure parameter set ("same-site" is nice to have, of course)
  • There is no expiration time, so the cookie will get deleted as soon as the user closes the browse. This defines a "Session Cookie." 
  • For extra-extra credit: Start the cookie's name with __Host or __Secure prefix.

Many sites will set various additional cookies, and often they are inserted by middleware. As I hate "shaming" others, let me use isc.sans.edu as a bad example. 

% curl -si https://isc.sans.edu | grep Set-Cookie
Set-Cookie: visid_incap_2188750=FYohHlwAB06WoVxsdKMnPSB4tsf5BK; expires=Fri, 10 Jun 2022 09:40:10 GMT; HttpOnly; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: nlbi_2188750_2100128=4jQpYhNNrz5qk8KuDW1UNgAAAADjVqz5zQSu/0YJRz/fEYuM; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: incap_ses_1243_2188750=v0+KUhJRlXC7EJCHVwZAEePvwWAAAAAAE0OXILjXlfNemg/mxkNCeQ==; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: ___utmvmpOBuREXZZ=OcBPfJZKGQA; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvapOBuREXZZ=qloSeVq; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvbpOBuREXZZ=MZL

Pulling in the index page for the site, you actually do not get a session cookie at all. This is because all these cookies are set by our CDN/WAF (we use Imperva's service for that). All CDNs will add cookies to track user's sessions. Cloudflare for example explains its cookies [4].

Comparing this to dshield.org, which doesn't use Imperva:

% curl -si https://dshield.org | grep Set-Cookie
%

Using a simple curl script and checking the top 100 sites (according to majestic.com), About 30 are setting cookies right as you download the index page before having a chance to approve them, as tested with a simple curl script. Testing with a real browser shows many more "hits."

Here are some of the current limits to cookies in modern browsers:

  • The RFC requires browsers to track at least 50 cookies per site (and 3000 total) [1]
  • The maximum amount of data allowed per cookie is at least 4kBytes (some browsers allow more)
  • If no "SameSite" property is set, browsers will now typically use "lax," not "none," so you get some basic CSRF protection by default
  • Third-party cookies, or the ability to set cookies for another site, are pretty much dead in a modern browser

A "Cookie2" header was introduced to distinguish proper session cookies from regular cookies in the past. But this header never really took off and has since been deprecated. [3]

Sites that do use cookies banners to allow users to select what cookies they want have also gotten crafty in tricking users into allowing them via "dark patterns." You will typically first see a dialog asking you for blanket permission to set cookies, and you need to review a second dialog to select particular cookie types. Precious seconds will delay you from getting to the content (and as a result, the user will often "approve" the first dialog).

[1] https://datatracker.ietf.org/doc/html/rfc6265
[2] https://www.whatismybrowser.com/detect/are-third-party-cookies-enabled
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie2
[4] https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies


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.

Architecture, compilers and black magic, or "what else affects the ability of AVs to detect malicious files", (Wed, Jun 9th)

This post was originally published on this site

In my last diary, we went over the impact of different Base encodings on the ability of anti-malware tools to detect malicious code[1]. Since results of our tests showed (among other things) that AV tools in general still struggle significantly more with detecting 64-bit malicious code then 32-bit malicious code, I thought it might be interesting to discuss another factor that might impact the ability of AVs to detect malware – specifically the choice of a compiler.

Since compilers can differ significantly in terms of their internal functionality and the use of various optimization techniques, it makes sense why they generate slightly (or significantly) different output from the same initial code. But do these differences have any impact in terms of hindering the ability of anti-malware to correctly identify malicious code? To try and answer this question, I devised a simple test.

I would start with 3 C++ programs:

  • one that would write a benign text file do disk (i.e. a “control” program that would allow us to identify the number of false-positive detections),
  • one that would drop the EICAR test file[2] on disk and
  • a program that would execute a staged Meterpreter reverse-tcp payload.

I would then compile each of these programs with 2 different compilers (TDM-GCC and Microsoft Visual C++) into both 32 and 64-bit binaries and use VirusTotal to find out whether would be any significant differences in their detections.

I used the following very simple code for both the “control” program and the EICAR dropper:

#include <iostream>
#include <fstream>
using namespace std;

int main() {
  ofstream OutFile([filename]);
  OutFile << [file contents];
  OutFile.close();
}

In the benign file, I’ve used the string “This is a benign string” as the contents. For the malicious program that would execute Meterpreter, I’ve used the same code as last time.

After all the binaries were compiled, it turned out that their VirusTotal detection scores did indeed differ – quite significantly in the case of our only “real” malicious file.

Besides a significant difference in the number of detections of the same 32-bit and 64-bit code, the chart seems to show that overall, the use Microsoft’s compiler might have negative impact on the ability of anti-malware tools to detect malicious code, at least when compared with TDM-GCC… But this isn’t actually true.

Even a small change to the initial code might result in significant changes to the resulting binary (and the ability of AVs to detect it) and these changes would be different for every compiler.

This can be seen quite clearly in the following chart, which shows detection scores of the original Meterpreter binaries and the scores for binaries that were compiled from the same source code, in which the only change was an increase (by about 1k) of the amount of memory allocated for the Meterpreter shellcode (which would not affect the basic function of the binary in this instance).

As we can see, the use of Visual C++ compiler over TDM-GCC does not always result in lower detection scores, as it might have appeared from the first chart. What is obvious from both charts, however, is that the choice of a compiler truly does make an impact when it comes to the ability of AVs to detect malicious code.

Even so, this is far from the whole story, since the choice of a compiler is not the only thing that affects the contents of a resulting binary. Use of different optimization settings might go a long way to change the result as well and the same might be true for use of different linkers. Given how simple our test code was, the differences caused by the use of different linkers should not be too significant here, but in the case of more complex code, it could certainly be noticeable… and there are many other factors as well. That will, however, be a topic for another time.

[1] https://isc.sans.edu/forums/diary/All+your+Base+arenearly+equal+when+it+comes+to+AV+evasion+but+64bit+executables+are+not/27466/
[2] https://www.eicar.org/?page_id=3950

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Microsoft June 2021 Patch Tuesday, (Tue, Jun 8th)

This post was originally published on this site

This month we got patches for 50 vulnerabilities. Of these, 5 are critical, 2 were previously disclosed and 6 is already being exploited according to Microsoft.

The highlight this time, of course, goes to the 6 zero-days: an elevation of privileges vulnerability on Microsoft DWM Core Library (CVE-2021-33739) – the only previously disclosed, an elevation of privilege vulnerability on Windows NTFS (CVE-2021-31956), an information disclosure vulnerability on Windows Kernel (CVE-2021-31955), an elevation of privilege vulnerability on Microsoft Enhanced Cryptographic Provider (CVE-2021-31201 and CVE-2021-31199) and, more importaltly, a remote code execution vulnerability affecting Windows MSHTML Platform (CVE-2021-33742).

Apart from the zero-days, there is an important security feature bypass Vulnerability Kerberos AppContainer (CVE-2021-31962). According to the advisory, in an enterprise environment this vulnerability might allow an attacker to bypass Kerberos authentication, to authenticate to an arbitrary service principal name. This vulnerability was associated to the highest CVSS this month: 9.4.

There is also a remote code execution affecing Windows Defender (CVE-2021-31985). According to the advisory, this vulnerability is more likely to be exploited, requires no authentication and the attack complexity is low.

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 Core and Visual Studio Denial of Service Vulnerability
%%cve:2021-31957%% No No Less Likely Less Likely Important 5.9 5.2
3D Viewer Information Disclosure Vulnerability
%%cve:2021-31944%% No No Less Likely Less Likely Important 5.0 4.4
3D Viewer Remote Code Execution Vulnerability
%%cve:2021-31942%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31943%% No No Less Likely Less Likely Important 7.8 6.8
Event Tracing for Windows Information Disclosure Vulnerability
%%cve:2021-31972%% No No Less Likely Less Likely Important 5.5 4.8
Kerberos AppContainer Security Feature Bypass Vulnerability
%%cve:2021-31962%% No No Less Likely Less Likely Important 9.4 8.2
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2021-33739%% Yes Yes Detected Detected Important 8.4 7.8
Microsoft Defender Denial of Service Vulnerability
%%cve:2021-31978%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Defender Remote Code Execution Vulnerability
%%cve:2021-31985%% No No More Likely More Likely Critical 7.8 6.8
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2021-33741%% No No Less Likely Less Likely Important 8.2 7.1
Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability
%%cve:2021-31199%% No Yes Detected Detected Important 5.2 4.8
%%cve:2021-31201%% No Yes Detected Detected Important 5.2 4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-31939%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Intune Management Extension Remote Code Execution Vulnerability
%%cve:2021-31980%% No No Less Likely Less Likely Important 8.1 7.1
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-31940%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31941%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2021-31949%% No No Less Likely Less Likely Important 6.7 5.8
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-31965%% No No Less Likely Less Likely Important 5.7 5.0
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-26420%% No No Less Likely Less Likely Important 7.1 6.2
%%cve:2021-31963%% No No Less Likely Less Likely Critical 7.1 6.2
%%cve:2021-31966%% No No Less Likely Less Likely Important 7.2 6.3
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-31964%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-31948%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-31950%% No No Less Likely Less Likely Important 7.6 6.6
Microsoft VsCode Kubernetes Tools Extension Elevation of Privilege Vulnerability
%%cve:2021-31938%% No No Less Likely Less Likely Important 7.3 6.4
Paint 3D Remote Code Execution Vulnerability
%%cve:2021-31945%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31946%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31983%% No No Less Likely Less Likely Important 7.8 6.8
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-31959%% No No More Likely More Likely Critical 6.4 5.6
Server for NFS Denial of Service Vulnerability
%%cve:2021-31974%% No No Less Likely Less Likely Important 7.5 6.5
Server for NFS Information Disclosure Vulnerability
%%cve:2021-31975%% No No Less Likely Less Likely Important 7.5 6.5
%%cve:2021-31976%% No No Less Likely Less Likely Important 7.5 6.5
VP9 Video Extensions Remote Code Execution Vulnerability
%%cve:2021-31967%% No No Less Likely Less Likely Critical 7.8 6.8
Windows Bind Filter Driver Information Disclosure Vulnerability
%%cve:2021-31960%% No No Less Likely Less Likely Important 5.5 4.8
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2021-31969%% No No Less Likely Less Likely Important 7.8 6.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2021-31954%% No No More Likely More Likely Important 7.8 6.8
Windows DCOM Server Security Feature Bypass
%%cve:2021-26414%% No No Less Likely Less Likely Important 4.8 4.2
Windows Filter Manager Elevation of Privilege Vulnerability
%%cve:2021-31953%% No No Less Likely Less Likely Important 7.8 6.8
Windows GPSVC Elevation of Privilege Vulnerability
%%cve:2021-31973%% No No Less Likely Less Likely Important 7.8 6.8
Windows HTML Platform Security Feature Bypass Vulnerability
%%cve:2021-31971%% No No Less Likely Less Likely Important 6.8 5.9
Windows Hyper-V Denial of Service Vulnerability
%%cve:2021-31977%% No No Less Likely Less Likely Important 8.6 7.5
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2021-31951%% No No More Likely More Likely Important 7.8 6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2021-31955%% No Yes Detected Detected Important 5.5 5.1
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
%%cve:2021-31952%% No No More Likely More Likely Important 7.8 6.8
Windows MSHTML Platform Remote Code Execution Vulnerability
%%cve:2021-33742%% No Yes Detected Detected Critical 7.5 7.0
Windows NTFS Elevation of Privilege Vulnerability
%%cve:2021-31956%% No Yes Detected Detected Important 7.8 7.2
Windows NTLM Elevation of Privilege Vulnerability
%%cve:2021-31958%% No No Less Likely Less Likely Important 7.5 6.5
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2021-1675%% No No Less Likely Less Likely Important 7.8 6.8
Windows Remote Desktop Services Denial of Service Vulnerability
%%cve:2021-31968%% Yes No Less Likely Less Likely Important 7.5 6.5
Windows TCP/IP Driver Security Feature Bypass Vulnerability
%%cve:2021-31970%% 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.

Amazon Sidewalk: Cutting Through the Hype, (Mon, Jun 7th)

This post was originally published on this site

Later this week (tomorrow?), Amazon will enable its new Sidewalk feature. The feature has already gotten a lot of bad press. Much of this comes from the fact that existing devices are automatically used as Sidewalk Gateways and users will have to opt-out. New devices may require a specific opt-in during setup.

Let's first start with what Amazon Sidewalk is not: Amazon Sidewalk is not WiFi. It has WiFi components, but you are not allowing access to your WiFi network if you enable Amazon Sidewalk. Amazon Sidewalk allows for the exchange of specific messages to Amazon's "Sidewalk Network Server".

The use case for Amazon Sidewalk is sensors or IoT devices exchanging messages with applications. For example, a motion sensor may send a message whenever it detects motion, or a Tile tracker may update the network about its location.

Amazon Sidewalk consists of three components:

  • Endpoint Device ("Device"): This is the device using Amazon Sidewalk to communicate (for example location trackers, light switches or motion sensors).
  • Gateway: A gateway receives messages from devices and passes them to Amazon's infrastructure (SNS). Amazon Echo devices or Amazon Ring Cameras are examples of gateways. They are always-on devices that are connected to the internet.
  • Amazon's Sidewalk Network Service (SNS): This is the infrastructure Amazon runs to send and receive messages.

There are a number of radio standards that can be used by devices to send messages to gateways. Amazon mentions Bluetooth LE, LoRa, and 900 Mhz Frequency Key Shifting ("Garage Door Openers"). Once a message hits a gateway, it will likely use Wifi to travel to an internet router and from there via the Internet to Amazon's SNS.

Amazon Sidewalk Overview

Intially, only Amazon devices and applications will be able to use Sidewalk. But Amazon specifically suggests that in the future, authorized 3rd parties will be able o participate as well. You may see various IoT or home automation production that will be able to connect to Amazon sidewalk, or act as a gateway.

In order to use Sidewalk capable devices, you will need a gateway. But you do not have to share the gateway with others. Your gateway will still work, and your own devices should still be able to use it. Typically you use a device specific Application to connect to your device or gateway. The same application will be used to configure the device and disable the sharing feature.

A Sidewalk capable device will arrive from the factory with a set of trusted certificate authorities pre-set. It will also include a unique public/private key pair with certificates that are signed by an trusted manufacturer's signing certificate. This will be the used to identify the device, and authorize access to the network. Amazon may block devices that misbehave. Devices will regularly register with Amazon using these certificates, and negotiate encryption keys.

Any messages sent by the device will be encrypted on the device, and then again by the gateway (the gateway is not able to decrypt the messages). The message can only be decrypted on Amazon's SNS as it has the keys for both the gateway and the device (gateways also register with Amazon). Amazon will remember which gateway sent a message from a particular device. To reply, or send a message to a particular device, Amazon will send it to the gateway that was last used by the device.

There are a couple of things Amazon says it is doing to protect the network and the customers:

  • The network will be "closed" with only approved developers and manufacturers being able to use it. To use the network, a manufacturer needs a trusted signing certificate. We will see how well Amazon manages the process (like "Marketplace" ?)
  • The total bandwidth used by a gateway will not exceed 80Kbps. This network is meant for small messages/status updates. Not for "Web Browsing".
  • A gateway will limit itself to 500MB of total traffic. This isn't much, but could be a problem on some expensive minimum data cap internet connections (cellular modems or some legacy satellite services)
  • Privacy: Amazon says that the gateway will not see any device identifier and the device will not see the gateway's identifier.

While the network isn't intended for "Internet Access", it is almost certainly going to be used as a messaging network. It should be trivial to open an approved device and replace the sensor with a device providing values to be sent over sidewalk. This would retain the certificate infrastructure embedded into the device without having to extract them. As a next step, someone is going to figure out (or already has?) how to extract the certificates used to authenticate the device and completely re-build them in software.

A lot of the "magic" happens on Amazon's side, and it remains to be seen what Amazon will do with the data. Should you disable Sidewalk access sharing? For the most part: You are already connecting to Amazon's cloud, and entrusting Amazon with your security camera's video footage and home automation sensor data just by using Amazon devices. Sidewalk does not appear to expose you to a substantial additional risk. There is a possibility that gateways will not implement the protocol correctly, and a malformed message will lead to code execution on the gateway. Give it a couple weeks/months for people to play with this to see what happens. Notably, a lot of checking and access control is done by Amazon. The gateway will just validate that the message is formated correctly.

[1] https://www.amazon.com/Amazon-Sidewalk/b?ie=UTF8&node=21328123011

[2] https://developer.amazon.com/en-US/blogs/alexa/device-makers/2020/09/amazon-sidewalk-paves-the-way-for-more-connected-communities

[3] https://m.media-amazon.com/images/G/01/sidewalk/final_privacy_security_whitepaper.pdf

 

 

 

 


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.

Strange goings on with port 37, (Thu, Jun 3rd)

This post was originally published on this site

Similar to Yee Ching's diary on Thursday, I noticed an oddity in the Dshield data last weekend (which I had hoped to discuss in a diary on Wednesday, but life got in the way) and thought it was worth asking around to see if anyone knows what is going on. As soon as I saw it, I reconfigured my honeypots to try to capture the traffic, but wasn't able to. I'm always very interested when I see some of the legacy ports and protocols pop up. In this case, %%port:37%% is the time protocol which operates on both TCP and UDP and is one of the many services that frequently ran on the low ports of Unix machines I administered back in the 1980s and 1990s. In recent years, most operating systems have disabled these services since they only seemed to be used for DDoS purposes. On Thursday, I took another look at the graph.

By default, we normally only show the Targets/Day and Sources/Day, but I've added in the Reports/Day and TCP Ratio for this analysis. The first thing that I noticed was the huge spike in reports. Our baseline was in the 200-500 reports/day range, but on 26 May, this jumped to around 46,000. So someone, was very actively looking, the other oddity to me was, that prior to the spike, nearly all of the probes were TCP, but from 25 May – 2 Jun, nearly all the attack traffic was UDP (the gold line on the graph above, ranges from 0 = all UDP to 100 = all TCP), which then seemed to disappear and return to the mostly TCP probes on 3 Jun when I took this snapshot. Since I was unable to capture any of the packets, I don't know if there was some strange data there that might have shed some light on the purpose of this activity. The total number of sources was still pretty small ranging from a low of 69 on 25 May to 176 on 2 Jun. Meanwhile the number of targets ranged from 156 on 25 May to almost 700 on 27 May, which is right in the range of targets we've seen for the past 10 months (there was a flurry of activity on the port last June and July that spiked regularly around 2400-2500 targets, not shown in the graph above). 

So, I'm not sure what to make of it, especially without any packets. If any of you managed to capture any of this traffic last weekend and early this past week and care to share, we'd love to have a look. Otherwise, if you have any insight into what was going on, please share below or via our contact form. I'm always very curious about these traffic oddities.

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

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