thái

Trong lần trước, khi bàn về các công ty Paypal-made-in-VN , tôi có nhắc đến ý: khó khăn lớn nhất mà tất cả các công ty e-payment gặp phải không phải đến từ kỹ thuật, mà chủ yếu đến từ khó khăn trong việc thuyết phục các nhà băng kết nối với họ. Đến giờ, sau hơn 2 tháng làm việc với khá nhiều công ty e-payment, tôi nhận ra rằng, không phải các nhà băng muốn gây khó dễ cho các công ty e-payment, mà chủ yếu sản phẩm - công nghệ của các công ty này vẫn chưa đủ sức thuyết phục nhà băng. Ngân hàng tôi đang làm việc khá cởi mở trong việc kết nối với các công ty e-payment, nếu sản phẩm - công nghệ của các công ty này đáp ứng được các tiêu chí mà đội ngũ kỹ thuật - nghiệp vụ của chúng tôi đưa ra, chúng tôi sẵn sàng kết nối với họ. Tuy vậy, hầu hết các công ty e-payment đều không thành công trong việc thuyết phục chúng tôi. Mô hình của quá trình xử lý e-payment. Đối với thẻ credit card, giữa Payment Gateway và Banking Network còn có thêm hệ thống của Visa, Master hay các hãng credit card khác. K

Sáng nay tôi có một cuộc họp với một đối tác, là một công ty muốn triển khai dịch vụ e-payment, tương tự như Paypal nhưng dành riêng cho dân VN. Trong số rất nhiều đối tác tôi đã gặp và làm việc trong gần vài năm gần đây, đối tác lần này là những người thực sự hiểu rõ và có kiến thức chuyên sâu về security nhất, thành ra nói chuyện cũng dễ dàng hơn. Họ gồm 3 người, một VP of Product Manager, một CTO và một CEO. Hai anh PM và CTO đều là Việt kiều, từng nhiều năm sống và làm việc ở Silicon Valley. Nói tiếng Anh theo giọng Mỹ chuẩn, kiến thức chuyên môn sâu và thật sự am hiểu về lĩnh vực mà họ đang làm. Trước đó tôi có nhận được email từ bà CEO, gửi thông tin về BOM của đối tác. Toàn là những tên tuổi mà tôi đã được nghe nói nhiều, ví dụ như Mr. Trung Dung , Mr. Kien Pham (VEF)...Anh PM trẻ măng ở trên hóa ra là một người mà tôi đã từng rất hâm mộ hồi mới học máy tính, hèn gì mặt nhìn quen quen. --- Nhìn chung business model của họ không mới và technology của họ cũng không có nhiều đột ph

Hôm nay vô tình tìm lại được một bài khá "nhí nhố" được tôi viết cách đây hơn 3 năm. Đọc lại thấy vui vui, dùng social engineering để đi...tán gái cũng hiệu quả ghê :-d. ---- Phần I: Ta đã bị đánh cắp! Một ngày đẹp trời, ta đang online và say sưa chat trên Yahoo! Messenger, tự nhiên có một tên nhảy vào gửi message cho ta. Một cái nick lạ hoắc. Nhưng trời ạ, làm sao hắn biết tất tần tật về ta, từ tên (có cả họ và chữ lót), tuổi (có cả ngày tháng năm sinh), chiều cao, cân nặng cho đến sở thích và luôn cả... độ cận nữa! Chuyện gì đã xảy ra vậy trời? Ta đã bị hack! Quá đỗi ngạc nhiên, ta tiếp tục chat với hắn. Hắn thú nhận với ta là vào một đêm mưa gió trở trời, hắn đã “đụng độ” với ta trên Moviesboom (trang web dành cho những fan của điện ảnh), nơi ta thường lui tới để xem thông tin về phim ảnh. Ấn tượng với cách nói chuyện của ta, cộng với một tí tò mò cùng kỹ năng điêu luyện của một tay hacker, hắn đã bới tung Internet để tìm cho ra được ta là ai. Và hắn đã thành công một

