giam sat an ninh mang

HomeBlogPapersToolsAbout Us

VNSECURITYContact UsCLGT TeamHow to JoinSite Map

Capture The Flag / CLGTMiscSecurity

Anti-VirusCryptographyExploitationFirewallForensicHardeningLegal IssuesMalware / Rootkit / Hostile CodeMobile SecurityPhysical SecurityReverse EngineeringSoftware SecurityVulnerabilitiesWeb Security

Site NewsVNSECON

Tiếng Việt

Posts CommentsYou are here: Home / Blog / Tiếng Việt

Giám sát an ninh mạng – hay là làm thế nào đểngăn chặn một cuộc tấn công DDoS trong 20′December 14, 2009 by thaidn · Leave a Comment

(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′

Tiếng Việt : VNSECURITY / CLGT TEAM http://www.vnsecurity.net/c/tieng-viet/page/2/

1 of 14 5/31/2013 3:43 PM

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ôngtừ 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êntụ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ị đangthấ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ôngdữ 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êngấ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ông này, và đưa toàn bộ hệ thống trở lại tình trạng bình thường. Chúng tôi làm được như vậy tất cả lànhờ vào việc đã áp dụng tốt các công nghệ và nguyên tắc của giám sát an ninh mạng.

Nếu quý vị từng phải xử lý một vụ tấn công DDoS, tôi tin chắc có một câu hỏi mà quý vị đã phải tự hỏi nhiềulần: chuyện gì đang diễn ra vậy? Tại sao hệ thống của tôi đang chạy ngon lành tự dưng lại cứng đơ, kháchhàng không sử dụng được nữa?

Bản thân tôi cho rằng đây là câu hỏi tối quan trọng mà bất kỳ ai làm việc trong lĩnh vực an ninh mạng đềuphải tự hỏi và phải có câu trả lời xác đáng. Ngay tại thời điểm này đây, ngay khi quý vị đang ngồi ở đây nghetôi trình bày, quý vị có biết ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị hay không?

Tại sao câu hỏi đó quan trọng? Tại sao quý vị cần phải biết được ai đang làm gì ở đâu như thế nào trên hệthống của quý vị? Đơn giản vì chúng ta không thể bảo vệ một hệ thống nếu chúng ta không biết được trạngthái của hệ thống đó. Và chúng ta chỉ có thể biết được trạng thái của một hệ thống bằng cách theo dõi nóthường xuyên. Nói cách khác, chúng ta phải biết được tất cả các hoạt động đã và đang diễn ra trên hệ thống.

Thử nhìn vào hoạt động của một khách sạn. Để đảm bảo an ninh, người ta phải đặt camera theo dõi ở khắpnơi. Các camera này chắc hẳn sẽ đưa hình ảnh về một địa điểm tập trung, nơi có các chuyên viên theo dõi24/7 để kịp thời phát hiện và đối phó với các sự cố an ninh.

Tương tự như thế, muốn đảm bảo an ninh thông tin chúng ta cũng phải tiến hành theo dõi 24/7. Nhưng trong


2 of 14 5/31/2013 3:43 PM

thực tế, theo quan sát của tôi, rất ít tổ chức ở VN có một hệ thống giám sát an ninh như thế. Để bảo vệ hệthống mạng của mình, các doanh nghiệp và các tổ chức công thường triển khai các thiết bị như tường lửa,phần mềm chống và diệt virus, thiết bị phát hiện xâm nhập, thiết bị ngăn chặn xâm nhập. Rõ ràng họ nghĩrằng, các thiết bị này đảm bảo an ninh mạng cho họ nên họ mới đầu từ nhiều tiền của để triển khai chúng.

Thật tế hầu hết những người giữ quyền quyết định đầu tư cho an toàn thông tin thường hay hành động theothị trường. Ví dụ như cách đây vài năm, tường lửa là mốt. Ai cũng đầu tư làm hệ thống tường lửa nên chúngta cũng phải làm tường lửa. Sau đó, các giải pháp phát hiện xâm nhập lên ngôi. Bây giờ cái gì đang là trào lưuquý vị biết không? ISO 27001.

Lãnh đạo doanh nghiệp thấy các các doanh nghiệp khác triển khai ISO 27001 nên họ cũng muốn doanhnghiệp của họ phải đạt được chuẩn này. Tôi không nói rằng tường lửa, thiết bị phát hiện xâm nhập hay đạtđược các chuẩn như ISO 27001 và ITIL là không có tác dụng, nhưng câu hỏi chúng ta cần phải tự hỏi là: tạisao sau khi triển khai quá trời thứ đắt tiền và tốn thời gian như thế, chúng ta vẫn bị xâm nhập, chúng ta vẫn bịtấn công? Liệu ISO 27001 hay tường lửa có giúp bạn khắc phục được một vụ tấn công từ chối dịch vụ trongvòng 20′? Rồi khi đã bị xâm nhập, có thiết bị đắt tiền hay tiêu chuẩn nào giúp quý vị biết được hệ thống củaquý vị bị xâm nhập khi nào, tại sao và như thế nào hay không?

Chỉ có con người mới có khả năng làm việc đó. Đây là điều tôi muốn nhấn mạnh, các thiết bị hay các tiêuchuẩn sẽ trở nên vô tác dụng nếu chúng ta không có con người thường xuyên theo dõi, giám sát hệ thống.Nghĩa là, chúng ta cần các chuyên gia giám sát hệ thống có chuyên môn cao.

Tại sao chúng ta cần phải có chuyên gia, tại sao tự bản thân các thiết bị hay các tiêu chuẩn không thể bảo vệhệ thống mạng? Bởi vì những kẻ tấn công rất thông minh, không thể dự đoán và rất có thể có động lực caonhất là khi thương mại điện tử phát triển như bây giờ. Máy móc và quy trình không thể ngăn chặn được họ,chắc chắn là như thế. Máy móc chắc chắn sẽ thua khi chiến đấu với não người. Đó là lý do chúng ta cần conngười, cần những chuyên gia, để biến an ninh mạng thành một cuộc chiến cân sức hơn giữa người và người,thay vì giữa máy và người.

Câu hỏi đặt ra là các chuyên gia an ninh mạng cần gì để có thể phát hiện và xử lý các sự cố an ninh mạngcũng như xây dựng các kế hoạch phòng thủ? Câu trả lời chỉ có một: tất cả dữ liệu mà chúng ta có thể thu

thập được trên hệ thống mạng trong khi sự cố xảy ra!

Quý vị còn nhớ ví dụ của tôi v/v làm sao để bảo vệ an ninh cho một khách sạn? Người quản lý cố gắng thuthập tất cả các dữ liệu, ở đây là hình ảnh và âm thanh, bằng các camera đặt khắp nơi trong khách sạn, và họcần có các chuyên gia lành nghề để phân tích các hình ảnh này để kịp thời xử lý các sự cố. Họ có hệ thốngchống và phát hiện cháy, họ có hệ thống chống trộm, nhưng những máy móc đó chỉ là công cụ, phần việcchính vẫn phải do con người, là các chuyên gia thực hiện.

Tóm lại, để đảm bảo an ninh, chúng ta cần phải theo dõi giám sát hệ thống mạng 24/7, và để làm chuyện đóchúng ta cần có các chuyên gia và các chuyên gia cần dữ liệu để thực hiện công việc của họ. Giám sát anninh mạng chính là phương thức giúp chúng ta có thể thực hiện việc này một cách tối ưu nhất. Vậy giám sátan ninh mạng là gì?

Thuật ngữ giám sát an ninh mạng được chính thức định nghĩa vào năm 2002 và về cơ bản nó gồm 3 bước: thu

thập dữ liệu, phân tích dữ liệu và leo thang thông tin.

Để thu thập dữ liệu, chúng ta sẽ sử dụng các phần mềm hay giải pháp có sẵn trên thị trường để thu thập dữliệu ghi dấu hoạt động của các máy chủ, thiết bị mạng, phần mềm ứng dụng, cơ sở dữ liệu…Nguyên tắc củathu thập dữ liệu là thu thập càng nhiều càng tốt, với mục tiêu là chúng ta phải có đầy đủ thông tin về trạngthái, log file của tất cả các thành phần trong hệ thống cần phải bảo vệ. Bởi vì có muôn hình vạn trạng các loạitấn công và sự cố ATTT, chúng ta không thể biết trước dữ liệu nào là cần thiết để có thể phát hiện và ngăn


3 of 14 5/31/2013 3:43 PM

chặn loại tấn công nào. Nên kinh nghiệm của tôi là nếu mà luật pháp và công nghệ cho phép, cứ thu thập hếttất cả dữ liệu mà quý vị có thể. Nguyên tắc “thà giết lầm còn hơn bỏ sót” có thể áp dụng ở đây.

Nếu phần mềm có thể giúp chúng ta làm công việc thu thập dữ liệu, thì để phân tích dữ liệu và ra quyết định,như đã nói ở trên, chúng ta cần có chuyên gia, bởi chỉ có chuyên gia mới có thể hiểu rõ ngữ cảnh của dữ liệumà phần mềm đã thu thập được. Ngữ cảnh là tối quan trọng. Một dữ liệu được thu thập trong ngữ cảnh A cóthể sẽ có ý nghĩa rất khác với cùng dữ liệu đó nếu nó thuộc về ngữ cảnh B. Ví dụ như một ngày đẹp trời hệthống thu thập dữ liệu cảnh báo rằng một số file chương trình trên một máy chủ quan trọng đã bị thay đổi.Nếu như xét ngữ cảnh A là máy chủ đó đang được nâng cấp phần mềm, thì thông tin này không có nhiều ýnghĩa. Nhưng nếu như ở ngoài ngữ cảnh A đó, nói cách khác, không có một yêu cầu thay đổi phần mềm nàođang được áp dụng cho máy chủ đó cả, thì rõ ràng rất có thể máy chủ đó đã bị xâm nhập. Và chỉ có nhữngchuyên gia mới có thể cung cấp được những ngữ cảnh như thế.

Quy trình giúp cho chúng ta leo thang thông tin. Leo thang thông tin là việc các chuyên gia báo cáo lên trêncho những người có quyền quyết định những vấn đề mà họ cho là quan trọng, cần phải điều tra thêm. Nhữngngười có quyền quyết định là những người có đủ thẩm quyền, trách nhiệm và năng lực để quyết định cách đốiphó với các sự cố ANTT tiềm tàng. Không có leo thang thông tin, công việc của các chuyên gia sẽ trở thànhvô ích. Tại sao phải phân tích để phát hiện các sự cố ANTT tiềm tàng nếu như chẳng có ai chịu trách nhiệmcho việc xử lý chúng?

Quay trở lại với câu chuyện vụ tấn công từ chối dịch vụ mà tôi chia sẻ ban đầu. Hệ thống giám sát an ninhmạng của chúng tôi thu thập tất cả dữ liệu liên quan đến hoạt động của các thiết bị như tường lửa, máy chủproxy, máy chủ web, các ứng dụng web chạy trên các máy chủ web. Dựa vào nguồn dữ liệu phong phú này,các chuyên gia của chúng tôi đã không mất quá nhiều thời gian để phân tích và nhận ra các dấu hiệu bấtthường trên hệ thống. Họ leo thang thông tin bằng cách thông báo cho tôi, và tôi quyết định kích hoạt quátrình đối phó với sự cố ANTT, ở đây là đối phó khi bị tấn công từ chối dịch vụ.

Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninhmạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không màkhông phải thực hiện thêm bất kỳ thao tác nào. Về mặt hành chính, tôi thông báo cho lãnh đạo doanh nghiệpvà các đơn vị như Trung Tâm Chăm Sóc Khách hàng, Trung tâm Vận hành Data Center cũng như mở kênhliên lạc với các ISP để nhờ họ trợ giúp nếu như đường truyền bị quá tải. Như quý vị đã thấy trong một slide ởphía trước, chỉ chưa tới 20′, vừa ngay sau lần kích hoạt hệ thống phòng thủ đầu tiên, vụ tấn công đã đượckiểm soát thành công. Hệ thống giám sát an ninh mạng cũng giúp chúng tôi làm các báo cáo để gửi lãnh đạocũng như gửi các cơ quan điều tra nhờ hỗ trợ truy tìm thủ phạm.

Toàn bộ phương thức giám sát an ninh mạng chỉ đơn giản như thế. Đến đây là chúng ta xong phần 1 của bàitrình bày này. Tiếp theo tôi sẽ chia sẻ một số thông tin về hệ thống cũng như công tác giám sát an ninh mạng.

Về mặt kỹ thuật, chúng tôi không mất quá nhiều thời gian cho việc thiết kế hệ thống và lựa chọn giải pháp,bởi vì ngay từ đầu chúng tôi đã xác định đây là một lĩnh vực tương đối mới mẻ, thành ra một giải pháp hoànchỉnh sẽ không có trên thị trường. Thay vào đó, giống như phát triển phần mềm theo nguyên lý agile, chúngtôi làm vừa làm vừa điều chỉnh.

Chúng tôi khởi đầu bằng việc xây dựng một hệ thống log tập trung. Như đã nói ở trên, đây là công đoạn thuthập dữ liệu. Trong quá trình làm, chúng tôi nhận thấy hầu hết các ứng dụng chạy trên nền UNIX hay cácthiết bị mạng đều hỗ trợ sẵn chuẩn syslog, thành ra chúng tôi quyết định chọn phần mềm mã nguồn mởsyslog-ng làm công cụ chính để thu thập log.

Tuy nhiên có hai vấn đề: các máy chủ Windows mặc định không hỗ trợ syslog; và một số ứng dụng do chúngtôi tự phát triển hay mua ngoài cũng không hỗ trợ syslog. Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm mộtphần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi. Đối với vấn


4 of 14 5/31/2013 3:43 PM

đề thứ hai, việc đầu tiên chúng tôi làm là xây dựng một quy định về log của các ứng dụng. Trong quy định nàychúng tôi yêu cầu tất cả các ứng dụng muốn được cấp quyền chạy trên hệ thống của chúng tôi thì phải thỏamãn các tiêu chí về log các sự kiện. Chúng tôi cũng hướng dẫn và cung cấp thư viện phần mềm mẫu để cáclập trình viên có thể tích hợp vào phần mềm có sẵn của họ.

Syslog-ng là một phần mềm mã nguồn mở tuyệt vời. Nó hoạt động cực kỳ ổn định, bền vững. Trong suốt hơn3 năm triển khai hệ thống này, chúng tôi chưa bao giờ gặp sự cố ở phần mềm này. Nhưng syslog-ng cũng chỉlàm tốt nhiệm vụ thu thập dữ liệu, làm sao phân tích dữ liệu đó? Trên thị trường lúc bấy giờ có khá nhiều côngcụ giúp giải quyết vấn đề này. Chúng tôi lần lượt thử nghiệm các công cụ này, và rồi chúng tôi phát hiện raSplunk. Chúng tôi hay gọi phần mềm này là “Splunk toàn năng”. Một công cụ phân tích dữ liệu trên cả tuyệtvời!

Splunk rất hay, nhưng nếu không có các chuyên gia có kỹ năng phân tích dữ liệu để khai thác Splunk thì hệthống cũng sẽ không đem lại nhiều ích lợi. Cái hay của Splunk là ở chỗ nó đã làm cho công việc phân tích logtưởng như nhàm chán trở nên cực kỳ thú vị. Chỉ trong một thời gian ngắn, nhân viên của tôi đã bị Splunk mêhoặc. Cái tên “Splunk toàn năng” cũng là do anh ấy đặt cho Splunk. Thành ra chúng tôi cũng không mất quánhiều thời gian để huấn luyện, bởi vì tự bản thân giải pháp nó đã đủ thú vị để cuốn hút con người chủ độngtìm hiểu nó.

Điều tối quan trọng nhất đối với một hệ thống giám sát an ninh là khả năng phân tích một lượng dữ liệu lớnmột cách nhanh chóng. Splunk làm rất tốt việc này. Tuy vậy trên thị trường vẫn có các giải pháp khác hoàntoàn miễn phí như tôi liệt kê ở trên. Bản thân tôi cho rằng Hadoop + Scribe + Hive là một hướng nghiên cứunhiều tiềm năng.

Với hệ thống này, bây giờ chúng tôi có thể an tâm rằng tôi có thể biết được chuyện gì đang diễn ra trên hệthống mạng của các khách hàng của chúng tôi ngay tại thời điểm tôi đang viết những dòng này.

Về phía lãnh đạo doanh nghiệp, họ cũng an tâm khi biết rằng, chúng tôi có thể phát hiện, truy vết và đối phólại với bất kỳ sự cố ANTT nào diễn ra trên hệ thống của họ. Thực tế là từ khi triển khai giải pháp này, chúngtôi giải quyết được 100% các sự cố an toàn thông tin trên hệ thống của các khách hàng của chúng tôi.

Ngoài ra hệ thống này còn giúp chúng tôi phát hiện và xử lý hơn phân nửa các sự cố an toàn thông tin. Có rấtnhiều tình huống, nếu không có sự hỗ trợ của hệ thống này, chúng tôi sẽ không thể giải quyết được vấn đề.Lại quay lại với câu chuyện bị tấn công DDoS ở trên.

Nhắc lại, một khách hàng của chúng tôi từng bị tấn công DDoS trên diện rộng vào hệ thống máy chủ InternetBanking. Ở thời điểm cao trào, có hơn 10000 IP gửi hàng ngàn request/s đến máy chủ của họ. Làm thế nào đểnhanh chóng lấy ra được danh sách 10000 IP này, ngăn chặn chúng trên hệ thống firewall, mà không chặnnhầm khách hàng? Làm thế nào để có thể tự động hóa quá trình trên, chẳng hạn như cứ mỗi 15′ sẽ lấy ra danhsách các IP đang tấn công, cập nhật bộ lọc của tường lửa?

Với hệ thống này, chúng tôi chỉ cần soạn thảo một đoạn script ngắn để lấy ra danh sách IP đang gửi hơn 100request/s rồi cài đặt chương trình để tự động cập nhật bộ lọc của firewall mỗi 15′. Một vấn đề tưởng như nangiải có thể giải quyết nhanh gọn lẹ và rất rẻ.

Các giải pháp chống DDoS sẽ có 2 thành phần chính: phát hiện và đánh chặn. Các giải pháp có sẵn trên thịtrường như các thiết bị của các hãng lớn hay các giải pháp mở như Iptables + Snort inline thường cố gắngphân tích các packet/request để phân loại chúng theo thời gian thực. Nghĩa là khi có một packet/request đivào, các giải pháp này sẽ cố gắng xác định xem packet đó có phải là một phần của vụ tấn công hay không,nếu phải thì thực hiện đánh chặn.

Sự khác biệt của giải pháp của chúng tôi so với các giải pháp chống DDoS đang có trên thị trường là chúng tôi


5 of 14 5/31/2013 3:43 PM

không cố gắng phân loại và ngăn chặn các packet/request theo thời gian thực. Thay vào đó, chúng tôi tách

phần phát hiện ra khỏi hệ thống phòng thủ, và thực hiện phần phát hiện hoàn toàn offline bằng cách sửdụng thông tin từ hệ thống NSM.

Cụ thể, thông tin từ hệ thống đánh chặn cũng như các nguồn khác như web server, proxy hay firewall sẽ đượcđưa vào hệ thống phân tích để chạy offline, rồi kết quả phân tích này sẽ được cập nhật ngược trở lại cho hệthống đánh chặn. Với cách làm này, giải pháp của chúng tôi có thể đáp ứng được lượng tải rất lớn vì chúng tôikhông phải tốn quá nhiều resource để phân tích on-the-fly một packet hay request như các giải pháp khác.

Về các hướng phát triển trong thời gian tới, tôi thấy một ứng dụng hay ho khác của hệ thống giám sát an ninhmạng là nó giúp chúng tôi có thể đo lường được mức độ an toàn của hệ thống. Có một nguyên tắc lâu đời củaquản lý là: chúng ta không thể quản lý những gì chúng ta không thể đo đạc. Do đó để quản lý được an toànthông tin, chúng ta phải biến an toàn thông tin thành những thông số có thể đo đạc và so sánh được. Đây làmột hướng tiếp cận an toàn thông tin từ góc nhìn của người quản lý mà chúng tôi muốn áp dụng cho cáckhách hàng trong thời gian sắp tới.

Tài liệu tham khảo:

Ký sự các vụ DDoS vào HVAOnlinehttp://taosecurity.blogspot.com

Share and Enjoy:

Filed under Firewall, Security, Tiếng Việt, Web Security · Tagged with DDoS, mitigate DDoS, NSM

Lỗ hổng nghiêm trọng của TLS/SSL

November 6, 2009 by thaidn · 1 Comment

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 aman-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintextprefix 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 whichthe MitM may splice together disparate TLS connections in a completely standards-compliantway. 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, trong đó TLS/SSL chỉ là một layer. Chuyện gì sẽ xảy ra nếu TLS/SSLkhông hiểu rõ cơ chế hoạt động của các protocol bên trên nó, như HTTP, SMTP hay POP3? Nói cách khác,chuyện gì sẽ xảy ra nếu các protocol ở mức Application không hiểu rõ cơ chế vận hành của TLS/SSL để sửdụng cho đúng cách? Đó là lúc lỗ hổng xuất hiện.

Tổng quan thì lỗ hổng này nằm ở sự thiếu “ăn rơ” giữa TLS/SSL và các protocol trên nó như HTTP haySMTP. Khai thác lỗ hổng này thì kẻ tấn công có thể chèn thêm một đoạn plaintext bất kỳ vào TLS/SSL


6 of 14 5/31/2013 3:43 PM

encrypted stream giữa client và server mà cả client và server đều không thể phát hiện được.

Đây là một lỗ hổng cực kỳ nghiêm trọng, bởi vì nó phá vỡ hoàn toàn cam kết an toàn của bộ giao thứcTLS/SSL. Nói một cách *hoành tráng* thì về mặt lý thuyết, nền tảng của thương mại điện tử đang chao đảo.Tôi dùng chữ lý thuyết vì để cho hướng tấn công này nguy hiểm hơn trong thực tế, thì còn có nhiều trở ngạiphải vượt qua (và sẽ bị vượt qua).

Để minh họa cho câu chuyện, và để dễ giải thích, tôi đặt ra một ví dụ như sau:

0. Giả định:

* Ngân hàng A có cung cấp dịch vụ Internet Banking ở địa chỉ https://www.ebank.com. Máy chủcủa của họ chạy phần mềm có lỗ hổng mà chúng ta đang bàn ở đây. Chúng ta gọi máy chủ này làserver.

* Để tăng cường an ninh, ngân hàng A yêu cầu khi khách hàng (giờ cứ gọi là client) sử dụng cáctính năng có liên quan đến giao dịch tài chính nằm trong khu vực https://www.ebank.com/account/, thì (browser của) họ phải có cài đặt client certificate cho ngân hàng A cung cấp. Lưu ýlà nhiều ngân hàng ở VN thực hiện cái này lắm nha.

* Ngoài ra ngân hàng A còn hỗ trợ khách hàng truy cập bằng (Safari trên) iPhone, lúc đó kháchhàng sẽ được chuyển đến https://www.ebank.com/iphone/. Do iPhone có processor yếu, nênngân hàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuite yếu hơn bộ ciphersuitemà họ sử dụng cho các khách hàng thông thường. Cái này trong thực tế cũng có nhiều công tytriển khai.

Rồi bây giờ tôi sẽ sử dụng cái kỹ thuật vừa mới phát hiện để tấn công các khách hàng của ngân hàng A theo 3hướng tấn công mà các tác giả nêu ra. Àh lưu ý là đây là loại tấn công MITM, nghĩa là attacker phải có quyềntheo dõi, điều chỉnh dữ liệu truyền qua lại giữa client và server nha. Attacker có thể làm việc này thông quacác tấn công vào các giao thức ARP hay DNS.

1. Hướng tấn công số 1

Đối với hướng tấn công số 1, tôi sẽ lợi dụng việc khi truy cập vào https://www.ebank.com/account/ thì serversẽ yêu cầu client phải trình certificate.

Sơ đồ bên dưới là tôi lấy từ paper của các tác giả phát hiện ra lỗ hổng này. Tôi thấy cái sơ đồ này giải thíchrất rõ lỗ hổng này và cách thức tấn công theo hướng thứ 1. Thật ra thì hướng thứ 2 và hướng thứ 3 cũng khágiống hướng thứ 1, nên tôi nghĩ nắm rõ hướng thứ 1 thì sẽ thấy các hướng kia cũng đơn giản.


7 of 14 5/31/2013 3:43 PM

Có 4 bước khi triển khai tấn công này:

* Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết nối đến attacker, và gửiCLIENT_HELLO để bắt đầu giao thức TLS/SSL. Attacker sẽ tạm dừng cái kết nối này và lưu msgCLIENT_HELLO lại để dùng trong bước 3.

* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao thức TLS/SSL để tạo thành mộtsession. Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:

* Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời dừng xử lý request này lại vànhư đã nói ở trên, nó yêu cầu attacker phải đưa client certificate cho nó xem. Cái hay ở đây, mặc dầuattacker không có (private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cái certificate đó từclient lên server, mà không bị bên nào phát hiện cả.

Server bắt đầu quá trình xác thực bằng việc gửi một msg HELLO_REQUEST ngược lại cho attacker.Attacker nhận được msg này thì hắn gửi CLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server. Rồicứ thế, attacker đứng giữa, chuyển msg qua lại giữa client và server cho đến khi quá trình xác thực bằngclient certificate kết thúc thành công.

Lưu ý là có 2 loại msg mà attacker sẽ gửi. Loại thứ nhất (trên sơ đồ là những msg kết thúc hoặc bắt đầu từ cộtm) là những msg mà hắn phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận “Certificate” từ phía clientthì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server. Loại thứ hai (trên sơ đồ là những msg màu hồng vàđỏ) là những msg mà hắn không đọc được (vì không có key), hắn chỉ làm mỗi việc là nhận từ client thì gửiqua server và ngược lại.

* Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server tiếp tục xử lý cái request củaattacker ở trên, và trả kết quả lại cho attacker (lưu ý là attacker sẽ không đọc được kết quả này).

Điểm yếu là ở đây. Như chúng ta thấy, khi attacker gửi request ở bước 3, lúc đó hắn chưa được xác thực. Nói

POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n


8 of 14 5/31/2013 3:43 PM

cách khác, lúc này request của hắn là unauthenticated request. Việc xác thực diễn ra sau đó, và sau khi xácthực rồi thì server lại quay lại xử lý tiếp cái unauthenticated request của attacker.

Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết quả về cho client để đóng kết nối lạimột cách êm đẹp.


Trước khi bắt đầu giải thích hướng số 2, tôi muốn nhấn mạnh ý này: tất cả 3 hướng tấn công này đều hướng

đến chôm credential của client để gửi các authenticated request đến server. Credential ở đây có thể làcertificate (như ở hướng số 1) hay cookie/session (như ở hướng số 2 và số 3). Nếu chỉ áp dụng choHTTPS, nhìn ở một góc độ nào đó, các hướng tấn công này rất giống với tấn công CSRF. Nên nếu ứng dụngcủa bạn đã có các phương thức phòng chống CSRF rồi hay nếu ứng dụng của bạn không chấp nhận thay đổistate bằng GET, thì tạm thời cũng không phải có gì lo lắng.

Đối với hướng số 1, tôi lợi dụng client certificate để gửi một authenticated request. Ở trường hợp các serverkhông xác thực bằng certificate, tôi sẽ sử dụng hướng tấn cống số 2.

Hướng tấn công này cũng có 4 bước:

* Bước số 1: tương tự như hướng tấn công số 1.

* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao thức TLS/SSL để tạo thành mộtsession.

Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:

* Bước số 3: server thấy có request đến /iphone/ nên nó tạm thời dừng xử lý request này lại và, như đã nói ởphần giả định, server sẽ bắt đầu quá trình renegotiate lại để chọn một bộ ciphersuite yếu hơn. Vấn đề ở đây làserver sẽ buffer lại toàn bộ nhóm unauthenticated request này, khi mà renegotiate xong thì lại quay lại xử lýhết tất cả.

Trong quá trình renogotiation, vai trò của attacker cũng tương tự như ở bước số 3 của hướng tấn công số 1,nghĩa là hắn cũng chỉ *proxy* msg qua lại giữa client và server, cho đến khi quá trình renegotiate kết thúcthành công.

* Bước số 4: lúc này, client thấy đã handshake xong rồi, nên bản thân nó sẽ gửi tiếp cái HTTP request của nóở dạng:

Chuyện bất ngờ diễn ra ở đây. Server nó sẽ gom nhóm unauthenticated request ở bước 2 (do attacker gửi) vàcái authenticated request này (do client gửi) rồi xử lý chung một lần. Nguyên nhân server xử lý như thế là do

GET /iphone/login HTTP/1.1\r\nHost: ebank.com\r\nConnection: keep-alive\r\n\r\nGET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\nHost: ebank.com\r\nConnection: close\r\nX-ignore-this:

GET /index HTTP/1.1\r\nCookie: AuthMe=Now\r\n\r\n


9 of 14 5/31/2013 3:43 PM

cái cờ keep-alive ở request đầu tiên. Thành ra lúc này nhóm request trở thành như sau (màu cam là attackergửi, màu xanh là client gửi):

Ở đây cái header X-ignore-this đã vô hiệu hóa cái request GET /index HTTP/1.1 của client, đồng thời chômluôn cookie của client để gắn vào cái unauthenticated request GET /account/transfer?amount=1000&

receiver=attacker. Rất hay!


Đây là hướng tấn công mạnh nhất, không cần server phải có cấu hình đặc biệt gì để thực hiện. Sự khác biệt cơbản giữa tấn công này với hai hướng tấn công vừa rồi là trong trường hợp này, client bắt đầu quy trìnhrenegotiation.

Ý tưởng thực hiện tấn công rất giống với hướng 2, chỉ khác nhau ở bước số 2, attacker sẽ không gửi GET

/iphone/login nữa mà gửi trực tiếp luôn request của hắn, kèm theo một cái “X-ignore-this” header.

Ngay sau khi gửi cái request đó, attacker sẽ forward cái CLIENT_HELLO thu được ở bước 1 sang cho phíaserver để bắt đầu quy trình renegotiation. Khi đã renegotiate xong, client sẽ gửi request ban đầu của mình đếnserver, lúc này toàn bộ request sẽ trông như sau (phần màu cam của attacker gửi, phần màu xanh của clientgửi):

Tương tự ở trên, X-ignore-this đã vô hiệu hóa request của client và chôm cookie để biến request của attackerthành authenticated. Không cần keep-alive, không cần server phải có cấu hình đặc biệt gì cả!

Share and Enjoy:

Filed under Cryptography, Tiếng Việt, Vulnerabilities, Web Security · Tagged with mitm, renegotiation, ssl, tls

Microsoft Security Essentials phiên bản chính thức

September 29, 2009 by lamer · Leave a Comment

Cái mà mình thật sự quan tâm không phải về chất lượng sản phẩm diệt virus này (nó tốt, ok,

GET /iphone/login HTTP/1.1\r\nHost: ebank.com\r\nConnection: keep-alive\r\n\r\nGET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\nHost: ebank.com\r\nConnection: close\r\nX-ignore-this:GET /index HTTP/1.1\r\nCookie: AuthMe=Now\r\n\r\n

GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\nHost: ebank.com\r\nConnection: close\r\nX-ignore-this: GET /index HTTP/1.1\r\nCookie: AuthMe=Now\r\n\r\n


10 of 14 5/31/2013 3:43 PM

http://www.computerworld.com/s/article/9134753/Antivirus_testing_outfit_Microsoft_Security_Essentials_makes_the_grade) mà là:

Còn ai muốn bỏ 290.000đ để mua một sản phẩm diệt virus ba xạo kia không?1.Còn đất sống cho các sản phẩm diệt virus cho Windows nữa không?2.

Khi đọc tin này có lẽ bạn đã có thể download thử MSE tại http://www.microsoft.com/Security_essentials/.

Share and Enjoy:

Filed under Anti-Virus, Malware / Rootkit / Hostile Code, Tiếng Việt · Tagged with

Chuyển nhà

June 10, 2009 by leenmie · Leave a Comment

Từ hôm nay chuyển nhà qua đây.

Welcome home.

Share and Enjoy:

Filed under Misc, Tiếng Việt · Tagged with

Nghị định 90/2008/NĐ-CP và Thông tư 12/2008

/TT-BTTTT

February 9, 2009 by lamer · Leave a Comment

Có điều là, ngoài các vấn đề kỹ thuật cơ bản khác, bản thân trung tâm điều phối lại sử dụng nhữngđịa chỉ thư điện tử như thế này đây:

[email protected]

[email protected]

[email protected]

[email protected]

Thứ nhất, trang web của trung tâm của Bộ TTTT có địa chỉ http://antispam.vncert.gov.vn mà lẽ nào không tạođược một vài địa chỉ thư cùng domain, hoặc ít nhất là @vncert.gov.vn?

Thứ hai, domain vncert.vn không thể hiện được tính quản lý của Nhà nước. Domain này hoàn toàn như mộtdomain thương mại thông thường.

Thứ ba, và tệ hại nhất, là sự sử dụng những dịch vụ miễn phí như gmail.com và yahoo.com.vn để thu nhận


11 of 14 5/31/2013 3:43 PM

các thông tin nhạy cảm. Điều này sẽ tạo điều kiện cho những kẻ giả danh tạo ra các tài khoản tương tựcanhbaothurac như canhbaospam, canhbaovncert, v.v…

Lẽ nào trung tâm điều phối chống thư rác lại tiếp tay cho những kẻ rải thư rác?

Share and Enjoy:

Filed under Legal Issues, Tiếng Việt · Tagged with

« Previous Page — Next Page »

VNSEC on Facebook

You can find most of our members on irc.freenode.net, channel #vnsec.

Follow @vnsec 1,217 followers

Archives

VnSecurity

Like 581

VNSEC Live Tweets

Join the conversation

vdchuyen "Coffee vs. beer: which drink makes you more creative?" by @MikaelCho medium.com/what-i-learned…,drink too much beer but no creative ?2 minutes ago · reply · retweet · favorite

vdchuyen "Coffee vs. beer: which drink makes you more creative?" by @MikaelCho medium.com/what-i-learned…5 minutes ago · reply · retweet · favorite

eugeneteo Broadcasting Act, Chapter 28 egazette.com.sg/pdf.aspx?ct=sl… #Singapore4 hours ago · reply · retweet · favorite

eugeneteo Singapore's online licensing rule a sign of more to come zdnet.com/sg/singapores-… /cc @eileenscyuwell-written.5 hours ago · reply · retweet · favorite

eugeneteo I would like to reach out to security folks at NTU and SUTD. Can someone please connect me to them?Thanks!5 hours ago · reply · retweet · favorite

vnsec [Secuinside CTF 2013] movie talk bit.ly/17yGXmz16 hours ago · reply · retweet · favorite


12 of 14 5/31/2013 3:43 PM

Categories

Recent Posts

[Secuinside CTF 2013] movie talk[Secuinside CTF 2013] Reader Writeup[Secuinside CTF 2013] pwnme writeup[Secuinside CTF 2013]Trace Him WriteupAnalysis of nginx 1.3.9/1.4.0 stack buffer overflow and x64 exploitation (CVE-2013-2028)

Recent Comments

[Secuinside CTF 2013] pwnme writeup (8)

2b: So, in the case we can leak base address of program (to build ROP), Do we still...longld: We still need some codes that can return status, e.g send back something after...

Analysis of nginx 1.3.9/1.4.0 stack buffer overflow and x64 exploitation (CVE-2013-2028) (1)

pip010: could you please summarize it for any app-developer out there, what were the...CMarkup Use After Free Vulnerability – CVE-2012-4782 (14)

S3ize: why is Use after Free?? I see it’s simple BOF…. D:

Disclaimer

VNSECURITY.NET has no relation with any other website called themself VNSECURITY such as

vnsecurity.com (VHF), vnsecurity.vn, vnsecurity.info…

Tags

2009 2010 2011 2012 aslr blackhat Capture The Flag / CLGT CLGT codegate conference Cryptography CSAW

CTF DDoS debugger DEFCON exploit format string gentoo Hack.lu hackinthebox Hacklu hitb Israel lighttpd mitigate DDoS mitm network

NSM OSX police renegotiation return-oriented-programming return-to-libc rop ropeme security check sha1 ssl stack guard tls vietnam

VNSECON wordpress zine

Blogroll

Eugene TeolongldthaidnXandoraXwings

Friends

ARTeamBlue MoonHackInTheBoxSapheads


13 of 14 5/31/2013 3:43 PM

giam sat an ninh mang

Documents