Messages posted by: boom_jt

Bạn có thể xem slides của tác giả để hiểu thêm về cách tấn công này :
http://cdn.ly.tl/talks/bad-memories.pdf
Nó nằm trong top 10 các kĩ thuật tấn công của năm 2010.

Ý tưởng là lợi dụng các library javascript thông dụng thường được chèn vào các trang web (ví dụ jquery, google analytic, etc.). Giả sử bạn kết nối đến 1 trang web thông thường (không có HTTPS), trang web này có sử dụng thư viện javascript google analytic. Lúc này attacker đóng vai trò man-in-the-middle sẽ trả lại cho bạn thư viện javascript trên được chèn thêm code của attacker. Browser sẽ lưu lại thư viện này trong cache.

Khi bạn kết nối đến 1 trang web HTTPS có sử dụng cùng thư viện javascript trên, browser sẽ gọi luôn thư viện này từ cache, chứ không kết nối đến server để lấy về nữa, vì nó tin tưởng nội dung trong cache. Như vậy, đoạn code javascript của attacker sẽ được load vào trang web, mặc dù nó được bảo vệ bởi HTTPS, i.e. mặc dù attacker không thể tấn công được đường truyền HTTPS, nhưng vẫn có thể chèn đoạn code của mình vào trang web một cách hợp lệ.

Tiếp đó khi đã có thể thực thi được javascript trong trang web, attacker làm gì tiếp thì bạn tìm hiểu thêm nhé. Mình đã nói điểm căn bản trong cách tấn công này rồi. Ngoài ra, cũng có thể có 1 số điểm mình chưa giải thích đầy đủ tường tận, bạn chịu khó đọc tài liệu nhé.

Ok, để boom_jt thử giải thích qua cách tấn công nhé, version đơn giản thôi, tất nhiên là lấy từ việc đọc hiểu paper :

BEAST mà mrro et al. (lol) tìm ra nhằm vào mã hoá đối xứng sử dụng CBC mode, tức là mã hoá theo khối, trong đó kết quả mã hoá của block trước sẽ được dùng để thay đổi kết quả mã hoá của khối tiếp theo.

Điều kiện thành công là attacker cài được 1 agent vào browser của victim. Agent này có khả năng yêu cầu browser thực hiện request HTTP và đọc nội dung request này. Agent này có thể đơn giản là 1 đoạn code javascript, cài vào browser theo cách tấn công XSS. Điều kiện tiếp theo là attacker phải bypass được SOA (same-origin policy) của browser, do đoạn code javascript không nằm trên cùng server với trang web HTTPS.

Các bước tấn công :
Attacker yêu cầu browser thực hiện request đến server HTTPS : POST /AAAAAA HTTP/1.1<CR><LF><REQUEST HEADERS><CR><LF><REQUEST BODY>

Nội dung browser gửi đến server sẽ có dạng C1|C2|C3|...|Cn là các khối được mã hoá. Trong đó
+ C1=encrypt("POST /AA")
+ C2=encrypt("AAAA HTT")
+ C3=encrypt("P/1.1<CR><LF><X>")
với <X> là kí tự đầu tiên của header tiếp theo.

Để ý rằng trong C3 này, thì 7 kí tự đầu tiên đều đoán được. Nhiệm vụ của attacker bây h để tìm ra <X> sẽ là yêu cầu browser gửi các khối [Cn.C2."P/1.1<CR><LF><Y>"] được mã hoá, với <Y> là 1 kí tự được phép trong header, sau đó so sánh đoạn mã hoá này với C3.

Chú ý rằng khi mã hoá khối B = "P/1.1<CR><LF><Y>" này, attacker phải thực hiện trước Cn.C2.B rồi mới yêu cầu browser gửi, do Cn ảnh hưởng tới kết quả mã hoá của block tiếp theo, còn C2 ảnh hưởng tới kết quả mã hoá của C3. Làm như vậy thì mới so sánh kết quả mã hoá của browser với C3 chuẩn xác được.

Khi attacker có được 1 đoạn mã hoá do browser gửi trùng với C3, đồng nghĩa với việc attacker giải mã được <X>