Không cần DNS Rebinding vẫn có thể scan port bằng ActionScript 3.0: In AS3 Adobe introduced a new socket-related event called SecurityErrorEvent. This event is always thrown when a Flash Player tries to connect to a socket that it is not allowed to connect to. The Problem with the SecurityErrorEvent is that it's thrown immediately when a Flash Player tries to connect to a closed TCP port. If a service is listening on that port the Flash Player writes the string " " and waits for response from the service. Nearly no TCP-service will respond to this request. We can assume the following: When trying to connect to a socket that the SWF is not allowed to and it doesn't get a SecurityErrorEvent within 2 seconds the port is most likely open. A new Flash player instance is used for every probed port because the Flash Player sends only one policy-file request per player per host per port.

Stanford Security Lab vừa công bố một tài liệu miêu tả khá đầy đủ DNS Rebinding Attacks (loại attack mà tôi trình bày ở VNSECON07 ): DNS rebinding attacks subvert the same-origin policy and convert browsers into open network proxies. These attacks can circumvent firewalls to access internal documents and services require less than $100 to temporarily hijack 100,000 IP addresses for sending spam and defrauding pay-per-click advertisers

Đây là slide về đề tài tôi trình bày tại VNSECON07 . Các địa chỉ demo sẽ vẫn còn hiệu lực cho đến hết ngày 04/08/2007. ----- Theo quan sát của tôi, nhìn chung ngày đầu tiên của VNSECON07 diễn ra hơi lộn xộn vì cách tổ chức chưa được tốt cho lắm. Tuy vậy, xin mọi người hãy cho BTC một tràng pháo tay, bởi tổ chức được những sự kiện như thế này không phải là dễ. Về các presentation, do buổi sáng bận việc nên tôi không tham dự được. Nghe bạn bè nói lại, bài nói chuyện của van hauser về IPv6 khá rõ ràng và dễ hiểu. Còn về bài logical fuzzing, nhiều người cho biết họ không hiểu nên bỏ về trước. Đây cũng là vấn đề chính của các presentation, đa số các speaker đều rất nhiệt tình, tuy nhiên có một số bài hơi sâu và không có thông dịch viên, thành ra người nghe không tiếp thu được nhiều. Đầu giờ chiều tôi có nghe được 2 bài về ".NET attacks" và "Automating Exploitation". Gọi là nghe nhưng do ngồi xa và không có sự chuẩn bị trước về máy móc nên đến giờ tôi cũng không nhớ đượ

Tương tự như nhiều ngành nghề khoa học kỹ thuật khác, lĩnh vực bảo mật ở VN vẫn còn khá tụt hậu so với thế giới bên ngoài. Đây cũng là mục tiêu chính của hội thảo VNSECON07 (diễn ra trong hai ngày 03-04/08/2007 tại Nhà thi đấu Phú Thọ Tp.HCM): đưa giới an ninh mạng VN xích lại gần hơn với thế giới bên ngoài. Sự khác biệt của VNSECON07 Nếu bạn quan tâm đến tình hình an ninh mạng, chắc hẳn bạn cũng biết rằng, năm nào ở VN cũng có tổ chức một vài hội thảo bảo mật. Đa số các hội thảo này do một số công ty tổ chức với mục đích quảng bá sản phẩm, vì thế chất lượng của chúng luôn là đề tài gây nhiều tranh cãi. VNSECON07 là một hội thảo hoàn toàn khác. Thay vì định ra trước danh sách các bài tham luận sẽ được trình bày như các hội thảo khác, BTC VNSECON07 đã gửi “Call For Papers” từ tháng 3/2007 để kêu gọi sự tham gia viết tham luận của các chuyên gia bảo mật từ khắp nơi trên thế giới. Sau gần 3 tháng, tổng cộng đã có hơn 30 bài tham luận được gửi đến. Dựa trên số bài này, Hội đồng chuyên môn

