[Funland] Vụ 'bốc hơi' 5 tỷ trong tài khoản gửi tiết kiệm online

itnd · 12:11 21/04/2026

con dơi 141 nói:
Với em thì sao mà bắn đc 2 cái API cuối cùng đồng thời là rất khó. Ngang với robotic đồng bộ điều khiển theo thời gian thực, không độ trễ. Thậm chí cái gán khớp đến phần triệu giây cũng quá khó, quá trùng hợp.

Trong khi đó việc copy một bản ghi và chèn vào thì hợp lý hơn nhiều.
Và hiện tại bank ko có dữ liệu sinh trắc học khi chuyển khoản số tiền lớn, cụ giải thích sao về việc bypass đc yêu cầu theo luật?

Cụ đọc comment mới của em sẽ hiểu nhé, khi clientApp giả mạo thì mọi thông tin xác thực (gồm cả dữ liệu sinh trắc) đã được đồng thời chuyển cho bên thứ 3. Nó là cùng 1 clientApp (giả mạo/chỉnh sửa) thực hiện chứ robotic nào ở đây cụ.

XSim · 12:16 21/04/2026

haitotbung nói:
Theo thông tin trên báo thì ông này ham lãi suất cao của một người lạ trên facebook. Nạn nhân cũng "cẩn thận" đến phòng giao dịch của Kiên Long hỏi và được nhân viên Kiên Long cảnh báo lừa đảo. Nhưng chắc do mê muội lãi cao nên cố chấp làm theo.

xong giờ nạn nhân đi đổ vạ cho ngân hàng mong được đền tiền. Việc lu loa om xòm cũng sau quá trình đàm phán bất thành. Tất nhiên, nếu thực sự là lỗ hổng bảo mật của ngân hàng thì em tin ngân hàng sẽ chi luôn 5 tỷ để bịt miệng. Còn đây ngân hàng họ chỉ đề nghị 500tr gọi là hỗ trợ tinh thần thì khả năng lớn là lỗi của khách.

Giơd kiện cáo om xòm thì 1 triệu cũng không có

Nạn nhân bị lừa trên mạng thì có rất nhiều thể thức khác nhau, nhưng chỉ khi nạn nhân bị lừa trực tiếp cho OTP, quét mặt, vân tay của mình thì ngân hàng mới không có trách nhiệm. Còn lừa kiểu ở đây có ls cao, ... thì chả liên quan gì cả.

XSim · 12:21 21/04/2026

con dơi 141 nói:
Lỗi đó em hiểu nhưng ko thể reg 2 thiết bị đồng thời đc. Ngày giờ phút đăng jys thiết bị + ngày giờ gán tài khoản hoàn toàn khớp đến phần triệu của giây. Các thể loại share ...đều đi vòng nên không thể đồng thời, nhất là quá trình eKYC sẽ gây ra độ trễ lớn. Chỉ có thể là chèn vào DB.

Nhìn cách đánh tên trường DB thì thấy đội IT ở đây lôm côm nhỉ, đặt tên chả theo chuẩn mực gì cả, lại tối nghĩa nữa.

XSim · 12:27 21/04/2026

itnd nói:
À. E thêm 1 ý nữa vì có thể cụ ko làm việc liên quan tới bảo mật thì cụ sẽ không hiểu. Việc chèn vào DB (nếu có) thì cũng vô nghĩa. Vì bản chất là: clientApp (real/fake) xác thực > được chấp nhận (được thêm vào db) > server trả 1 key cho clientApp. Với key này (được bind với các thông số phần cứng của thiết bị) mới gen được SmartOtp. Nên việc chỉ chèn vào DB thì clientApp (fake) sẽ không có được key => vô nghĩa. Nên khả năng cao nhất của trường hợp này: phía backend có bug (không đánh chặn được trường hợp bất thường), phía khách hàng đã dùng 1 clientApp (đã bị can thiệp) để xác thực. Quá trình xác thực đã clientApp đó đã clone thêm 1 thiết bị giả mạo. Bước cuối cùng khi đã được chấp nhận thì private key kèm các thông số phần cứng giả mạo (mẹ bồng con) bị forward sang bên thứ 3.

Hình như các thiết bị giả mạo, bị can thiệp đều không thể cài app ngân hàng nữa mà nhỉ?

