Đầu năm 2017, một ngân hàng ở Việt Nam nhờ tôi kiểm tra an ninh cho app Mobile Banking. Từ nhiều năm nay đây là công việc hàng ngày của tôi, nhưng đây cũng là lần đầu tiên tôi đánh giá một sản phẩm của VIệt Nam. Tôi mất gần 2 tuần để tìm hiểu cách thức hoạt động của app Mobile Banking này.

Tôi tìm được nhiều lỗ hổng, nhưng nghiêm trọng hơn hết là tôi tìm được cách trộm tiền từ bất kỳ tài khoản nào. Đối với một app Mobile Banking thì dân trong nghề gọi một lỗ hổng như vầy là game over, không còn gì để mà hack nữa. Sau đó tôi còn phát hiện ra khoảng 3-4 ngân hàng thuộc hàng top của Việt Nam cũng có lỗ hổng tương tự, vì họ sử dụng chung giải pháp Mobile Banking.

Hình chỉ mang tính minh họa, giúp tôi hướng dẫn quan khách cách suy nghĩ như một hacker, nhưng lỗ hổng trộm tiền là hoàn toàn có thật.

Thử nghĩ chuyện gì sẽ xảy ra nếu một ai đó tự động chuyển tiền và khóa tài khoản của hàng triệu người dùng trên hệ thống 4-5 ngân hàng lớn nhất cả nước? Trong phút chốc, niềm tin, vốn đã dễ bị lung lay, của người dân vào hệ thống ngân hàng sẽ sụp đổ và tôi không thể tưởng tượng được hậu quả sẽ như thế nào cho kinh tế Việt Nam.

Không phải tôi có tài năng gì đặc biệt, mà bất kỳ bạn sinh viên chán học nào cũng có thể tìm được những lỗ hổng này, chỉ cần mất một thời gian huấn luyện. Ngay cả quý vị ngồi đây, nếu muốn học, tôi nghĩ chỉ cần huấn luyện 2-3 năm.

Làm việc với các bên liên quan để sửa lỗi, tôi nhận ra rằng vấn đề không phải họ không quan tâm đến bảo mật, mà là họ không biết nên làm sao  và không có người để làm. Mặc dù rất muốn làm cho đúng, cho tốt, rất cầu thị và sẵn sàng đầu tư, nhưng họ thường làm những việc không cần và không làm những việc cần. Đã 3 năm kể từ ngày tôi thực hiện dự án này, nhưng tôi không thấy có nhiều hy vọng tình hình đã tốt hơn.

Những dữ kiện mà tôi thu thập được trong quá trình chuẩn bị bài nói chuyện này cho thấy dường như mọi chuyện vẫn như cũ.

Nhắc lại: trong một hội thảo gần đây, tôi có nói đầu năm 2017 tôi tìm được một lỗ hổng cho phép trộm tiền từ bất kỳ tài khoản nào của 4-5 ngân hàng ở Việt Nam.

Hình ở trên là một slide trong bài nói chuyện của tôi. Đây là một buổi giảng dạy về an ninh mạng, nên tôi dùng form này để hướng dẫn cho khách tham dự cách suy nghĩ như một hacker. Tôi thấy đây là một cách tiếp cận hiệu quả, mà không cần phải đi sâu vào các chi tiết kỹ thuật, bởi vì không phải ai nhìn vào ô số tiền cũng có thể nghĩ ngay đến "àh, tôi sẽ nhập vào số âm".

Lỗ hổng mà tôi phát hiện là có thật, nó không nằm ở chỗ số tiền chuyển khoản âm, mà là ở chỗ hoán đổi tài khoản của người nhận và người gửi. Một số bạn đọc thắc mắc, nghi ngờ về lổ hổng này. Tôi thấy nghi ngờ là đúng, chính tôi cũng không tin vào mắt mình khi tìm thấy lỗ hổng này.

Tôi không thể tiết lộ ngân hàng nào hoặc sản phẩm nào, vì lý do hiển nhiên, nhưng tôi có thể giải thích thêm về chi tiết kỹ thuật lỗ hổng khá thú vị này. Thiền sư gamma95 từng nói thật khó để thuyết phục người khác mía đường có vị ngọt, nếu họ chưa từng nếm thử bao giờ. Do đó, tin hay không thì tùy duyên vậy ;-).

Một giải pháp Mobile Banking thường bao gồm mobile app và một máy chủ API cung cấp các chức năng như truy vấn tài khoản hay chuyển tiền.

Câu hỏi: nếu được giao nhiệm vụ thiết kế API chuyển tiền trên máy chủ, API của bạn sẽ như thế nào?

Câu trả lời không khó, nhưng nếu chưa làm bao giờ thì cũng có nhiều thứ phải suy nghĩ. Trước khi xem tiếp, bạn hãy thử viết ra câu trả lời của riêng bạn.

Để chuyển tiền, máy chủ cần ít nhất 3 thông số:

1/ Tài khoản nhận

2/ Tài khoản gửi

3/ Số tiền

Tài khoản nhận và số tiền sẽ do người dùng nhập vào mobile app, rồi mobile app chuyển lên máy chủ. Nhưng tài khoản gửi thì lấy ở đâu ra?

