Tôi đã hack Facebook như thế nào?

[Mơ Hồ]

Dưới đây là bài viết của tác giả Orange Tsai và quá trình mà nhóm của anh ấy tìm ra lỗ hổng trên MobileIron MDM để hack Facebook. Hy vọng bài viết này mang lại nhiều kiến thức cho các bạn.

Bài viết này trình bày nghiên cứu của tôi vào tháng 3/2020, cách mà tôi tìm thấy lỗ hổng trên Mobile Device Management (MDM) và đã vượt qua nhiều hạn chế để đạt được Unauthenticated RCE. Tất cả các lỗ hổng bảo mật đã được báo và khắc phục trong tháng 6. Sau đó, chúng tôi tiếp tục theo dõi các tập đoàn lớn để theo dõi tiến độ sửa lỗi tổng thể và nhận thấy rằng Facebook đã không cập nhật bản vá trong hơn 2 tuần. Vì thế chúng tôi đã thả một shell trên Facebook và báo cáo cho họ!

Nghiên cứu này cũng được trình bày tại HITCON 2020. Bạn có thể xem slide tại đây

Là một thành viên của Red Team, chúng tôi luôn tìm kiếm những phương pháp mới để thâm nhập vào mạng công ty từ bên ngoài. Cũng giống như nghiên cứu của chúng tôi ở Black Hat USA năm ngoái , chúng tôi đã chứng minh cách các VPN SSL hàng đầu có thể bị tấn công và trở thành Mạng “Công cộng” ảo của bạn! SSL VPN được tin cậy là an toàn và được coi là cách duy nhất để truy cập mạng riêng của bạn. Nhưng, điều gì sẽ xảy ra nếu các thiết bị đáng tin cậy của bạn không còn đáng tin cậy nữa?

Dựa trên kịch bản này, chúng tôi muốn khám phá các khía cạnh tấn công mới đối với bảo mật doanh nghiệp và chúng tôi đã chọn MDM, vì vậy bài viết này được ra đời!

Vậy MDM là gì?

Mobile Device Management, còn được gọi là MDM, là một hệ thống đánh giá tài sản giúp doanh nghiệp quản lý BYOD – Bring Your Own Device của nhân viên dễ dàng hơn. Nó được đề xuất vào năm 2012 để đáp ứng với số lượng máy tính bảng và thiết bị di động ngày càng tăng. MDM đảm bảo các thiết bị đó đang chạy theo đúng chính sách của công ty và trong một môi trường đáng tin cậy. Doanh nghiệp có thể quản lý tài sản, cài đặt các chứng chỉ, triển khai ứng dụng và thậm chí khóa/xóa dữ liệu thiết bị từ xa để ngăn chặn rò rỉ dữ liệu.

UEM (Unified Endpoint Management) là một thuật ngữ mới hơn có liên quan đến MDM, có định nghĩa rộng hơn cho các thiết bị được quản lý. Tiếp theo, chúng tôi sử dụng MDM để đại diện cho các sản phẩm tương tự!

Mục tiêu

MDM, là một hệ thống tập trung, có thể quản lý và kiểm soát tất cả các thiết bị của nhân viên. Đây là một hệ thống lý tưởng cho một công ty đang phát triển. Bên cạnh đó, MDM phải được truy cập công khai để đồng bộ hóa các thiết bị trên toàn thế giới. Một thiết bị tập trung và công khai là mục tiêu cực kỳ hấp dẫn đối với tin tặc.

Do đó, chúng tôi đã phát hiện nhiều tin tặc và các nhóm APT lợi dụng MDM trong những năm này! Chẳng hạn như lừa đảo các nạn nhân để biến MDM trở thành máy chủ C&C trên thiết bị di động của họ, hoặc thậm chí xâm nhập máy chủ MDM của công ty để đẩy Trojan độc hại đến tất cả các thiết bị. Bạn có thể đọc báo cáo Malicious MDM: Let’s Hide This App của nhóm Cisco Talos và First seen in the wild - Malware uses Corporate MDM as attack vector công bởi nhóm CPR CheckPoint để biết thêm chi tiết!

Từ những trường hợp trước, chúng tôi biết rằng MDM là mục tiêu chắc chắn của các tin tặc và chúng tôi muốn nghiên cứu nhiều hơn về nó. Có một số giải pháp MDM, ngay cả các công ty nổi tiếng như Microsoft, IBM và Apple cũng có giải pháp MDM của riêng họ. Chúng ta nên bắt đầu với cái nào?

Chúng tôi đã liệt kê các giải pháp MDM đã biết và quét các mẫu tương ứng trên Internet. Chúng tôi nhận thấy rằng MDM phổ biến nhất là VMware AirWatch và MobileIron!