luyenok · 12:33 21/04/2026

XSim nói:
Hình như các thiết bị giả mạo, bị can thiệp đều không thể cài app ngân hàng nữa mà nhỉ?

Với điều kiện app ngân hàng biết đc đó là thiết bị ko đạt chuẩn

Ngoài ra thì app mà mình cài đó nó chỉ là cái vỏ thôi, với nhiều hệ thống ko tốt thì nó còn chả cần cài app mà gọi api trực tiếp để thực hiện các tác vụ luôn đó cụ.

trinhhunghb · 12:36 21/04/2026

Civic TN nói:
Cứ ra quầy gặp mấy cháu GDV cho vui cụ anh nhỉ

Được đón tiếp lão ạ . Xong còn được phong bì nữa

itnd · 12:37 21/04/2026

XSim nói:
Hình như các thiết bị giả mạo, bị can thiệp đều không thể cài app ngân hàng nữa mà nhỉ?

Nó đều nằm ở trình độ làm app và bảo mật thôi cụ. Cuối cùng nó đều quy là các lệnh gọi thuần về backend. Khi backend yếu thì cụ chẳng cần app nào cả, chỉ cần các lệnh raw cũng làm được mọi thứ.

XSim · 12:44 21/04/2026

luyenok nói:
Với điều kiện app ngân hàng biết đc đó là thiết bị ko đạt chuẩn
Ngoài ra thì app mà mình cài đó nó chỉ là cái vỏ thôi, với nhiều hệ thống ko tốt thì nó còn chả cần cài app mà gọi api trực tiếp để thực hiện các tác vụ luôn đó cụ.

Vâng với hệ thống thiết kế không tốt thì mọi thứ đều có thể xảy ra.

Có điều em nghĩ đã là ngân hàng thì hệ thống IT cũng phải đạt mức cơ bản nào đó thì họ mới dám mang ra dùng, chứ lởm đến mức bị lỗi sơ đẳng như cụ nói thì họ sập tiệm từ lâu rồi

con dơi 141 · 12:45 21/04/2026

itnd nói:
Cụ đọc comment mới của em sẽ hiểu nhé, khi clientApp giả mạo thì mọi thông tin xác thực (gồm cả dữ liệu sinh trắc) đã được đồng thời chuyển cho bên thứ 3. Nó là cùng 1 clientApp (giả mạo/chỉnh sửa) thực hiện chứ robotic nào ở đây cụ.

Em ko nói nó là Robotics. Em chỉ so sánh thôi. Ở đây là máy giả mạo chứ ko phải app giả mạo cụ nhé. Vẫn là 2 chient app thật. Nếu client app giả mạo thì đã không đăng ký trên DB 2 máy.

Và khi client app1 hoàn thành ekyc gửi thông điệp API thì bằng phương thức nào client app 2 biết trước để gửi đồng thời thông điệp API trùng khớp cả phần triệu giây?

con dơi 141 · Thứ ba lúc 13:15

itnd nói:
À. E thêm 1 ý nữa vì có thể cụ ko làm việc liên quan tới bảo mật thì cụ sẽ không hiểu. Việc chèn vào DB (nếu có) thì cũng vô nghĩa. Vì bản chất là: clientApp (real/fake) xác thực > được chấp nhận (được thêm vào db) > server trả 1 key cho clientApp. Với key này (được bind với các thông số phần cứng của thiết bị) mới gen được SmartOtp. Nên việc chỉ chèn vào DB thì clientApp (fake) sẽ không có được key => vô nghĩa. Nên khả năng cao nhất của trường hợp này: phía backend có bug (không đánh chặn được trường hợp bất thường), phía khách hàng đã dùng 1 clientApp (đã bị can thiệp) để xác thực. Quá trình xác thực đã clientApp đó đã clone thêm 1 thiết bị giả mạo. Bước cuối cùng khi đã được chấp nhận thì private key kèm các thông số phần cứng giả mạo (mẹ bồng con) bị forward sang bên thứ 3.

Khúc của cụ cũng chỉ đúng khi làm chuẩn chỉnh. Nếu key đc thiết kế lởm, ko bind vào ID máy thì vô nghĩa.
Và tại sao phần xác thực sinh trắc khi tạo lệnh thanh toán bank ko có dữ liệu? Dù đây là quy định bắt buộc trong luật?

