Analysis of the "Anywhere Door" Vulnerability on the 360 Browser


“It’s not a bug. It’s a feature.” – A developer’s quote

“It’s not a vulnerability. It’s a backdoor.” – A hacker’s quote

The door at the beach


We first introduced “Anywhere Door” (in Chinese: “任意门”) in this previous article. “Anywhere Door” is a new Wormhole vulnerability that affects versions of the 360 Browser prior to beta. By sending a certain crafted HTTP request, a remote attacker can execute an arbitrary shell command on the target phone, with the privilege of the 360 Browser app. If the phone is rooted, the attacker can do anything on the root user’s device, such as install and remove apps.

In this article, we will disclose more details of this vulnerability.

Like all the Wormhole vulnerabilities that have come before it, “Anywhere Door” is triggered on a customized HTTP server, on the port 6587. The server is used for cross-process communications, and contains a few APIs, such as popping-up a browser window. The purpose of this API is to display an “uninstall survey” when the main app is being removed. And the server logic is implemented by a native library (.so file) called um.3 (UninstallManager we guess?)


Port 6587 will be opened upon the first launch of the 360 browser


The HTTP server in um.3 is running in an independent process


The um.3 will be copied from the assets folder to so_libs folder

When handling the “launch browser” request, we found the um.3 directly executes a shell command to launch the browser process. For example, when popping up the “uninstall survey”, the command is goes like this:

/data/data/com.qihoo.browser/files/so_libs/um.3 com.qihoo.browser –execute am start -n -a android.intent.action.VIEW -d\&Wid=81e188a23869a898d1343eaa20c11495
–user 0

There is a critical vulnerability in this design: the url, which is part of the shell command, is controllable by a HTTP GET parameter. And the entire command is executed via system() without any filtering, causing a remote command injection vulnerability. A remote attacker could use “;” to close the original “am start” command, add any malicious commands after the “;”, and have those commands executed by the 360 browser on the target phone.

We reverse engineered the um.3 using IDA Pro/HexRay. The critical code is mainly in 2 functions: sub_9018 and sub_9078, which are used for handling HTTP server logic and GET parameter parsing. The code logic is explained in the comments in the following figure (click for enlarged image):

Untitled drawing (9)

From the reversed C code, we can see that the raw command to be executed is:

am start -n com.qihoo.browser/.BrowserActivity -a android.intent.action.VIEW -d %s -e from %s

And the value of GET parameter “u” will be filled in the first “%s” (while the “t” value must be set to “1”). To exploit it, all an attacker needs to do is simply send the following request:

curl -X http://%5Btarget IP]:6587/t=1&;echo 1>/sdcard/lol.txt;

After that, the attacker will find a lol.txt generated in the sdcard folder.

By default, the attacker could share the privileges of the 360 browser, such as sending and accessing SMS messages, reading the call logs, accessing browser history, and monitoring the camera and microphone.

If you are targeting a rooted phone, you can do almost anything. For instance, silently replacing the user’s banking app with a phishing app (as shown in the following video). Even if the user has installed a root management tool like SuperSU, the confirmation dialog will appear in the name of the 360 browser, which is likely to be trusted by the user.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s