Như vậy, attacker chỉ cần liên tục thực hiện các request rồi so sánh, từ đó sẽ giải mã được nội dung request byte-by-byte. Với ví dụ như trên, chắc các bạn cũng đoán được request tiếp theo cần phải có dạng thế nào, để kí tự cần giải mã tiếp theo nằm đúng vào vị trí cuối cùng trong block.

Trong trường hợp demo của mrro, đó là việc giải mã lấy cookie (được gửi trong mọi request) của paypal để đăng nhập.

Như vậy, có thể nói attacker đã bypass được HTTPS, lợi dụng đường truyền và tính toán của browser để giải mã theo kiểu Chosen-plaintext attack mà không cần tấn công trực tiếp vào mã hoá.
(A. Shamir (the S in RSA) once said "Cryptography is typically bypassed, not penetrated", lol)

Có gì sai sót mong các bạn chỉ giáo. Và một lần nữa chúc mừng mrro smilie

Mình cũng vừa đọc được thông tin về BEAST xong, liền vào hva để đọc thêm. Chúc mừng mrro và đồng tác giả smilie

Ngoài ra các lỗi 0-day tìm được cũng không tệ chút nào nhé.

Mình đã thử và thấy đúng vậy, mình thêm một số dấu cách vào trước và sau password của mình và login và ok. Như vậy có thể phỏng đoán gmail dùng 1 hàm chuẩn hóa các input, loại bỏ các dấu cách trước và sau xâu nhập vào ...

Tuy nhiên đây có lẽ là 1 thiếu xót về mặt logic, khi người dùng nhập password không chính xác mà vẫn vào được tài khoản. Vấn đề đặt ra là liệu có thể khai thác thiếu xót này ko ?

Còn nếu bạn vẫn muốn alert XSS với cấu hình hiện tại thì thử cái này xem sao ^^

http://localhost/xss.php?name=<script>alert(/XSS/)</script>

file này có thể bị tấn công thông qua các lỗi như Arbitary File download, Local file inclusion, hay không loại trừ khả năng kẻ tấn công đã có sẵn shell, và đọc file này để lấy các thông tin cần thiết như user pass, csdl ...

về phòng chống, bạn có thể đặt nó ở 1 thư mục không phải mặc định, thậm chí đổi tên ... hoặc có thể mã hóa. Tuy nhiên cho đến giờ mình chưa thật sự thấy cách nào an toàn có thể phòng chống lại mọi trường hợp thì phải.

Khi bạn public web lên server, nội dung bạn đưa vào web.config sẽ được mã hóa. Vì vậy, nếu bạn muốn có thông tin được ghi trong file này, trước tiên bạn phải bẻ khóa được .NET 2.0 đã smilie

Vì vậy đây thật sự là cách tin cậy được.

Mình nói thêm chút, mật khẩu để trong csdl chưa hẳn đã là an toàn đâu smilie

nếu so sánh 2 trường hợp vừa nếu thì mình sẽ chọn giải pháp đầu ^^ tất nhiên còn tùy mục đích và trường hợp nữa smilie

uhm, là người đứng xem và nhận xét khách quan thì boom nói thế này:
- boom không thấy thái độ coi thường hay thù địch gì ở đây cả, antidos có thể hơi "nhạy cảm" chăng ^^
- một điểm lạ là antidos đã thực hiện thử nghiệm vài ba lần, trong khi hva lúc nào cũng có mem truy nhập, trong số đó hẳn phải có một vài mod, nhưng chưa thấy ai xác nhận hva bị từ chối dịch vụ cả. Bằng chứng đưa ra chỉ là 1 link tới host-tracker, bằng chứng này liệu có đáng tin cậy?
- Từ lúc antidos bắt đầu thread tới giờ, có lẽ không chỉ boom, mà nhiều người cũng đoán già đoán non xem cách thức tấn công, và việc muốn antidos chia sẻ là chuyện hoàn toàn tự nhiên. Cũng phải nói thêm là nếu đây là điều đúng, thì nó có thể không chỉ nguy hiểm cho hva, hay một trang web nói riêng nào đó, mà hoàn toàn có thể đánh sập hệ thống mạng toàn cầu (hi vọng boom không nói quá). 1 lỗi đã tồn tại, antidos không phát hiện ra, sẽ có người khác phát hiện ra. Hi vọng antidos hiểu điều boom định nói, giữ riêng cho mình không để ai biết không phải là cách hay, nhưng công bố thế nào cũng cần suy nghĩ thận trọng.
Thân

Bác conmale thử check log tại chính xác thời điểm này xem sao : 06/02 19:33:22 (giờ vn, tức là +0700 nhé)
Boom thấy ghi trên hosttracker như vậy, có vẻ khá hợp với thời gian gửi bài của antidos - 06/02/2009 19:39:31 (+0700)

Vấn đề cần phải phân biệt :

SessionID là 1 chuỗi NGẪU NHIÊN được sinh ra bởi WEBSERVER chứ không phải là 1 giá trị nào đó mà ứng dụng web có thể quyết định. Vì vậy, mỗi lần user đăng nhập (hoặc bắt đầu từ 1 hành động nào đó khiến cho ứng dụng web sử dụng tới session), user được cấp 1 SessionID ngẫu nhiên, KHÔNG THỂ ĐOÁN TRƯỚC bởi ứng dụng web cũng như người dùng web.
Câu trả lời cho câu hỏi cuối là "không"

Đây khuyến mại anh em cái link mediafire nhé

http://www.mediafire.com/download.php?gmm4nk4f5jg

zerozeroone wrote:

... mỗi Ethernet frame có kích thước tối thiểu là 64 bytes (đã bao gồm phần Ethernet trailer 4 bytes) hoặc 60 bytes (không bao gồm phần Ethernet trailer 4 bytes) hoặc 46 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes) và kích thước tối đa là 1500 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes).
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

hi,
boom làm rõ thêm ý này chút bằng 1 quote từ TCP/IP illustrated nha:

There is a minimum size for 802.3 and Ethernet frames. This minimum requires that the data portion be at least 38 bytes for 802.3 or 46 bytes for Ethernet. To handle this, pad bytes are inserted to assure that the frame is long enough.

Như vậy trong trường hợp này (Ethernet), số byte padding sẽ là 46 - 28 (cho ARP) = 18 hoàn toàn khớp với gói tin quanta đã capture.

Hic bồ "@boom_jt" và trả lời như thế thì tôi nghĩ bồ chưa hiểu ý tôi rồi. Tôi đặt 1 câu hỏi không với mục đích mong trả lời mà để bồ ngộ ra điều khác kìa.

Hi vọng link sau, chưa thật rõ ràng lắm, nhưng sẽ giúp bạn hiểu thêm về cách lưu cookie của IE
http://search.cpan.org/~gaas/libwww-perl-5.814/lib/HTTP/Cookies/Microsoft.pm

chưa rõ ý bác lamer lắm, nhưng giữa "file thực thi" và web page có khác nhau đó ^^ .
Tương tự, "chương trình của hắn" và chương trình bạn cài trong máy cũng có khác nhau mà smilie

ai chà, nổi ghê ! Cái này post vào box "Thông tin new bugs và exploits" có lẽ đúng và có ích hơn. Ngoài ra thì hình như bkis không phải là đầu tiên tìm ra lỗi của Chrome, nhưng lỗi này critical nhất tính cho tới nay.

ok bạn cứ change, 1 ông nội nào đó có thể tìm không ra, vậy xin hỏi trình duyệt làm thế nào để tìm ra? Hi vọng bạn hiểu ý mình.
IDM theo mình biết thì chạy trên Windows, chứ không chạy trên Mac hay Linux gì gì đó. Và giả sử nếu có muốn viết 1 chương trình download có chức năng tương tự trên các OS này thì phải dựa trên môi trường của nó chứ. Đây là điều đương nhiên, bạn đưa ra cái "thì sao" này thừa và sai rồi.
Ý thứ 3:

ham_choi wrote:

Và IDM không hỗ trợ đọc cookies

Bạn thử cài wireshark (hay ethereal) và thử xem nhé, khẳng định vội vàng quá