Chí ít mỗi lần chient app1 vs client app2 đổi phiên thì phải xác thực. Bank ko cover đc thì tức là phần mềm ko đạt yêu cầu rồi.

Điều 2. Các tổ chức tín dụng, chi nhánh ngân hàng nước ngoài, tổ chức cung ứng dịch vụ trung gian thanh toán phải triển khai áp dụng các giải pháp giảm thiểu rủi ro trong thanh toán trực tuyến như sau:

1. Đối với khách hàng cá nhân, trước khi thực hiện giao dịch lần đầu bằng ứng dụng Mobile Banking hoặc trước khi thực hiện giao dịch trên thiết bị khác với thiết bị thực hiện giao dịch Mobile Banking lần gần nhất thì phải xác thực khách hàng:

itnd · 13:15 21/04/2026

con dơi 141 nói:
Em ko nói nó là Robotics. Em chỉ so sánh thôi. Ở đây là máy giả mạo chứ ko phải app giả mạo cụ nhé. Vẫn là 2 chient app thật. Nếu client app giả mạo thì đã không đăng ký trên DB 2 máy.

Và khi client app1 hoàn thành ekyc gửi thông điệp API thì bằng phương thức nào client app 2 biết trước để gửi đồng thời thông điệp API trùng khớp cả phần triệu giây?

Nói vậy mà cụ vẫn ko hiểu là do cụ ngoài ngành nên e giải thích thêm 1 lần nữa thôi nhé: chỉ có 1 clientApp (fake/đã bị chỉnh sửa) duy nhất gửi các lệnh này. Khi app thật đã bị reverse các logic về mã hóa đã bị sao chép thì bên tấn công muốn gửi thông tin nào đi cũng được. Kể cả là iphone18 (chưa ra mắt). Chỉ 1 vòng lặp thì nó có gen ra chục hay ngàn devices (với thương hiệu, imei, uid...khác nhau). Còn phần dữ liệu sinh trắc khi thanh toán không có thì em chưa thấy ở đâu nói tới, em hỏi thật. Nếu cụ có nguồn dẫn giúp em thao khảo thêm. Mà nếu nó bỏ qua thì cũng là 1 bug bên phía bank thôi. Mục tiêu đúng nhưng thực hiện không tốt thì thảm họa xảy ra thôi

itnd · 13:21 21/04/2026

con dơi 141 nói:
Khúc của cụ cũng chỉ đúng khi làm chuẩn chỉnh. Nếu key đc thiết kế lởm, ko bind vào ID máy thì vô nghĩa.
Và tại sao phần xác thực sinh trắc khi tạo lệnh thanh toán bank ko có dữ liệu? Dù đây là quy định bắt buộc trong luật?

Chí ít mỗi lần chient app1 vs client app2 đổi phiên thì phải xác thực. Bank ko cover đc thì tức là phần mềm ko đạt yêu cầu rồi.

Điều 2. Các tổ chức tín dụng, chi nhánh ngân hàng nước ngoài, tổ chức cung ứng dịch vụ trung gian thanh toán phải triển khai áp dụng các giải pháp giảm thiểu rủi ro trong thanh toán trực tuyến như sau:

1. Đối với khách hàng cá nhân, trước khi thực hiện giao dịch lần đầu bằng ứng dụng Mobile Banking hoặc trước khi thực hiện giao dịch trên thiết bị khác với thiết bị thực hiện giao dịch Mobile Banking lần gần nhất thì phải xác thực khách hàng:

Khổ quá. Ngay từ đầu em đã nói là backend phía bank có bug chứ có phải nói nó không có bug đâu. Tuy nhiên, nếu không có sự "giúp sức" của "bị hại" (em không nói cụ thể trường hợp khách hàng này nhé) thì cũng không thể lấy tiền được. Nếu dùng app chính chủ không can thiệp thì sẽ không khai thác được lỗi trên, nhưng đây cũng là vấn đề nghiêm trọng, Bank không phát hiện ngăn chặn được từ sớm là yếu kém

con dơi 141 · 13:22 21/04/2026

