Tham dự Tech Lounge

Tham dự Tech Lounge


Thử nghiệm bảo mật của web và ứng dụng của một số ngân hàng tại VN

mrpaint
24/7/2016 12:42Phản hồi: 184
184 bình luận
Chia sẻ

Xu hướng

Đây là một dạng bài viết thể hiện đúng cái kiểu người viết "viết mà ko biết mình đang viết gì"

- Tiêu đề thì ghi là "Kiểm tra bảo mật cho web và ứng dụng", trong bài viết chỉ đề cập đến phần cấu hình TLS/SSL ở server side và client-side. Nên nhớ rằng, đó chỉ là phần rất nhỏ trong tổng thể các vấn đề bảo mật. Vì vậy, tiêu đề mang tính giật tít câu view. Đáng lý ra, tiêu đề phải là "Kiểm tra cấu hình kết nối TLS/SSL của ứng dụng web và mobile" để ko bị nhầm lẫn với các phương pháp kiểm tra khác.

- Sử dụng các tool có sẵn để thực hiện kiểm tra không phải là cách hay, đôi khi cần manual, người viết không biết (hoặc không thể) thực hiên với vài test cases, mà lại đưa ra kết luận quá vội vã -> Không có tính khách quan cao.

Đơn cử một ví dụ với Web của BIDV (www.bidv.vn:81). Có thể thực hiện kiểm tra sử dụng openssl, request lên lần lượt với 3 protocol TLSv1, TLSv1.1, TLSv1.2 để lấy thông tin:

openssl s_client -host bidv.vn -port 81 -tls1

openssl s_client -host bidv.vn -port 81 -tls1_1

openssl s_client -host bidv.vn -port 81 -tls1_2

Kết quả trả về là gì? 3 giao thức này dùng chung 1 cipher suite là DES-CBC3-SHA (POODLE attack)? Tại sao chỉ sử dụng duy nhất 1 cipher cho 3 protocol? Tại sao trong bài viết của người viết ko đề cập được điều này và kết luận "BIDV: vô địch tuyệt đối ở cả web và ứng dụng"?

Qua scan cho thấy server của BIDV chỉ chấp nhận 3 cipher là AES128-SHA, AES256-SHA và DES-CBC3-SHA.

- Phần ghi chú thêm của ACB có ghi "công nghệ cũ và có điểm yếu". Người viết ko thực sự biết DH là gì, thấy trong report ghi là weak thì bảo là nó "yếu". Thực tế nếu generate randomize DH parameter đủ dài (2048 bit, 4096 bit) thì vẫn được coi là an toàn. Việc này thực hiện rất dễ dàng, vậy nên ko thể nói là "công nghệ cũ", mà phải nói là "không biết cấu hình"
Phuongtv_76
ĐẠI BÀNG
8 năm
Đề nghị mod tinhte trả lương cho nhân viên qua BIDV ngay và luôn 😁
Diễn đàn tự do thì khi viết những bài kiểu như này cũng cần nghiên cứu cẩn thận kỹ lưỡng. Không phải viết cái gì thì viết.

Đồng ý với bạn, cần có những chứng cứ xác thực hơn, chứ không phải là cái bảng nhiều màu nào đấy được vẽ ra không dựa trên cơ sở căn cứ nào của chủ thớt.
mrpaint
TÍCH CỰC
8 năm
Chỗ đó không đánh giá luôn đó bạn.

CA đã từng bị leak private key rồi đó bạn. Tất nhiên là người dùng bình thường thì chả sao, nhưng an toàn hơn thì tại sao không nhỉ?

Điện thoại hoặc token vẫn có trường hợp mất mát hay bị chôm nha bạn, cẩn thận vẫn hơn.

Cái đó không dám múa rìu qua mắt thợ, mình chỉ là thằng tester =))
mrpaint
TÍCH CỰC
8 năm
Thử mấy cái này dễ ẹt mà hơi lâu chút xíu thôi, mình có để link dẫn tới mấy trang test luôn đấy bạn. Mà cũng toàn thông tin công cộng cả nên mình cứ nói rõ để ai muốn kiểm tra lại thì chạy thử.

