Giao thức bảo mật HTTPS và MITM attack(Secure Coding P1)

Table of contents

• Giao thức bảo mật HTTPS và MITM attack
• MITM attack với WebProxy

Giao thức bảo mật HTTPS và MITM attack

Như tất cả lập trình viên đều biết: HTTPS là một giao giức bảo mật, dữ liệu được mã hóa trên đường truyền, các bước bắt tay (handshake) để mã hóa được dữ liệu của nó tóm gọn bởi các bước bên dưới

Các bước handshake này sẽ đảm bảo dữ liệu giữa client và server được mã hóa bởi một key mà chỉ có client và server biết. Sẽ không ai có thể đọc trộm hoặc sửa đổi các gói tin giữa client và server

Tuy nhiên, nhìn sơ đồ trên chúng ta có thể thấy mắt xích yếu nhất của các bước HandShake chính là step 1 và step 2

Về mặt logic: Nếu như ở Step 1 client say hello với "ai đó" ko phải server, Step 2 server response với "ai đó" ko phải là client thì sao? nếu như client và sever ko làm làm việc trực tiếp với nhau mà thông qua "ai đó" thì Masterkey ở step 7 đã bị "ai đó" lấy – và "ai đó" có khả năng tóm được gói tin, có khả năng giải mã được gói tin, có khả năng gói tin sẽ bị sửa đổi trong quá trình khi gửi nhận giữa client và server?

Nếu điều này xảy ra, đó chính là MTTM attack – Man In The Middle Attack – một hình thức tấn công chen vào giữa đường truyền để lấy dữ liệu, sửa đổi, giả mạo gói tin

Hầu hết các kết nối hiện tại của web, mobile đều đang sử dụng HTTPS để gửi nhận dữ liệu trên đường truyền. Điều này khiến đại đa số lập trình viên yên tâm và hài lòng với về mức độ an toàn này. Nếu sử dụng cách chặn gói tin thông thường thì cái mà attacker thu được chỉ là một gói dữ liệu đã mã hóa – không có giá trị gì.

Nhưng thực tế có đúng như thế ko?

Không, tất nhiên là không, hiện thực tàn khốc hơn thế rất nhiều

Trên thực tế, dữ liệu gửi từ A sang B trên Internet ko thực sự đi trực tiếp từ A sang B, mà có thể nó sẽ còn phải qua rất nhiều server Trung gian khác.

Quay lại lý thuyết về các bước HandShake – với hai mắt xích yếu nhất là Step1 và Step2 – Giả sử chúng ta lừa được client(ở đây là mobile) rằng ServerXXX mới là con server, lừa nốt server(ở đây là Server mà chúng ta cần kết nối đến) rằng ServerXXX mới là client thì sao?

Bingo!!!

Tức là thực tế dữ liệu đã gửi đến 1 con ServerXXX trung gian, sau đó forward cho client hoặc server – nghĩa là dữ liệu này hoàn toàn có thể được đọc, được giải mã, được sửa đổi ở server ServerXXX?

Chúng ta có thể kiểm chứng suy luận này một cách dễ dàng theo cách bên dưới.

(Mình xin nhấn mạnh lại một lần rằng, đây chỉ là một trò chơi ở level Kiddy có thể dùng trong việc kiểm thử – còn trên thực tế, sẽ tàn khốc hơn thế này rất nhiều. Nên việc chú trọng vào Security khi thiết kế, lập trình ứng dụng là cực kỳ quan trọng)

MITM attack với WebProxy

Chuẩn bị

• Cài Web Proxy trên máy tính: Fiddler (Window), Charles (Mac)
• Chuẩn bị 1 con điện thoại Android
• Kết nối Máy tính, Android vào cùng 1 giải mạng
• Cài đặt proxy của điện thoại Android trỏ vào IP của máy tính: mục đích mọi gói tin đi qua android đều đi qua proxy là máy tính

Mô hình mạng sẽ như sau

Do Mobile nhận PC là proxy, nên toàn bộ việc gửi nhận dữ liệu – nói một cách chính xác là: toàn bộ hoạt động liên quan đến internet của Mobile đều bị Proxy – ở đây là PC giám sát Khi mở Webproxy trên máy tính – ở đây mình dùng Fiddler – chúng ta có thể nhìn thấy các gói tin

Tất nhiên, các gói tin này nếu dùng HTTPS thì sẽ là gói tin mã hóa – Không có giá trị gì

Vậy làm sao để giải mã các gói tin này? Easy, follow 4 steps bên dưới nhé

1. Setting Proxy của điện thoại trỏ vào PC(Giả sử IP của PC là 192.168.0.100)

2. Setting WebProxy để capture HTTPS Connect & Decrypt data

Vào setting của WebProxy, chọn 2 mục

• Capture HTTPS CONNECTs
• Decrypt HTTPS traffic

Sang thẻ connection

• Port :ở đây mình chọn port 8888 – đây chính là port để setup proxy cho Mobile
• Chọn Allow remote computers to connect

3. Export Cert của webproxy và cài vào điện thoại

Export root cert của webproxy sau đó copy vào điện thoại – cài cert như bình thường

Mục đích của việc này chính là để WebProxy và điện thoại có thể "hiểu nhau" – sau hành động mọi kết nối đến internet từ điện thoại – thông qua proxy đã ko còn bí mật – Proxy sẽ nhìn được toàn bộ dữ liệu của điện thoại

4. Kết quả test thử với việc đăng nhập account Fsoft

Dù là giao thức HTTPS nhưng dữ liệu username/password vẫn phơi thân ra như ảnh dưới Mọi người có thể thử với 1 số ngân hàng, ví điện tử, không phải ngân hàng/ví điện tử nào cũng áp dụng các cơ chế để phòng tránh MITM attack. Mình đã thử với 1 số ví điện tử/ngân hàng(mà ko tiện kể tên ra) thì thấy dữ liệu dạng này vẫn phơi thân ra mời gọi đầy quyến rũ 😛

Replay gói tin

Một tính năng cực kỳ hay ho của các tool Web Proxy là chúng ta có thể Replay gói tin, thậm chí sửa dữ liệu trước khi replay. Tức là ví dụ Chuyển 10 đồng thì chúng ta có thể sửa lại thành 200 đồng rồi replay gói tin. Tình cờ 1 cách đen đủi bạn code backend ko tính khả năng này là chúng ta đã có 200 đồng rồi. Đây cũng chính là thủ thuật áp dụng để trick điểm một cách quang minh chính đại trên Server GST – Hero. VD mình chơi được 30 điểm thì mình có thể sửa lại dữ liệu thành 50 điểm rồi đẩy lên server bằng tính năng Replay

Yeah, câu hỏi quan trọng nhất: Phòng chống MITM attack thế nào?

Client(mobile, web..etc) cần làm gì, Server cần làm gì?

Nếu bạn là 1 developer, nếu bạn có nhiều hơn 2 năm kinh nghiệm, nếu lĩnh vực chính của bạn là client server, ví điện tử, financial…etc thì chúng ta sẽ buộc phải quan tâm đến vấn đề này

Mình post bài lấy chỉ tiêu nên chúng ta hẹn nhau ở post sau nhé 😛