To search

w3pwnz

w3pwnz, therefore we are

Tag - forensics

Entries feed Comments feed

Monday, July 2 2012 21:08

NDH2k12-wargame Write-up What the file ?

Name What the file ?
Score 1000
Content While doing some forensics, an analyst found a weird file. Please help him.

We have this file unknown.bin

$ file unknown.bin.png
unknown.bin.png: PNG image data, CORRUPTED
$ pngcheck -vt7f unknown.bin
File: unknown.bin (1179008 bytes)
File is CORRUPTED.  It seems to have suffered EOL conversion.
It was probably transmitted in text mode.


Ok, it's a corrupted PNG that we have to patch.

We realized that the lengths and the chunks' names are affected by several alterations.

We begun by correcting those names and lengths for each chunk.

A quick reminder from the RFC 2083 about the chunk layout :

Length
	A 4-byte unsigned integer giving the number of bytes in the
	chunk's data field. The length counts only the data field, not
	itself, the chunk type code, or the CRC.  Zero is a valid
	length.  Although encoders and decoders should treat the length
	as unsigned, its value must not exceed (2^31)-1 bytes.

Chunk Type
	A 4-byte chunk type code.  For convenience in description and
	in examining PNG files, type codes are restricted to consist of
	uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
	and 97-122 decimal).  However, encoders and decoders must treat
	the codes as fixed binary values, not character strings.  For
	example, it would not be correct to represent the type code
	IDAT by the EBCDIC equivalents of those letters.  Additional
	naming conventions for chunk types are discussed in the next
	section.

Chunk Data
	The data bytes appropriate to the chunk type, if any.  This
	field can be of zero length.

CRC
	A 4-byte CRC (Cyclic Redundancy Check) calculated on the
	preceding bytes in the chunk, including the chunk type code and
	chunk data fields, but not including the length field. The CRC
	is always present, even for chunks containing no data.  See CRC
	algorithm (Section 3.4).

No apparent problem for IHDR, sBIT, pHYs, tEXt(Software) and IEND chunks.

For IDAT chunks, we can understand that they're 8192 bytes long.
We scripted the thing to patch the file from offset 0x6A each 8204 bytes (8192 + 4 + 4 + 4) to 00 00 20 00 49 44 41 54 (Length + "IDAT").

$ pngcheck -vt7f unknown.bin.png
  [...]
  chunk IDAT at offset 0x11c717, length 8192
  chunk IDAT at offset 0x11e723, length 8192:  EOF while reading data


We almost got a proper and genuine png file from pngcheck's point of view, except the latest IDAT chunk. This is normal, as this chunk is the latest one and isn't 8192 bytes long.

We fixed this by correcting with that value : size until the end of file - IEND chunk (12 bytes) - checksum (4 bytes) = 5705 bytes (0x1649).

$ pngcheck -vt7f unknown.bin.png
  [...]
  chunk IDAT at offset 0x11c717, length 8192
  chunk IDAT at offset 0x11e723, length 5705
  CRC error in chunk IDAT (actual 66b9b445, should be 68cf7786)
  chunk IEND at offset 0x11fd78, length 0



Weird, the checksum is not correct, unlike all the IDAT checksums so far...We'll see later.

As the image can be open with several editors, some others won't because of the latest chunk's checksum. Nevertheless, we can see our old Chuck Norris and only half of the flag.

wtf_chucknorris.png

650b0a5aa1ec4cea................

So at this time we have the first part of the flag...

The wrong checksum of the last IDAT is probably a good clue to get the second part of the flag.
At the end of the file, we can see above IEND chunk a ...zTX3..., maybe a zTXt chunk ? Let's give it a try...

The length will be 27 bytess, 0x1B.
We also changed the length of the last IDAT chunk, 5705 - 27 - 12 = 5666 that's to say 0x1622.

Excellent, this time no more problem with checksums.

$ pngcheck -vt7f unknown.bin.png
  [...]
  chunk IDAT at offset 0x11e723, length 5666
  chunk zTXt at offset 0x11fd51, length 27:   keyword has control characters, keyword: x\DA\D3\D3C\05\96\A9\06\C9\16\A6I\86\86i\89I\A6\A6\C9f
    (compressed zTXt text)
  zTXt chunk contains one or more control characters
  chunk IEND at offset 0x11fd78, length 0



Then let's decompress the string with zlib.

#!/usr/bin/python
import zlib
 
print zlib.decompress("78 DA D3 D3 43 05 96 A9 06 C9 16 A6 49 86 86 69 89 49 A6 A6 C9 66 00 6D 17 07 6F".replace(" ","").decode("hex"))



................9e0c85b11fab55c6

w3ll done

Sunday, March 25 2012 13:27

NDH2k12 Prequals - What is it about this file ? - Mole Information

MoleInformation.png

In the sp113.pdf found in the bitmap “Wallpaper image”, we can see “author: SciteekSmith”.

