Here's some background information I discovered:
- The Flash standard incorporates local Shared Objects (LSOs), which allow data (such as preferences) to be stored in the local Flash instance on a user’s machine.
- LSOs are stored as individual files with a .SOL file extension. By default they are less than 100 kB in size and have no expiration (unlike traditional HTTP cookies).
- Flash requires that LSOs be stored hierarchically by domain.
- A local shared object can be read only by the website domain that created the object.
- Operating System-dependent file storage locations can be found at Wikipedia.
- subdirectories under '#SharedObjects/' contain the actual Flash cookies; subdirectories under 'Macromedia.com' contains persistent global and domain-specific settings for how the Flash player operates.
SOL file are stored in a binary format, so the contents are not immediately accessible with a text editor. I located two free tools to decode these files:
- FlashCookiesView - a MS Windows, GUI-based tool (http://www.nirsoft.net/utils/flash_cookies_view.html)
 |
| FlashCookiesView tool |
- s2x.py - a command line interface-based Python script to convert the .sol file format to XML (http://osflash.org/s2x)
- note: I encountered a 30-40% rate of "Unexpected Error" messages using this tool
ls -l /home/testuser/.macromedia/Flash_Player/#SharedObjects/F34956GR/
total 188
drwx------ 3 testuser testuser 4096 2010-11-09 15:09 a.blip.tv
drwx------ 3 testuser testuser 4096 2010-11-04 17:57 abcbank.com
drwx------ 3 testuser testuser 4096 2010-11-01 10:03 adsatt.disney.go.comtotal 188
drwx------ 3 testuser testuser 4096 2010-11-09 15:09 a.blip.tv
drwx------ 3 testuser testuser 4096 2010-11-04 17:57 abcbank.com
drwx------ 3 testuser testuser 4096 2010-11-08 10:58 as1.suitesmart.com
drwx------ 3 testuser testuser 4096 2010-11-22 12:49 assets.disney.go.com
...
I would like to decode LSO files en masse, and possibly on a recurring, automated basis, so I chose to work with the command line-based s2x Python script, despite its higher rate of errors.
I created a simple wrapper bash shell script, partially shown below, to recursively enter each LSO subdirectory, look for files with the .sol extension, decode these files, and store the output.
for DIR in $(find $dirpath -type d)
do
cd $dirpath
cd $DIR
echo "The present working directory is:" `pwd`
for FILE in $(ls -l ./ | grep -v total | awk '{print$NF}' | grep ".sol")
do
echo "Attempting to decode $FILE .."
echo "The full path to this file is:" $DIR\/$FILE
/opt/s2x.py -x $DIR\/$FILE /tmp/s2x/xmls/$FILE.xml >> /tmp/s2x/s2x-multi.out
if [ `grep -c "$FILE.xml Was Successfully Created" /tmp/s2x/s2x-multi.out` != "0" ] ; then
echo $FILE >> /tmp/s2x/s2x.filenames
grep " name=\"" /tmp/s2x/xmls/$FILE.xml >> /tmp/s2x/s2x.names-values
else
echo "The file $FILE was not successfully decoded."
fi
done
cd $dirpath
done
The script was written to pull out LSO files with potentially "interesting" names - containing words such as "account", "session", "credentials", etc.
The results of bulk decoding these files were mostly uninteresting - contents related to video volume settings, performance information, etc. However, as shown in the output below, one of the decoded files is named v4_UserCredentials.sol. A closer look at the (redacted) contents of this file, which resides in the pandora.com subdirectory, is shown below.
The password value is hashed or encrypted, so in order to gain access to the account, rather than expending effort to attempt to decode or decrypt the value, I simply copied the .sol file itself to another system, in an attempt to clone the session.
From the second test system, I initially visited the Adobe Website Storage Settings panel to ensure no pre-existing pandora.com LSOs remained on the new system. I deleted the pandora.com website from the listing, and confirmed that the directory and files no longer existed on the system:
otheruser@laptop:~/.macromedia/Flash_Player/#SharedObjects/..$ ls -l pandora.com/
ls: cannot access pandora.com/: No such file or directory
ls: cannot access pandora.com/: No such file or directory
I visited www.pandora.com on the new system, confirming no authenticated session:
 |
| Unauthenticated pandora.com access |
I pasted the v4_UserCredentials.sol file from the first system into the newly-created pandora.com subdirectory (created upon visiting the pandora.com homepage):
otheruser@laptop:~/.macromedia/Flash_Player/#SharedObjects/..$ cp /home/user/test/lsos/pandora.com/v4_UserCredentials.sol ./pandora.com/
otheruser@laptop:~/.macromedia/Flash_Player/#SharedObjects/..$ ls -l pandora.com/
-rw-r----- 1 user user 187 2010-11-22 17:15 v3_Machine.sol
-rw-r----- 1 user user 138 2010-11-22 17:15 v3_PerfComp.sol
-rw-r----- 1 user user 119 2010-11-22 17:17 v4_UserCredentials.sol
I then refreshed the pandora.com webpage, and was able to view account details for the original, authenticated session:
 |
| Cloned pandora.com session access |
This example confirms that, while most "Flash cookies" may be used for rather mundane (from a security perspective) uses such as setting video preferences, the potential exists to locate, decode and/or clone sensitive, user session-enabling LSO files.
As a security-conscious Internet user, possible steps to protect against unauthorized account access based on LSOs include:
- viewing, managing, and removing otherwise indefinitely-stored LSOs using the aforementioned Adobe Website Storage Settings panel;
- ensuring appropriate permissions on LSO directories and files - specifically, everything under the #SharedObjects/ directory.
As a professional security penetration tester, the take-away is that LSO files provide another potential avenue to advance unauthorized access, once a system or account has been compromised. Add .sol files to the list of "interesting" system files to take a look at!
No comments:
Post a Comment