BTC VNSECON07 đã công bố lịch làm việc của VNSECON07 . Hội thảo sẽ diễn ra trong hai ngày, 03-04/08/2007 tại Nhà thi đấu Phú Thọ, Tp.HCM. Có tổng cộng 20 bài tham luận , được chia ra trình bày liên tục trong hai ngày, theo hai phiên sáng chiều. Phiên buổi sáng tập trung vào các đề tài trong business track, bắt đầu lúc 8h. Phiên biểu chiều tập trung vào các đề tài trong technical track, bắt đầu lúc 13h. Riêng ngày 03/08, phiên buổi chiều sẽ có hai tham luận được trình bày song song với nhau. Song song với hội thảo là cuộc thi Capture the Flag , các đội đến đăng ký và dự thi ngay tại chỗ với BTC. Tôi có tham gia trình bày đề tài "Biến trình duyệt web thành zombie thông qua Flash Player 9", vào lúc 16h ngày 03/08 tại phòng 041. Xin kính mời mọi người tham dự!

Cập nhật mới : các menu ở www.tuoitre.com.vn giờ đã trở thành clickable, có vẻ như họ rất quan tâm đến những gì tôi viết ;). Hôm nay vào www.tuoitre.com.vn, tôi thấy họ lại thay đổi thiết kế của menu. Bản thân tôi nghĩ rằng thiết kế mới này là một bước lùi đáng kể so với thiết kế cũ mà tôi đã phân tích trước đây . Chỗ không hay nhất trong thiết kế này là unclickable menu . Tôi không thể click trực tiếp vào các menu như "Thế giới" hay "Thể Thao", mà tôi phải rê chuột vào các menu này, rồi sau đó rê chuột xuống các submenu bên dưới và click vào các submenu này. Điều này sẽ đem lại rất nhiều phiền toái cho tôi: Thứ nhất , để đọc được tin tức trong một chuyên mục nào đó, tôi phải thực hiện tổng cộng 3 thao tác, thay vì chỉ 1 thao tác nếu như các menu là clickable. Đó là chưa kể một vài submenu còn sổ ra một dropdown menu nữa, tôi buộc phải click vào chúng thêm một lần nữa. Khi số lượng thao tác tăng lên, nghĩa là xác suất tôi - người sử dụng - gây ra lỗi hoặc phải suy

Nhắc lại phần đầu , máy chủ Oracle của một khách hàng mặc dù có đến 32G RAM và 16CPU nhưng vẫn thường xuyên bị treo vì quá tải. Tôi được giao nhiệm vụ tìm hiểu nguyên nhân và nhờ sự hỗ trợ của Oracle Metalink , tạm thời tôi đã tìm ra đầu mối liên quan đến Hugepages. HugePages là một tính năng được giới thiệu từ phiên bản Linux kernel 2.6. Linux sử dụng page như là đơn vị cơ bản của bộ nhớ - bộ nhớ vật lý được phân chia và truy cập theo từng page. Kích thước mặc định của một page trong kiến trúc x86 là 4KB, trong ia64 là 16KB, nghĩa là nếu tôi có 32G RAM, Linux sẽ tự động chia lượng RAM này thành 2^21 page, một con số khổng lồ. Hugepages, như tên gọi của nó, giúp Linux tăng kích thước mỗi page lên, nhằm mục đích giảm số lượng page. Với kiến trúc x64, khi sử dụng Hugepages, mỗi page sẽ có kích thước lên đến 256MB, nghĩa là nếu tôi có 32RAM, Linux chỉ cần chia ra 128 hugepage là đủ. Trước khi đi vào chi tiết những lợi ích của Hugepage, ta hãy cùng điểm qua hai thành phần rất quan trọng

