Penetration Testing Step 3 – Tấn công vào Authentication mechanisms liệu có khả thi?

Kết thúc nội dung Penetration Testing Step 3 – Các thể loại SQL injection phổ biến (Part 7), tôi cũng xin tạm dừng các trò chích choác để chuyển sang một chủ đề mới cũng không kém phần gay cấn là Authentication (tạm dịch là xác thực).

Đây có thể xem là cổng chính của các thành trì, nơi hàng tấn các giải pháp bảo vệ, gia cố được triển khai để bảo đảm kiểm soát việc ra vào của các nhóm đối tượng khác nhau.

Chi tiết về vấn đề Authentication, các giang hồ mạng chắc đã xuất bản cả trăm ngàn tài liệu liên quan. Do vậy, tôi sẽ không nhai lại các nội dung mà người khác đã nói kỹ (thực ra cho dù có muốn nhai lại chắc tôi cũng không làm tốt bằng). Mục tiêu của tôi ở đây chỉ gói gọn trong việc giới thiệu nhưng nguyên lý căn bản của Authentication (trong kỳ này) và sau đó triển khai một số nội dung demo để làm rõ các ý tưởng tấn công liên quan (trong các kỳ kế tiếp).

#1 Tóm lại Authentication là gì?

Authentication có thể hiểu đơn giản là quá trình xác nhận danh tính của user, coi họ có đúng là người như họ đã khai báo không hay đang bơm đểu.

Authentication có thể dựa vào nhóm các Factors (yếu tố) bao gồm:

  • Something you know: là thứ bạn biết, ví dụ như password, PIN, secret phrase,…;
  • Something you have: là thứ bạn có thể sở hữu vật lý, ví dụ như cái Smart card, điện thoại hoặc security token để nhận mã xác thực,…;
  • Something you are: là thứ có thể đại diện cho bạn, ví dụ đám biometrics (sinh trắc học) như vân tay, khuôn mặt,….

Với việc xác thực dựa trên Factors, bạn sẽ có thể thấy thứ gọi là Multi-Factor Authentication – MFA tương ứng với trường hợp sử dụng tối thiểu 2 trong 3 nhóm Factors nói trên (thông thường sẽ là 2 yếu tố tương ứng với trường hợp hay gặp là 2 Factor Authentication – 2FA).

Ví dụ minh họa 2FA với password và Smartcard được minh họa như sau.

2FA
2FA

Nguồn: CompTIA Security+

Ngoài ra, bạn cũng có thể gặp Authentication dựa vào Attributes – là các yếu tố có thể được xem xét bổ sung thêm trong quá trình xác thực. Các thể loại phổ biến bao gồm:

  • Somewhere you are: xem xét dựa vào vị trí, ví dụ vị trí vật lý hay cả logical address như IP/MAC address;
  • Something you can do: xem xét dựa vào thứ bạn có thể làm được ví dụ như typing rhythm (nhịp điệu cào phím), gait (tướng đi), handwriting, …;
  • Something you exhibit: xem xét dựa vào các chi tiết ghi nhận liên quan đến đối tượng, ví dụ OS đang sử dụng là gì, tính chất của kết nối là local hay remote,..;
  • Someone you know: xem xét dựa vào chain of trust – đại khái là kiểu bạn của bạn tin một ai đó thì bạn cũng tin theo (dù đôi lúc sẽ ăn hành sml vì kiểu tin tưởng bắt cầu này).

#2. Ủa vậy rồi Authentication có gì khác so với Authorization?

Một điểm quan trọng cần lưu ý là phân biệt Authentication vs Authorization. Authentication liên quan đến việc xác nhận tuyên bố danh tính của user trong khi Authorization (tạm dịch là phân quyền) liên quan đến việc xác nhận quyền hạn được phép của user (vấn đề này có nhiều điểm tương đồng với Access Control – kiểm soát truy cập).