Vậy, tại sao chúng tôi lại chọn MobileIron làm mục tiêu của mình? Theo trang web chính thức của hãng, hơn 20.000 doanh nghiệp đã chọn MobileIron làm giải pháp MDM và hầu hết khách hàng của chúng tôi cũng đang sử dụng giải pháp đó. Chúng tôi cũng biết Facebook đã để lộ máy chủ MobileIron từ năm 2016. Chúng tôi cũng đã phân tích Fortune Global 500 và tìm thấy hơn 15% công ty sử dụng máy chủ MobileIron và để lộ điều này ! Vì những lý do trên, MobileIron đã trở thành mục tiêu chính của chúng tôi!

Bắt đầu từ đâu?

Từ các lỗ hổng cũ, chúng tôi biết rằng không có quá nhiều nhà nghiên cứu đi sâu vào MobileIron. Có lẽ vẫn chưa rõ véc-tơ tấn công. Nhưng chúng tôi nghi ngờ lý do chính là “Firmware”. Khi nghiên cứu một thiết bị, việc chuyển thử nghiệm BlackBox thuần túy thành thử nghiệm GrayBox hoặc WhiteBox là rất quan trọng. Chúng tôi đã dành rất nhiều thời gian để tìm kiếm tất cả các loại thông tin trên Internet và cuối cùng chọn bằng gói RPM. Tệp RPM này được cho là gói thử nghiệm của nhà phát triển. Tệp này được tìm thấy trên một website bằng Google Search.

Ngày phát hành là vào đầu năm 2018. Nó có vẻ hơi cũ một chút nhưng có còn hơn không!
P/S: Chúng tôi đã thông báo cho MobileIron và các tập này đã bị xóa.

Tìm kiếm lỗ hổng

Sau một thời gian vật lộn với đống hổ lốn, nhóm chúng tôi cuối cùng cũng cài đặt được gói thử nghiệm. Thành phần dựa trên Java và có 3 cổng mở:

• 443 – Giao diện người dùng
• 8443 – Giao diện quản lý thiết bị
• 9997 – Giao thức đồng bộ hóa thiết bị MobileIron (Giao thức MI)

Do trang web sử dụng Spring MVC nên rất khó để tìm thấy các lỗ hổng truyền thống như SQL Injection hoặc XSS. Vì vậy, kiểm tra phần logic và kiến trúc là mục tiêu của chúng tôi lúc này!

Nói về lỗ hổng, nguyên nhân sâu xa lại khá đơn giản. Tomcat để lộ ra một dịch vụ web deserialize (chuyển đổi cấu trúc dữ liệu sang dạng đối tượng) dữ liệu đầu vào của người dùng với định dạng Hessian. Tuy nhiên, điều này không có nghĩa là chúng ta có thể làm mọi thứ! Nỗ lực chính của bài viết này là để giải quyết vấn đề đó, vì vậy hãy xem phần khai thác bên dưới.

Mặc dù chúng tôi biết dịch vụ web deserialize dữ liệu đầu vào của người dùng, nhưng chúng tôi không thể kích hoạt nó. Điểm cuối nằm trên cả hai giao diện sau:

• Giao diện đăng ký người dùng - https://mobileiron/mifs/services/
• Giao diện quản lý - https://mobileiron:8443/mics/services/

Chúng tôi chỉ có thể tác động vào quá trình deserialization thông qua giao diện quản lý vì giao diện người dùng chặn truy cập Dịch vụ Web.

Đó là một cú đánh chí mạng đối với chúng tôi vì hầu hết các doanh nghiệp sẽ không để lộ giao diện quản lý của họ và lỗ hổng chỉ dành cho quản lý hông hữu ích cho chúng tôi nên chúng tôi phải cố gắng nhiều hơn.

Xem xét kỹ lưỡng, chúng tôi thấy Apache chặn quyền truy cập của chúng tôi thông qua Quy tắc Rewrite:

RewriteRule ^/mifs/services/(.*)$ https://%{SERVER_NAME}:8443/mifs/services/$1
[R=307,L] RewriteRule ^/mifs/services [F]

MobileIron dựa trên Quy tắc viết lại Apache để chặn tất cả quyền truy cập vào Dịch vụ web. Nó nằm trước reverse-proxy và phần phụ trợ là một máy chủ web dựa trên Java.

Bạn đã nhớ lại điều gì đó chưa?

Vâng, vượt qua logic phân tích cú pháp! Đó là tấn công reverse proxy mà tôi đã đăng vào năm 2015 và được trình bày tại Black Hat USA 2018. Kỹ thuật này tận dụng sự mâu thuẫn giữa Apache và Tomcat để vượt qua kiểm soát ACL và truy cập lại Dịch vụ Web. BTW, kỹ thuật tuyệt vời này cũng được áp dụng cho lỗ hổng F5 BIG-IP TMUI RCE gần đây !