Hôm nay tôi có một case khá thú vị. Một khách hàng gọi điện, báo server của họ đặt ở FPT Telecom (chỗ 64-66 Võ Văn Tần Q.3) bị phía FPT Telecom ...tắt mất vì có quá nhiều traffic đi vào server này, có thời điểm lên đến 100Mbs. Họ nhờ tôi đến FPT Telecom trực tiếp kiểm tra xem nguyên nhân tại sao có quá nhiều traffic đến server. Trên đường đi, tôi được biết server của khách hàng tôi không hề bị treo hay gặp vấn đề gì cả, chỉ có...firewall của FPT Telecom (nếu tôi đoán không lầm là Checkpoint trên Windows) lại bị treo khi phải tiếp nhận và xử lí lượng traffic lớn như thế; thành ra toàn bộ các server nằm phía sau con firewall này coi như bị cách ly với thế giới bên ngoài. Bên FPT Telecom cũng đã thông báo cho khách hàng của tôi rồi, nhưng khách hàng của tôi lại không biết cách kiểm tra thế nào, thế mới xảy ra chuyện FPT Telecom buộc lòng tắt server và disable cái switch port luôn. Đến chỗ FPT Telecom, đợi gần 15' đám bảo vệ mới cho vào, rồi leo thang bộ lên đến tận tầng 5, tôi muốn ná

Liên tục trong tuần này tôi nhận được tổng cộng 5 email từ các công ty VDC Hà Nội, VDC Tp.HCM, PAVietnam và NetNam. Ngoại trừ một email có tiêu đề là "Thử phát nữa" (??!!) từ VDC Tp.HCM, tất cả các email còn lại đều...khuyên tôi nên chuyển các tên miền .vn tôi đang sở hữu ở VNNIC sang công ty của họ. Dĩ nhiên tất cả đều không quên quảng cáo về công ty cũng như dịch vụ "ưu việt" mà họ hứa hẹn sẽ cung cấp cho tôi, nếu tôi đồng ý với đề nghị của họ. Đây rõ ràng là hành động spamming và các công ty kể trên chính là spammer, bởi lẽ tôi không muốn và không đăng ký để nhận email quảng cáo từ họ. Tuy vậy, chuyện các công ty kể trên đi spam khách hàng đã là chuyện thường ngày ở huyện, không có gì mới cả. Chuyện mới ở đây là tại sao các công ty này lại có thông tin về tên miền và địa chỉ email của tôi? Phải chăng VNNIC đã bán thông tin khách hàng cho spammer?

VietnamNet vừa có đăng một bài nhan đề Thư rác Việt Nam vào thời "loạn"! Dịch vụ gửi thư rác ở Việt Nam đã lên đến mức "chuyên nghiệp". Ngay tại Hà Nội, đã có hàng chục công ty công khai tên tuổi, danh tính tuyên bố sẵn sàng gửi thư rác thuê với số lượng hàng triệu e-mail mỗi ngày Nhìn chung bài báo đưa ra được những cảnh bá o cần thiết về tình trạng bùng phát của việc gửi spam ở VN. Tuy vậy tôi thấy có vài điểm cần bàn ở đoạn cuối của bài báo này: Ai là người chịu thiệt? Tất nhiên là người dùng! Năm 2005, một trong những nhà cung cấp dịch vụ Internet ở Việt Nam từng bị thế giới xếp vào danh s ách có số lượng spam mail ở mức báo động, và các doanh nghiệp sử dụng dịch vụ của ISP này sau đó không thể gửi thư điện tử ra nước ngoài vì bị chặn . Đương nhiên người dùng mới là những người chịu thiệt đầu tiên. " Thời gian gần đây, số thư rác tiếng Việt bùng phát gây ra những phiền toái và thiệt hại cho công ty chúng tôi rất nhiều, có hôm, cả cơ quan bị nghẽn mạng và kh

Câu trả lời là ngồi càng gần đuôi máy bay càng có nhiều cơ hội sống sót nếu xảy ra tai nạn:

Hôm rồi một khách hàng thông báo website của họ cứ chập chờn, lúc vào được, lúc lại không. Tôi vào kiểm tra thì thấy web-server của họ hoàn toàn ổn, duy một điều coi log lại không thấy kết nối nào đến được web-server cả. Loay hoay một hồi, khách hàng mới báo cho biết rằng họ có sử dụng một con squid làm reverse proxy đứng trước web-server, mục đích là để cache lại static content. Tôi vào kiểm tra con squid này thì phát hiện trong log của nó phun ra khá nhiều lỗi. Google cho biết đây là những lỗi khá nghiêm trọng và cũng có đưa ra vài giải pháp, nhưng do tôi không có nhiều kinh nghiệm với squid thành ra loay hoay mãi mà vẫn không sao giải quyết được. Tôi quyết định tạm thời stop con squid này lại, tìm một giải pháp thay thế. Ban đầu tôi định sử dụng Apache để làm reverse proxy do tôi có nhiều kinh nghiệm với thằng này. Tuy vậy, giải pháp này khá mất thời gian mà con reverse proxy này cũng sẽ bị "kết liễu" trong vài ngày tới, nên tôi quyết định sử dụng chức năng NAT của iptabl