^^ mình thì không nghĩ admin rs làm thế nào đâu, chỉ là IDM nó có khả năng đọc cookie của Internet explorer thôi bạn ạ. Việc tìm ra địa chỉ lưu cookie trong máy đâu phải là không thực hiện được.

Cho mình hỏi bạn "dán" vào IDM thế nào được không?

boom trả lời được cho bạn câu hỏi 1 nha ^^
Cơ chế hoạt động của acc premium của rapidshare rất đơn giản. Nó không hề dựa trên IP của khách hàng, mà chỉ dựa vào cookie. Nó tạo biến cookie tên là user với nội dung là [mã khách]-[mật khẩu ở dạng URL encoded].
Như vậy bạn chỉ cần login 1 lần bằng trình duyệt là những lần sau sẽ được download tự động.

Trường hợp bạn chỉ cần đưa link rapidshare vào IDM mà nó tự động chuyển thành link cho bạn download trực tiếp thì mình chắc rằng bạn đã sử dụng chức năng "Sites logins" của IDM (Download -> Options -> Sites Logins -> New ...)

Thân

jforum3000 wrote:

...Mình đã kiểm tra lại mã nguồn forum phpBB3 của mình, cũng như view source ở trang HTML kết quả trả về từ web server ...

Có thể bước này bạn làm chưa thật tốt chăng. Hoặc giả cũng có thể máy nào đó trên dải server của bạn bị virus arp ... (trong trường hợp này thì view kết quả html cũng phải tìm thấy smilie

) Bạn check lại các giả thiết này xem, check thêm là server có đảm bảo ko nhé, hàng xóm thăm nhau mà mình chả biết là khổ đó

Nếu ko ngại thì pm cho mình link web của bạn nha, mình nghía thử xem smilie

bạn có thể dùng _SERVER["HTTP_REFERER"]... tham khảo thêm phpinfo là thấy liền smilie

watchd0g wrote:

Các bước "kiểm tra đuôi của file? kiểm tra header của file? kiểm tra trọn bộ nội dung file?" đều có cách giả dạng 1 phiên upload để đưa lên server file mong muốn. Theo em nên kết hợp với việc hạn chế user truy cập trực tiếp vào file vừa upload, điều này có thể dễ dàng thực hiện:
- Dời những file upload sang 1 thư mục không phải là web root (theo ví dụ của anh comale thì web root là public_html)
or
- Hạn chế user truy cập vào upload folder trên web root directory.
or
- Đổi tên file upload bằng 1 chuỗi ngẫu nhiên.

Đây chính là cách mà 1 số code 4rum áp dụng, và ko phải là "or", mà họ dùng "and" smilie

Vậy điều gì xảy ra nếu filename được truyền lên có dạng ../filename.php trong khi ta vẫn cho phép upload php và chỉ quan tâm đảm bảo an toàn cho thư mục uploads ? ^^

Hi, thanks anh PXMMRF đã cập nhật thông tin,

File mp3 "gốc" thì có thể down ở đây trong trường hợp server của anh có lúc không "ngon" smilie

http://media.techtarget.com/audioCast/SECURITY/SecurityWireWeekly08062008.mp3

Còn đây là : Security Wire Weekly: Dan Kaminsky on the DNS flaw
http://media.techtarget.com/audioCast/SECURITY/SecurityWireWeekly07_16_08.mp3

xanh: chưa chắc do nhà cung cấp đâu bạn, mình đã từng gặp trường hợp có admin để cả thông tin bàn giao host trên server của mình và có directory listing -> ko còn gì để nói !

@anh conmale:

conmale wrote:

... Nói chung, một khi đã có một cái bash shell thì cơ hội bị escalate lên root khá cao.

Khi nào rảnh anh có thể làm 1 bài tổng hợp về vấn đề này được ko ạ? Theo suy nghĩ và hiểu biết hiện tại của em thì nó không đến nỗi "khá cao", phụ thuộc vào nhiều yếu tố mà (trong đó tất nhiên có yếu tố cá nhân người thâm nhập nữa ^^ )