In Level01 , we are given the following vulnerable c program:
#include <stdlib.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <stdio.h> int main(int argc, char **argv, char **envp) { gid_t gid; uid_t uid; gid = getegid(); uid = geteuid(); setresgid(gid, gid, gid); setresuid(uid, uid, uid); system("/usr/bin/env echo and now what?"); } This is the code of the /home/flag01/flag01 program that runs as flag01 user
level01@nebula:~$ ls -la /home/flag01/flag01 -rwsr-x--- 1 flag01 level01 7322 Nov 20 2011 /home/flag01/flag01 As setresuid sets the Real, Effective and Saved uids to the effective one (flag01), the following call to system will effectively run as flag01.
I decided to improve my exploiting skillz and try the Exploit-Exercises levels. First levels are quite easy but I decided to catch them'all!
Ok, so Level00 is about finding a executable owned by flag00 user and that has the setuid flag, easy as:
level00@nebula:~$ find / -executable -user flag00 -perm -4000 2> /dev/null /bin/.../flag00 level00@nebula:~$cd /bin/... level00@nebula:/bin/...$ ./flag00 Congrats, now run getflag to get your flag! flag00@nebula:/bin/...$ getflag You have successfully executed getflag on a target account
While researching SpringMVC Restful APIs, I found out that any RESTful webservice built with SpringMVC and using JAXB as mashalling library to convert XML object representations to Java objects, was vulnerable to XML eXternal Entity Injection (XXE) attacks since the JAXB was configured to resolve external entities by default and it could not be configured to not do so.
SpringMVC uses SpringOXM (Object to XML Mapper) to automatically convert XML messages into Java objects so developers dont need to process the XML message and instantiate their own class instances, they just need to declare what type they are expecting in their controller method.
“Wait, I’m not clear on what’s happening here. Is this even possible? Just by giving an application a single piece of XML, you can cause it to steal other files for you?”
Those were a customer’s words when an XML External Entity injection vulnerability was reported on one of his applications and although these kinds of attacks are known since the early 2000s I’m still under the impression that they are not known and tested enough by application developers and security auditors.
The Android platform enables an inter application communication that can cause side effects in the security of our application. If a component allows any application to send him intents, we can end up being a puppet on any malware hands.
In order to prevent this situation, the Android platform enables two controls to limit who can talk to you application components. These controls are:
Permissions Intents types The first one is obvious, the component can request the calling application to present a specific permission in order to call your application.
Better late than never. Here is my write-up for the RootedArena 2012 CTF [Spanish]
writeup.pdf
The login activity uses an asynchronous task to validate the user credentials. The ValidateCredsAsyncTask performs this validation
private class ValidateCredsAsyncTask extends AsyncTask<Void, Void, HashMap<String, String>> { Login mActivity; public ValidateCredsAsyncTask(Login activity) { mActivity = activity; } @Override protected HashMap<String, String> doInBackground(Void... params) { LoginRequest client = new LoginRequest(context); String userName = userNameEditText.getText().toString(); String password = passwordEditText.getText().toString(); boolean rememberMe = rememberMeCheckBox.isChecked(); HashMap<String, String> userInfo = new HashMap<String, String>(); if (allFieldsCompleted(userName, password)) { UserInfoDBHelper dbHelper = new UserInfoDBHelper(context); try { userInfo = client.
Continuing the previous post …
RestClient was getting an HttpClient instance using the CustomSSLSocketFactory.getNewHttpClient static method:
public static HttpClient getNewHttpClient() { try { KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType()); trustStore.load(null, null); SSLSocketFactory sf = new CustomSSLSocketFactory(trustStore); sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); HttpParams params = new BasicHttpParams(); SchemeRegistry registry = new SchemeRegistry(); registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80)); registry.register(new Scheme("https", sf, 443)); ClientConnectionManager ccm = new ThreadSafeClientConnManager(params, registry); return new DefaultHttpClient(ccm, params); } catch (Exception e) { return new DefaultHttpClient(); } } Can you spot another, related, vulnerability?
OK, so let start reviewing the FourGoats App. First, If you havent done yet, clone the ForGoats repo from github to get the source code.
Try to get an idea of how does the app work, install it in your device and/or emulator and get familiar with the different activities and application flow.
Open the Main activity and check what its doing. Basically, its looking for a sessionToken and if she cannot find it, it will start the Login Activity, otherwise it will take the user to the Home or AdminHome activities.
If we keep on reading the Login activity, we will soon spot an asynchronous task used to validate the user credentials in the server and we will see that there is a harcoded user/password pair that will set up the admin property and so it will enable us to access the AdminHome Activity:
if (userName.equals("customerservice") && password.equals("Acc0uNTM@n@g3mEnT")) userInfo.put("isAdmin", "true"); If we enter these credentials (and the user is registered in the backend), we will be able to access the AdminHome Activity:
