Giải pháp nâng cao tính riêng tư và bảo mật chống tấn công đánh cắp mã OTP trong Internet banking

Các kỹ thuật đảm bảo an ninh ngày càng hiện đại tuy nhiên vẫn không thể đảm bảo an toàn trước sự tấn công của hacker.

An toàn thông tin

Hoàng Sĩ Tương
09:03 AM 29/12/2020
In bài viết này

Chia sẻ bài viết này

Yêu cầu bảo mật cho các dịch vụ của ngân hàng

Hiện nay khi hệ thống của ngân hàng được kết nối với mạng Internet để phục vụ các giao dịch của khách hàng, hacker luôn tìm cách để tấn công vào hệ thống này mọi lúc, mọi nơi. Một số giải pháp an toàn đã được các ngân hàng triển khai cho hệ thống Internet Banking của mình nhằm mục đích đảm bảo an toàn cho các giao dịch của khách hàng. 

Tuy nhiên các cuộc tấn công vào hệ thống này vẫn luôn diễn ra dưới nhiều hình thức khác nhau như truy cập trái phép, phá hủy hệ thống, đánh cắp xác thực OTP, sửa đổi dữ liệu hoặc tấn công sử dụng độc nhằm gây lỗi mạng, khởi động hoặc làm treo hệ thống. Các kỹ thuật đảm bảo an ninh ngày càng hiện đại tuy nhiên vẫn không thể đảm bảo an toàn trước sự tấn công của hacker. Ngoài ra nếu các hệ thống an ninh không được cấu hình đúng cách hoặc các bản lỗi không được cập nhật thường xuyên cũng tạo ra các lổ hổng bảo mật, gây ra các nguy cho hệ thống Internet banking.

Tổng quan v OTP

OTP là gì?

OTP từ viết tắt của One Time Password, nghĩa mật khẩu chỉ sử dụng một lần. một dãy gồm các tự hoặc chữ số được ngân hàng tạo ra gửi đến số điện thoại của khách hàng nhằm xác nhận giao dịch để tăng tính bảo mật cũng như đảm bảo an toàn khi sử dụng dịch vụ ngân hàng điện tử hoặc thanh toán trực tuyến. Đúng như tên gọi, OTP được dùng xác nhận giao dịch một lần duy nhất. Thậm chí khi khách hàng chưa sử dụng thì sau khoảng 30 giây đến 2 phút, xác nhận này cũng không còn hiệu lực. khách hàng cũng không thể sử dụng nó cho bất kì giao dịch nào khác. OTP thường được dùng để làm bảo mật 2 lớp trong các giao dịch xác minh đăng nhập, đặc biệt là giao dịch với tài khoản ngân hàng. OTP giúp ngăn chặn, giảm thiểu những rủi ro bị tấn công khi mật khẩu bị lộ hoặc hacker xâm nhập.

Những rủi ro khi sử dụng OTP trong Internet Banking 

Mặc dù OTP mang lại nhiều thuận lợi cho khách hàng, tuy nhiên vẫn còn đó những nhược điểm xảy ra, và độ an toàn của OTP được nhiều chuyên gia bảo mật thế giới khuyến cáo. Với SMS OTP, khách hàng sẽ không thể nhận được mã OTP trong trường hợp điện thoại mất sóng, hay di chuyển ra nước ngoài mà không cài đặt dịch vụ chuyển vùng quốc tế. Nhưng quan trọng hơn, mã OTP nhận được có thể bị tin tặc đánh chặn và ăn cắp thông tin bằng cách khai thác lỗi của các hệ thống viễn thông. Trong đó, hình thức được đặc biệt lưu ý là tráo SIM, tấn công vào các trang web xác thực nhiều lớp, và sử dụng các phương thức lừa đảo như Muraen hay  NecroBrowser.

Giải pháp nâng cao tính riêng tư và bảo mật chống tấn công đánh cắp mã OTP trong Internet banking - Ảnh 1.

Đặc biệt, hiện nay do không có các kỹ thuật xác thực lẫn nhau giữa các thuê bao di động và các trạm phát sóng trong hệ thống mạng GSM dẫn đến việc các hacker có thể giả mạo các trạm phát sóng để tấn công các thuê bao di dộng. Hacker thường sử dụng kỹ thuật tấn công này để chặn bắt các lưu lượng mạng (bao gồm cả tin nhắn SMS) của người dùng đầu cuối. Mạng GSM thường sử dụng các thuật toán khác nhau để mã hóa các phiên truyền thông giữa các thuê bao di động và các trạm phát sóng. 

Vì vậy nếu các thuật toán có độ bảo mật thấp có thể dễ dàng bị hacker phá vỡ chỉ trong vài giây. Các nghiên cứu gần đây đã chỉ ra rằng hiện nay không có sự bảo mật các kết nối end – to – end cho các mạng GSM dẫn đến việc hacker có thể dễ dàng bắt được các lưu lượng của mạng GSM bằng các thiết bị giải mã đang được bày bán trên thị trường. Truyền thông giữa các thuê bao di động và các trạm phát sóng có thể bị nghe trộm và giải mã bằng cách khai thác các điểm yếu trong các giao thức truyền thông.

Th SIM dùng để chứa số điện thoại của các thuê bao di động nơi nhận các xác thực SMS từ ngân hàng, thành phần quan trọng nhất nhận các xác thực SMS. Các thuê bao động phải tránh việc cho bên thứ ba mượn điện thoại thẻ SIM, kể cả trong trường hợp người dùng thể kiểm soát được cách bên thứ ba sử dụng điện thoại thẻ SIM của mình. Hãy sử dụng PIN để bảo vệ điện thoại của mình khỏi việc sử dụng trái phép của bên thứ ba. Phải luôn giữ mật PIN không cung cấp cho bên thứ ba cũng như tránh việc làm mất PIN. xác thực do ngân hàng cung cấp cho khách hàng phải được giữ mật không cung cấp xác thực này cho bất kỳ người nào khác.

Đề xuất giải pháp đảm bảo an toàn cho mã OTP trong Internet banking

Các giải pháp xác thực hiện nay: Hiện nay hai giải pháp xác thực bản đang được các ngân hàng sử dụng để đảm bảo tính riêng bảo mật cho khách hàng thông qua tin nhắn SMS gồm:

Sử dụng xác thực SMS: xác thực SMS thể được yêu cầu khi người dùng đăng nhập vào ứng dụng của ngân hàng hoặc đặt lại mật khẩu. Sử dụng các xác thực SMS rất tiện lợi; tuy nhiên, thể gây ra các vấn đề về bảo mật. Nếu xác thực bị đánh cắp bởi hacker, thể gây ra thiệt hại về tài chính cho khách hàng.

Một hệ thống khác hiện cũng đã được sử dụng để bảo vệ các tin nhắn SMS thông qua việc thay đổi Android framework.

Nhược điểm: Các ứng dụng độc thể chặn bắt các tin nhắn SMS để truy xuất các xác thực sau đó chặn các truyền thông SMS một cách lén lút người sử dụng không hề hay biết.

Giải pháp đề xuất: Đầu tiên, Code Tracker được thiết kế để bảo vệ các xác thực SMS, không dùng để bảo vệ các tin nhắn. Tuy nhiên, trong quá trình biên dịch DE, tác giả nhận thấy nhiều ứng dụng độc đánh cắp các tin nhắn. Tác giả tập trung mở rộng Code Tracker thành một hệ thống cho phép bảo vệ tất cả các tin nhắn bằng cách áp dụng các truy vết thông qua thẻ mờ (taint tag) cho các tin nhắn SMS thay đổi các chính sách bảo mật cho phù hợp với tình hình thực tế. 

Ưu điểm: Sử dụng kỹ thuật Dynamic lightweight nhằm mục đích theo dõi bảo vệ các xác thực trên nền tảng Android Mobile. Cụ thể, tác giả sử dụng kỹ thuật truy vết mờ (taint) đánh dấu các xác thực với các thẻ mờ cho các tin nhắn SMS gốc và sau đó truyền các thẻ này qua hệ thống. Tiếp theo, tác giả áp dụng các chính sách bảo mật cho các điểm cuối nơi các mã xác thực được gửi đi.

Các mô đun của giải pháp đề xuất

Mô đun người dùng: Trong mô đun này, giao diện của người dùng được thiết kế để thêm các thông tin chi tiết của người dùng vào hệ thống. Các mô đun này giúp ngân hàng dễ dàng tạo các tài khoản cho khách hàng cũng như giúp ngân hàng lưu trữ các thông tin cơ bản của khách hàng. Tính năng này cung cấp việc xác thực giúp đảm bảo khách hàng đăng nhập vào hệ thống là những khách hàng đã được ngân hàng cấp tài khoản. Khách hàng phải đăng nhập bằng tên và mật khẩu hợp lệ nếu không truy cập sẽ bị từ chối. Đây là cơ chế bảo mật để đảm bảo chỉ có người dùng được xác thực mới được phép truy cập vào hệ thống.

