Tổng quan

Bức tranh kênh thanh toán online

Ngày nay, việc mua bán online hay thanh toán trực tuyến là một hoạt động diễn ra hết sức phổ biến, ít nhất trong chúng ta đều đã sử dụng chúng không dưới một lần hoặc đang sở hữu một tài khoản ngân hàng, thanh toán online trên các kênh mua sắm. Các dịch vụ mua sắm không chỉ mang lại sự tiện lợi, dễ sử dụng mà còn giúp giảm thiểu thời gian cũng như công sức mua sắm cho người dùng. Hơn nữa, các chương trình khuyến mãi và hậu mãi càng làm việc sử dụng các thanh toán online trở nên phổ biến hơn. Hầu hết các nhà bán hàng đều tạo cho mình những kênh thanh toán trực tuyến hoặc sử dụng dịch vụ bên thứ ba cung cấp cho phép người dùng thanh toán online.

Dù việc thanh toán online có nhiều ưu điểm và tiện lợi nhưng bên cạnh đó nó cũng phải đối mặt với rất nhiều những nguy cơ tấn công đến từ những kẻ tấn công trên internet. Nếu các kênh thanh toán online không tuân thủ theo những biện pháp bảo mật hoặc không triển khai các biện pháp bảo vệ an toàn thì rất có thể là mục tiêu tấn công của kẻ xấu. Một khi các hệ thống này bị tấn công, không chỉ người dùng mà ngay cả bản thân những nhà bán hàng cũng sẽ phải chịu những tổn thất lớn về kinh tế cũng như danh tiếng. Vậy các hệ thống về tài chính, thanh toán online thường gặp phải các lỗ hổng bảo mật như thế nào chúng ta cùng tìm hiểu trong bài viết này nhé!!