itnd nói:
À e trả lời thêm vụ cùng 1 thời điểm gán 2 điện thoại là không thể. Cái này là "mục tiêu" đúng với mọi hệ thống tương tự, với điều kiện là hệ thống phải được lập trình tốt. Còn trường hợp này hệ thống lập trình không tốt nên khi bị 2 luồng gần như gọi đồng thời nó đã không chặn được. Giống chương trình khuyến mãi giá 1000đ cho 10 chiếc iphone 17 tại 1 giờ nhất định, vài trăm ngàn ông canh "giật slot", nếu hệ thống tốt thì chỉ đúng 10 ông giật được slot này, nếu hệ thống tệ thì có khi cả ngàn ông lọt qua

Làm hệ thống bank mà ko nắm đc và biết xử lý vấn đề đó thì là lỗi nghiêm trọng rồi. Hệ thống core bank khi openning sẽ chạy cả trăm nghìn lệnh. Nếu dính lỗi sơ đẳng như cụ thì balance check toang ngay. Cụ so với canh giật Iphone thì ko hiểu về kinh doanh rồi. Bọn lập trình thừa sức chặn overbooking nhưng nó cố tình để mua hụt để tăng độ hót, tăng traffic, thu thập dữ liệu người dùng...

con dơi 141 · 13:27 21/04/2026

itnd nói:
Nói vậy mà cụ vẫn ko hiểu là do cụ ngoài ngành nên e giải thích thêm 1 lần nữa thôi nhé: chỉ có 1 clientApp (fake/đã bị chỉnh sửa) duy nhất gửi các lệnh này. Khi app thật đã bị reverse các logic về mã hóa đã bị sao chép thì bên tấn công muốn gửi thông tin nào đi cũng được. Kể cả là iphone18 (chưa ra mắt). Chỉ 1 vòng lặp thì nó có gen ra chục hay ngàn devices (với thương hiệu, imei, uid...khác nhau). Còn phần dữ liệu sinh trắc khi thanh toán không có thì em chưa thấy ở đâu nói tới, em hỏi thật. Nếu cụ có nguồn dẫn giúp em thao khảo thêm. Mà nếu nó bỏ qua thì cũng là 1 bug bên phía bank thôi. Mục tiêu đúng nhưng thực hiện không tốt thì thảm họa xảy ra thôi

Đây cụ nhé. Yêu cầu sinh trắc học và kết quả thực hiện.
Khách hàng không phải Master, bank với kiến thức, kinh nghiệm, tiềm lực kinh tế tài chính sẽ phải tiên liệu. Cụ phán như bệnh nhân hướng dẫn bác sĩ mổ ấy.

Một điều nữa là cái iphone concon đó khi trình báo, nếu dính client app fake thì đã đx công bố bởi CA rồi, theo cụ có khó không. Hiện tại em ko thấy thông báo vậy

itnd · 13:27 21/04/2026

con dơi 141 nói:
Làm hệ thống bank mà ko nắm đc và biết xử lý vấn đề đó thì là lỗi nghiêm trọng rồi. Hệ thống core bank khi openning sẽ chạy cả trăm nghìn lệnh. Nếu dính lỗi sơ đẳng như cụ thì balance check toang ngay. Cụ so với canh giật Iphone thì ko hiểu về kinh doanh rồi. Bọn lập trình thừa sức chặn overbooking nhưng nó cố tình để mua hụt để tăng độ hót, tăng traffic, thu thập dữ liệu người dùng...

Thì rõ ràng 2 "thiết bị" kích hoạt ở thời gian cực gần nhau mà không chặn được là bug rõ ràng đó thôi. Cụ hơi bị nhầm ở hệ thống lớn nhé, việc giải quyết vài trăm ngàn event ở 1 cùng 1 thời điểm nó không đơn giản như cụ nghĩ đâu. Làm chơi chơi nhỏ nhỏ ai cũng thấy dễ, nhưng để đáp ứng đúng và hiệu quả thì tiền tấn đấy. Thôi e xin dừng tiếp chuyện với cụ

itnd · 13:30 21/04/2026

con dơi 141 nói:
Đây cụ nhé. Yêu cầu sinh trắc học và kết quả thực hiện.
Khách hàng không phải Master, bank với kiến thức, kinh nghiệm, tiềm lực kinh tế tài chính sẽ phải tiên liệu. Cụ phán như bệnh nhân hướng dẫn bác sĩ mổ ấy.

