CodeGate 2010 – Challenge 6 writeup

March 20, 2010 by longld · 3 Comments 

Summary

Challenge 6 is a forensics problem with a mountain of data, a packet capture file and a FAT32 filesystem image. In order to find the secret you have to watch for the “key” exchanged via MSN conversation in a packet capture file, then use it to find the secret file name. With forensics problems, luck is more important than techniques and you should only do it if you don’t have anything to play during the game.

Analysis

Challenge information:

credentials:

http://ctf.codegate.org/thisiswhereiuploadmyfiles/CC2A8B4FA2E1FA6BD7FE9B8EFC86BCB7

Substitute for those who are not in Korea : http://www.mediafire.com/?wyhexdmzzdm

You should convert the flag into lower case letters and try to auth with it.

Hint: The packet of messenger is important. You don’t need to care the ftp stuff.

Hint2: Please put your flag without any extension to the auth page.

File info

$ file CC2A8B4FA2E1FA6BD7FE9B8EFC86BCB7
CC2A8B4FA2E1FA6BD7FE9B8EFC86BCB7: gzip compressed data, from Unix, last modified: Fri Mar 12 17:20:19 2010

$ zcat CC2A8B4FA2E1FA6BD7FE9B8EFC86BCB7 > challenge6
$ file challenge6
challenge6: POSIX tar archive (GNU)

$ tar xvf challenge6
352FCD8BDEC8244CDED00CA866CA24B9
B400CBEA39EA52126E2478E9A951CDE8

$ file 352FCD8BDEC8244CDED00CA866CA24B9 B400CBEA39EA52126E2478E9A951CDE8
352FCD8BDEC8244CDED00CA866CA24B9: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
B400CBEA39EA52126E2478E9A951CDE8: x86 boot sector, code offset 0x58, OEM-ID "MSDOS5.0",
sectors/cluster 8, reserved sectors 4334, Media descriptor 0xf8, heads 255, sectors 1982464 (volumes > 32 MB) ,
FAT (32 bit), sectors/FAT 1929, reserved3 0x800000, serial number 0x7886931a, unlabeled

We have 2 files: a tcpdump packet capture and a FAT32 filesystem image. From the hints (yes, without it we don’t know what to search for), we focus our search to:

  • Final secret key must be a file and it may rely on FAT32 image
  • Keyword to find out that secret file must be exchanged via MSN conversation(s) in tcpdump file

MSN conversation

Using chaosreader (you can use other tools to have the same result) to analyse pcap file, we will have a list of sessions like below:

Chaosreader Report - msnp

The session number 263 & 264 is MSN chat. Following the conversion by looking in to raw file we find some interesting things:

forensic-proof@live.com> i;d like to get a file that i asked you before……
forensic-proof@live.com> now availabel?

securityholic@hotmail.com> ah
securityholic@hotmail.com> ok wait a min :)

[... MSN P2P file transfer session ...]

forensic-proof@live.com> thanks….

securityholic@hotmail.com> this is between you and me :-/

It looks like they exchange some “secret” via MSN P2P file transfer. Looking at file transfer session (refer to References for MSN protocol) :

To: <msnmsgr:securityholic@hotmail.com;{95178158-37b6-45ce-b332-2042a4d27563}>
From: <msnmsgr:forensic-proof@live.com;{281f2818-580b-46f0-909f-c009de526642}>
Via: MSNSLP/1.0/TLP ;branch={51D93360-BFBD-40CB-AD0A-2D7FB5C28031}
CSeq: 1
Call-ID: {71021C00-FE1C-4E91-B415-D2145D7C1C24}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transrespbody
Content-Length: 482

Listening: true
NeedConnectingEndpointInfo: false
Conn-Type: Direct-Connect
TCP-Conn-Type: Direct-Connect
IPv6-global: 2001:0:cf2e:3096:2036:1131:5c67:c1c5
UPnPNat: false
Capabilities-Flags: 1
srddA-lanretnI4vPI: 85.26.251.361
troP-lanretnI4vPI: 2133