(bạn Lê Quỳnh, phóng viên VNN, có hỏi ý tôi về việc đăng bài này lên VNN, và tôi đã đồng ý. Các bạn có thể xem ở http://vietnamnet.vn/giaoduc/2009/03/833719/). Câu hỏi nào là khó trả lời nhất khi phỏng vấn xin việc? Không biết đối với người khác thì như thế nào, đối với tôi đó chính là câu "thế anh đề nghị mức lương bao nhiêu?". Từ trước đến giờ, không kể các dạng làm theo hợp đồng, tôi có apply vào tổng cộng 3 công ty. Hầu như lần nào tôi cũng đề nghị một mức lương thấp hơn tôi dự tính rồi nhận một mức lương thấp hơn tôi xứng đáng được nhận. Công ty đầu tiên đầu tiên của tôi là FPT Telecom, hồi cuối năm 2003. Lúc người phỏng vấn hỏi câu trên, tôi đã rất thành thật khai báo mất lương hiện tại của tôi là 2.500.000/tháng (lúc đó tôi làm cộng tác viên cho Tuổi Trẻ Online) và chỉ muốn nhận bằng khoản lương đó. Bài học đầu tiên : mỗi lần đổi công việc là mỗi lần phải được tăng lương, nghĩa là bạn phải yêu cầu một mức lương cao hơn công việc cũ, coi như là chi phí để làm quen với m

Cách đây hơn 2 tháng, một khách hàng của tôi có một project rất quan trọng: nâng cấp máy chủ database từ Oracle 9i lên Oracle 10g cho hệ thống core-banking của họ. Mọi việc diễn ra tốt đẹp cho đến ngày đưa hệ thống vào production. Cứ chạy chừng 30' là con server "hàng khủng" 16 CPU Intel Itanium 2 + 32G RAM "sụm bà chè". CPU idle 0%, ssh vào còn không được, huống hồ chi là chạy Oracle. Họ liên hệ với tôi để tìm cách cứu chữa (tôi vốn có làm dự án core-banking này từ trước). Việc đầu tiên tôi làm là...nhất nút reboot máy chủ. Dẫu biết đối với hệ thống database, việc hard reset như thế là điều tối kỵ, nhưng lúc đó quả thật tôi chẳng còn lựa chọn nào khác để giải thoát máy chủ ra khỏi tình trạng treo cứng, đành phải gửi trọn niềm tin vào Larry Ellison, hi vọng "bé" Oracle sẽ tự phục hồi sau khi reboot (thật ra vẫn còn một giải pháp dự phòng nếu Oracle không thể tự phục hồi được nên tôi mới tự tin vậy). Sau khi reboot, tôi bắt đầu chuẩn bị một mớ công

Ý tưởng Dựa vào gợi ý của Amit Klein : Notice the first limitation of the technique - it states that no raw CR and LF can be placed in the body section. This means that the technique cannot be used to send (POST) requests whose body complies with the "multipart/form-data" content-type format (this format uses raw CRs and LFs to mark headers and boundaries). In other words, a (POST) request whose body is a valid "multipart/form-data" stream is guaranteed (as far as today's knowledge extends) not to be sent from a Flash player. Web application authors can therefore use HTML forms whose ENCTYPE attribute is set to "multipart/form-data", and enforce that the submission contains a valid multipart/form-data body. Once these mechanisms are in place, and a request passes through, it is known not to originate from a Flash player, so the attack described here is irrelevant. Gợi ý ở trên có thể được diễn giải như sau: Cách thức browser xử lí các HTML form có e