Nếu cho phép người dùng chọn, lỡ họ nhập vào tài khoản của người khác thì sao? Tức là máy chủ phải kiểm tra người dùng có quyền chuyển tiền ra khỏi tài khoản đó hay không (authorization). Muốn như vậy thì trước tiên máy chủ phải xác thực người dùng (authentication).

Trên web, sau khi khách hàng đăng nhập, máy chủ sẽ trả về một HTTP cookie, browser ghi nhớ và sử dụng cookie để xác thực các yêu cầu tiếp theo. Thường các công nghệ làm web phổ biến (như .NET, Spring, PHP, hay Ruby On Rails) đã làm sẵn phần này, lập trình viên không cần phải làm gì thêm.

Vấn đề là trên mobile không có sẵn công nghệ nào như HTTP cookie, nên các lập trình viên thường phải tự chế ra cách xác thực. Có người sử dụng các giải pháp như OAuth hay JWT. Trong trường hợp này, sản phẩm dùng một giải pháp xác thực tự chế.

Trước khi nói về giải pháp đó, sẵn đang ở đây, tôi muốn nói thêm một chút về các giải pháp như cookie, OAuth, hay JWT. Tựu trung lại thì các giải pháp này đều giống nhau ở chỗ sau khi khách hàng đăng nhập, máy chủ sẽ cấp phát cho mobile app một token đại diện cho khách hàng. Mobile app sẽ đính kèm token khi gửi yêu cầu đến máy chủ. Máy chủ kiểm tra token như thế nào là mấu chốt của vấn đề.

Thí dụ thế này cho dễ hiểu nhé. Mỗi lần bạn gửi xe máy, nhà xe cho bạn một cái phiếu. Cái phiếu này có vai trò giống như token mà tôi nói ở trên. Muốn lấy lại xe, bạn phải đưa lại cái phiếu và nhà xe sẽ phải kiểm tra như sau:

1/ Cái phiếu còn hợp lệ. Như thế nào là hợp lệ thì tùy chỗ, thường thì họ sẽ dựa vào ngày tháng năm, con dấu, chữ ký ghi trên phiếu. Ví dụ như nếu nơi đó không gửi xe qua đêm mà bạn đưa phiếu ngày hôm qua thì tức là phiếu có vấn đề.

2/ Cái phiếu được phát cho chiếc xe mà bạn đang muốn lấy ra. Chỗ này quan trọng nha, vì nếu không, tôi có thể gửi vô một chiếc xe đạp, dùng phiếu của chiếc xe đạp để trộm một chiếc xe máy xịn. Để bịt lỗ hổng này, nhà xe thường ghi số phiếu lên yên xe. Khi bạn dắt xe ra, họ sẽ kiểm tra xem số trên phiếu và số trên yên xe có giống nhau không. Ai suy nghĩ như một hacker sẽ thấy ngay lỗ hổng: lỡ ai xóa số trên yên xe, ghi lại số khác thì sao? Giải pháp thường gặp là ghi số xe vào phiếu giữ xe. Khi bạn dắt xe ra, nhà xe sẽ kiểm tra số xe trên phiếu có trùng với số xe trên biển số hay không.

Quay trở lại câu chuyện thiết kế API chuyển tiền. Ngoài 3 thông số tài khoản người nhận, tài khoản người gửi và số tiền, mobile app cần phải đính kèm token của khách hàng. Máy chủ sẽ phải kiểm tra như sau:

1/ Token hợp lệ. Tương tự như phiếu gửi xe, token hợp lệ sẽ có, ví dụ như, chữ ký điện tử hợp lệ, còn hạn sử dụng, chưa bị thu hồi (revoked), v.v. Nhiều nơi sử dụng các giải pháp stateless như OAuth hay JWT, nhưng các giải pháp này có nhiều vấn đề. Vấn đề gì thì tôi muốn để dành làm bài tập về nhà cho bạn đọc.

2/ Token là của một người dùng và người đó được phép chuyển tiền ra khỏi tài khoản gửi. Trường hợp mỗi khách hàng chỉ có một tài khoản, trên token có thể ghi luôn số tài khoản đó (giống như trên phiếu gửi xe có ghi số xe). Trường hợp mỗi khách hàng có thể có nhiều tài khoản, trên token có thể ghi một user ID (là một số điện thoại chẳng hạn). Từ user ID này có thể lấy ra (từ core banking chẳng hạn) danh sách tài khoản mà người dùng có thể chuyển tiền ra. Máy chủ sẽ phải kiểm tra để đảm bảo số tài khoản gửi nằm trong danh sách này.

Tôi phát hiện máy chủ đã không thực hiện bước thứ 2. Nói nôm na, tôi sử dụng một token hợp lệ của chính tôi để vượt qua bước kiểm tra thứ 1, nhưng tôi đổi số tài khoản gửi bằng số tài khoản của nạn nhân mà tôi muốn trộm tiền. Trước khi chuyển tiền, máy chủ có yêu cầu phải xác thực OTP qua SMS. Nhưng, thay vì gửi OTP đến số điện thoại của tài khoản gửi, máy chủ lại gửi OTP đến số điện thoại nằm trong token, tức là số điện thoại của tôi.