IPv6-Addrs: 2001:0:cf2e:3096:2036:1131:5c67:c1c5 2002:a398:3e3a::a398:3e3a
IPv6-Port: 3313
Nat-Trav-Msg-Type: WLX-Nat-Trav-Msg-Direct-Connect-Resp
Bridge: TCPv1
Hashed-Nonce: {E3759BB3-EED9-04F3-3B1A-56044619D59F}

What the hell is this: srddA-lanretnI4vPI: 85.26.251.361? It’s reversed! So, file transfer session has this information: IPv4Internal-Addrs: 163.152.62.58, IPv4Internal-Port: 3312. It’s confirmed by looking at chaosreader output:

Chaosreader Report- 3312

Let dump that session and use tcpxtract to extract files from the pcap:

$ tcpdump -nn -r 352FCD8BDEC8244CDED00CA866CA24B9 'port 3312' -w 3312.pcap
$ tcpxtract -f 3312.pcap
 Found file of type "pdf" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000001.pdf
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000008.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000009.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000010.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000011.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000012.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000013.jpg
 Found file of type "jpg" in session [163.152.62.59:37390 -> 163.152.62.58:61452], exporting to 00000014.jpg

During the game, we opened PDF file but it’s just blank then we focused on JPG files, but no luck. Re-examined the blank PDF, by “Select All” we found there’s hidden text at the bottom of  the page: CC105EE2A139A631175571452968D637. Looks like a “key” – checksum of the secret file.

Searching on FA32 filesystem image for that checksum:

$ sudo mount -o loop,ro B400CBEA39EA52126E2478E9A951CDE8 /mnt/loop

$ find /mnt/loop -type f -exec md5sum {} \; >> md5sum.txt

$ grep -i CC105EE2A139A631175571452968D637 md5sum.txt
cc105ee2a139a631175571452968d637  /mnt/loop/hqksksk/iologmsg.dat

Matched! Finally, the secret key is: iologmsg. We’re just lucky!

Now, look back to the hint “You should convert the flag into lower case letters and try to auth with it.”, it sounds irrelevant or the md5sum was the correct key at first?

References

Keywords: network forensics, msn protocol, codegate 2010

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Add to favorites
  • Reddit
  • Technorati
  • Tumblr
  • Twitter
  • Slashdot
  • Identi.ca

Codegate 2010 Challenge 12 writeup

March 18, 2010 by Hiếu Lê · 2 Comments 

Summary

  • Problem: Finding the key in one raw-data-file – forensic challenge
  • Techniques: Using foremost to extract data
  • Solution: Just extract data and it’s done

Analysis

After downloading the file, let’s skim over.

$ file 514985D4E9D80D8BF227859C679BFB32 514985D4E9D80D8BF227859C679BFB32: CDF V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 949, Title: Chzcxva Pneivat Znqr Rnfl, Author: Flfnqzva, Template: Normal.dotm, Last Saved By: FRETR INHQRANL, Revision Number: 12, Name of Creating Application: Microsoft Office Word, Total Editing Time: 21:00, Create Time/Date: Mon Feb 22 12:48:00 2010, Last Saved Time/Date: Thu Mar 4 13:54:00 2010, Number of Pages: 7, Number of Words: 1381, Number of Characters: 7876, Security: 0

$ ls -l 514985D4E9D80D8BF227859C679BFB32

-rw-r–r– 1 hieuln hieuln 867328 2010-03-13 21:18 514985D4E9D80D8BF227859C679BFB32

Of course, it’s not CDF document. So, the general step is using foremost to extract inside-data.

$ foremost -c /etc/foremost.conf -v -o out 14985D4E9D80D8BF227859C679BFB32