https://mobileiron/mifs/.;/services/someService

Khai thác
OK, bây giờ chúng ta có quyền truy cập vào quá trình deserialization ở bất kỳ đâu trên giao diện đăng ký hoặc giao diện quản lý. Cùng khai thác nào!

Moritz Bechler đã có một nghiên cứu tuyệt vời tóm tắt lỗ hổng giải mã Hessian trên whitepaper của mình, Java Unmarshaller Security. Từ mã nguồn marshalsec, chúng ta tìm hiểu các kích hoạt deserialization Hessian trong equals()và hashcode() trong khi tái tạo lại HashMap. Nó cũng có thể kích hoạt toString()thông qua Xstring và các gadget khai thác đã biết cho đến nay là:

• Apache XBean
• Caucho Resin
• Spring AOP
• ROME EqualsBean/ToStringBean

Trong môi trường của chúng tôi, chỉ có thể kích hoạt chuỗi gadget Spring AOP và nhận được JNDI Injection.

Khi đã có JNDI Injection, các phần còn lại của việc khai thác rất dễ dàng! Chúng ta có thể tận dụng công việc của Alvaro Muñoz và Oleksandr Mirosh, A Journey From JNDI/LDAP to Remote Code Execution Dream Land, từ Black Hat USA 2016 để thực thi mã…

Kể từ khi Alvaro Muñoz và Oleksandr Mirosh giới thiệu điều này trên Black Hat, chúng ta có thể nói rằng kỹ thuật này giúp ích cho vô số nhà nghiên cứu bảo mật và đưa lỗ hổng Java deserialization vào một kỷ nguyên mới. Tuy nhiên, Java cuối cùng đã giảm thiểu điều đó vào tháng 10 năm 2018. Sau đó, tất cả phiên bản java cao hơn 8u181, 7u191 và 6u201 không còn có thể thực thi mã thông qua JNDI remote URL-Class loading. Do đó, nếu chúng ta khai thác Hessian deserialization trên MobileIron mới nhất, chúng ta phải đối mặt với vấn đề này!

Java đã thay đổi giá trị mặc định com.sun.jndi.ldap.object.trustURLCodebase thành False để ngăn những kẻ tấn công tải xuống remote URL-Class để thực thi mã. Nhưng chỉ điều này đã bị cấm. Chúng ta vẫn có thể thao tác JNDI và chuyển hướng Naming Reference đặt tên đến local Java Class!

Khái niệm này hơi giống với Return-Oriented Programming, sử dụng Java Class hiện có nội bộ để khai thác. Bạn có thể tham khảo bài viết Exploiting JNDI Injections in Java của Michael Stepankin đầu năm 2019 để biết thêm chi tiết. Nó mô tả cuộc tấn công khai thác POST-JNDI và cách lạm dụng Tomcat BeanFactory để đưa ELProcessor gadget vào để thực thi mã. Dựa trên khái niệm này, nhà nghiên cứu Welkin cũng cung cấp một ParseClass gadget khác trên Groovy. Như được mô tả trong bài báo (tiếng Trung) của anh ấy:

除了 javax.el.ELProcessor ， 当然 也 还有 很多 其他 的 类 符合 条件 可以 beanClass 注入 到 BeanFactory 中 实现 利用。 个 例子 ， 如果 目标 机器 classpath 中 有 groovy 的 库 ， 则 可以 结合 之前 Orange 师傅 Jenkins 的 漏洞 实现 利用

Cách tiếp cận có vẻ khả thi đối với chúng tôi. Nhưng cả hai gadget ELProcessor và ParseClass đều không khả dụng do các thư viện của mục tiêu đều đã lỗi thời. Tomcat đã giới thiệu ELProcessor từ phiên bản 8.5, nhưng mục tiêu của chúng tôi là phiên bản 7. Đối với Groovy gadget, phiên bản Groovy mục tiêu quá cũ (1.5.6 từ năm 2008) để hỗ trợ Meta Programming, vì vậy chúng tôi vẫn phải tự mình tìm kiếm một gadget mới. GroovyShellCuối cùng thì chúng tôi cũng tìm thấy một gadget mới . Nếu bạn quan tâm, bạn có thể kiểm tra Pull Request mà tôi đã gửi cho dự án JNDI-Injection-Bypass !

TẤN CÔNG FACEBOOK

Bây giờ chúng ta có một RCE hoàn hảo bằng cách liên kết JNDI Injection, Tomcat BeanFactory và GroovyShell. Đã đến lúc hack Facebook!

Như đã nói ở trên, chúng tôi biết Facebook sử dụng MobileIron từ năm 2016. Mặc dù hiện tại, máy chủ phản hồi 403 Forbidden khi truy cập, nhưng Dịch vụ web vẫn có thể truy cập được!