Tôi viết là "hiểu nôm na" vì sản phẩm này không xác thực bằng token, mà dùng một giải pháp "nhà trồng được" khá rối rắm, nhưng có thể tóm tắt thế này:

1/ Giải pháp sử dụng chữ ký điện tử để xác thực khách hàng.

2/ Máy chủ tạo ra một bộ khóa RSA cho mỗi khách hàng.

3/ Mobile app dùng khóa riêng (private key) của khách hàng để ký tất cả các yêu cầu gửi đến máy chủ, kể cả các yêu cầu xác thực.

Câu hỏi hiển nhiên là: làm sao mobile app có được khóa riêng của khách hàng? Vì bộ khóa được tạo trên máy chủ (đây là một lỗ hổng khác), nên mobile app sẽ phải tải khóa riêng từ máy chủ. Ai có suy nghĩ như một hacker sẽ thấy ngay một vấn đề con gà và quả trứng ở đây: để xác thực thì cần phải có khóa riêng, nhưng để có khóa riêng thì cần phải xác thực trước đã!

"Giải pháp" mà họ sử dụng là thêm vào một API cho phép mobile app tải về khóa riêng của bất kỳ khách hàng nào, chỉ cần biết số điện thoại của khách hàng đó. Nói cách khác, đây là một unauthenticated API giúp tôi có thể lấy khóa riêng và từ đó giả danh (impersonate) bất kỳ tài khoản nào.

Tóm lại thì giải pháp này chỉ an toàn khi người ta không hiểu được giao thức giữa máy chủ và mobile app. Đây là một sự vi phạm nguyên lý Kerckhoff khi thiết kế giao thức bảo mật.

Một hệ thống an toàn là một hệ thống mở, ai cũng biết cách thức nó hoạt động, nhưng không ai có thể phá vỡ nó. Nếu sự an toàn của hệ thống phụ thuộc vào giả định rằng không ai biết cách nó hoạt động ra sao, không sớm thì muộn hệ thống đó sẽ bị tấn công. Làm rối rắm mã hay che dấu cách thức hoạt động của phần mềm không phải là không có tác dụng trong việc tăng cường bảo mật cho hệ thống, nhưng chúng không thể là phương thức bảo vệ duy nhất. Dịch ngược mã phần mềm khó, nhưng rất nhiều người làm được.

Thiết kế của hệ thống cần phải là thiết kế mở vì chỉ như vậy mới chống lại được các hành vi phá hoại, xâm nhập từ bên trong, vốn là mối nguy lớn nhất cho các hệ thống ngân hàng. Rất nhiều nhân viên ngân hàng hiểu giao thức giữa mobile app và máy chủ, nếu những người này muốn trộm tiền, làm sao để ngăn chặn họ? Ngày hôm nay họ còn là nhân viên, nhưng nếu sau này họ nghĩ việc thì sao? Chỉ có thể trả lời được câu hỏi này bằng cách xây dựng hệ thống với giả định rằng kẻ tấn công đã biết rõ mã nguồn và tài liệu thiết kế.

Happy hacking!

Cập nhật: tôi muốn viết thêm một chút về thiết kế giải pháp an ninh mạng (security engineering) vì đề tài này liên quan đến tuyến bài chính về tình hình và chính sách an ninh mạng ở Việt Nam.

Thiết kế và xây dựng giải pháp xác thực cho một sản phẩm mobile banking là một công việc lai giữa applied security và product security. Việc này không dễ cũng không khó, nhưng tôi nghĩ ở Việt Nam chưa có mấy người làm. Đa số người làm security ở Việt Nam tập trung vào tìm kiếm lỗ hổng, hoặc network security, rất ít người có thể xây dựng giải pháp để giải quyết các vấn đề security thường gặp như identity access management bao gồm authentication, authorization và auditing, key/secret management hay data protection.

Nguồn: Blogger vnhacker

Có thể bạn chưa biết:

Vấn đề với điện thoại di động

Facebook bị hack và những nguy hiểm khó lường hết

Hack tài khoản Facebook, Twitter... trong nháy mắt

Hack khách hàng của Facebook Fanpage

Tớ đã hack trang SinhVienIT. net như thế nào?

Làm thế nào để chuỗi cung ứng không bị hack?

Thiếu niên 17 tuổi hack cả nhà mạng lớn ở Mỹ để dùng chùa ...

Facebook thưởng nóng $15000 cho hacker hack thành công tài ...

Hack facebook? Không ngờ đã có người hack trước rồi

Báo cho Facebook các nội dung xấu, nội dung sex...

Dirty COW - Lỗi bảo mật mới trên hệ điều hành Linux

Mật khẩu mặc định của các camera an ninh thông dụng trên thị trường

Cấm truy cập danh mục file và thư mục trên web server

Tại sao app Facebook lại có id là Katana (kiếm Nhật)

DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...

Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…

Quý khách xem Hồ sơ năng lực của DVMS tại đây >>

Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>