Mình không biết hack bạn ơi :oops:

Ack, lúc thử mình có dòm mà không thấy dấu "=" nên không nghĩ là base64. Để mình sửa lại phần này. Cảm ơn bạn nhé.
mrpaint
TÍCH CỰC
8 năm
Đầu bài mình có nói rõ các bước trong khuôn khổ thử nghiệm rồi mà bạn. Những điểm ngoài lề xin phép không ý kiến. Ví dụ như cách tính điểm của SSL Labs như thế nào là việc của họ, còn trong bài này thì ngưỡng pass là điểm A trở lên. Có nhiều quan điểm liên quan khác nhau xem nên làm thế này hay nên làm thế kia, cái đó chắc để bàn trong một không gian khác chuyên về bảo mật hơn?

TLS vẫn mitm được nha bạn, đã từng có CA bị leak private key rồi đó huhu. MITM được thì chắc là chèn code tè le vô webview luôn.

Mật khẩu xài mã hóa một chiều là an toàn nhất luôn đó bạn.

Vụ Pinning thì cũng như trên, mỗi người một ý nhưng trong bài thử này thì sẽ pass nếu mà có xài. (Không xài thì kiểm tra tiếp đoạn mã hóa.)

Dà, ngày nào cũng vẫn phải học thêm nữa 😔
@mrpaint - Key bị leak chỉ là điều kiện cần, điều kiện đủ còn nhiều thứ khác, nếu CA đã leak, đủ thủ thuật để chặn package làm man in the middle xong rồi chèn code xong rồi, nó không đủ thông minh để disable cái mã hoá password password để đọc được luôn từ trình duyệt à? Lúc đó nó disable pinning certificate đi luôn chỉ là chuyện nhỏ vì nó chỉ là optional ở phía client, vì vậy trên web thì vứt 2 cái đó đi là vừa
- Pinning đã nói lúc đầu là nằm ở client, và HSBC có enable nó, Citibank dùng web view nên có cũng chẳng để làm gì nên họ không dùng.
Còn mã hoá 1 chiều mà nói bảo mật thì khác gì kiểu mình bị mắt lại rồi chắc không thằng nào thấy mình cả. Về ý nghĩa thì cho vui, vì nếu API đã chấp nhận mật khẩu đã được MD5 đi chẳng hạn, thì cái MD5 đấy cũng chính là password của người dùng, và thằng bên ngoài vẫn có thể dùng cái chuỗi MD5 đấy để truy cập vào API hoặc bank của người dùng để lấy tiền.
Có duy nhất bảo vệ cho những User dùng chung password ngân hàng cho tất cả ngân hàng khi 1 thằng bị mất password không dẫn đến mất password những thằng khác, bạn nghĩ coi ngân hàng nó nghĩ cho thằng đối thủ mình à?

Lỗ hổng bảo mật lớn nhất ở các công ty không phải là công nghệ an toàn, mà chính là ở những người tin rằng mình an toàn. Bạn làm cho người khác tin rằng mình an toàn.

- Ví dụ 1 flow mã hoá tốt nhất là sử dụng chìa khoá bên ngoài thật (như là token của HSBC, smart token mình cũng chẳng an tâm). Hoặc cao hơn nữa là smartcard (trên máy dell có).
x10man
ĐẠI BÀNG
8 năm
@mrpaint Nếu mật khẩu mã hoá 1 chiều nhưng chỉ có 2 ký tự thì có an toàn không ?
mrpaint
TÍCH CỰC
8 năm
@tin_truc22 Mới liên quan dến TLS mitm nè bác https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html