It got a lot of stuffs. Let’s browsing images file first. I noticed there’s a small image named “00000041.tif” looks like a captcha. Try with that phrase and it is the right key “E5R69267″.

Sad, really upset. That’s such a bad challenge with 300 points. And I can’t imagine that CLGT is the 3rd team submit this flag, it’s the end of first day.

References

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Add to favorites
  • Reddit
  • Technorati
  • Tumblr
  • Twitter
  • Slashdot
  • Identi.ca

How to recover RSA private key in a coredump of ssh-agent – Sapheads HackJam 2009 Challenge 6

October 1, 2009 by thaidn · Leave a Comment 

Last week or so I joined CLGT to take part in HackJam 2009 by Sapheads. AFAIK this is the first CTF that Sapheads organizes, but they had done a very good job. To most people’s surprise, the contest attacted quite a lot of teams from around the world, and it had quickly become an international competition.

Did I tell you that we’re the winner? Ha ha ha this is our very first win since the name CLGT was born.

BTW, HackJam 2009 was a success because Sapheads had kept their promise which is to “provide challenges that greatly resemble real world scenarios and environments, at the same time, adding fun and educational ingredients to them”. We really had fun ^_^, not disturbing pains *_*, in solving the challenges. Thank you Sapheads! We’re looking forward to HackJam 2010.

I promised to some people in #sapheads that I would release some writeups about the challenges after the contest ended, and here they are. Sorry for the delay, I have been busy working with vendors on this which you may want to read too.

I’ll post writeups of challenge 4, 6, 7, 8, 9 on this blog and CLGT’s homepage in the next two weeks. These are the challenges that I solved or helped to solve. I leave out challenge 1 and challenge 2 because they are trivial. I was out or sleeping when the team solved challenge 3 and 5, so I guess I don’t write nothing about them either. You can download all the binaries in the contest here.

I hope you enjoy reading them as much as I enjoy writing them.

——-

As the title of this entry suggests, this is the writeup of challenge 6 which is IMHO the coolest CTF challenge ever :-D. I really like its concept and implementation. Thank you whats ^_^!

For those who didn’t take part in HackJam, these two men are the criminals who had stolen and leaked a new album of SNSD (you should check these girls out ^_^). All teams are in charged of tracking them down.

As you can see in the comic, the criminals got a coredump when they were trying to transfer a MP3 to his server at 67.202.60.164. And that coredump is the only file given in challenge 6.

So first thing first:

$ file core.6261

core.6261: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'ssh-agent'

As you can see, this is a coredump of ssh-agent. This is from the manpage of ssh-agent:

ssh-agent is a program to hold private keys used for public key
authentication (RSA, DSA). The idea is that ssh-agent is started in the
beginning of an X-session or a login session, and all other windows or
programs are started as clients to the ssh-agent program.

The manpage doesn’t tell where ssh-agent stores private keys, but one can guess that it would store them in its memory. When ssh-agent crashes, all of its memory content would be written to the coredump. So I guess the idea of challenge 6 is to recover the private key of the criminals stored in the coredump, and use that private key to SSH into 67.202.60.164 which may give me the key for challenge 7.

This is why Sapheads challenges are better than other CTFs. They don’t try to distract us by giving false trails. They give good trails which can be deduced using logical thinking. This challenge also greatly resembles real world scenario which in turn makes it much more interesting than other non-sense challenges somehow created only to show that their authors are smarter than others.

Okie enough bullshit, let’s get back to challenge 6. As whats from Sapheads suggests, I take a look at static variables of ssh-agent.c which are defined like below:

typedef struct identity {
 TAILQ_ENTRY(identity) next;
 Key *key;
 char *comment;
 u_int death;
 u_int confirm;
} Identity;

typedef struct {
 int nentries;
 TAILQ_HEAD(idqueue, identity) idlist;
} Idtab;