Thật ra cặp bài trùng này thường hay được nhắc đến trong bộ 3 nguyên tử AAA services – Authentication, Authorization and Accounting. Và bộ 3 này có thể được diễn giải rõ hơn khi xem xét quy trình xử lý bảo mật gồm 5 yếu tố:

  • Identification: Tuyên bố lai lịch khi truy cập vào hệ thống được bảo mật;
  • Authentication: Xác nhận lai lịch đã tuyên bố;
  • Authorization: Xác định quyền hạn truy cập dựa trên lai lịch đã xác nhận;
  • Auditing: Ghi nhận events & activities log liên quan trong quá trình hoạt động;
  • Accounting (accountability): Soát xét log để kiểm tra việc tuân thủ với chính sách/quy định đã thiết lập.

Liên quan đến Authentication vs Authorization, còn một yếu tố khác cũng không kém phần quan trọng cần lưu ý là Session Management. Đây có thể xem là chất keo liên kết phần Authentication với Authorization/Access Control để bảo đảm duy trì thông tin đã xác thực cho những phiên hoạt động tiếp theo đúng quyền hạn và nghĩa vụ.

Session Management
Session Management

Nguồn: owasp.org

Lưu ý: Đây cũng là một trong những vị trí hấp dẫn cho những đối tượng có dã tâm thích thích đâm thọc, chọc ngoáy.

#3 Authentication vulnerabilities – Các kiểu lỗ hổng trong quá trình xác thực

Như tôi đã giới thiệu ở phần mở đầu, Authentication thường sẽ được bảo vệ, gia cố với hàng tấn giải pháp. Tuy nhiên, thực tế cho dù được quan tâm bảo vệ tận răng, việc tồn tại lỗ hổng bảo mật trong quá trình xác thực của hệ thống có là điều có thể xảy ra.

Nhìn chung, phần lớn các lỗ hổng phát sinh trong cơ chế xác thực đều nằm trong 2 dạng:

  • Cơ chế xác thực quá yếu đuối, bẩn bựa không chống lại được brute-force attacks;
  • Có lỗi trong logic xử lý hoặc quá trình thực thi cho phép các đối tượng xấu có thể bypass cả quá trình xác thực.

Các thể loại lỗ hổng phổ biến trong cơ chế xác thực thường gặp bao gồm:

  • Password-based login;
  • Multi-factor authentication;
  • Các cơ chế xác thực khác;

Lưu ý: Bạn cũng có thể gặp các lỗ hổng trong Third-party authentication mechanisms (ví dụ Oauth authentication).

#4 Ngăn chặn tấn công vào cơ chế xác thực có dễ không?

Câu trả lời ngắn gọn là không. Ngăn chặn tấn công vào cơ chế xác thực là một kiểu công việc bạc bẽo – bạn bảo vệ hệ thống trụ vững liên tục 10 năm cũng ít ai nhớ, nhưng ai cũng nhớ khi bạn để hệ thống bị xuyên thủng một lần.

Bên cạnh đó, bản chất việc phòng thủ cũng sẽ rất mệt mỏi, bạn phải phân tích đánh giá và vá hết tất cả các lỗ hổng có thể có trong khi attacker chỉ cần đâm vô đúng một điểm tử huyệt là đã chiến thắng (Lưu ý, đây là việc so sánh tương đối cho công việc của phe tấn công và phe phòng thủ, bạn đừng đọc đoạn này rồi mạnh dạn kết luận việc tấn công thành công là dễ dàng).