Mã hóa một chiều giảm thiểu rủi ro cho người dùng chứ bác, nhiều người giờ còn xài chung mật khẩu ở nhiều nơi (như bác nói). Với cả giờ không thấy ngân hàng nào cho chuyển khoản mà không có biện pháp xác thực phụ (cũng như bác nói) nên nguy cơ ở đây là về thông tin người dùng là chính. Về bảo mật mình thấy có khái niệm đa lớp rất hay, không một công cụ nào là bất khả xâm phạm nhưng kết hợp lại thì sẽ đủ để gây khó khăn và tạo dấu vết khi bị tấn công -> vì vậy trong khả năng có thể làm được gì thì nên cố làm càng nhiều càng tốt.

Mình nghĩ lỗ hổng bảo mật lớn nhất không phải do trong đầu nghĩ gì mà do con người nói chung luôn. Bảo mật cho cố vô xong bấm ba lăng nhăng tự dưng rơi vào bẫy xong lại hỏi tại sao tui bị hack.
@mrpaint đã bảo cái mã hoá ở client là useless rồi cứ cãi, kiếm 1 ngân hàng nào làm mã hoá ở client đi rồi mình nói tiếp, vậy hén.
mrpaint
TÍCH CỰC
8 năm
Chuẩn luôn bạn ơi, mấy cái món này là cứ phải làm định kì. Không biết có cao nhân nào rảnh viết báo cáo thường niên cho mọi người đọc không nhỉ?

Cái vụ BIDV bị hố hàng, để mình sửa lại. Còn mật khẩu mã hóa một chiều là chuẩn không cần chỉnh nha bác (hoặc xài 2fa).
webzone.vn
TÍCH CỰC
8 năm
@mrpaint
Mình thấy bạn có Test HSBC, Nhưng ko thấy bạn nói tới cái thiết bị bảo mật của HSBC toàn thấy BAD và FAIL.

Cái này cũng giống như OTP mình thấy rất bảo mật. Bạn nhận xét sao về thiết bị này (Mình đang dùng VCB và HSBC điều có thiết bị bảo mật này - DigiPass). VCB thì mỗi lần giao dịch cần đến nó. Còn HSBC ko có nó là ko login được.
@mrpaint
khi mà front end nằm ở đầu user, thuật toán ở đầu user -> hacker chỉ cần decode là có thể có nguyên bộ user + password -> việc này có thực sự cần thiết?
mrpaint
TÍCH CỰC
8 năm
Trên trang thấy link về cổng 81 bác ạ. Với cả https hình như không nói gì là cổng 443...
Cái vụ mã hóa bị nhiều gạch quá, để mình ghi rõ là mã hóa một chiều trong bài ạ.

Mình chỉ chạy thử được tới đây, sâu hơn không đủ trình rồi.

Dà, chưa được đi học cái chứng chỉ nào luôn bác ơi. Nội dung bài cũng không có thông tin gì bảo mật hay lỗi đâu ạ.

Bảo mật nhiều bước vậy thì an toàn hơn nhiều rồi. Hơi bất tiện thôi nhỉ?
mrpaint
TÍCH CỰC
8 năm
Anh em làm IT đều biết đời không bao giờ được như mơ 😔 Khổ lắm cơ.

Định hỏi nên làm như thế nào thì bác chơi luôn đoạn mở ngoặc =))

Thử cái đó nguy hiểm lắm bác, với cả chủ yếu là khó =))

