Tor – Xác định các exit relay độc hại

August 14, 2014 by tienpp · Leave a Comment 

1. Mở đầu
Bài viết này là phần mô tả sơ lược và bình luận bài báo “Spoiled Onions: Exposing Malicious Tor Exit Relays”[1].
Tor exit relay là nút cuối dùng trong hành trình vận chuyển của các gói tin trọng mạng Tor, gói tin từ đây sẽ đi đến địa chỉ thực sự cần đến. Nó được vận hành bởi các người dùng tình nguyện trọng mạng và có thể nói tổng lưu lượng qua các exit relay này khá lớn (cỡ 1GB/s). Theo thiết kế, thì các người dùng ở các exit relay này có thể quan sát và thay đổi nội dung của các dữ liệu trong mạng.

Trong bài báo này, tác giả đề xuất các phương pháp để nhận ra các exit relay nào đang chơi bẩn và ghi lại những hành động của chúng. Họ xây dựng hai khung chương trình để phát hiện hoạt động bất thường của các exit relay. Một để chủ động phát hiện các hành động như thay đổi nội dung dữ liệu (Man in the middle), một là phần thụ động, để điều tra các exit relay sử dụng phương thức nghe lén (traffic sniff) để ăn cắp dữ liệu. Các giải pháp của tác giả được hiện thực chú trọng đến tính nhanh và hiệu quả trong quá trình quét các exit relay.

2. Khái quát hoạt động của mạng Tor

Hình trên là mô hình 3 nút của mạng Tor, dữ liệu từ một tor client bất kì bắt đầu hành trình trong mạng thì nó sẽ đi qua:

  1. Nút đầu (Entry guard): Đây này là nút đầu tiên trong hành trình của dữ liệu trong mạng.
  2. Nút giữa (Middle relay): là các nút trung chuyển dữ liệu trong mạng.
  3. Nút thoát (Exit relay): nút cuối hành trình của dữ liệu trọng mạng, đây là nút bắt cầu mà từ đây dữ liệu sẽ ra khỏi mạng mã hóa của Tor và đi đến đích nằm trong phần còn lại của thế giới – Internet. Dữ liệu – nếu có thể- sẽ bị nghe lén hoặc thay đổi ở nút này.

3. Giám sát các Tor exit relay:
Như đã nói ở trên, tác giả đã xây dựng hai khung chương trình nhằm giám sát các exit relay trong toàn bộ mạng Tor. Phần này chúng ta sẽ lần lượt đi qua quá trình thực hiện hai khung chương trình đó. Ngoài ra, tác giả có công bố mã nguồn của chúng ở đây[3].

3.1 exitmap:
Đây là khung chương trình thứ nhất tác giả hiện thực, nó sẽ giám sát chủ động các exit relay trong việc thay đổi nội dụng dữ liệu của người dùng trong mạng.

Thiết kế:

exitmap chạy trên một máy đơn lẻ, được xây dựng dựa vào thư viện python Stem – một thư viện hiện thực các giao thức Tor. Tác giả dùng Stem để khởi tạo và đóng các kết nối vào mạng. Bên cạnh đó cần một Tor client đang chạy để lấy các thông tin về các nút để biết đâu là các exit relay đang trực tuyến.

Hoạt động:

  1. Đầu tiên, exitmap lấy toàn bộ các exit relay từ Tor client đang chạy. Thực hiện chọn ra một exit relay ngẫu nhiên để kiểm tra.
  2. Khởi tạo một vòng (circuit) dữ liệu trong mạng Tor với exit relay là nút được lấy ngẫu nhiên từ 1.
  3. Giao tiếp với Tor client để vận chuyển dữ liệu.

Nâng cao hiệu năng của thiết kế:
Với mô hình và hoạt động của hệ thống ở trên, dữ liệu từ exitmap vào mạng Tor và đi lòng vòng qua rất nhiều nút khác rồi mới đến exit relay chọn sẵn, nên hiệu năng không cao. Trong khi mục đích của việc kiểm tra này hoàn toàn không đòi hỏi tính ẩn danh của Tor mang lại, nên tác giả đã cải tiến thêm hệ thống như sau.

Thay vì chạy lòng vòng trong mạng dẫn đến ảnh hưởng hiệu năng của việc kiểm tra, tác giả đề xuất mô hình: dữ liệu chỉ chạy qua một nút cố định rồi đi ngay đến exit relay.

Phần quét:
Dựa vào exitmap được xây dựng như trên, tác giả viết thêm các phần kiểm tra cho các giao thức như HTTPs, XMPP, IMAPs, SSH, phát hiện sslstrip và phân giải DNS giả tạo.
Các phần quét kiểm tra dựa trên các giao thức HTTPs, XMPP, IMAPs và SSH: đều được thực hiện thông qua việc kiểm tra chứng chỉ hợp lệ trả về khi dữ liệu đi qua mạng Tor. Một exit relay thực hiện MitM sẽ khiến cho chứng chỉ trả về không đúng như ý và từ đó phát hiện được hành vi MitM của exit relay đó.
Hình dưới tác giả cung cấp một đoạn mã giả mô tả phần đã nói ở trên:

Sslstrip: Thay vì cố gắng quan sát dữ liệu đã được bảo vệ với kết nối TLS, kẻ tấn công sẽ cố gắng chuyển các đường dẫn từ https về http, từ đó dữ liệu được chuyển dưới dạng hoàn toàn minh bạch, và kẻ tấn công dễ dàng lấy cắp các dữ liệu chúng muốn. Để phát hiện việc “downgraded” này, phần quét sslstrip cố gắng phát hiện trong dữ liệu HTML các đường dẫn bị thay đổi từ HTTPS thành HTTP.

Phân giải DNS giả mạo: Địa chỉ DNS cũng có thể được các client gửi đến exit relay để phân giải, việc này dẫn đến phía exit relay có thể giả mạo việc phân giải đó. Một mặt, các exit relay trong quá khứ có thể bị thiết lập sai khi dùng các DNS bị cản lọc – ví dụ như ở một số ISP ở Trung Quốc, Việt Nam, và một số nước châu âu. exitmap cũng sẽ phát hiện các phân giải DNS giả tạo này.

3.2 HoneyConnector:
Khung chương trình này được xây dựng để phát hiện thụ động một vài exit relay đang cố gắng quan sát dữ liệu (sniffing) của người dùng Tor. Việc quan sát các dữ liệu này hầu hết là trên các giao thức không được mã hóa như là FTP, IMAP.

Mô hình:

Khung chương trình này hoạt động như sau:
Từ Tor client liên tục gửi đi các yêu cầu login đến “Destination Server” là các FTP/IMAP server với các thông tin đăng nhập user/pass được tạo sẵn, đồng thời gửi các thông tin đó đến server đích.
Các thông tin đăng nhập trên được lưu trong database, bao gồm đã được gửi qua exit relay nào. Trong thời gian theo dõi (hàng tháng), nếu một thông tin đăng nhập nào đó được dùng để đăng nhập vào các FTP/IMAP server trên thì sẽ bị lưu lại và đối chiếu với thông tin trong cơ sở dữ liệu, tìm ra được exit relay nào đã tiến hành lấy cắp dữ liệu.

Phần còn lại của bài báo là các thông tin rút ra được từ kết quả kiểm tra của tác giả trong nhiều tháng liền. Trong phần đúc kết thông tin này, có nhiều thông tin rất thú vị, ví dụ như về một số nhóm chuyên đi lợi dụng các exit relay để sniffing, chèn thêm mã độc vào trang html, … Hình dưới liệt kê 40 exit relay mà tác giả đã kiểm tra được có hành vi nguy hiểm:

C:\A31D5665\347F1D4E-A7C2-4647-96EF-468158E00942_files\image006.png

Và các exit relay đã nghe lén để ăn cắp thông tin (đăng nhập) của người dùng Tor:

C:\A31D5665\347F1D4E-A7C2-4647-96EF-468158E00942_files\image007.png

Các bạn đọc thêm ở tài liệu trong phần 4, các phần phân tích kết quả còn lại.

Phần còn lại trong bài báo là các phát triển thêm của tác giả cho trình duyệt Tor browser, để có thể phòng ngừa nếu một exit relay nào đó đang MitM, mà không hiểu gì về trang cảnh báo của trình duyệt. Thay vì để trình duyệt hiện cảnh báo thì Tor sẽ tự xác minh và từ bỏ ngay exit relay đang MitM đó. Các bạn đọc thêm trong phần 6 của bài báo.

4. Tổng kết
Vậy dùng tor có an toàn không? Dù rằng bài báo đã cho thấy rằng có khả năng bị tấn công khi sử dụng Tor, tuy nhiên các tấn công này hoàn toàn là phòng ngừa được nếu như người dùng tôn trọng các nguyên tắc bảo mật (trong trường hợp bị MitM), và không dùng các giao thức cũ để đăng nhập (FTP/IMAP) để có thể dễ dàng bị đánh cắp dữ liệu.
Gần đây cũng có một nghiên cứu về Tor nữa, nhưng đã bị hủy bỏ trước khi trình bày ở hội nghị Blackhat USA. Nghiên cứu này về vấn đề nặc danh của Tor. [2]
Quay lại với bài báo, có cách nào có thể qua mặt được các kiểm tra như bài báo đã làm hay không. Và có cách nào để có thể ứng dụng vào Tor để phát hiện ngay tức thì các hành động gây hại ở exit relay và loại bỏ nó ra khỏi mạng. Mong các bạn thảo luận thêm :)

Tham khảo:

[1] https://petsymposium.org/2014/papers/Winter.pdf
[2] http://freedomhacker.net/tor-project-fixing-vulnerability-that-could-expose-users/
[3] http://www.cs.kau.se/philwint/spoiled_onions/

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

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