/* private key table, one per protocol version */
Idtab idtable[3];
int max_fd = 0;
/* pid of shell == parent of agent */
pid_t parent_pid = -1;
u_int parent_alive_interval = 0;
/* pathname and directory for AUTH_SOCKET */
char socket_name[MAXPATHLEN];
char socket_dir[MAXPATHLEN];

So right above socket_name are 3 integers, and then comes idtable which contains pointers to Identity structures, which in turn contains pointers to Key structures. This is how a Key structure looks like (it’s in openssh/key.h):

struct Key {
 int     type;
 int     flags;
 RSA    *rsa;
 DSA    *dsa;
};

Ah RSA structure! This is how it looks like (it’s in openssl/rsa.h):

struct rsa_st
 {
 /* The first parameter is used to pickup errors where
 * this is passed instead of aEVP_PKEY, it is set to 0 */
 int pad;
 long version;
 const RSA_METHOD *meth;
 /* functional reference if 'meth' is ENGINE-provided */
 ENGINE *engine;
 BIGNUM *n;
 BIGNUM *e;
 BIGNUM *d;
 BIGNUM *p;
 BIGNUM *q;
 BIGNUM *dmp1;
 BIGNUM *dmq1;
 BIGNUM *iqmp;
 /* be careful using this if the RSA structure is shared */
 CRYPTO_EX_DATA ex_data;
 int references;
 int flags;
 /* Used to cache montgomery values */
 BN_MONT_CTX *_method_mod_n;
 BN_MONT_CTX *_method_mod_p;
 BN_MONT_CTX *_method_mod_q;
 /* all BIGNUM values are actually in the following data,
  * if it is not NULL */
 char *bignum_data;
 BN_BLINDING *blinding;
 BN_BLINDING *mt_blinding;
 };

typedef bignum_st BIGNUM;
struct bignum_st
 {
 BN_ULONG *d;    /* Pointer to an array of 'BN_BITS2' bit chunks. */
 int top;    /* Index of last used d +1. */
 /* The next are internal book keeping for bn_expand. */
 int dmax;    /* Size of the d array. */
 int neg;    /* one if the number is negative */
 int flags;
 };

As one can expect, a RSA structure contains n, e, d, p, q and some other data. We need to get these numbers, which are stored in BIGNUM structures, out of the coredump. So the next thing to do is know where idtable is in the coredump. I load the coredump into bless, my favourite hex editor (click on the image to zoom in):


As you can see, at offset 0×13b0 is socket_name. Based on the analysis of the last paragraph, we can guess that max_fd, parent_pid, and parent_alive_interval are stored in 12 bytes between offset 0×13a4 and 0×13af. Then one can ask, what are those 16 null bytes from offset 0×1394 to 0×13a3? I don’t know. If you know, please drop me a line. But I know for sure, idtable is stored in 36 bytes from offset 0×1370 to 0×1393, just right before those weird 16 null bytes.

The idtable array has 3 entries, one for each SSH protocol version. Each entry is an structure whose length is 12 bytes (hence 36 bytes for the whole array). When ssh-agent starts, each Idtab is initiated like this:

TAILQ_INIT(&idtable.idlist);
idtable.nentries = 0;

where TAILQ_INIT is a macro defined in sys/queue.h as following:

#define    TAILQ_INIT(head) do {
 (head)->tqh_first = NULL;
 (head)->tqh_last = &(head)->tqh_first;
} while (/*CONSTCOND*/0)

So after initiation, an Idtab structure would contain 1 zero integer for nentries, 1 null pointer for idlist.tqh_first, and 1 pointer for idlist.tqh_last which points back to idlist.tqh_first. Looking at the coredump, one can see that the first two Idtab entries of idtable don’t contain any key information because their nentries is 0. This is as expected, since SSH protocol 1 and 1.1 are long deprecated. The last entry of idtable is the Idtab of SSH protocol version 2. As one can see, its nenetries is 1, and we can guess that the pointer 0×0806E3B8 is pointing to an identity structure which contains 4 pointers and 2 integers. Let’s see if this is the case:

