Sean Mackert professional headshot

Sean Mackert

- Passionate about security
- Aspiring red teamer
- Seeking mentorship

3-Minute Read

In this part, I will cover the initial steps, thoughts, and problems I had while attacking LAN Messenger.

I decided to attack LAN Messenger because it was an application which I had used previously and I already found a remote DoS exploit accidentally while poking around with netcat.

According to the SourceForge repository, LAN Messenger was last updated in 2012 (version 1.2.35) which gave me hope that there were some bugs that could be easily exploited. As this was a task meant for practice, I tried to avoid “spoilers”, however I later discovered that there were only two reported vulnerabilities issued CVEs. Both ended up being DoS bugs, one of which I already found anyway and the other doesn’t really make sense and claims to be for a version that doesn’t exist.

Despite there only being two CVEs, I was also very interested in a comment on the SourceForge page by a user claiming that there was a known XSS actively being exploited in the program as well. Despite the initially confusing comment which referenced an Exploit-DB ID for a completely different product, an XSS polyglot eventually did uncover the bug. After several more Google searches, I finally discovered a 2012 PoC from Vulnerability Laboratory that described the XSS, although the URL encoding suggested caused the bug not to trigger on my test machine.

Sometime during testing I discovered that LAN Messenger was forked to a project on GitHub as version 1.2.39.

6-Minute Read

In my experience, .DS_Store is an essential line in your personal scanning lists. These days, exposed .DS_Store files can be rare, but it can be a useful string to use when trying to find hard-to-discover paths as well. Here’s a brief introduction to .DS_Store, and a recount of a time when it really paid off for me.

The .DS_Store file contains folder metadata for Mac users. These files are created automatically inside of archives, local folders, and even remotely mounted folders. More importantly, for us, these files can include file and folder names that we would have otherwise been unable to guess during normal directory bruteforcing techniques.

Luckily for us the format has been reversed engineered and you can use this simple one-liner or this Python-dsstore project to parse the file and read the contents. Additionally you can simply read the file with a text editor. You’ll just have to ignore the gibberish bits between the files/folders.

A quick grep of SeclLists’ Web-Discovery folder reveals that the file is included in all sizes of the file/word raft lists, quickhits.txt, and dirsearch.txt which are among the most popular pre-made bruteforce lists.

However, this file doesn’t always make into the pentester’s personal shortlists, which I believe is a mistake.

3-Minute Read

Since the news of Log4shell initially broke, a few news outlets have been stoking fear about an imminent attack from a devastating worm, from the usual suspects, armed with a Log4j exploit. A month later, and we still haven’t seen it — but why? And how is it actually being used?

The attack surface that a Log4j worm would have to target is very incongruous. Systems such as web servers are easy to mass scan and Java-based web applications like Elasticsearch and VMware Horizon have already been exploited in great numbers. Scanning the entire internet for a select few vulnerable services or even blindly pray-and-spraying every found web service with a payload can be done in a day.

Writing a worm for a scannable exploit is pretty much pointless. Worms like WannaCry made use of an SMBv1 service vulnerability in Windows systems meaning that the entire network could be compromised from a single exploit. Log4j, while devastating in it’s breadth, isn’t as ubiquitous as a default Windows service and the method of exploitation for this library will vary greatly depending on its implementation.

A Log4j worm would only affect the few machines running this library and internal uses of the library would be too varied to be predictable in any meaningful way. Even the operating system would

Additionally, the skill requirement of writing a worm is much higher than scanning. Only nation-state threat actors have the skill and resources to put together an impactful worm quickly enough to be competitive with scanning and even the efficacy of this is debatable.

Recent Posts

Categories

About

Sean Mackert is an IT professional passionate about security and helping inform others.