The following article is about the personal experience of Orange Tsai so they are listed literally says his words about how he managed to hack Facebook once again.
Hi, a long time has passed since my last article. This new post is about my research this March on how I found vulnerabilities in a flagship Mobile Device Management product that I overcame to achieve remote code execution.
All vulnerabilities have been reported to the vendor and fixed in June. After that, we kept track of big companies to track the overall progress of the correction and then we found that Facebook did not keep up with the patch for more than 2 weeks, so we tried to seize the opportunity!
As a Red Team, we are always looking for new ways to penetrate corporate networks. This time we are investigating the attacks that concern their security operational and we are interested in MDM, so the following article is about it!
What is MDM?
Mobile Device Management, also known as MDM, is a data evaluation system that makes employee BYOD (Bring your own device) more manageable for businesses. MDM can guarantee that the devices operate in accordance with corporate policy and in a reliable environment.
MDM, as the central system, can manage and control all employees' devices. It is undoubtedly an ideal target for hackers. Therefore, we have seen hackers and APT teams abusing MDM all these years!
We have recorded well-known MDM solutions and scanned corresponding patterns all over the internet. We found that the most common MDMs are VMware AirWatch and MobileIron!
So why did we choose MobileIron as our goal? According to their official website, more than 20.000 companies have chosen MobileIron as their MDM solution. We also know that Facebook has been exposing the MobileIron server since 2016. We also analyzed the Fortune Global 500 and found that over 15% use and expose the MobileIron server to the public! For the above reasons, it became our main goal!
The file we will research was released at the beginning of 2018. It looks a bit old but it is better than nothing!
After we finally completed the test package we saw that the component is based on Java and has been exposed to three ports:
- 443 - the user registration interface
- 8443 - the device management interface
- 9997 - MobileIron device synchronization protocol (MI protocol)
All open ports are encrypted with TLS. Apache is located at the front of the web section and provides all the backend connections, a Tomcat with Spring MVC.
Due to Spring MVC, it is difficult to find traditional vulnerabilities such as SQL Injection or XSS.
Speaking of vulnerability, the root cause is simple. Tomcat has introduced a Web service that deserializes user input in the Hessian format. However, this does not mean that we can do everything! The main effort of this article is to resolve this, so see exploitation below:
Although we know that the Web Service is deserializing the user input, we can not enable it. The endpoint is in both:
- User registration interface - https://mobileiron/mifs/services/
- Management interface - https://mobileiron:8443/mics/services/
We can only "touch" deserialization (it is the process of converting an object to data format that can be restored later) only through the management interface, because the user interface blocks the access in the Web Service.
MobileIron relied on Apache Rewrite Rules to block access in the Web service. It is located in front of a reverse-proxy architecture and the backend is a Java-based web server.
Exploitation of vulnerabilities
Moritz Bechler has done an awesome research, which summarizes the "Hessian deserialization" vulnerability in his whitepaper called Java Unmarshaller Security. From the marshalsec source code, we learn that Hessian deserialization activates equals () and hashcode () while rebuilding a HashMap. It could also enable toString () via XString and known gadgets for exploit so far are:
- Apache XBean
- Resin rubber
- Spring AOP
- ROME EqualsBean / ToStringBean
In our environment, we could only activate the Spring AOP gadget chain and perform a JNDI Injection. Once the JNDI Injection is performed, the rest of the vulnerabilities are easy!
Attack on Facebook
We now have a perfect RCE (remote code execution) combining JNDI Injection, Tomcat BeanFactory and GroovyShell. It's time to hack Facebook!
However, we have known that Facebook has been using MobileIron since 2016. Although the server response is 403 Forbidden now, the Web Service is still accessible!
A critical vulnerability (CVE-2015-3253) in Groovy 2.4 allowed us to achieve RCE by exploiting a Java deserialization error.
MobileIron uses version 1.5.6 of Groovy, which was vulnerable to attack. Therefore, we were able to use this attack to hack Facebook.