thái

(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ôn

Cập nhật: bạn nào quan tâm đến lỗ hổng này có thể tham gia thảo luận ở đây . Một phát hiện hết sức thú vị : The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an “authentication gap” exists during the renegotiation process at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS. Thú vị ở chỗ bao nhiêu người, bao nhiêu chuyên gia, bao nhiêu năm qua dòm vô TLS/SSL mà không thấy được lỗ hổng có vẻ như rất hiển nhiên mà các tác giả ở trên phát hiện. Có lẽ nguyên nhân nhiều người dòm nhưng không thấy là vì họ chỉ dòm TLS/SSL khi nó đứng một mình, mà không nhìn vào bức tranh lớn OSI, tron

(nên đọc nếu tiền làm bạn đau đầu :-D) mình thấy mình thiếu kiến thức nghiêm trọng, hay nói cách khác, cực kỳ ngu dốt, về chuyện quản lý tài chính cá nhân. đi làm 7 năm, làm *chuyên nghiệp* 5 năm, vậy mà nhìn lại tài chính thì rối tung, tài sản thì chỉ được mỗi mụn sách, còn đầu tư thì bỏ lỡ quá trời cơ hội. giá mà có ai đó nói cho mình biết việc quản lý tài chính này nó quan trọng đến cỡ nào thì có lẽ tình hình đã tốt hơn rất nhiều rồi. ít nhất là không bị mất ngủ vì cái sự ngu dốt của mình. thôi, bỏ qua. giờ biết mình ngu cũng chưa có muộn lắm. bắt đầu học lại vậy. ---- mình có lời khuyên cho các bạn đang muốn thấu chi (dành cho các bạn không làm ngân hàng: thấu chi là vay tiền ngân hàng, để có thể rút vượt quá số tiền còn lại trong tài khoản). mình nói hoài àh, giờ nhắc lại lần cuối: đừng bao giờ thấu chi! nếu mà mấy năm vừa rồi, các bạn vẫn sống được, thì không cần thấu chi, các bạn vẫn có thể sống tốt. kinh nghiệm thấu chi của mình đau đớn lắm nha. làm nguyên năm, đến cuối n

Challenge 8 is a trivial format string bug, but one needs neat shellcode to get the flag. 1. Analysis First thing first: $ file t1g3rd t1g3rd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.15, dynamically linked (uses shared libs), not stripped t1g3rd is a regular network service that when executed would listen on port 7384. When a client comes in, the binary forks a new child process, and calls a function named handleClient . At the begining of handleClient , t1g3rd calls setrlimit(2) to disallow this child process to open new file or fork a new process. This makes the binary a perfect example to illustrate how to write neat shellcode using inlineegg :-D. handleClient then goes on to read two inputs, which are 19 bytes long and 512 bytes long respectively, from the client. The first input is sent back to the client using printf(3) , and the second is just discarded. 2. Vulnerability As one can guess, the printf(3) call at 0x08048c52 t

Last week or so I joined CLGT to take part in HackJam 2009 by Sapheads. AFAIK this is the first CTF that Sapheads organizes, but they had done a very good job. To most people's surprise, the contest attacted quite a lot of teams from around the world, and it had quickly become an international competition. Did I tell you that we're the winner ? Ha ha ha this is our very first win since the name CLGT was born. BTW, HackJam 2009 was a success because Sapheads had kept their promise which is to "provide challenges that greatly resemble real world scenarios and environments, at the same time, adding fun and educational ingredients to them". We really had fun ^_^, not disturbing pains *_*, in solving the challenges. Thank you Sapheads! We're looking forward to HackJam 2010. I promised to some people in #sapheads that I would release some writeups about the challenges after the contest ended, and here they are. Sorry for the delay, I have been busy working with v

Flickr's API Signature Forgery Vulnerability Thai Duong and Juliano Rizzo Date Published: Sep. 28, 2009 Advisory ID: MOCB-01 Advisory URL: http://netifera.com/research/flickr_api_signature_forgery.pdf Title: Flickr's API Signature Forgery Vulnerability Remotely Exploitable: Yes 1. Vulnerability Description Flickr is almost certainly the best online photo management and sharing application in the world. As of June 2009, it claims to host more than 3.6 billion images. In order to allow independent programmers to expand its services, Flickr offers a fairly comprehensive web-service API that allows programmers to create applications that can perform almost any function a user on the Flickr site can do. The Flickr's API consists of a set of callable methods, and some API endpoints. To perform an action using the Flickr's API, you need to select a calling convention, send a request to its endpoint specifying a method and some arguments, and will receive