Trong những năm gần đây, Việt Nam luôn là một trong những quốc gia có tỉ lệ nhiễm mã độc và hứng chịu các cuộc tấn công mạng thuộc nhóm cao trên thế giới. Bên cạnh đó, mức độ sử dụng máy tính và các thiết bị thông minh tại Việt Nam tăng đột biến do ảnh hưởng của COVID-19, và đây cũng chính là môi trường lý tưởng để virus bùng phát, lây lan mạnh. Điều nay làm dấy lên mối lo ngại về an ninh trên không gian mạng, một vấn đề mà ít người Việt quan tâm đến nhưng lại có tầm quan trọng cao và sức ảnh hưởng lớn. Chính vì lí do đó, ở số Techtalk #46 này, Grokking Việt Nam xin giới thiệu với các bạn chủ đề “Những bài học về xâm nhập và bảo vệ hệ thống mạng Việt Nam” do anh Dương Ngọc Thái trình bày. Anh Thái hiện đang làm việc tại Google, anh thường được biết đến thông qua blog cá nhân vnhacker@blogspot. "Từ năm 2016, cùng với vài người bạn, tôi đã xâm nhập vào hệ thống mạng máy tính của nhiều ngân hàng, bệnh viện, startup ở Việt Nam (với sự đồng ý của họ). Đối với các ngân hàng, chúng tôi đã có thể đánh cắp được lượng tiền lớn và nhiều dữ liệu nhạy cảm. Đối với các bệnh viện, chúng tôi đã có thể đánh cắp toàn bộ dữ liệu khách hàng và thậm chí có thể thay đổi hồ sơ bệnh án. Trong bài nói chuyện này, tôi chia sẻ những gì chúng tôi đã học được, cung cấp thông tin về hiện trạng an ninh mạng ở Việt Nam. Tôi cũng đưa ra một cẩm nang giúp các doanh nghiệp và tổ chức bảo vệ tài sản và dữ liệu, tạo ra những sản phẩm được khách hàng tin tưởng." - Anh Thái chia sẻ về mục đích của bài talk.

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?