░░░░░▄▄▄▄▀▀▀▀▀▀▀▀▄▄▄▄▄▄░░░░░░░
░░░░░█░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░▀▀▄░░░░
░░░░█░░░▒▒▒▒▒▒░░░░░░░░▒▒▒░░█░░░
░░░█░░░░░░▄██▀▄▄░░░░░▄▄▄░░░░█░░
░▄▀▒▄▄▄▒░█▀▀▀▀▄▄█░░░██▄▄█░░░░█░
█░▒█▒▄░▀▄▄▄▀░░░░░░░░█░░░▒▒▒▒▒░█
█░▒█░█▀▄▄░░░░░█▀░░░░▀▄░░▄▀▀▀▄▒█
░█░▀▄░█▄░█▀▄▄░▀░▀▀░▄▄▀░░░░█░░█░
░░█░░░▀▄▀█▄▄░█▀▀▀▄▄▄▄▀▀█▀██░█░░
░░░█░░░░██░░▀█▄▄▄█▄▄█▄████░█░░░
░░░░█░░░░▀▀▄░█░░░█░█▀██████░█░░
░░░░░▀▄░░░░░▀▀▄▄▄█▄█▄█▄█▄▀░░█░░
░░░░░░░▀▄▄░▒▒▒▒░░░░░░░░░░▒░░░█░
░░░░░░░░░░▀▀▄▄░▒▒▒▒▒▒▒▒▒▒░░░░█░
░░░░░░░░░░░░░░▀▄▄▄▄▄░░░░░░░░█░░
Lâu nay vẫn xảy ra cuộc chiến dai dẳng và thầm lặng giữa dân chơi hệ Server-Side vs dân chơi hệ Client-Side, giữa XSS 10k$ vs RCE = Informative, …
Việc phán xét bên nào hay hơn, bên nào nghiêm trọng hơn, bên nào đáng tiền hơn rất là khó, nó dựa trên nhiều tiêu chí để đánh giá, nhưng chủ yếu là dựa vào đối tượng bị ảnh hưởng,
Lấy một ví dụ như sau:
- Stored-XSS trên một trang web Ebanking của một ngân hàng X này nọ, có thể ảnh hưởng tới tiền nong của rất nhiều người => Có thể chấp nhận là Critical được.
- Hoặc là RCE trên một hệ thống CI/CD nào đó, vốn dĩ những hệ thống này đã được thiết kế để có thể thực thi lệnh tùy ý rồi, nên ở đây RCE bị đánh = Informative là chuyện hoàn toàn có thể chấp nhận được. Chuyện đó chỉ có thể thay đổi khi mà bạn có thể chứng minh được bug RCE này có thể làm được những gì?
Mình là một dân chơi hệ Server-Side, những bug mình làm/writeup đa số đều là những bug về RCE hoặc là chain để có thể RCE.
Tuy nhiên gần đây, khi tiếp xúc với một số bạn mới vào làm pentest, thấy cái sự hời hợt trong những bản Report pentest. Đặt mình vào vị trí của đơn vị phát triển, mình không thấy những bản Report đó có gì đáng thuyết phục, không có sự nguy hiểm gì đủ để bên vận hành thức giấc lúc 2h sáng để patch hệ thống.
Mình mới nhận ra, ở những bản report này không có một cái tư duy gì về Red Team, hay là đó giờ cái tư duy về Red Team chưa được “công khai phổ biến” rộng rãi.
Người ta chỉ đọc những report h1 RCE, writeup 10k và làm theo y chang trong đó, mà không hề biết mình có thể làm gì hơn với những thứ đó.
Và cũng nhận ra, đó giờ viết bao nhiêu cái về RCE, nhưng mình lại quên nói về một thứ đầu tiên và quan trọng nhất:
- RCE để làm gì 🤷♀️???
Theo Wiki:
“An arbitrary code execution vulnerability is a security flaw in software or hardware allowing arbitrary code execution.” (https://en.wikipedia.org/wiki/Arbitrary_code_execution)
Tóm tắt in Vietlisk:
“Một lỗ hổng RCE tồn tại trong phần mềm, cho phép thực thi lệnh tùy ý bởi attacker.”
Trong độ 4–5 năm gần đây, ngành ATTT nở rộ, mà có cầu thì sẽ có cung, điều đó ai cũng hiểu.
Sự thiếu hụt nhân lực ATTT nói chung, và đặc biệt là Pentester, đã đẩy pentester trở thành một trong những ngành đã, đang và sẽ cực kỳ hot. Có những trường hợp 1 ông pentester chưa kịp nghỉ việc ở chỗ này đã có chỗ khác deal lương cao hơn nhiều lần,
Thị trường cần Pentester, do đó mà họ đổ xô đi học các khóa về CEH, học hack này nọ để vào làm pentest, lấp đầy đi sự thiếu hụt nhân sự của mảng này. Thành ra là tới năm 2021 này, thượng vàng hạ cám, đủ kiểu pentester ở đủ loại trình độ được sinh ra, giỏi có, kém có, và cả phá hoại cũng có!
Dù là mỗi tổ chức, đơn vị có cách sử dụng các pentester riêng, nhưng đa phần đều là give task => do task => close task, nó bị giới hạn trong một phạm vi của task.
Hay như những ae chơi bug bounty, thì cũng là find bug => submit bug => debate => close case => reopen case => triaged => profit … Cũng bị giới hạn trong một khuôn khổ nào đó, việc thực hiện các hành vi ngoài scope sẽ bị gọi lên phường uống chè ( ͡° ͜ʖ ͡°).
Mình không có ý kiến gì về cách hoạt động này, tuy nhiên nếu một Pentester bị cuốn vào và lạc trong cái vòng luẩn quẩn này đủ lâu thì sẽ hình thành cái tư duy dập khuôn, sẽ trở thành cái máy, mà mất hết đi cái ý tưởng mới trong quá trình pentest.
Nguy hiểm hơn là đối với chính những pentester vừa mới vào làm đã bị cuốn vào vòng xoáy này, nó sẽ triệt tiêu hết cái sự sáng tạo, không biết được cái ý nghĩa thực tế của những bug mình tìm ra là để làm gì,
Lòng vòng nãy giờ, vẫn quay trở lại câu hỏi: Vậy LFD/XXE/RCE là để làm gì ???
Hiểu theo nghĩa đen, RCE rồi thì coi như đã chiếm được cái máy chủ, cái đối tượng đó, và có thể thao túng được dữ liệu, cách hoạt động của máy chủ đó.
Đó giờ vẫn thấy người ta show proof RCE, “id”, “whoami”, “ifconfig” các thứ. Public PoC chỉ mỗi RCE là dân tình đã nhốn nháo lên rồi.
Từ đó kéo theo nhiều s̶c̶a̶n̶n̶e̶r̶ hacker có sẵn list target, cũng chỉ chờ có PoC public là đem ốp vào tool rồi report cho bug bounty program (¯\_(ツ)_/¯ rồi dup tè le lại than vãn với cuộc đời là trâu chậm uống nước độc).
Nhưng đó là phạm trù của bug bounty, không nên vì ham mê bug bounty nhiều mà quên mất cái mục đích thực sự của RCE là gì.
Trong một Red Team operation, RCE chỉ góp một phần rất nhỏ để đợt tấn công đó có thể hoàn thành mục đích.
Nói sơ qua về Red Team, theo mình làm và hiểu thì ở phương diện nào đó, Red Team có thể được coi là tiền thân của pentest. Red Team là làm tất cả các trò để đạt được mục đích, còn Pentest thì chỉ tập trung vào một đối tượng nào đó và cố gắng tìm ra hết cả khả năng để tấn công đối tượng đó.
Đại khái pentest là như này:
Còn đây là Red Team:
Một đợt tấn công bởi Red Team thực tế còn phức tạp hơn nhiều, trong đó RCE chỉ là một mắt xích nhỏ trong hành động, nhưng thiếu nó thì không thể hoàn thành được chuỗi tấn công.
Trong thực tế, Red Team chưa(không) được hợp thức hóa bởi độ phức tạp và khó quản lý của nó (ai biết được ông sẽ làm gì với những dữ liệu đó), thường được thực hiện “in the dark”.
Hoặc nếu hợp pháp hóa thì cũng chỉ có ở những tổ chức lớn, có cái suy tính xa hơn, họ chủ động thuê hoặc có đội Red Team riêng, ký đầy đủ NDA, để tấn công và tìm ra những rủi ro trong hệ thống một cách toàn diện, đảm bảo không bị tấn công bởi những tổ chức Red Team khác với mục đích không hề tốt đẹp.
Với việc tham gia Red Team, pentester sẽ bị đặt vào tình huống thiếu thốn nhất, cần phải tối ưu những lỗ hổng tìm thấy hết mức có thể, sao cho đạt được mục đích cuối cùng. Report của Red Team mà chỉ show mỗi “whoami”, “ifconfig” cũng chưa đủ để những người làm non-tech - ở đây là lãnh đạo của tổ chức — người trả tiền cho các bạn, có thể hiểu được các bạn đã làm được gì nghiêm trọng với tổ chức này.
Lấy ví dụ về trường hợp lỗ hổng Pre-Auth RCE trên Confluence (Nếu tôi nhớ ko nhầm thì nó có số CVE-2021–26084),
Người ta hô hào, rầm rộ về PoC RCE, report duplicated, show “whoami ”các thứ trên twitter.
Số đông đều thấy vậy và hùa theo, bỏ qua cái sự thật là nó có thể làm nhiều hơn là mỗi vậy.
Các tổ chức, sysadmin, dev, … khi vận hành và sử dụng sản phẩm đều phải lưu lại quy trình sử dụng, mô hình hệ thống vào một nơi nào đó, và Confluence được sinh ra để làm như vậy.
Với một Red Team operation, thay vào việc cắm mặt hack loạn xạ lên thì người ta đi săn lùng những tài liệu nội bộ, để làm sao có thể hiểu được cách xây dựng, mô hình tổ chức của cả hệ thống này. Khi đã hiểu được thì họ có thể đánh chiếm tất cả tổ chức chỉ trong vòng vài phút, trước khi các hệ thống giám sát kịp phát hiện ra. Và Confluence chính là nơi mà họ cần hướng đến và đánh chiếm.
PoC RCE lưu hành trên mạng thường có dạng như này:
Nhưng thực tế thì có thể làm nhiều hơn vậy, PoC này có thể thực thi code Java tùy ý, vậy tại sao ko sửa code để gọi tới method create User, create hẳn user mới, login vào và thoải mái xem xét các tài liệu bên trong đó ( ͡° ͜ʖ ͡°)
Chắc chắn không chỉ mình, mà cũng có nhiều researcher khác cũng nghĩ tới cách làm này, nhưng không ai show cái này trên mạng cả, thành ra nhiều người nghĩ chỉ cần “ifconfig” là đủ.
Mục đích cuối cùng của việc hack vẫn là đi chiếm dữ liệu, RCE mà chỉ “whoami” thì chỉ nên đem show off thôi, làm gì được với nó mới là thứ chúng ta cần nghĩ tới, để chứng minh và để mình tránh khỏi cái vòng xoáy của nghề này.
Post này hơi toxic, có thể sẽ động chạm tới nhiều người nên hy vọng bạn đọc có thể bỏ qua,
Cảm ơn các bạn đã theo dõi!