Mới đó mà cũng đã 2 tháng kể từ bài đầu tiên của series này, ngày hôm qua mình xem lại thống kê bài viết mới nhớ ra là vẫn còn nợ mấy phần sau của series. Thực ra mình cũng muốn tiếp tục series này lâu ròi, nhưng cứ đặt tay vào viết thì hết M$ ròi tới Oracle lại ra patch, nên là mới bị delay tới bây giờ đây.
Như đã biết ở phần trước, mình có nói về 1 mảng nhỏ của ATTT, Kiểm thử xâm nhập — Penentration Testing, cũng như các yêu cầu đặc thù của nghề này. Trong đó mình cũng có đề cập tới một nhóm Reseacher nhỏ, đóng vai trò hỗ trợ, cung cấp các công cụ, mã khai thác cho pentester.
Hiện nay những người làm công việc này được gọi với nhiều cách gọi khác nhau, người thì gọi là Bug Hunting, người thì gọi là Security Researching, hay có một số gọi là nghề đục lỗ (Exploitation), vv…
Nhưng chung quy lại, đều là đi vào tìm kiếm lỗ hổng trên một đối tượng nào đó, tùy từng đối tượng khác nhau mà có thể cách gọi cũng khác theo.
Với tên gọi Security Researcher nó rất là rộng, và thường là được dùng để gọi chung những người làm về mảng nghiên cứu của ATTT, không riêng gì những người làm nghề đục lỗ! ¯_(ツ)_/¯
Bởi vì bên cạnh mảng đục lỗ, cũng có mảng nữa là nghiên cứu về các giải pháp ATTT, xây dựng các công cụ (xây dựng ko có nghĩa là tự code) hay hệ thống để phòng thủ (theo thiên hướng defense). Họ cũng phải bỏ ra nhiều chất xám ra để học hỏi và tìm ra những điều cốt lõi của điểm yếu và đưa ra cách để phòng thủ.
Hay cũng có những người, tổ chức, họ nghiên cứu và phát minh ra một cái sáng kiến gì đó mới mẻ trong Security, giúp cải tiến bảo mật cho những cái đang có, … Cũng được gọi với cái tên là Security Researcher …
Có nhiều mảng nữa cũng được gọi với cái tên Security Researcher này, nhưng do ko phải chủ đề chính của bài viết nên mình xin phép được kể một vài ví dụ như vậy.
Mục tiêu của bài này là nói đích danh về mảng “Tìm kiếm lỗ hổng phần mềm — Vulnerability Research” (tạm thời gọi là N-day hunter đi).
Cái tên N-day hunter mình tạm gọi vậy bởi vì công việc của những người làm nghề này là đi tìm kiếm những sai sót, lỗ hổng trong thiết kế của một đối tượng nào đó, và lợi dụng nó làm cho đối tượng hoạt động theo hướng ngoài ý muốn (unintended nhưng ko biết dịch làm sao cho đúng). Đối tượng ở đây có thể là một chương trình, một website hay một thuật toán, kiến trúc nào đó,
Trước đó, định nghĩa Exploitation thường được mặc định hiểu là những người làm về Binary Exploitation … Ngay cả tại thời điểm hiện tại, giáo trình của một số bộ môn về lỗ hổng phần mềm/secure coding ở KMA cũng chỉ định nghĩa và dạy về Binary Exploitation.
Trong khi thực tế đã khác rất nhiều, lỗ hổng phần mềm đã và đang xuất hiện ở nhiều nền tảng lập trình khác nhau: PHP, Java, .NET, … Exploitation không đơn thuần chỉ là các bug của binary nữa, nó nên được hiểu theo nghĩa rộng hơn.
Hiện nay, việc tìm kiếm lỗ hổng phần mềm thường được chia ra theo 2 hướng chính như sau:
Binary Exploit (hay còn đc gọi là pwn): Nghiên cứu về những lỗ hổng trên Binary như Buffer Overflow, Format String, Integer Overflow, Use-After-Free … Mặc dù những lỗ hổng này đã tồn tại từ những năm 70s của thế kỷ trước, nhưng đến tận bây giờ nó vẫn tồn tại, dù đã có nhiều biện pháp giảm thiểu. Thực tế thì mình ko làm về mảng này nên cũng ko có nhiều kiến thức để chia sẻ, có thể một ngày nào đó sẽ có người làm việc này!
High-Level Language Exploit: Mảng này mình gọi chung cho việc tìm kiếm lỗ hổng ở các nền tảng ngôn ngữ lập trình bậc cao, ví dụ như: Java, PHP, C#, Python … Các ngôn ngữ lập trình này có thể không tồn tại(hoặc là hiếm gặp) những lỗ hổng như là Buffer Overflow hay Use-after-free nữa. Thay vào đó là các lỗ hổng của trên nền tảng ngôn ngữ lập trình bậc cao như: Insecure Object Deserialize, SQL Injection, Command Injection …
Cái tên “High-Level Language Exploit” cũng là do mình tự đặt để gọi chung cho những lỗ hổng trên nền tảng ngôn ngữ lập trình bậc cao, điển hình như: Java, C#, Python, PHP, Ruby, … những ngôn ngữ lập trình mà theo mình cảm nhận là dễ tiếp cận cho người dùng phổ thông!
Trong những năm gần đây, một số lỗ hổng kinh điển xuất hiện trên các nền tảng lập trình bậc cao này có thể kể đến như: SQL Injection, LFI, Insecure Deserialization, XXE (định thêm XSS nhưng hết chỗ ròi ( ͡° ͜ʖ ͡°)) …
Có những loại bug chỉ xảy ra trên 1 nền tảng, nhưng cũng có những loại bug xuất hiện ở nhiều nền tảng khác nhau, ví dụ như: Insecure Deserialization xuất hiện trên cả Java, C#, PHP, nodejs, Python, và mới đây ngta còn phát hiện nó cũng có trên cả Ruby nữa.
Tại VNPT, mình bắt đầu đi sâu vào nghiên cứu lỗ hổng bảo mật từ khoảng cuối năm 2018, và lỗ hổng đầu tiên mình nghiên cứu là 1day của Liferay về Java Deserialization.
Hồi đó, cách nhìn của mình về Java Deserialization khá là đơn giản và có phần lệch lạc, chỉ đơn thuần là gen payload = ysoserial và gửi lên => RCE.
Được thì được, mà không được thì thoi cũng kệ, chả nghiên cứu sâu hơn về cách hoạt động hay gì cả.
¯_(ツ)_/¯ vì mình có một cái suy nghĩ trong đầu, mà có thể nhiều bạn làm ngành sec cũng có, đó là: “kỹ thuật này cao siêu lắm, bao nhiêu ông trên thế giới còn chưa bypass được, thì mình tuổi đ’ gì mà bypass được chứ? …”
Nhưng cuộc sống không giống với cuộc đời, hồi đó thì ban đầu mình có xem sơ sơ và bỏ qua mấy lỗi của liferay như vậy,
Nhưng một tuần sau, bên mình lại nhận thêm gần chục trang cũng dùng liferay như vậy, và kết quả sau mỗi lần pentest các site đó thường ko đc khả quan lắm.
Lý do cũng dễ hiểu, là vì dev tận dụng hầu hết các tính năng mà liferay cung cấp để code portlet, prepare statement … hầu như các lỗi SQLi, LFI, XSS không còn nữa. Điều này thúc đẩy mình phải tìm ra một thứ gì đó tốt hơn, nguy hiểm hơn, để đem lại được lợi thế và tiếng nói của các bản report đầu ra của team pentest.
Hiểu đơn giản một điều như thế này, một bản report toàn XSS với info leak thì may mắn lắm 2 tháng sau dev sẽ chịu nghe lời và fix các lỗi đó, nhưng khi mà đã deface tè le server ròi thì chắc chắn đội dev sẽ nhảy ngược lên và chạy đi fix cái lỗi đó, ¯_(ツ)_/¯ cuộc sống mà!
Thành quả là sau đó mình cùng với một số ae trong team đã thử nghiệm thành công lỗ hổng Liferay Deserialization tưởng như chỉ có trong sách vở (https://www.tenable.com/security/research/tra-2017-01), và phát hiện ra không chỉ nhiều website của các tổ chức, chính phủ tại Việt Nam đang dính lỗ hổng này, mà tới những tổ chức lớn ở nước ngoài cũng có chung tình trạng:
Lúc này mình mới vỡ lẽ ra một tật xấu trong tư tưởng của nhiều thành phần nằm trong cộng đồng Sec nói chung:
- “Ai cũng nghĩ là sẽ có người khác làm việc đó, và cuối cùng chả ai là người bắt tay vào làm cả.”
Sau khi nghiên cứu bug đầu tiên này xong, với mình, đây là một dấu mốc quan trọng, bởi đã đạt được một thành tựu gì đó, nó đem lại cái động lực mạnh mẽ thúc đẩy cho quá trình tiếp tục nghiên cứu sâu hơn về lỗ hổng trên nền tảng Java này!
Và có lẽ không chỉ riêng với mình, mà nó cũng là điều tối quan trọng với những bạn trẻ mới bắt đầu bước chân vào ngành này nói chung, cũng như về mảng nghiên cứu nói riêng. Thành tựu ban đầu có thể chỉ là 1 mảnh rất nhỏ so với những thứ nghiên cứu sau này, nhưng nó lại xác định cho biết bản thân mình đang đi đúng hướng, là nguồn cảm hứng cho bản thân tự xác định được sẽ tiếp tục làm gì trong tương lai!
.
.
.
Thôi lan man chuyện cá nhân nhiều quá,
👉Tiếp tục là nói về đối tượng thường được nhắm đến của các Researcher này.
Với những người làm về nghiên cứu lỗ hổng trên các ngôn ngữ lập trình bậc cao như bọn mình, đối tượng được nhắm đến thường là các loại máy chủ web, máy chủ gì gì đó, mà có thể truy cập từ bên ngoài đối tượng đó vào, ví dụ như: Apache Tomcat, Weblogic, SSH Server, … những thứ gì mà lộ ra bên ngoài, có thể truy cập vào được thì đều trở thành mục tiêu bị săn đón bởi Researcher!
Và đương nhiên, những loại lỗ hổng mà chúng tôi hướng tới, là những loại lỗ hổng nghiêm trọng, có thể thao túng được đối tượng như: Deserialization, RCE, LFI, SQL Injection …
Những lỗi client-side như XSS hay CSRF gì đó thường được bỏ qua, cho dù nó kịch bản bypass/tấn công có hay đến đâu thì cũng nó cũng vẫn phải dựa dẫm vào một tác nhân khác để có thể tấn công thành công, ở đây là dựa dẫm vào Client.
Việc bạn show 1 cái pop up “alert(1)” trên facebook không có nghĩa là bạn đã hack đc web đó
👉Vậy tại sao lại là các đối tượng remote, server?
Dưới đây là một mô hình cơ bản về vị trí cũng như thành phần tổ chức hoạt động của một máy chủ dịch vụ nào đó.
Để một website hoạt động được, mã nguồn của website đó cần được deploy lên máy chủ web để chạy. Đặt vị trí mình vào vị trí của attacker, và mục đích là phải tấn công được website kia để lấy về dữ liệu.
Bỏ qua trường hợp ngay trên mã nguồn của website đó đã có lỗi và cho phép RCE để chiếm quyền điều khiển,
Giả sử như website đó chỉ là một dạng landing page, cũng có vài cái XSS này nọ nhưng website này làm gì có admin mà chiếm phiên??
Đó là khi mũi tên tấn công được chuyển hướng, thay vì nhắm vào mã nguồn của website đó, tại sao ko nhắm vào cái máy chủ dịch vụ mà website đó đang sử dụng??
Một khi đã xâm nhập thành công vào máy chủ đó, thì việc đánh cắp mã nguồn hay database đã dễ dàng hơn rất nhiều, chỉ là việc sớm hay muộn mà thôi. Thậm chí trong thực tế, các máy chủ nội bộ lân cận cũng bị ảnh hưởng do lúc này attacker đã nằm trong mạng nội bộ, và có thể tấn công các máy chủ lân cận đó bất cứ lúc nào!
Thực chất thì các loại web server, ssh server … cũng là do con người xây dựng, không thể nào tránh khỏi những sai sót trong quá trình lập trình, và điều đó vô tình lại tạo ra việc cho những người như mình ( ͡° ͜ʖ ͡°).
Hơn nữa, không giống như mỗi website chỉ sử dụng một bộ mã nguồn cho chính website đó, các dịch vụ như web server, ssh server, vpn server … lại được sử dụng chung và có độ phổ biến khá là rộng,
Đơn cử như nền tảng Liferay, ở Việt Nam nói chung đã có tới hàng trăm website của tổ chức, chính phủ sử dụng nền tảng này. Chỉ cần tìm ra một lỗ hổng RCE trên Liferay thì hoàn toàn có thể tấn công và chiếm quyền điều khiển hàng trăm website đó mà không cần biết developer đã code ngon, xịn như nào.
Vì bản chất lỗi không phải tại ông developer, mà lỗi nó xảy ra ở chính cái nền tảng mà ông developer đó sử dụng ¯_(ツ)_/¯.
👉Qua một vài điểm trên, có thể thấy tầm quan trọng của việc Research đối với công việc pentest nói riêng, và đối với ngành Sec nói chung như thế nào.
.
.
Với tầm quan trọng như thế, và đặc biệt là trong thời đại bùng nổ của chiến tranh mạng như hiện nay, những người làm công việc này có thể ví như những tay sản xuất vũ khí lạnh vậy!
Ngay trong quý 1/2021 vừa rồi, hơn chục 0day bị phát hiện khi đem đi tấn công ngoài thực tế!
Do là 0day, các máy chủ chưa hề có cơ chế phát hiện và phòng vệ gì nên khi phát hiện tấn công thì mọi chuyển cũng đã rồi, hacker đã tấn công sâu vào hệ thống và lấy đi những dữ liệu quan trọng, gây ảnh hưởng lớn tới tổ chức.
Vậy bạn có thắc mắc là tại sao ngày càng nhiều 0day bị sử dụng vào tấn công trong thực tế như vậy?
Để trả lời cho câu hỏi này thì cần phải quay về vấn đề gốc rễ:
- “Làm gì để ra tiền với Vulnerability Research?”
¯_(ツ)_/¯
Công việc Research khá là khó khăn và tốn nhiều thời gian để có thể ra được kết quả.
Ví dụ như với công việc hiện tại của mình, có thể mất tới 1–2 tháng để tìm ra một lỗ hổng 0day có giá trị, nhiều khi ròng rã mấy tháng trời không ra được kết quả gì.
Vậy trong khoảng thời gian 2–3 tháng đó thì ai nuôi?
Hiện tại ở VN, nghề Vuln Research nói chung vẫn chưa có chỗ đứng lắm, vì thực tế là nó không làm ra được kết quả ngay, không làm ra tiền được, nên chả công ty nào dám nhận về nuôi, ¯_(ツ)_/¯ bài toán kinh tế mà. Chả vậy mà nhiều anh em xã hội đã xác định ra đi tìm đường cứu nước, nói chảy máu chất xám thì cũng không đúng, nhưng thực tế nó phũ phàng vậy!
👉Vậy làm gì để ra tiền với Vuln Research?
Để làm tiền với Vuln Research, người ta thường tìm đến một số “chợ đen, chợ đỏ 0day” như ZDI, SSD, NVWA, Z*rodium.
Lỗ hổng 0day sau khi được người của những “chợ 0day” này confirm tính đúng đắn thì sẽ thương lượng giá và trao tiền cho hacker. Có thể sau đó hacker cũng phải ký một thỏa thuận không tiết lộ gì đó về lỗ hổng này.
Số tiền nhận được cũng tùy vào mức độ nghiêm trọng và độ phổ biến của đối tượng đó, ví dụ như: một 0day Pre-Auth RCE trên Exchange có giá tầm 4–5 tỉ VND, nhưng cũng có nhưng target bèo bọt, có 100–200USD với 1 bug tương tự như vậy😢.
Và có ai thắc mắc sau đó cái 0day này sẽ đi đâu ko ( ͡° ͜ʖ ͡°).
Mình cũng không rõ về tương lai của những 0day sau khi được bán cho chợ đen,
Có người nói là được chính phủ sử dụng để bắt tội phạm,
Có người lại nói được tội phạm sử dụng để hack chính phủ
¯_(ツ)_/¯