Mô đun chuyển tiền: Trong mô đun này, tiền có thể được chuyển từ một tài khoản của người dùng này sang tài khoản của người dùng khác. Đây là phần chính của hệ thống nơi mà người dụng nhập dạng chuyển tiền (nó có thể là thanh toán các hóa đơn hoặc chuyển một số tiền nhất định như thanh toán mua hàng hoặc một vài loại hình thanh toán khác). Mô đun này cũng bao gồm cả giao diện giúp người dùng nhập số tiền cần chuyển. Từ giao diện này hệ thống sẽ nhận được thông tin để thực hiện quá trình chuyển tiền.

Tạo Thẻ mờ (Taint Tag): Độ dài của OTP là 4 và kích thước của tất cả các kí tự có thể có trong OTP là 62. Do vậy tổng số cặp OTP là 6212. Xác suất và chạm của hai OTP là 626/6212 = 1/626 = 1/56800235584 = 1.7605561-11.

Xác định mã xác thực SMS: Xác định mã xác thực SMS và sau đó áp dụng thẻ mờ, hệ thống cho phép xác định các nội dung của tin nhắn SMS và các mã xác thực. Đầu tiên, chúng ta cần phải quyết định thời điểm tạo mã xác thực. Lưu ý hệ thống tin nhắn SMS của Android chủ yếu nhận tin nhắn SMS thông qua phát sóng quảng bá tin nhắn SMS hoặc bằng cách đọc tin nhắn từ cơ sở dữ liệu SMS. Do đó, chúng ta chỉ cần xác định xem một tin nhắn SMS có chứa mã xác thực trước khi gửi tin nhắn SMS và sau khi tin nhắn được nạp từ cơ sở dữ liệu SMS hay không. Tuy nhiên, vì lớp framework của Android sẽ chưa giải mã nội dung tin nhắn trước khi phát SMS nên chúng ta khó xác định được mã xác thực bằng cách tìm kiếm chúng trong nội dung tin nhắn. 

Do đó, tác giả tận dụng địa chỉ người gửi của tin nhắn SMS để xác định liệu tin nhắn có chứa mã xác thực hay không; nếu có, tác giả đánh dấu nó là mã ủy quyền SMS tiềm năng. Tác giả duy trì danh sách địa chỉ người gửi các mã xác thực SMS và xem tất cả các tin nhắn SMS bắt nguồn từ các địa chỉ này là các tin nhắn có khả năng chứa mã xác thực SMS. Sau khi tin nhắn SMS được đọc từ cơ sở dữ liệu SMS, tác giả tìm kiếm nội dung của tin nhắn có chứa chuỗi mẫu chuỗi của mã xác thực nhằm xác định xem tin nhắn có chứa mã xác thực hay không. 

Sau khi xác định tin nhắn SMS có chứa mã xác thực (hoặc có khả năng chứa mã xác thực), tác giả đánh dấu và theo dõi tin nhắn bằng cách thêm thẻ (hoặc thẻ mờ) vào nó (tin nhắn được đánh dấu được gọi là nguồn mờ (taint)). Điều quan trọng cần lưu ý là nếu chúng ta thêm các thẻ vào tất cả các biến trong hệ thống, nó có thể truy vết dữ liệu tốt hơn, nhưng chi phí bộ nhớ sẽ trở thành mối quan tâm. Tác giả nhận thấy một tin nhắn SMS thường được lưu trữ trong một mảng ký tự hoặc dưới dạng các byte; do đó, tác giả chỉ cần thêm các thẻ vào trong mảng ký tự và các byte. Ngoài ra, tác giả thêm một thẻ  cho  mỗi  mảng  để giảm chi phí bộ nhớ.

Xác minh mã xác thực SMS: Các ứng dụng độc hại có thể chuyển tiếp mã xác thực SMS bị đánh cắp thông qua SmsManager hoặc giao diện mạng. Do đó, để bắt được các hành vi như vậy, chúng ta cần sửa đổi các giao diện tương ứng trong lớp Android framework và áp dụng các chính sách bảo mật tương ứng. Khi hacker chuyển tiếp tin nhắn thông qua SmsManager, tác giả trích xuất thẻ của dữ liệu được gửi. Khi hacker chuyển tiếp dữ liệu qua giao diện mạng, nó có thể được thực hiện theo nhiều cách khác nhau, ví dụ: qua email, qua giao thức HTTP và qua các TCP/UDP socket. 