Mọi thứ đã sẵn sàng chỉ chờ mỗi khai thác thôi! Tuy nhiên, vài ngày trước cuộc tấn công, chúng tôi nhận ra rằng có một vấn đề nghiêm trọng trong quá trình khai thác. Từ bài viết our last time popping shell on Facebook , chúng tôi nhận thấy nó chặn các kết nối gửi đi do lo ngại về bảo mật. Kết nối ra ngoài là rất quan trọng đối với JNDI Injection vì ý tưởng là khiến nạn nhân kết nối với một máy chủ độc hại để thực hiện khai thác sâu hơn. Nhưng bây giờ, chúng tôi thậm chí không thể tạo kết nối ra bên ngoài, chưa kể đến những chuyện khác.

Tất cả các bề mặt tấn công trên JNDI Injection đã bị đóng, chúng tôi không còn lựa chọn nào khác ngoài việc quay trở lại Hessian deserialization. Nhưng do thiếu các gadget có sẵn, chúng ta phải tự mình tìm một cái mới!

Trước khi bắt đầu tìm gadget mới, chúng ta phải hiểu đúng nguyên nhân gốc của các gadget hiện có. Sau khi đọc lại bài của Moritz Bechler , có một đoạn khiến tôi để ý:

Cannot restore Groovy’s MethodClosure as readResolve() is called which throws an exception.

Một câu hỏi nhanh chóng hiện ra trong đầu tôi: Tại sao tác giả lại để chữ này ở đây? Mặc dù nó không thành công với những ngoại lệ, nhưng chắc hẳn phải có điều gì đó đặc biệt để tác giả viết ra điều này.

Mục tiêu của chúng tôi đang chạy với Groovy rất cũ, vì vậy chúng tôi đoán rằng readResolve()ràng buộc có thể chưa được áp dụng cho phiên bản đó! Chúng tôi đã so sánh tệp groovy/runtime/MethodClosure.java giữa phiên bản mới nhất và phiên bản 1.5.6.

$ diff 1_5_6/MethodClosure.java 3_0_4/MethodClosure.java
>     private Object readResolve() {
>         if (ALLOW_RESOLVE) {
>             return this;
>         }
>         throw new UnsupportedOperationException();
>     }

Yessss, chúng tôi đúng. Không có ALLOW_RESOLVE trong Groovy 1.5.6, và sau đó chúng tôi đã phải nghiên cứu CVE-2015-3253 chỉ để vì điều đó. Đây là một biện pháp giảm thiểu cho lỗ hổng deserialization Java đang gia tăng vào năm 2015. Vì Groovy là một thư viện được sử dụng nội bộ, các nhà phát triển sẽ không cập nhật nó nếu không có trường hợp khẩn cấp. Groovy lỗi thời cũng có thể là một nghiên cứu điển hình tốt để chứng minh cách một thành phần vô hại có thể khiến bạn bị xâm nhập!

Tất nhiên cuối cùng thì chúng tôi cũng cài được shel trên Facebook. Đây là video:

Báo cáo lỗ hổng và phiên bản vá

Chúng tôi đã thực hiện tất cả các nghiên cứu vào tháng 3 và gửi tư vấn cho MobileIron vào ngày 4/3. MobileIron đã phát hành bản vá vào ngày 15/6 và giải quyết 3 CVE. Bạn có thể kiểm tra trang web chính thức để biết chi tiết!

• CVE-2020-15505 - Thực thi mã từ xa
• CVE-2020-15506 - Bỏ qua xác thực
• CVE-2020-15507 - Đọc tệp tùy ý

Sau khi bản vá được phát hành, chúng tôi bắt đầu theo dõi Internet để theo dõi tiến trình sửa lỗi tổng thể. (Unknown là viết tắt của máy chủ đã đóng cả cổng 443 và 8443)

Đồng thời, chúng tôi cũng chú ý đến Facebook. Với 15 ngày xác nhận không có bản vá, cuối cùng chúng tôi đã đẩy một con shell lên và báo cáo với chương trình Bug Bounty của họ vào ngày 7/2!

Phần kết luận
Cho đến nay, chúng tôi đã chứng minh được Unauthenticated RCE trên MobileIron. Từ cách chúng tôi lấy Firmware, tìm lỗ hổng. Còn những chuyện khác nhưng do thời gian nên chúng tôi chỉ liệt kê chủ đề tại đây cho những ai quan tâm:

• Cách tiếp quản thiết bị của nhân viên từ MDM

• Giải mã giao thức MI

• Và CVE-2020-15506, một phương thức bỏ qua xác thực thú vị

Tôi hy vọng bài viết này có thể thu hút sự chú ý đến MDM và tầm quan trọng của bảo mật doanh nghiệp! Cảm ơn vì đã đọc.

Nguồn: Orange Tsai​