Quay lại vấn đề chính, quá trình che chắn, phòng thủ chắc chắn sẽ cần nhiều phân tích đánh giá, nhưng nhìn chung cần tuân thủ các nguyên tắc cơ bản sau:

  • Tuyệt đối không được tin tưởng user khi triển khai các giải pháp bảo mật: Vâng, bạn không đọc nhầm đâu, con người thường sẽ là mắc xích yếu nhất trong hệ thống. Do vậy, khi triển khai giải pháp bảo mật (ví dụ vấn đề độ phức tạp của password), bạn cần bảo đảm user phải tuân thủ thông qua các quy trình kiểm soát chặt chẽ (tức là đặt password bựa thì đừng mong được cấp quyền truy cập) chứ đừng đưa ra chính sách sau đó hy vọng user sẽ răm rắp nghe theo;
  • Quản lý kỹ user credentials: Đây là việc hiển nhiên nhưng vẫn cần nhấn mạnh vì cơ chế xác thực xịn sò đến đâu mà bạn lại tự nguyện 2 tay dâng user credential cho attacker (ví dụ kiểu gửi thông tin đăng nhập qua các kết nối không mã hóa) thì bao nhiêu công sức cũng sẽ đổ sông đổ biển;
  • Ngăn chặn username enumeration: Nếu để việc dò tìm username tồn tại trong hệ thống dễ dàng thì coi như bạn đã chấp attacker nửa đường. Để ngăn chặn việc này, bạn cần bảo đảm hệ thống không phụt ra thông báo lỗi hoặc kiểu thời gian phản hồi cho phép attacker xác định được cái username vừa đút vào test có tồn tại hay không;
  • Triển khai giải pháp chống brute-force chặt chẽ: Giải pháp phổ biến cho vấn đề này là giới hạn số lần thử-sai của attacker ví dụ phương án khóa truy cập sau một số lần đăng nhập sai, khóa truy cập dựa vào IP, sử dụng CAPTCHA trong mỗi lần đăng nhập. Nói chung vỏ quýt dày sẽ có móng tay nhọn, đâu đó bạn sẽ bắt gặp các giải pháp phá các phương án bảo vệ nói trên (ví dụ sử dụng TOR). Tuy nhiên, nếu bạn triển khai nhiều lớp bảo vệ chặt chẽ, khả năng cao là attacker sẽ cắp đít ra về để tìm các con mồi khác dễ xơi hơn;
  • Kiểm tra kỹ verification logic: Việc kiểm tra logic của quá trình xác nhận là rất quan trọng. Nếu có lỗ hổng trong logic xử lý thì giải pháp kỹ thuật của bạn có hoàn hảo đến đâu cũng dễ dàng bị attacker bypass;
  • Lưu ý các chức năng bổ sung: Đôi khi quá trình xác thực khi đăng nhập bạn xử lý hoàn hảo. Nhưng đâu đó trong quá trình triển khai reset/change password bạn lại mắc sai lầm để lại một lỗ hổng to đùng cho attacker chọc ngoáy. Lời khuyên ở đây là độ mạnh của hệ thống sẽ bằng với độ mạnh của hệ thống yếu nhất – do vậy bạn nhớ kiểm tra coi tình trạng cửa sổ, cửa hậu, … đã được gia cố bài bản luôn chưa nhé;
  • Thực thi Multi-Factor Authentication chuẩn cmn mực: Hiện nay Multi-Factor Authentication – MFA (hay Two-Factor Authentication – 2FA) không còn xa lạ gì với người dùng. Tuy nhiên bạn cần bảo đảm quá trình triển khai MFA phải chuẩn cmn mực. Tức là tối thiểu bạn phải có ít nhất 2 Factors đề cập trong Mục 1 được sử dụng thì hiệu quả của quá trình xác thực mới được tăng cường. Ngoài ra, cũng cần lưu ý, tùy thuộc vào bản chất của giải pháp triển khai, độ mạnh của phương án xác thực cũng sẽ thay đổi đáng kể (ví dụ sử dụng code nhận thông qua SMS trên điện thoại của bạn sẽ tiềm ẩn nhiều nguy cơ hơn so với việc sử dụng thiết bị chuyên dụng như security token hoặc application tạo verification code).

Nếu đọc các thông tin tôi chém gió ở trên xong mà vẫn thấy mơ hồ thì bạn cũng đừng lo. Tôi sẽ bố trí phần demo sinh động để làm rõ vấn đề trong các kỳ tiếp theo. Còn giờ thì xin tạm biệt.

1 thought on “Penetration Testing Step 3 – Tấn công vào Authentication mechanisms liệu có khả thi?”

Leave a Reply

Your email address will not be published. Required fields are marked *