Google is our friend : http://lmgtfy.com/?q=SciteekSmith

There is 1 result : http://www.facebook.com/SciteekSmith

facebook.png

NDH2k12 Prequals - Time is running out - captured file

mail_captured_file.png

There is one file : sciteekadm.cap
It’s a 802.11 capture.

Let’s crack it with aircrack-ng and a wordlist.

aircrack.png

Then we decrypted the capture with Cain.

cain.png

We opened the decrypted capture with Wireshark.

wireshark.png

We can see a png file.

We extracted it and we got the flag.

flag_captured_file.png

Tuesday, April 5 2011 21:53

NDH2k11 Prequals - Forensic200

Nous avons à notre disposition pour ce challenge le fichier ntdis.dit d'une machine exécutant un active directory et le fichier system de la machine. Nous devons retrouver au travers de ces deux fichiers le mot de passe du compte john.

Il s'agit d'un chall plus que classique, la seule subtilité ici est que nous avons à notre disposition ici la base des comptes active directory et non le fichier SAM qui contient les comptes locaux d'un poste. Les outils classiques type pwdump ne sont donc d'aucune utilité.

Après quelques recherches, je tombe sur Reset Windows Password de chez PASSCAPE qui permet de dumper les hashs à partir d'une base active directory => c'est gagné.

Reset Windows Password se présente comme une image iso bootable, au lancement il demande si c'est une base SAM ou Active Directory :

forensic200-esr

Après quelques secondes, il nous sort l'ensemble des comptes et leur hash windows :

Administrateur:500:NO PASSWORD*********************:726a36acb62f51ecee698e66fc118683:Compte d'utilisateur d'administration:
Administrateur:500:aad3b435b51404eeaad3b435b51404ee:NO PASSWORD*********************:LM history hash:
Administrateur:500:NO PASSWORD*********************:726a36acb62f51ecee698e66fc118683:NT history hash:
Administrateur:500:NO PASSWORD*********************:fbbf55d0ef0e34d39593f55c5f2ca5f2:NT history hash:
Invité:501:NO PASSWORD*********************:NO PASSWORD*********************:Compte d'utilisateur invité:
SUPPORT_388945a0:1001:NO PASSWORD*********************:30d4a2ef16deff366bd4b9f010b1bd26:Ceci est le compte d'un fournisseur pour les service Aide et support:
SYSDREAM-TTXW4P$:1005:NO PASSWORD*********************:6580b1de7daec96c9d98dbcd2f63f527::
krbtgt:502:NO PASSWORD*********************:b316ba9fe983951bfae8262757aa6f18:Compte de service du centre de distribution de clés:
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:NO PASSWORD*********************:LM history hash:
krbtgt:502:NO PASSWORD*********************:b316ba9fe983951bfae8262757aa6f18:NT history hash:
john:1108:615a367ca6280c40b4c08420b3143e50:3fb89706895e92798aeda7a399a6c417::
john:1108:615a367ca6280c40b4c08420b3143e50:NO PASSWORD*********************:LM history hash:
john:1108:NO PASSWORD*********************:3fb89706895e92798aeda7a399a6c417:NT history hash:

Le compte qui nous intéresse ici :

john:1108:615a367ca6280c40b4c08420b3143e50:3fb89706895e92798aeda7a399a6c417::

On le donne à ophcrack en utilisant les rainbow tables de base, et il nous sort en moins de 3min:

john:1108:615a367ca6280c40b4c08420b3143e50:3fb89706895e92798aeda7a399a6c417:TGYD7OE:25G:TgYD7oE25g

ophcrack

Le flag est donc TgYD7oE25g

NDH2k11 Prequals - Forensic100

Support : image RAW

But : “On a dump la RAM d'une machine sur laquelle tournait un serveur VNC. Le but est de récupérer le mot de passe de ce serveur.”

Après quelque recherches, on apprend que le mot de passe VNC est stocké de manière cryptée dans la base de registre ici : “HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC\WinVNC\Password”

On trouve rapidement sur le net, un programme qui permet de décrypter un pass VNC crypté : VNCpwdump

Le but est donc de retrouver dans le dump mémoire la clé de registre correspondante et de la décrypter.

On tente d'ouvrir le fichier .raw dans volatility :

D:\Challenges\NDH\Volatility-1.3_Beta>python volatility ident -f dump.raw
             Image Name: dump.raw
             Image Type: Service Pack 2
                VM Type: pae
                    DTB: 0xae2000
               Datetime: Thu Mar 10 14:28:56 2011

Le fichier est bien identifié et en parcourant la Documentation , on s’aperçoit qu'il est possible avec la version 1.4 de volatility d'ouvrir directement une clé de registre. Après installation, il n'y a plus qu'à lancer la bonne commande :

C:\Users\K-Lu\Desktop\Volatility-1.4_rc1>python vol.py printkey -f dump.raw -K RealVNC\WinVNC4