Góp ý của bác hay quá, xin nhận và xin cảm ơn bác nhiều. Ngoài ra này chỉ xét điểm SSL Labs nên không có chạy thêm cái gì khác ạ.
Chỉ nhìn lớp sơn mà đánh giá bức tường.
squall1411
ĐẠI BÀNG
8 năm
Đọc topic này thấy hay quá, ngày xưa chọn nhầm nghề rồi 😔
quanqw
TÍCH CỰC
8 năm
Tính ra chỉ có kĩ năng xã hội mới bảo mật được thôi. Không cho ai biết dù là người thân.
Ps: Đang cần tìm một cô người yêu làm ngân hàng mà không có ai chịu.
Các bác cứ yên tâm mà dùng internetbanking, phần này các ngân hàng đều phải bỏ một đống tiền cho các hãng bảo mật. Ngoài lề một chút, các bạn lên đăng ký dịch vụ SMS để kiểm tra số dư, khi thấy bất thường báo vào tổng đài cskh là xong ngay vì việc toàn trong Vietnam thì kiểu gì cũng tìm được, và đây không phải là giao dịch chuyển tiền quốc tế lên không lo gì cả. Chuyển vào ngân hàng A rồi sang ngân hàng B rồi sang ví điện tử thì cũng tóm được thôi, vì liên quan ngân hàng đều phải có thông tin rõ ràng cả...Các bạn có kiến thức thì mình khuyên lên sử dụng vào những việc có ích và kiếm ra tiền hơn ngành này không dễ ăn cơm nhà nước lắm 😃 Người dùng internet banking không cung cấp mật khẩu cho bên thứ ba ( đọc, nhập ...)là yên tâm an toàn giao dịch. Giao dịch chứng từ giấy cũng rủi ro không kém đâu: Giả giấy chứng minh thư, giả chứ ký ...Internetbanking giờ hiện đại : Chuyền tiền, Gửi tiền online, rút tiết kiệm online (BIDV đã dùng), nạp tiền điện thoại, thanh toán cước internet, truyền hình cáp...sợ thì đưa tiền cho vợ cũng không hết đâu 😃)
BOT LOC
CAO CẤP
8 năm
Em định cài cái App của agribank mà thế này lại thôi. Vì cũng lười ra ngân hàng đăng ký xài app
mikan293
TÍCH CỰC
8 năm
Đang dùng TPBank mà ko thấy có,mai rut hết cắp đit cho an tâm 😔.
ngân hàng Shinhan korea đang dùng còn bị điểm C đợt hack thông tin người dùng nó cũng dính ngân hàng đền khối vi bị mất tiền khách hàng.shinhan việt nam bị điểm F quá tệ hại.
Leak private key là lớn chuyện rồi nha bạn. Private key mà mất thì chắc hacker nó vào tận thâm cung bí sử rồi nên không lấy chuyện test vòng ngoài cào cào vài ba cái bằng ssllab rồi phán là bảo mật hay không được.

Hash cũng chỉ là một cách để xác thực, nếu attacker có thể access vào db để overwrite hash thì không có ý nghĩa nha bạn. Nên không thể nói dùng hash là an toàn nhất vì an toàn dựa vào rất nhiều yếu tố. Bạn có biết md5 có thể bị trùng không (md5 bị ..... nên người ta mới chuyển qua SHA, giờ từ SHA256 lên SHA512)?

Mình hoàn toàn đồng ý với những gì bạn tin_truc nói. Ngoài ra, để đánh giá bảo mật của 1 ngân hàng phải cần 1 đánh giá tổng thể, từ web layer, web service, core database, từ lớp hardware đến software logic. Theo mình thì bạn chủ topic này không đủ kinh nghiệm lẫn kiến thức để đi đánh giá về bảo mật, gây hoang mang dư luận.
webzone.vn
TÍCH CỰC
8 năm
@levuhoang1234 Cái này đúng là nếu nhiều người không biết, sẽ về chuyển ngân hàng sang BIDV hết cho chắc 😔
traind
CAO CẤP
8 năm
ứng dụng mobile của BIDV khá chuối. Giao dịch dưới 5tr sẽ ko có mã OTP gửi về đt.
thinhmaya
ĐẠI BÀNG
8 năm
Mình dùng cả ứng dụng và wed của Vietcombank, đáng ngại nhỉ

Xu hướng

Bài mới









  • Chịu trách nhiệm nội dung: Trần Mạnh Hiệp
  • © 2024 Công ty Cổ phần MXH Tinh Tế
  • Địa chỉ: Số 70 Bà Huyện Thanh Quan, P. Võ Thị Sáu, Quận 3, TPHCM
  • Số điện thoại: 02822460095
  • MST: 0313255119
  • Giấy phép thiết lập MXH số 11/GP-BTTTT, Ký ngày: 08/01/2019