Một điều nữa là cái iphone concon đó khi trình báo, nếu dính client app fake thì đã đx công bố bởi CA rồi, theo cụ có khó không. Hiện tại em ko thấy thông báo vậy

Đã nói rồi. Nó có thay đổi thiết bị đâu, nó thực hiện 2 lệnh đăng ký cùng lúc (thời điểm đó db chưa có thiết bị nào nên đều check pass). Và do đánh chặn không tốt nên mới xảy ra vấn đề trên. Khi đã reverse được clientApp thì mô phỏng được mọi thiết bị, mọi thông số. Còn iPhone với Android gì ở đây nữa

con dơi 141 · 13:32 21/04/2026

itnd nói:
Thì rõ ràng 2 "thiết bị" kích hoạt ở thời gian cực gần nhau mà không chặn được là bug rõ ràng đó thôi. Cụ hơi bị nhầm ở hệ thống lớn nhé, việc giải quyết vài trăm ngàn event ở 1 cùng 1 thời điểm nó không đơn giản như cụ nghĩ đâu. Làm chơi chơi nhỏ nhỏ ai cũng thấy dễ, nhưng để đáp ứng đúng và hiệu quả thì tiền tấn đấy. Thôi e xin dừng tiếp chuyện với cụ

Em làm cùng đội dev suốt. Cái request đó chẳng hiếm lạ gì cụ nhé. Nên là bank thì phải đáp ứng dù là khó. Cụ đừng đánh đồng 2 việc với nhau vì đó là critical requirement.

itnd · 13:33 21/04/2026

con dơi 141 nói:
Em làm cùng đội dev suốt. Cái request đó chẳng hiếm lạ gì cụ nhé. Nên là bank thì phải đáp ứng dù là khó. Cụ đừng đánh đồng 2 việc với nhau vì đó là critical requirement.

Vậy mà rất nhiều cái cơ bản mà nãy giờ cụ chả hiểu gì cả. Thôi e xin phép tạm dừng

con dơi 141 · 13:34 21/04/2026

itnd nói:
Đã nói rồi. Nó có thay đổi thiết bị đâu, nó thực hiện 2 lệnh đăng ký cùng lúc (thời điểm đó db chưa có thiết bị nào nên đều check pass). Và do đánh chặn không tốt nên mới xảy ra vấn đề trên. Khi đã reverse được clientApp thì mô phỏng được mọi thiết bị, mọi thông số. Còn iPhone với Android gì ở đây nữa

Cụ ko hiểu ý tôi. 2 bước sinh trắc thì evidence bước sinh trắc khi lập lệnh đâu

taiadau · 13:35 21/04/2026

itnd nói:
Thì rõ ràng 2 "thiết bị" kích hoạt ở thời gian cực gần nhau mà không chặn được là bug rõ ràng đó thôi. Cụ hơi bị nhầm ở hệ thống lớn nhé, việc giải quyết vài trăm ngàn event ở 1 cùng 1 thời điểm nó không đơn giản như cụ nghĩ đâu. Làm chơi chơi nhỏ nhỏ ai cũng thấy dễ, nhưng để đáp ứng đúng và hiệu quả thì tiền tấn đấy. Thôi e xin dừng tiếp chuyện với cụ

TPS lên đến vài trăm ngàn thì em nghĩ ở VN mình rấ hiếm có hệ thống để xử lý tốt nó (đỉnh cấp cỡ OCS của telecom thì may ra) còn banking thì vài nghìn là xịn xò rồi (cá biệt có 1 số hệ thống thanh toán trên thế giới may ra mới đạt con số đến mức vài trăm nghìn)

[Funland] Vụ 'bốc hơi' 5 tỷ trong tài khoản gửi tiết kiệm online

Xe hơi

Xe lăn

Xe lăn

Xe lăn

Xe điện

Xe cút kít

Xe hơi

Xe lăn

Xe điện

Xe điện

Xe hơi

Xe hơi

Xe điện

Xe điện

Xe hơi

Xe hơi

Xe điện

Xe hơi

Xe điện

Xe điện

Thông tin thớt