Tuy nhiên, dù hacker sử dụng bất kỳ phương thức chuyển tiếp nào thì dữ liệu mạng cuối cùng sẽ được gửi đến đến kernel thông qua các lời gọi hệ thống, được thực hiện thông qua lớp Posix. Do đó, tác giả có thể phát hiện và bảo vệ dữ liệu xác thực SMS bằng cách giám sát các hoạt động liên quan đến mạng trong lớp Posix. Nếu chúng ta nhận được một thẻ mờ (taint tag) từ các byte hoặc mảng ký tự, chúng ta có thể nhận được một vài giá trị. 

Trong số các giá trị này, 0x00000000 (ví dụ, t_n) biểu thị rằng dữ liệu không chứa bất kỳ thẻ mờ nào; 0x00000001 (ví dụ, t_p) cho biết dữ liệu có thể chứa mã xác thực và dữ liệu này được lấy trực tiếp thông qua tin nhắn SMS; 0x00000002 (ví dụ, t_d) và 0x00000003 (ví dụ t_d | p) cho biết dữ liệu được nạp từ cơ sở dữ liệu SMS; và 0x000000007 (ví dụ t_a | d | p) biểu thị dữ liệu được nạp từ cơ sở dữ liệu SMS và chứa mã xác thực. Khi giá trị là 0x00000001 hoặc 0x00000007, tác giả xử lý dữ liệu theo các luật được định nghĩa trước (ví dụ: cấm gửi, cảnh báo người dùng hoặc gửi giá trị không có thật). 

Điều quan trọng cần lưu ý là nếu một ứng dụng gửi dữ liệu có thẻ 0x00000001 (ví dụ, t_p), tác giả xác định đó là một hoạt động nguy hiểm. Điều này là bởi dữ liệu được lấy trực tiếp thông qua việc phát tin nhắn SMS và sau đó ứng dụng đang cố gắng gửi dữ liệu ra bên ngoài. Đây được xem là hành động của mã độc, vì một ứng dụng lành tính luôn tìm cách nạp một tin nhắn SMS từ cơ sở dữ liệu SMS và sau đó mới gửi tin nhắn đi.

Kết luận

Trong bài báo, tác giả đề xuất phương pháp chèn mã (Code Inject), cụ thể ở đây là chèn mã vào OTP. OTP được gửi qua tin nhắn SMS không phải là OTP gốc mà là OTP đã được sửa đổi bằng phương pháp chèn mã (Code Inject). Các ứng dụng được ủy quyền chỉ có thể lấy OTP gốc từ OTP đã được sửa đổi. Với OTP đã được sửa đổi, ứng dụng không thể giao dịch chuyển tiền từ ngân hàng. Phương thức chèn mã (Code Inject bao) bao gồm các mục chọn chức năng và tạo số ngẫu nghiên, điều này giúp tạo ra OTP được sửa đổi cho OTP nguồn. Các kết quả đánh giá trên các tập dữ liệu trong mội trường thực tế đã chứng minh chi phí bảo vệ quyền riêng tư trong Android giảm đáng kể so với các phương pháp hiện có, các thử nghiệm cũng chứng minh được tính hiệu quả và tính thực tiễn của giải pháp.


Tài liệu tham khảo

1. S. Al-Rahami and K. Paterson, "Certifi ateless public key cryptography," in Proc. Int. Conf. Theory Appl. Crypto. Inf. Security, 2003, pp. 452–473. 

2.  X. Huang, Y. Mu, W. Susilo, D. S. Wong, and W. Wu, "Certifi ateless signature revisited," in Proc. 12th Australasian Conf. Inf. Security Privacy, 2007, pp. 308–322. 

3. K.-H. Yeh, "Cryptanalysis of Wang et AL's certifi ateless signature scheme without bilinear pairings," Nat. Dong Hwa Univ., Hualien, Taiwan, Tech. Rep. NDHUIM-

IS-2017-001,  2016.

(Bài đăng ấn phẩm in Tạp chí TT&TT số 15+16 tháng 11/2020)