3 min read appsec

Add .DS_Store to Your Wordlists (TFC CTF's "MacDonalds" challenge)

One of the CTF challenges from TFC CTF was called “MacDonalds”. This challenge essentially asks you to find a web directory–without using a scanner like dirb–given a few hints.

There’s nothing interesting in the HTML or in the headers (or anything else viewable in Dev Tools).

All we know is that the person developing the website has a MacBook (hence the name of the challenge, MacDonalds).

.DS_Store

Looking at the typical “common.txt” wordlist for dirb, there are plenty of entries but very few jump out as obviously Mac-related.

If you own a Mac and/or have done development work with it, you know that the OS will automatically generate .DS_Store files in each directory that is opened in Finder.

You don’t see this file when browsing in Finder, since it starts with a .. However, if you aren’t careful with file uploads, zipping, git repositories, etc., you can accidentally share this file.

.DS_Store is short for Desktop Services Store and stores custom attributes such as icons, background images, and so on. The file structure is proprietary but the files themselves are typically not very long, and have been reverse-engineered.

This post has an in-depth view of the .DS_Store file format, and how to read the header, and traverse different data structures within the file.

At the end of the post, there’s a link to an online .DS_Store file parser: https://labs.internetwache.org/ds_store/

CTF Example: TFC CTF’s “MacDonalds” challenge

If we try to open up .DS_Store in the webserver: http://server.challenge.ctf.thefewchosen.com:1339/.DS_Store, we get a file download.

Opening it up in Hex Fiend or another hex editor, there’s a ton of whitespace and then some text values:

If we upload it to the .DS_Store file parser linked in the previous section, we get the following output:

This is a ‘snapshot’ (of sorts) of the directory contents on the website developer’s machine. There’s the index.php and CSS files, and then there’s something called secrets.

Navigating to http://server.challenge.ctf.thefewchosen.com:1339/secrets or http://server.challenge.ctf.thefewchosen.com:1339/secrets/ doesn’t get us anything.

But, if we add another .DS_Store to the end: http://server.challenge.ctf.thefewchosen.com:1339/secrets/.DS_Store, we get a second .DS_Store file.

Uploading this one to the online parser is quite a bit more straightforward:

If we navigate to http://server.challenge.ctf.thefewchosen.com:1339/secrets/5973b4cc1d61c110188ee413cddb8652.php, we get the flag:

Adding .DS_Store to your wordlist

A good web development process should not leave files like .DS_Store on a server, but plenty of people make mistakes.

.DS_Store is included on Daniel Miessler’s “quickhits” wordlist. You can also manually add it to a wordlist of your choice (adding new directories or file extensions as you discover them in CTFs, bug bounty, etc)

Here are a few CTF examples and other references that make use of .DS_Store files as a form of data leakage:

.DS_Store Google dorks

Finding .DS_Store files mistakenly uploaded using Google Dorks (credit: https://miloserdov.org/?p=3867)

intext:.DS_Store & intitle:index -github
intitle:"index of" intext:".ds_store"
inurl:.DS_Store intitle:index of
inurl:.DS_Store intitle:index.of

You can also search on GitHub: https://github.com/search?q=.DS_Store&type=Commits