Volatile Systems Volatility Framework 1.4_rc1
Legend: (S) = Stable   (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\software

Key name: WinVNC4 (S)
Last updated: 2011-03-10 13:10:51
Subkeys:
Values:
REG_BINARY    Password        : (S)
0000   DA 6E 31 84 95 77 AD 6B                            .n1..w.k
REG_SZ        SecurityTypes   : (S) VncAuth
REG_SZ        ReverseSecurityTypes : (S) None
REG_DWORD     QueryConnect    : (S) 0
REG_DWORD     QueryOnlyIfLoggedOn : (S) 0

Nous retrouvons donc bien le pass VNC crypté : DA 6E 31 84 95 77 AD 6B, plus qu'à le décoder avec VNCpwdump :

D:\Hacking\Tools\VNCpwdump>vncpwdump.exe -k DA6E31849577AD6B

VNCPwdump v.1.0.6 by patrik@cqure.net
-------------------------------------
Password: secretpq

Et voilà il n'y avait plus qu'à rentrer le flag.

Monday, April 4 2011 23:41

NDH2k11 Prequals - Forensic300

Pour cette épreuve, on nous fournissais, sans donner d'indications, un dump de la ram d'une machine (fichier .vmem). La première étape est d'identifier la machine, pour cela on utilise comme souvent l'outil volatility :

C:\ndh\Volatility-1.4_rc1>python vol.py -f DumpRAM_CTF.vmem imageinfo
Volatile Systems Volatility Framework 1.4_rc1
Determining profile based on KDBG search...

WARNING : volatility.obj      : Unable to find a type for pointer64, assuming int
          Suggested Profile(s) : Win7SP1x86, Win7SP0x86

La machine est donc un windows 7, on utilisera donc par la suite le profile Win7SP1x86 de volatility.

Petite anecdote : à posteriori, on a su que la principale difficulté voulue par l'auteur pour cette épreuve, était que volatility ne prenait pas en charge les machines windows 7. Mais c'était sans compter la RC 1.4 qui le gère parfaitement, sans rancune Heurs ;)

On va maintenant lister les processus :

C:\ndh\Volatility-1.4_rc1>python vol.py pslist --profile=Win7SP1x86 -f DumpRAM_CTF.vmem
Volatile Systems Volatility Framework 1.4_rc1
WARNING : volatility.obj  	: Unable to find a type for pointer64, assuming int
 Offset(V)  Name             	PID	PPID   Thds   Hnds   Time
---------- -------------------- ------ ------ ------ ------ -------------------
0x839af898 System                	4  	0 	70	434 2011-03-31 14:38:10
0x84c01d40 smss.exe            	216  	4  	2 	29 2011-03-31 14:38:10
0x84ea8030 csrss.exe           	304	296  	8	310 2011-03-31 14:38:18
[...]
0x83ace030 nc.exe             	1720   1392  	2 	72 2011-03-31 14:40:41

On remarque un processus intéressant : nc.exe (pid 1720), on peut donc s'imaginer qu'il y a eu une connexion et des échanges avec une autre machine. Cherchons cette machine :

C:\ndh\Volatility-1.4_rc1>python vol.py netscan --profile=Win7SP1x86 -f DumpRAM_CTF.vmem
Volatile Systems Volatility Framework 1.4_rc1
Offset 	Proto	Local Address              	Foreign Address  	State        	Pid  	Owner      	Created
[...]
0x1f086df8 TCPv4	192.168.163.216:49158      	88.190.230.12:48625  ESTABLISHED  	1720 	nc.exe
[...]

La connexion s'est donc faite avec la machine 88.190.230.12 sur le port 48625, on peut d'ailleurs se connecter à la machine nous même avec netcat et lui envoyer des données, mais elle ne nous envoie rien. Il doit nous manquer un élément, fouillons dans la mémoire de nectat :

C:\ndh\Volatility-1.4_rc1>python vol.py --profile=Win7SP1x86 -f DumpRAM_CTF.vmem memdump -p 1720 --dump-dir C:\ndh
Volatile Systems Volatility Framework 1.4_rc1
WARNING : volatility.obj      : Unable to find a type for pointer64, assuming int
************************************************************************
Writing nc.exe [  1720] to 1720.dmp

Dans le dump obtenu, on a plusieurs fois les strings suivantes (5 occurences chacunes) :

  • Secret pass is H4x0r
  • Nice job ! … The hash is ***************

On imagine que ce pourrait être un échange réseau, on envoie donc Secret pass is H4x0r à la machine distante, et elle nous renvoie le vrai flag !

C:\ndh\Volatility-1.4_rc1>nc 88.190.230.12 48625
88-190-230-12.rev.dedibox.fr [88.190.230.12] 48625 (?) open
Secret pass is H4x0r
Nice job!
The hash is 9vjgH368$hgHGjh

\o/