(Nguồn: https://www.cyberdb.co/financial-cyber-attacks-in-2021/)

Một số cuộc tấn công tài chính lớn

Một số cuộc tấn công vào các công ty, dịch vụ tài chính lớn tính đến năm 2022:

• First American Financial Corp Data Breach (5/2019): Hơn 885 triệu hồ sơ tài chính và cá nhân liên quan đến các giao dịch bất động sản đã bị lộ thông qua một lỗ hổng web phổ biến
• Equifax Data Breach (9/2017): Dữ liệu cửa 147 triệu khách hàng bị lỗ thông qua lỗ hổng CVE-2017-5638
• Heartland Payment Systems Data Breach (1/2008): Dữ liệu của 130 triệu số thẻ ghi nợ và thẻ tín dụng bị hacker đánh cắp
• Và rất nhiều các cuộc tấn công khác, bạn đọc có thể xem thêm tại : https://www.upguard.com/blog/biggest-data-breaches-financial-services

II. Các lỗ hổng thường gặp trong các ứng dụng tài chính - ngân hàng

1. Time-of-Check-Time-of-Use (TOCTOU) and Race Condition Issues

TOCTOU là lỗi phần mềm xảy ra khi ứng dụng kiểm tra trạng thái của tài nguyên trước khi sử dụng chúng. Hay hiểu đơn giản, bạn có thể sử dụng tài nguyên đó nhiều lần trước khi ứng dụng có thể kiểm tra và giới hạn. Thời gian và trình tự đặt hàng là rất quan trọng để điều chỉnh các hoạt động của phần mềm tài chính. Nhiều giao dịch tài chính dựa vào việc kiểm tra số dư và giá trị (đôi khi theo thời gian thực) trước khi xử lý. Lỗ hổng này thường xảy ra khi ứng dụng xử lý tài nguyên bằng các thread khác nhau mà không thực hiện đồng bộ dữ liệu khi xử lý. Nó cũng được gọi với tên: Race Conditions

1.1 Transferring Money or Points, or Buying Items Simultaneously

Một ví dụ đơn giản cho lỗ hổng này như sau:

Một ứng dụng ngân hàng khi chuyển tiền sẽ thực hiện kiểm tra số dư trước khi chuyển và thực hiện cộng tiền vào tài khoản nhận và trừ tiền từ tài khoản gửi với cùng một số tiền. Hacker tấn công bằng việc gửi rất nhiều request trong một thời điểm khiến cho hệ thống không kịp xử lý và từ đó khiến ứng dụng hoạt động sai logic.

Ví dụ trong tài khoản bạn đang có 10.000.000 vnd, hacker sử dụng công cụ thực hiện chuyển khoản 1 triệu với rất nhiều request gửi cùng một thời điểm. Trong cùng lúc đó, ứng dụng chia nhiều threads để xử lý đồng thời 3 công việc: trừ tiền tài khoản gửi, kiểm tra số dư và cộng tiền số tài khoản nhận. Kết quả là tài khoản hacker bị trừ 10.000.000 vnd nhưng tài khoản nhận lại nhận được 12.000.000 vnd. Đồng nghĩa ứng dụng đã bị lỗ hổng TOCTOU hay Race condition.

1.2 Changing the Order upon Payment Completion

Các ứng dụng cho phép người dùng thay đổi đơn đặt hàng của họ trong khi thanh toán cho một mặt hàng cũng có thể dễ bị tấn công khi không thực hiện lại xác minh cuối cùng trước khi thanh toán. Trong trường hợp này, đơn hàng có thể được thay đổi khi người dùng đang ở trạng thanh toán và trước khi nhấp vào nút “thanh toán” để hoàn tất thanh toán. Việc thay đổi các mặt hàng trong giỏ, phương thức vận chuyển và địa chỉ đăng, số lượng mặt hàng, v.v. có thể ảnh hưởng đến giá cuối cùng trong khi ứng dụng vẫn sử dụng giá rẻ hơn ban đầu.

Ví dụ hacker sẽ 2 tab khác nhau trên trình duyệt: Tab số 1 thực hiện việc thanh toán nhưng chưa nhấn nút thanh toán ở bước cuối (Ví dụ đang có 3 sản phẩm trong giỏ với giá 1 triệu đồng) Tab số 2, thực hiện việc tăng số lượng sản phẩm, số lượng voucher, đổi địa điểm giao hàng... (Thay đổi thành 5 sản phẩm)

Sau khi thay đổi ở bước 2, tiến hành thanh toán hệ thống chỉ kiểm tra tiền ở tab 1 và trừ 1 triệu nhưng đơn hàng thì thanh toán thành công với số lượng sản phẩm là 5.

1.3 Changing the Order after Payment Completion

Việc cập nhật chi tiết trong một đơn đặt hàng đã hoàn thành, hóa đơn hoặc báo giá đã tạo có thể dẫn đến những lỗ hổng gây tổn thất tài chính. Điều này có thể xảy ra khi một ứng dụng không xác minh trạng thái của một giao dịch đã hoàn thành. Do đó, có thể thêm nhiều mặt hàng hơn vào đơn đặt hàng đã hoàn thành, sửa đổi các mặt hàng hiện có để sử dụng được các đãi hiện có hoặc thay đổi các chi tiết khác mà không phải trả thêm phí.

1.4 Các chức năng khác có thể dễ bị lỗi và cách phòng tránh

Một số chức năng có thể bị lỗ hổng này nếu không được kiểm tra và giới hạn số request gửi lên:

• Chuyển điểm, nhận điểm
• Lấy voucher giảm giá, sử dụng mã giảm giá
• Tặng, gửi, nhận quà hoặc tiền
• Chức năng mua hàng
• Chức năng vote, upvote, like...

Một số lỗi trong thực tế Một lỗ hổng Race-Condition trong ứng dụng mua bán vé số Vietlott được tìm ra bởi một nhà nghiên cứu bảo mật tại Việt Nam: Lỗ hổng xảy ra trong chức năng rút tiền cho phép kẻ tấn công có thể rút nhiều hơn số tiền có trong tài khoản bằng cách thực hiện gửi rất nhiều request rút tiền trong một khoảng thời gian ngắn. Do cơ chế xử lý Load Balance của server chưa thực sự tốt khi người dùng gửi request nên đã gây ra lỗi này.

Biện pháp phòng tránh:

• Giới hạn request gửi đến enpoint đó trong một thời điểm, sử dụng Capcha
• Luôn luôn thực hiện lấy dữ liệu giá, đơn hàng trên server để tránh can thiệp từ người dùng
• Ứng dụng luôn kiểm tra lại đơn hàng trước khi thanh toán hoặc không cho phép thay đổi khi đơn hàng đã thanh toán thành công
• Sử dụng cơ chế đồng bộ hóa dữ liệu trên server
• Một số ngôn ngữ hỗ trợ threads lock để hạn chế việc hệ thống can thiệp vào dữ liệu đang xử lý bởi thread khác: threading.lock python

2. Parameter Manipulation

Thay đổi hoặc thêm bớt các tham số trong request được gửi từ người dùng lên server để khiến các ứng dụng thực hiện mọi việc theo cách mà người dùng thường không thể làm được như bình thường.

2.1 Price Manipulation

Thông thường các ứng dụng thanh toán sẽ sử dụng các tham số trong request của người dùng gửi lên để xác định được sản phẩm mà người dùng muốn mua (thông qua id của sản phẩm), số lượng sản phẩm họ muốn mua, địa chỉ giao hàng, số điện thoại... Tuy nhiên, giá của sản phầm là trường mà người dùng sẽ không được nhập. Các ứng dụng có thể tính giá tiền của đơn hàng bằng cách gửi kèm một hidden param ở trong form là giá của sản phẩm hoặc theo cách truy vấn giá của sản phẩm trong database.

Với cách làm sử dụng hidden param sẽ dễ bị kẻ tấn công can thiệp và sửa giá sản phẩm bằng các công cụ proxy như BurpSuite để thay đổi giá trị đơn hàng. Còn với cách lấy giá trong database thì kẻ tấn công sẽ không tấn công bằng cách này.

Trong một báo cáo của NCC Group khi kiểm tra một ứng dụng thanh toán, họ phát hiện ra một lỗ hổng bảo mật. Họ gửi giá sản phẩm trong hidden param nhưng khi thanh toán, họ loại bỏ tham số này mà sử dụng giá trong database. Tuy nhiên, với những sản phẩm nằm trong danh mục khuyến mãi thì họ lại sử dụng giá trong hidden param gửi lên từ client, từ đó kẻ tấn công có thể sửa giá của sản phẩm.

2.2 Currency Manipulation

Lỗ hổng xảy ra khi người dùng sử dụng nhiều đơn vị tiền tệ khác nhau trong quá trình thanh toán. Một ví dụ, người dùng thanh toán £20 (20 bảng anh) cho một trang web, người dùng sử dụng tùy chọn thanh toán PayPal.

1. Kẻ tấn công sửa request trang web gửi đến trang web PayPal và thay đổi tham số tiền tệ từ “GBP” (Bảng Anh) sang “INR” (Rupee Ấn Độ) .
2. Sau khi hoàn tất giao dịch trên trang web PayPal với 20 Rupee Ấn Độ, trang web đã ủy quyền giao dịch mà không cần kiểm tra tiền tệ
3. Người dùng thanh toán thành công đơn hàng với giá 20 bảng Anh trong khi chỉ có £0,22 được rút từ tài khoản PayPal của kẻ tấn công

2.3 Quantity Manipulation

Các trang web tính giá cuối cùng dựa trên số lượng mặt hàng đã mua. Vì vậy, hacker có thể thay đổi tham số này để chứa các giá trị nhỏ hoặc âm, nhằm ảnh hưởng đến giá cuối cùng trang thanh toán. Hacker có thể giảm số lượng số âm để giá trị đơn hàng giảm. Trang web có thể xóa các mặt hàng có giá trị bằng 0 hoặc âm trong tham số số lượng. Trong trong trường hợp này, các giá trị thập phân như “0,01”, “0,51” hoặc “0,996” có thể được kiểm tra để xem chúng có ảnh hưởng gì không trên giá cuối cùng.

Đôi khi hình thức tấn công chỉ ảnh hưởng đến logic của hệ thống, nhưng cũng có thể gây thiệt hại đến kinh tế.

2.4 Additional Costs Manipulation

Đôi khi kẻ tấn công có thể chèn thêm các mã giảm giá, khuyến mại vào request dù thông thường sản phẩm không được áp dụng khuyến mại. Nếu trên server xử lý không đúng có thể dẫn đến việc kẻ tấn công có thể sử dụng thành công mã giảm giá, khuyến mại để mua hàng với giá trị thấp hơn.

2.5 Mass Assignment, Autobinding, or Object Injection

Điều này xảy ra khi một ứng dụng chấp nhận các tham số bổ sung khi chúng được đưa vào một yêu cầu. Điều này có thể xảy ra ở một số ngôn ngữ hoặc framework như Ruby on Rails, NodeJS, Spring MVC, ASP NET MVC và PHP. Đây có thể là vấn đề đối với ứng dụng tài chính khi dữ liệu liên quan đến chi phí có thể bị thêm bớt để thay đổi giá cuối cùng của đơn hàng.

Tham khảo thêm lỗ hổng Mass Assignment ở tại bài viết: Lỗ hổng Mass Assignment và cách phòng tránh

2.6 Repeating an Input Parameter Multiple Times

Điều này rất hiếm khi xảy ra, nhưng việc lặp lại một tham số đầu vào trong một yêu cầu đến ứng dụng hoặc đến cổng thanh toán có thể gây ra các vấn đề logic. Một ví dụ là chúng ta gửi nhiều mã trong một request để được áp dụng nhiều lần:

Cách phòng tránh

• Sử dụng giá sản phẩm bằng cách truy vấn trên server, không nhận từ phía client
• Luôn luôn kiểm tra request được gửi từ phía client: -Whitelist các trường được phép cập nhật
  • Blacklist các trường không được phép cập nhật
• Sử dụng Data Transfer Objects (tham khảo tại đây). DTO định nghĩa chính xác các trường dữ liệu được phép bind.

Tổng kết

Trên đây là 2 kiểu tấn công cơ bản mà các ứng dụng về tài chính dễ bị kẻ tấn công lợi dụng để tấn công. Để phòng tránh các lỗ hổng trên đòi hỏi nhà phát triển phải hiểu rõ cơ chế hoạt động của hệ thống cũng như cách thức tấn công của hacker để từ đó triển khai các biện pháp bảo vệ phù hợp. Phần tiếp theo chúng ta sẽ bàn tới các loại lỗ hổng khác.

References

Bài viết được viết dựa trên nội dung của bài viết thuộc về NCC Group: https://soroush.secproject.com/downloadable/common-security-issues-in-financially-orientated-web-applications-_v1.1.pdf