Tài liệu trình bày những bài học từ việc hack và bảo vệ các mạng máy tính của ngân hàng Việt Nam, nhấn mạnh rằng sự phụ thuộc vào an toàn thông qua sự mơ hồ đã dẫn đến nhiều lỗ hổng bảo mật nghiêm trọng. Các tác giả đã thành công trong việc chiếm đoạt tiền từ tài khoản ngân hàng thông qua các phương pháp kỹ thuật phá vỡ mã và đã đưa ra nhiều khuyến nghị nhằm cải thiện an ninh mạng. Cuối cùng, tài liệu cảnh báo về việc các nhóm tội phạm có khả năng gây thiệt hại lớn nếu có đủ nguồn lực.

1. Lessons from years of hacking
and defending
Vietnamese computer networks
Thái Dương, joint work with An Trịnh

2. Disclaimer
All hacks described in this talk were done with permission.
Many details are intentionally vague to protect the involved parties.
Opinions are our own.

3. whoami
● Product security/cryptography tech lead at Google
● Co-founder of popular cryptography projects Wycheproof and Tink
● Works featured on the NYTimes, BBC, taught at Stanford, MIT
● Notable awards and honors
○ 2010, 2011, 2012 - 1st place of Top 10 Web Hacking Techniques
○ 2011 - Winner of Pwnie Awards “Best Server-Side Bug”
○ 2017 - Winner of Google “Technical Infrastructure Awards”
○ 2020 - Winner of Google “Feats of Engineering Awards”

4. Agenda
Our adventures in hacking & defending Vietnamese banks
How banks got hacked & what you should do to avoid the same fate
Bonus: who are the hackers?

5. Why I started hacking Vietnamese banks

6. Case studies

7. Case study #1: mobile banking apps
All I had was a heavily obfuscated Android app.
It took me two weeks of very hard (yet exciting!) work to reverse engineer the app.
The result was terrifying: I could programmatically steal money from any accounts.

8. Did the bank care?
Yes. Security is front and center in the mind of bank executives and engineers.
Then... why did they get it wrong so badly?

9. “There are two ways of constructing a
software design: One way is to make
it so simple that there are obviously
no deficiencies, and the other way is
to make it so complicated that there
are no obvious deficiencies.”
Tony Hoare

10. Security through obscurity
The app was so heavily obfuscated that its obvious vulnerabilities were hiding in
plain sight for years.
Security through obscurity is not bad, but the bank relied on it as its sole defense.

11. Absence of security engineering
Security engineering is the art and science of balancing safety and usability.
The app, however, overdid security at the expense of usability and underdid
security at the expense of safety.
Root cause: Vietnam lacks people that can engineer security.

12. 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. Tôi thấy sự an toàn của
<đã lược bỏ> phụ thuộc hoàn toàn vào việc giữ bí mật giao thức giữa app và máy chủ.
Đối với sản phẩm tài chính ngân hàng như <đã lược bỏ>, an toàn luôn được đặt lên hàng đầu.
Kiện toàn bảo mật cho một ứng dụng như thế này không quá khó, khó khăn nằm ở chỗ làm sao
cho an toàn mà lại không gây ảnh hưởng đến trải nghiệm của người sử dụng. Tôi thấy <đã
lược bỏ> chưa có sự cân bằng giữa an toàn và trải nghiệm người dùng.
Trích “Báo cáo kiểm tra bảo mật <đã đục bỏ>”

13. Case study #2: digital banking platform
Once again, I was only given a heavily obfuscated APK.
I wasn’t too excited, so reverse engineering went sluggish for months.
Then I teamed up with An Trịnh.

14. “Instead of reverse engineering, why don’t
we just hack [the bank] to steal their
source code?”
An Trịnh

15. “The attack surface is the vulnerability -
finding a bug there is just a detail.”
Mark Dowd
Infrastructure
DevOps
Backend
Apps

16. How we stole money from any accounts
Using a series of 0-day/N-day vulnerabilities, we compromised a test system and
obtained the source code of the digital banking servers.
We audited the code and found 3 different ways to, once again, programmatically
steal money from any accounts.
This is a recurring theme.

17. A fun vulnerability: predictable SMS OTP
The bank generated OTP using java.lang.Math.random() which calls java.util.Random.
But:
Result: given two consecutive OTPs, can predict the rest.

18. What went wrong?
The bank exposed a large attack surface with tons of outdated software.
Once we had a foothold within the bank’s network, the whole internal network was
wide open.
The digital banking platform was poorly software engineered.

19. What have we learned?

20. Lesson #1: Accept that prevention would eventually fail,
invest in detection and response
Security
D
e
t
e
c
t
i
o
n
Prevention
R
e
s
p
o
n
s
e

21. Lesson #2: Simulate APT regularly
Nothing makes people care more about security than witnessing the theft of
millions of dollars.

22. Lesson #3: Engineer away security issues
If your security team can’t code, you’re doing it wrong.
Security is an engineering discipline, solve it with technology, not regulations.
Security product != product security.

23. Lesson #4: Bundle security as a product feature
Product (in)security is a consequence of (bad) software engineering practices.
Only prisons need maximum security, what you need is usable security.

24. Lesson #5: Assume that your opponents know everything
When designing and evaluating the security of your system, assume that all
source code and documentation are publicly available.
Focus on insider threats.

25. “The enemy knows the system.”
Claude Shannon

26. Top things that help
Red teaming
Cloud, Cloud, Cloud
Two factor authentication for employees
Vulnerability management
SecDevOps
Centralized logging
Bug bounty
Trích Báo cáo “Làm an toàn thông tin cho doanh
nghiệp là làm gì?

27. Who are the attackers?

31. One more thing

32. Final thought
It never took us more than a few weeks to steal money from any networks that
we’ve engaged with.
We could have totally destroyed these banks or hospitals, and caused a
short-term collapse of the Vietnamese economy.
If such a small team like ours could do this, what could more resourceful
adversaries do?