SAE Cloud Service Security Sandbox Bypass 4 (File Access bypass defense)

Summary

Thank you for your support. We have reached the fourth level. After several exchanges, we found that SAE's children's shoes attached great importance to safety and held a "welcome" attitude. They affirmed this attitude and had such an attitude, the author has the desire to continue. We all believe that SAE will eventually become safer and safer.

Body

In the previous article "SAE Cloud Service Security Sandbox Bypass 3 (bypassing Command Execution defense)", the author used SAE to limit only EXEC commands without the vulnerability of other functions, the whole sandbox defense is broken. In the final suggestions, the author also mentioned the method of defense against the sandbox. SAE accepts the conventional sandbox security solution and is no longer limited to limiting a function or other policies. Now there are limits everywhere. This is really a tough start for the author. I feel that SAE's security restrictions on Sandbox are more BT than google's, and even some don't take care of the JAVA framework, in any case, the author continues.

Environment Test
First, let's look at some common and dangerous functions:
CrackClassLoader
This is the code used in the previous articles, so I will not post it again. Let's look at the results:

CreateClassLoader has been restricted, so the custom classLoader is invalid. This means that you cannot define a class with custom permissions.

Test the connection socket

Http://2.javasandboxtest.sinaapp.com/socket.jsp? Host = www.inbreak.net & port = 80 & page =/

Socket connection is not allowed, XXX is not allowed, and XXX is not allowed...

This is not a solution. They are all killed. At this time, we need a way to break the conventional Sandbox Bypass.

Read File Test

The author found a very interesting situation. In the JAVA environment of SAE, there is a Class called "com. sina. sae. security. saeSecurity ", this Class, such as for verification, contains the method" checkRead ". If you know the verification logic of this method, and when the developer implements this method, a logic vulnerability occurs, then bypass may occur. However, under such conditions, it is very difficult to obtain the source code of SAE. It can only be detected from the side.

The author thought that the simplest architecture would be to let this class take effect during permission verification and run before java remote sandbox. lang. securityManager is a native function provided by java. By default, it performs various authentication based on the permission whitelist set in the policy file of java. A Class inherits SecurityManager, which is the so-called custom SecurityManager. Both SAE and google use the custom SecurityManager.

Check the document description of this Class. There are many permission verification methods that can be implemented by developers themselves, covering the java Native verification logic.

There are many verification methods in the figure, which can be covered by the verification methods implemented by the developers themselves. Once the SAE developers overwrite these methods, such as command execution, before executing a real java command, the system will verify the permission and use the method written by the SAE developer instead of the JAVA Native verification.

The error message of a normal JAVA sandbox should not be related to the security authentication implemented by SAE itself. Theoretically, java sandbox already has File Reading and other authentication. However, according to the exception information shown in the preceding figure, the author assumes that the SAE developer replaces JAVA Native security authentication. From this point, we can also see that SAE is ambitious and has a tendency to replace the Security Sandbox of JAVA itself. However, the JAVA code has been raging for many years and various bypass methods have appeared, it is still difficult for SAES to develop new code to meet this standard.

We can test the security of the sandbox code by SAE from various angles. The checkRead method verifies the file read permission. Files uploaded by the user can be read. Otherwise, the restriction on sandbox is too BT.

The author uploads a file, reads it, and obtains the file path. For details, see the previous article SAE Cloud Service Security Sandbox Bypass 3 (bypassing Command Execution defense)

This is readable, which indicates the path:

/Data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_ 3_javasandboxtest-any-/webapp

All files under are readable, so the File Permission verification must include this path. Can this security policy be bypassed?

Start bypass

This reminds the author of The File Download Vulnerability. Attackers can bypass arbitrary file downloading vulnerabilities and have numerous experiences from their predecessors. The most common idea is.

Read/etc/passwd file content:


Http://3.javasandboxtest.sinaapp.com/down.jsp? Filename =/data1/jetty_work/84/export andboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_ 3_export andboxtest-any-/webapp/.../....../../etc/passwd

One success! This kind of thing really has a lot to do with luck!

In this process, the SAE authentication code and the checkRead method are further verified. There may be only one row. The following is the hypothetical pseudo code:
If (XXXX. startwith (/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_ 3_javasandboxtest-any-/webapp ))
{
Return true;
}
This vulnerability is a classic File Download Vulnerability code, but is stored in a sandbox, which causes the sandbox to be bypassed. Now we can read user files on the cloud.

Question about the friendliness between sandbox and jspspace

We know that JAVA web applications only exist in the era of jsp and servlet. No matter which application, the shadows of JAVA frameworks, such as struts and spring, are everywhere. The implementation of the framework itself often involves getClassLoader and other operations. Now SAE limits this thing. The author expressed his question about whether the STRUTS2 application can run on SAE. For this reason, the author uploads the official struts showcase.
The error 503 is returned and is unavailable.

Summary

Even a very simple STRUTS2 application is unavailable, and many other frameworks also have their own classLoader operations. If the JAVA framework is not supported, such an SAE, what is the value of existence? Therefore, these permissions are not only simple prohibitions, but there are still many things to be done. Security without availability is not really safe. Such a security solution will disappear in the morning and evening under the pressure of the business. To ensure availability and security, this is the real security. Therefore, when SAE's classLoader restrictions disappear, everything returns to 0.

The best way is to take over the JAVA Native security verification code and make an overall revuew. Before the Code cannot guarantee security, take over more secure things, this is a security risk. Who dares to write their own code? It must be safer and more robust than those of SUN (who wrote sandbox before oracle?

In fact, the Sandbox Bypass technology is also the first time for the author to play. Each time it is necessary to wait for the SAE to be repaired, a new method will appear. SAE certainly hopes that I will give all the bypassing methods at one time, but the problem is that we have not yet done a good deal of defense. What about attacks? We recommend that you perform an overall review of the SAE Code, especially taking over the JAVA sandbox authentication. We believe there are more serious vulnerabilities in it to solve this problem, only security personnel can read this information. If SAE is open enough, it is recommended that it be open-source directly to obtain security information more openly.
By empty prodigal son heart http://www.inbreak.net Weibo: http://t.qq.com/javasecurity