SANS Gold Paper - Website Security for Mobile

Smartphones and Tablets are very popular nowadays; other than playing around the apps, most of us use the
mobile devices to browse web pages. People usually look for convenient and quick browsing without paying much attention to security settings like anti-phishing or anti-xss filtering. Thus, special attention must be paid
to the end-user's web security when they use mobile devices (mainly on iOS and Android Platforms). For
example, how easily phishing can be done in mobile devices; what is the impact of visiting...

http://www.sans.org/reading-room/whitepapers/pda/website-security-mobile-34190

PlaidCTF 2014 For-350 write up

Challenge:

You have traveled back in time, but look, hunting The Plague is tough. You're really just going back to relax for a while without having to worry about all that nonsense. As you walk in the park you stumble across someone's BlackBerry. Wow, people still use BlackBerry phones (time travel gets so confusing)? You figure you should return it to the owner, but you have a hard time getting inside. Figure out what's on the phone, and maybe we'll be able to return it to the rightful owner.

Password is saved as SHA1, and it is located in NVRAM on the device. So in order to find the location of the password, let's set one on our own first, open simulator, do factory reset, so we can set our password and search in memory later on. Let's reset it by entering the password 10 times wrongly.

Let's reset the screen lock password to be "password", and its SHA is 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"

Let's search for in the NVRAM, 9930-nv.dmp, search for "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"
the offset is 00053020 (and starting with "3C000000")

Restore the original 9930-nv.dmp, go to the same offset, got the hash "3E270F54C6EB3175B4EF8B20080795EF2EE15589"

Google it, we got "fuckfuckfuckyouhahaha"...

We go back to the BB again and unlock, cool, we can enter it!

From the hints, let's search the contact, and we found Plaid CTF

Open it, and we get the first key, "fuckfuckfucky0uh4h4h4".. but there's another challenge, ok let's download it

From blackberry.dmp, it looks like a full dump, anyway, let's open it with winhex. In order to speed up, we just search for  "3C000000"... first of all, we got "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8" again, it's "password", but it does not look like the key :-(...

With more patience... we got another one, we got "AC0CFE7BD0AE22B44722F1A01ECB6CE102CA27C5"

we google it, finally got "BerryGood"

Reference:
http://crackberry.com/security-blackberry-balance
The personal master key is also randomly generated. The personal master key is stored in NVRAM on the device and is encrypted with the system master key

http://www.forensicfocus.com/Forums/viewtopic/t=7055/
password should be in SHA1

ebctf 2013 For-100 write up

Challenge:

After a recent attack, we found this encrypted file. Luckily, we made a memory dump, can you decrypt the file?
Archive password: lcoXse3oa3Uicioc

Files can also be found here: http://ctf.zone/EbCTF-2013-08/Forensics/100/

Download and unzip the memory dump, check the file type

Also check the strings, so it could be linux 64 bit

Pre-requisites:
We will be using volatility to investigate the memory dump, and a suitable linux profile to read it. In this case, for convenience, we can simply download Ubuntu 12.04 64bit and run it in VM
http://www.ubuntu.com/download/desktop/questions?distro=desktop&bits=64&release=lts
after setting up the VM for Ubuntu, we will install volatility (you may also need to install subversion beforehand)
in Ubuntu 64bit open the terminal,  to install subversion:
$ sudo apt-get install subversion
To install volatility:
sudo  svn checkout http://volatility.googlecode.com/svn/trunk/ volatility
$ cd volatility
$ sudo python setup.py install
*note: the path in the sample codes may be different (subject to your own environment)

To create Linux Profile (Ubuntu1204-64bit) for read the memory dump
ref:  https://code.google.com/p/volatility/wiki/LinuxMemoryForensics

To install dwarfdump:
$ apt-get install dwarfdum
$ cd volatility/tools/linux
$ make
$ head module.dwarf

Making the profile:

From above, we found “BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic”, we may create the profile from Ubuntu12.04 64bit with System.map-3.5.0-23-generic

$ sudo zip volatility/volatility/plugins/overlays/linux/Ubuntu1204.zip volatility/tools/linux/module.dwarf /boot/System.map-3.5.0-23-generic

Ubuntu1204.zip will be created, we can see “LinuxUbuntu1204x64” profile

$ python vol.py  --info | grep Linux

Everything is ready, we can analyze the memory dump, There's a python2 process (pid=1317), we will want to examine it further
$ python  vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_pslist

We will use linux_bash to check for any clues in the history
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_bash

Two important findings here,
python2 ctf.py ‘ i hide my ‘
kill -s SIGUSR 1317
the python was executed with argument “ i hide my”, and eventually the process was killed by SIGUSR1

The python code could still be in the memory, so we grep the strings
$strings memory.dump | grep SIGUSR1

“signal.signal(signal.SIGUSR1, encrypt)” seems to be part of the python
We save the strings in a text file and do another search for the rest of the codes
$ strings memory.dump > memory.dump.txt
Search the string “signal.signal(signal.SIGUSR1, encrypt)” in text editor, we could find the python codes around
Now we’ve got key1: ‘is this where’, key2: ‘ i hide my ’, and now we have to find key3 in order to decrypt the “flag” file

We try examine the python process memory for what could be input as argument
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_proc_maps -p 1317
We see “[heap]” between python2 and encrypt, it could be string of the input

We dump the memory for further analysis
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_dump_map -p 1317 –dump-dir output/
$ grep -r 'i hide my' output/
These two files should contain “i hide my”,  Let’s search the strings in these two files
Ha! We got sth. useful! ‘is this where i hide my secrets?’, so key3 is “secrets”!

You may also simply search for memory.dump strings to find “is this where i hide my secrets”

Now we modify the python code to see if it can decrypt the flag, we got key1, key2 and key3, and we print the result of decrypt

Finally we got the flag :)
ebctf{55169c1c241aa20412da94b3fcbf8506}

