|
 |
 |
 |
 |
Đăng Kí | Hỏi/Đáp | Danh Sách | Lịch | Bài Trong Ngày | Tìm Kiếm |  |
|
||||||||
|
||||||||
|
Chia Sẽ Kinh Nghiệm Về IT
  |
 |
|
Công Cụ | Xếp Bài | |
08-08-2011, 10:06 AM
|
#1 |
|
Guest
Trả Lời: n/a
|
Truy tìm thủ phạm hack website(Phần 1,2)
Truy tìm thủ phạm hack website(Phần 1,2) P/S : Sưu tầm đọc thấy rất hay,mang về cho anh em (những ai chưa đọc hiểu thêm về thế giới oép mát tơ Truy tìm thủ phạm (1) Hello bà con, Mấy tháng nay công việc bù đầu, rồi thêm HVAOnline up/down liên tục thành ra thaidn tui chẳng viết được một bài nào cho “ra đầu ra đũa” cả. Cách đây 2h đồng hồ, một người bạn gọi điện cho hay là website của anh ấy vừa bị deface, nhờ tui tìm hiểu thử xem sự thể như thế nào. Sẵn máu forensic đã có trong người từ rất lâu, tui hâm hở nhận lời. Vầ dưới đây là toàn bộ câu chuyện -0-… Trước khi bắt đầu, xin cho tui được “tâm sự” vài lời. Mặc dầu rất mê cái món forensic nhưng mà đây là lần đầu tiên tui có cơ hội phân tích, điều tra một vụ xâm nhập (chẳng biết hên hay xui nữa  ). Tui đã đọc qua một số cuốn sách nói về computer forensic và tự thấy rằng phương pháp mà tui áp dụng ở dưới đây là rất thiếu bài bản và sự chuyên nghiệp cần có trong công tác điều tra, do đó rất mong nhận được sự đóng góp, chỉ bảo từ các anh chị có nhiều kinh nghiệm trong lĩnh vực này. Vấn đề thứ hai mà tui muốn đề cập là đạo đức trong việc kinh doanh. Mong là những người đứng ngoài sau phá phách này ngộ ra được và chấm dứt những hành động bẩn thỉu của mình trước khi quá muộn. Ok, dài dòng xong rồi, giờ chúng ta bắt đầu.Ngay khi nhận được tin báo, việc đầu tiên tui yêu cầu bạn tui phải làm là đổi hết tất cả các mật khẩu, từ mật khẩu email cá nhân, mật khẩu tài khoản quản trị diễn đàn cho đến mật khẩu root trên server cũng như các tài khoản khác; đồng thời giữ nguyên hiện trạng server-1- cho đến khi tui truy cập vào nó để điều tra. Đây là hai phản ứng cơ bản mà tui đọc được trong các cuốn sách nói về incident response. Tui nhanh chóng hoàn thành các bài tập gym rồi chạy về nhà và truy cập vào server liền. Tui cho là trong những trường hợp như thế này, thời gian giữ một vai trò rất quan trọng, càng sớm tiếp cận được hiện trường vụ án thì cơ hội thu thập được nhiều thông tin giá trị càng cao. Đó là một dedicated server chạy LAMP -2-, đặt tại Mỹ, bạn tui thuê của một công ti Việt Nam để host một diễn đàn khá lớn về âm nhạc. Trao đổi với anh bạn, tôi được biết là vụ tấn công xảy ra lúc khoảng 4h-5h chiều. Bình thường khi user truy cập vào trang chủ, họ sẽ tự động được chuyển sang diễn đàn, nhưng chiều nay file index.html của anh đã bị thay đổi với nội dung như sau: hacked by cana_ximuoiCó một cái gì đó bất thường, tui chợt nghĩ. Nếu như kẻ xâm nhập đã có nhã ý muốn nhắc nhở bạn tôi cần phải quan tâm hơn đến vấn đề bảo mật thì tui nghĩ họ đã không chọn cách làm thiếu văn hóa như thế này. Còn nếu như kẻ xâm nhập có dụng ý phá hoại thì chắc hẳn họ đã phô trương bản thân và chửi bới nhiều hơn, điều thường gặp ở những người nghĩ là họ thông minh hơn người khác. Dẫu là ai đi chăng nữa, với hành động deface như vầy, có vẻ kẻ xâm nhập không phải là một tay cừ khôi, âu cũng là một điều đáng mừng  .Vừa login vào server, tui liền chạy lệnh: # dateLệnh thứ nhất cho tui biết ngày giờ trên server, từ đó tui sẽ tính ra được độ chênh lệch giữa múi giờ trên server và múi giờ ở Việt Nam, trong trường hợp này là 14 giờ, nghĩa là server được đặt ở vùng GMT -7. Đây là một yếu tố cực kì quan trọng, nó sẽ giúp ích rất nhiều trong công tác event correlation -3-. Như vậy, nếu tính theo giờ server, chắc hẳn website của bạn tui đã bị deface trong khoảng Mar 21 02:00:00 GMT -7 đến Mar 21 03:00:00 GMT -7. Lệnh thứ hai cho tui biết ai đã truy cập vào máy chủ kể từ Fri Mar 3 11:02:19 2006. Dòng đầu tiên cho thấy một người truy cập vào lúc Tue Mar 21 07:22 và vẫn còn đang ở trong server. Kẻ đó chính là…tui. Chà, ngoài tui ra, chẳng có ma nào ssh vào server trong ngày Mar 21 cả. Như vậy có vẻ kẻ xâm nhập không vào server (và từ đó thay đổi nội dung file index.html) qua đường ssh. Một câu hỏi tự nhiên được đặt ra: ngoài ssh, còn có con đường nào khác đi vào server này? Trước đây, tui đã có vài lần giúp giải quyết sự cố trên server này thành ra nó cũng tương đối quen thuộc với tui. Ngoài ssh ra, server này còn chạy các dịch vụ: cpanel, ftp (sử dụng pureftpd), smtp/pop3 (sử dụng exim) và http (sử dụng apache). Đó là nói về dịch vụ, về phía user thì ngoài root và yeahlap như đã thấy ở trên, server này còn một user là hippie. Có hai website được host trên server này, mỗi website tương ứng với hippie và yeahlap. Website bị deface chính là website của hippie. Ngó nghiêng qua /etc/passwd thì tui thấy: yeahlapChà, user hippie không có shell -4-! Phản xạ tự nhiên, tui chạy: # ls -l /home/hippie/public_html/index.htmlChà, file index.html này có permission là 644 với owner là hippie, mà thằng hippie lại chẳng có shell, vậy muốn thay đổi nó thì thằng attacker phải hoặc a) chiếm được quyền root trên serverhoặc b) lấy được password user hippie rồi thông qua ftp để upload file lên. Đó là hai hướng tấn công mà tui nghĩ đến đầu tiên. Tui nghiêng về hướng thứ hai hơn, đơn giản vì như tui đã nói, tui không nghĩ kẻ xâm nhập là một tay lành nghề đủ khả năng chiếm được quyền root trên server. Nếu hắn chôm được password root thì hằn cũng chẳng thể ftp vào được server bởi vì mặc định các ftp daemon đều không cho phép account root đăng nhập. Mà như đã thấy ở trên, chẳng có ma nào ssh vào server trong ngày 21/03/2006 trừ tui ra. Dĩ nhiên khi có quyền root thì kẻ xâm nhập có thể xóa sạch tất cả những dấu vết mà hắn để lại trên server, nhưng chẳng ai dày công làm như vậy chỉ để hăm dọa một người không rành về máy tính như bạn của tui. Bạn tui cho biết ngày 20/03/2006, anh có ra chơi ở tiệm cafe Thụy Du trên đường Lý Chính Thắng, chỗ đó nổi tiếng là có nhiều “hacker”, cho nên khả năng bị ai đó chôm mật khẩu là rất lớn. Một tay rỗi hơi nào đó cài vài ba con keylogger lên các máy tính ở Thụy Du và rồi vô tình vớ được mật khẩu của hippie khi bạn tui upload file lên server. Là một Google “hacker”, hắn chẳng biết làm gì với một cái account của một server Linux, hắn bèn “mua vui” bằng cách deface cho bỏ công chôm chia. Nghe cũng hợp lý chứ nhỉ? Tui có sử dụng pure-ftpd từ trước nên biết rõ là thằng này nó lưu thông tin log vào thẳng syslog /var/log/messages. Tui vớ lấy cái đám /var/log/messages* “nóng hổi”, rồi chạy các lệnh sau: # cat /var/log/messages | grep index.html | grep “Mar 21″Lệnh trên giúp tui lấy ra tất cả những dòng thông báo của pure-ftpd có liên quan đến file index.html trong ngày 21/03/2006. Kết quả như mọi người đã thấy, đầu tiên vào lúc Mar 21 04:17:45 (nghĩa là khoảng 6h chiều giờ VN) file index.html được download xuống, rồi sau đó nó được upload lên liên tục hai lần vào lúc Mar 21 04:18:13 và Mar 21 04:18:35. Những con số được tô màu chính là kích thước của file index.html tại từng thời điểm. Như vậy đã rõ, cả 3 lần upload/download này đều là do bạn tui thực hiện sau khi website bị deface. Lần đầu anh download file index.html đã bị sửa đổi, file này có kích thước là 206 byte. Lần hai và ba anh upload lại file nguyên mẫu ban đầu, có kích thước là 702 byte. Chà, sao chẳng thấy ai upload file index.html có kích thước 206 byte lên hết nhỉ? Để chắc ăn, tui kiểm tra mớ log file lại một vài lần nữa nhưng vẫn không tìm thấy bất cứ thông tin gì liên quan đến file index.html ngoài 3 lần ở trên. Tui bắt đầu hoang man, phải chăng tui đã đánh giá quá thấp đối thủ của mình? (còn tiếp) — Ghi chú -0-: Thật ra tôi đã cố tình chỉnh sửa, thêm thắt, làm cho câu chuyện hấp dẫn và dài thêm một chút để tiện trình bày những điều tôi muốn gửi đến người đọc. -1-: Lẽ ra lời khuyên phải là tắt server đó ngay. Những chứng cứ trên server sẽ trở nên vô nghĩa trước pháp luật nếu như server vẫn tiếp tục hoạt động ngay sau khi bị phát hiện tấn công. Tuy nhiên trong trường hợp này, do anh bạn tôi chỉ có một server duy nhất và anh ấy cũng không có ý định kiện tụng ai cả, nên tôi chỉ yêu cầu anh ta không được thay đổi gì trên server. -2-: LAMP là thuật ngữ dùng để chỉ các server chạy hệ điều hành Linux, website Apache, máy chủ database MySQL và sử dụng PHP để làm web-application. -3-: event correlation là quá trình chỉ ra sự tương quan giữa ra các sự kiện khác nhau trên các thành phần khác nhau trong cùng một hệ thống hoặc trên các hệ thống khác nhau. Sự tương quan này sẽ giúp cho điều tra viên có được cái nhìn toàn cảnh về những gì đã diễn ra trên toàn hệ thống trước, trong và sau vụ tấn công. Có được thông tin về múi giờ chính xác là điều kiện tiên quyết để có thể tiến hành công tác event correlation. -4-: shell tương ứng với khả năng đăng nhập và làm việc (thông qua rsh hoặc ssh) trên một server *nix. Có shell trên một server nghĩa là có khả năng đăng nhập và làm việc trên server đó và ngược lại. Truy tìm thủ phạm (2) Tui hoang mang vì một lẽ con đường khả dĩ nhất đi vào server, phù hợp nhất với những giả định và lập luận của tui không phải là con đường mà kẻ xâm nhập đã chọn. Điều làm tui lo lắng nhất chính là khả năng kẻ xâm nhập là một tay cao thủ và hắn đang chơi trò “mèo vờn chuột”. Đối mặt với một tay có khả năng “lai vô ảnh, khứ vô hình” là một điều thú vị nhưng tui e rằng mình vẫn chưa đủ “cao tay ấn” để mà “chơi” với hắn. Khi đó điều tệ hại nhất không phải là không xác định được ai là thủ phạm mà là xác định nhầm đối tượng. Thật sự từ khi bắt đầu điều tra, mặc dù tui luôn giả định kẻ xâm nhập là một tay mơ nhưng thú thật tui chưa bao giờ tin tưởng tuyệt đối những gì mà mình thấy trên server. Trong đầu tui tồn tại hai tư tưởng: a) cứ phân tích dựa theo những gì mình thấy để nhanh chóng tìm ra thủ phạm; b) paranoid, paranoid, paranoid, thủ phạm đang lừa mình vô tròng đó! Vì nôn nóng và hiếu thắng nhất thời, tui đã chọn cách làm thứ nhất để rồi lâm vào tình trạng bế tắc. Phải paranoid! Tui đã được “dạy dỗ” như vậy từ khi mới chân ướt chân ráo mày mò học bảo mật. Tui bắt đầu rà soát lại điểm mấu chốt trong lập luận của mình. Nhắc lại, vì file index.html có permission mode là 0644 với owner và group là hippie/hippie mà user hippie lại không có quyền shell nên tui đã suy ra rằng chỉ có hai hướng để kẻ xâm nhập thay đổi file này: a) chiếm được quyền root trên server; b) lấy được password user hippie rồi thông qua ftp để upload file lên ghi đè file index.html. Như mọi người đã thấy ở phần 1, giả thuyết b) mà tui đưa ra (và hết sức tin tưởng) đã hoàn toàn phá sản. Như vậy chỉ còn lại khả năng kẻ xâm nhập đã chiếm được quyền root trên server. Có thể đơn giản bằng cách nào đó (cài keylogger trên máy tính ở Thụy Du chẳng hạn), kẻ xâm nhập chôm được mật khẩu root của server, hoặc phức tạp hơn, hắn khai thác một lỗi bảo mật nào đó trong cái đám service đang chạy hoặc trong chính cái kernel mà server đang sử dụng. Bằng cách nào đi chăng nữa thì việc kẻ tấn công chiếm được quyền root là hết sức nguy hiểm. Có thể ngay lúc này đây, thông qua một con rookit -5- nào đó, hắn đang ung dung theo dõi những bước điều tra của tui từ đầu đến giờ và cười sảng khoái khi thấy tui lâm vào đường cùng. Tui thót giật mình khi nghĩ đến điều rất-có-khả-năng-là-sự-thật này  (! Tui nhanh chóng download, cài đặt và chạy bộ công cụ chkrootkit. Chẳng có rootkit nào được phát hiện trên server. Một câu hỏi được đặt ra, liệu kết quả này có đáng tin hay không? Ai biết được kẻ cao thủ mà tui đang đối mặt đã có kế hoạch ứng phó với chkrootkit từ trước hay không? Nói như vậy không có nghĩa là chkrootkit hoàn toàn vô dụng, ít nhất nó cho tui biết khả năng mà kẻ xâm nhập là một “đại cao thủ” là cực thấp.Có rất nhiều loại attacker, thượng vàng hạ cám đều có đủ. Loại attacker có khả năng chiếm quyền root trên server rồi cài đặt rootkit có sẵn lên đó thì nhiều, nhưng loại attacker có khả năng đánh lừa cả chkrootkit thì tui cho là rất ít. Cộng thêm yếu tố là người VN và hành động deface nữa thì chắc chẳng còn ai. “OK, cứ tạm tin tưởng vào kết quả chkrootkit đi xem sao”, tui tự nhủ. Như vậy trên server không có rookit, và chkrootkit cũng thông báo cho tui biết là lastlog -6- và wtmp -7- chưa hề bị chỉnh sửa. Như vậy có thể tạm tin vào thông tin từ lệnh last mà tui đã chạy ở trên. Tui thử chạy tiếp: # lastlogNhư vậy có thể thấy chỉ có 3 user từng ssh vào server là root, yeahlap và clamav. Tui nhanh chóng kiểm tra user clamav # cat /etc/passwd | grep clamavChà lạ nhỉ, user clamav này chẳng có shell mà sao lastlog lại thông báo là nó đã login vào server lúc Thu Feb 16 20:29:59 -0700 2006? User clamav chắc hẳn dùng để chạy ClamAV, phần mềm GPL chống virus trên mail server rất nổi tiếng. Mail server được sử dụng trên server là Exim, chắc thằng này đi kèm với Cpanel. Tui đoán không sai, có cả SpamAssassin để chống spam nữa. Hiện tại trên server đang chạy clamd daemon, nó chẳng listen trên tcp/ip socket nào mà sử dụng unix domain socket nằm ở /var/clamd. Thằng ClamAV này được cài đặt từ source, do đó một giả thuyết được đặt ra là tay Administrator lúc tạo user clamav đã cho user này một cái shell, một cái password (vẫn còn nằm trong /etc/shadow). Sau khi đã hoàn thành việc cài đặt, tay Admin mới bỏ cái shell đó đi, và disable luôn cái account bằng lệnh passwd -l clamav (bằng chứng là field chứa password trong /etc/shadow có kí tự “!” đứng đầu). Chắc hẳn tay Administrator làm theo một cái HOWTO nào đó. Có thể tạm tin tưởng là vậy bởi thời điểm 16/02/2006, bạn tui vẫn chưa tiếp nhận server này. Bạn tui cho hay anh ấy order server này hồi đầu tháng 02/2006 và đến khoảng 20/02/2006 thì bên công ti hosting mới setup xong và giao server lại cho anh. Như vậy chỉ còn 2 user là root và yeahlap đã từng truy cập vào server. Thông tin output của lastlog cũng rất phù hợp với output của last. Shell của yeahlap: # cat /etc/passwd | grep yeahlapJailshell hưh? Search một vòng trên Google thì thấy như vầy: Jailshell is a very limited shell that allows clients to logon to your server via SSH. It limits them to their home directories, keeping the rest of your files on your server from being viewed. Use caution when giving users shell accounts on your server, as it’s likely possible to breakout of the jailshell.Đọc cái dòng “it’s likely possible to breakout of the jailshell” nghe thấy ớn quá. Như vậy cũng có khả năng kẻ xâm nhập chôm được mật khẩu yeahlap từ cafe Thụy Du, login vào server qua ssh, rồi “breakout of the jailshell”, tiếp theo là get root, và deface. Tui tổng kết lại các khả năng có thể xảy ra: a) chôm mật khẩu root, login vào server rồi deface b) chôm mật khẩu yeahlap, login vào server, break out of jailshell, get root rồi deface. c) khai thác một lỗi nào đó trong các service chạy trên server hoặc ngay chính cái kernel đang được sử dụng, get root rồi deface Còn gì nữa không ta? Tui chợt nhớ đến scp và sftp -8-. Số là tui không có cảm tình với ftp, nên mặc dù trên server có ftp service nhưng do thói quen, tui sử dụng scp để chép một số file log về desktop để tiện tìm hiểu và chợt nhật ra một thiếu sót là kẻ tấn công vẫn còn một hướng khác: d) chôm mật khẩu root, sử dụng scp ghi đè lên file index.html để deface. Đây chỉ là 4 trong số rất nhiều khả năng khác có thể xảy ra, tui tự nhủ. (còn tiếp) Bật mí kì cuối: chu choa ơi, thằng attacker nó chẳng sử dụng cái cách nào trong 4 cách trên hết. Ai đó thử đoán xem nó làm thế nào để deface mà: không có quyền root và user hippie không có shell? —chú thích— -5-: rootkit là thuật ngữ dùng để chỉ những phần mềm giúp kẻ xâm nhập che dấu tung tích của hắn khi “ẩn mình” trong một hệ thống máy tính nào đó. Tham khảo th http://en.wikipedia.org/wiki/Rootkit -6-: tham khảo “man lastlog” -7-: tham khảo “man last” -8-: sftp là một phần của bộ giao thức ssh, giúp truyền file một cách an toàn bằng cách mã hoá dữ liệu truyền đi trên mạng. Trích ThaiDn HVAonline  |
|
|
|
|
Chế độ bình thường