$ gdb /usr/bin/ssh-agent core.6261
Core was generated by `/usr/bin/ssh-agent'.
[New process 6261]
#0  0xb7f55424 in __kernel_vsyscall ()

(gdb) x/6x 0x0806E3B8
0x806e3b8:    0x00000000    0x0806297c    0x0806e158    0x0806e3a8
0x806e3c8:    0x00000000    0x00000000

(gdb) x/s 0x0806e3a8
0x806e3a8:     "id_rsa"

As you can see, the 4th pointer is comment. So the 3rd pointer should be key, i.e. it should point to a Key structure which contains 2 integers and 2 pointerss:

(gdb) x/4x 0x0806e158
0x806e158:    0x00000001    0x00000000    0x0806e170    0x00000000

If everything is correct, the pointer 0×0806e170 should point to a RSA structure:

(gdb) x/22x 0x0806e170
0x806e170:    0x00000000    0x00000000    0xb7ed5840    0x00000000
0x806e180:    0x0806e210    0x0806e228    0x0806e240    0x0806e288
0x806e190:    0x0806e270    0x0806e2b8    0x0806e2a0    0x0806e258
0x806e1a0:    0x00000000    0x00000000    0x00000001    0x0000000e
0x806e1b0:    0x00000000    0x00000000    0x00000000    0x00000000
0x806e1c0:    0x0806e950    0x00000000

How to be sure this is a RSA structure? Is there any known value to test? Fortunately, the answer is yes. If this is a RSA structure, the 6th pointer 0×0806e228 should point to a BIGNUM structure containing the value of the e parameter which should be 0×23, the default value that ssh-keygen uses for e. Let’s see:

(gdb) x/5x 0x0806e228
0x806e228:    0x0806e2e0    0x00000001    0x00000001    0x00000000
0x806e238:    0x00000001

(gdb) x/2x 0x0806e2e0
0x806e2e0:    0x00000023  0xb7d39150

Yay! We got it!

The next step is to extract all the parameters. It was not as easy as it sounds though. I spent quite a lot of time to read out the value of these parameters due to my ignorant of big-edian and little-edian storage. But I managed to get them out eventually. I generated the RSA private key from p and q, and used it to SSH into 67.202.60.164 which indeed gave me the key for challenge 7. I got my first breakthrough he he he.

That’s it. Thanks for reading.

Err…but how to generate RSA private key from n, d, e, p and q? I’m glad that you ask. Tools like openssl can not help in this case. You must write your own tool. I suggest you taking a look at ASN.1. There’s a very good tutorial here.

If you understand ASN.1, I’m pretty sure you’d know how to generate RSA private key from its parameters. You can use pyasn1 which is a very good ASN.1 library for Python. I can’t release my tool because it’s part of the upcoming CTF that I’m organizing. After that CTF, I’ll update this post with the tool.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Add to favorites
  • Reddit
  • Technorati
  • Tumblr
  • Twitter
  • Slashdot
  • Identi.ca

ISEC 2009 CTF Prequal – Challenge 4

August 27, 2009 by leenmie · Leave a Comment 

This was a funny challenge. Below are two pictures provided by the organizer. Just use a picture compare tool and look in to the girl’s boobs. There is nothing to say more.

Picture 1:

ISEC 2009 CTF Prequal Img1

ISEC 2009 CTF Prequal Img1

Picture 2:

ISEC 2009 CTF Prequal Img2

ISEC 2009 CTF Prequal Img2

Comparing the two pictures using Beyond Compare tool, the secret will be revealed.

Compare 2 Images

Compare 2 Images

The keyword is “OH, WTF” (the text on the pink girl boobs ^^,)

It’s really funny.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Add to favorites
  • Reddit
  • Technorati
  • Tumblr
  • Twitter
  • Slashdot
  • Identi.ca