PlaidCTF 2014 For-400 write up

Challenge:

The Plague is using state of the art systems for storing his data. Our operatives managed to steal [a drive](zfs-ff06f37193caa92456e9c03090c80600.tar.bz2) from one of his servers, but it seems like our haste may have led to some uber-corruption. Can you get the data off the drive to track down The Plague?

From the question title, “disk” is kind of corrupted zfs drive. In order to recover the data as quick as possible, recovery tools like UFS Explorer Pro is used. Open the “disk” with it, you can see one file “not_the_key”.

Opening “not_the_key”, it’s really not the key… dig deeper

Then trying to recover the data from “disk”, three files are found.
key.xor_encrypted
not_the_key
xor_key

Extract the files, two of them look interesting. “xor_key” and “key.xor_encrypted” look self-explanatory, let’s try to “xor” them. The python code “xor” the two files.

from binascii import unhexlify, hexlify

def str_xor(s1, s2):
    return "".join([chr(ord(c1) ^ ord(c2)) for (c1,c2) in zip(s1,s2)])

def get_bytes_from_file(filename):  
    return open(filename, "rb").read()  

encByte = get_bytes_from_file('key.xor_encrypted')

keyByte = get_bytes_from_file('xor_key')

s = ''.join(chr(ord(c1) ^ ord(c2)) for c1, c2 in zip(encByte[-len(keyByte):], keyByte))

print s

Run the python code, the flag is here

===========================================================

Alternate Method:

Hex analysis approach to dig out the files, assuming we did not use UFS Explorer, we can use Hex Editor like WinHex

Oh well, we did not have clues, so we did some key word search, how about “key”?

Ok, we got “not_the_key”. Scroll up, it looked interesting, and we copy the block out.

Then we got “not_the_key” file and it asks us to dig deeper again. .\/. OK, find next... We continue to “dig deeper” and continue to search, we see three names:

key.xor_encrypted

not_the_key

xor_key

Ok, it's a bit by chance, we found that there's a 0x200 block ... 

And we scroll down to get another 0x200 block to see if we can do an XOR... 

oh yeah, it could perfectly do the XOR and get the cute shark again -_-.....