graphite.composer.views.send_email vulnerable to SSRF

[alex]

(I didn't discover this, it was publicly described here: http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html)

https://github.com/graphite-project/graphite-web/blob/master/webapp/graphite/composer/views.py#L95-L102

Some sort of validation should be performed on the server component of the URL (possibly a whitelist in settings? I'm not overly familiar with the design of this module). Currently it's possible to use this view to make HTTP requests to services visible from the server.

[JLLeitschuh]

Hi,

So this vulnerability is still live, and this could 100% be abused to exploit the servers publicly exposing the Graphite server here:

https://www.shodan.io/search?query=Graphite+Browser

Here are the vulnerable lines:

graphite-web/webapp/graphite/composer/views.py

Lines 95 to 124 in 8ee7d04

	def send_email(request):
	try:
	recipients = request.GET['to'].split(',')
	url = request.GET['url']
	proto, server, path, query, frag = urlsplit(url)
	if query: path += '?' + query
	conn = HTTPConnection(server)
	conn.request('GET',path)
	try: # Python 2.7+, use buffering of HTTP responses
	resp = conn.getresponse(buffering=True)
	except TypeError: # Python 2.6 and older
	resp = conn.getresponse()
	assert resp.status == 200, "Failed HTTP response %s %s" % (resp.status, resp.reason)
	rawData = resp.read()
	conn.close()
	message = MIMEMultipart()
	message['Subject'] = "Graphite Image"
	message['To'] = ', '.join(recipients)
	message['From'] = 'composer@%s' % gethostname()
	text = MIMEText( "Image generated by the following graphite URL at %s\r\n\r\n%s" % (ctime(),url) )
	image = MIMEImage( rawData )
	image.add_header('Content-Disposition', 'attachment', filename="composer_" + strftime("%b%d_%I%M%p.png"))
	message.attach(text)
	message.attach(image)
	s = SMTP(settings.SMTP_SERVER)
	s.sendmail('composer@%s' % gethostname(),recipients,message.as_string())
	s.quit()
	return HttpResponse( "OK" )
	except:
	return HttpResponse( format_exc() )

A simple version of this exploit would be to chain this together with an SSRF attack against AWS to steal very valuable information and rack up a very sizable AWS bill. Given the code paths that I've seen, I know that this is most likely possible.

This should 100% have a CVE number assigned to it.

---

@orangetw: Can you please make sure you sweep up after yourself when you disclose vulnerability at large hacker conferences like Defcon? ❤️

[deniszh]

Well, we overlooked that somehow and we should probably fix that even without CVE number. I’ll try to look at it, but I’m not sure that I’m experienced enough to fix that properly. Any suggestions? @orangetw @alex @JLLeitschuh ? Otherwise I would prefer to remove that functionality completely, I’m doubt that it widely used. What do you think @DanCech @piotr1212 @cbowman0 ? Thanks!

…

On Tue, 1 Oct 2019 at 20:43, Jonathan Leitschuh ***@***.***> wrote: Hi, So this vulnerability is still live, and this could 100% be abused to exploit the servers publicly exposing the Graphite server here: https://www.shodan.io/search?query=Graphite+Browser A simple version of this exploit would be to chain this together with an SSRF attack against AWS to steal very valuable information and rack up a very sizable AWS bill. Given the code paths that I've seen, I know that this is most likely possible. This should 100% have a CVE number assigned to it. ------------------------------ @orangetw <https://github.com/orangetw>: Can you please make sure you sweep up after yourself when you disclose vulnerability at large hacker conferences like Defcon? ❤️ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2008?email_source=notifications&email_token=AAJLTVW3EVYBDT6PDZMBK3LQMOK4VA5CNFSM4DU4S5U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEACKBOQ#issuecomment-537174202>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJLTVT7M6LVGK6NPHIZEUTQMOK4VANCNFSM4DU4S5UQ> .

[JLLeitschuh]

One way to fix this issue would be to convert that endpoint from accepting HTTP GET requests to accepting only Cross Site Requset Forgery (CSRF) protected POST requests that require a user to be logged in.

Part of the problem with this though is that Graphina ships with the default credentials of root root. I'd advise also preventing the use of this endpoint (at minimum) if the user is detected to still have the default credentials.

[JLLeitschuh]

Also, I'd recommend limiting the outgoing request so that it can only be made against known safe/trusted endpoints.

Also, I stand by this needing a CVE.
If you want to use the GitHub process to get this, consider moving this discussion to a security advisory (and including all of us in it).

https://github.com/graphite-project/graphite-web/security/advisories

[JLLeitschuh]

@deniszh Can you also create another security advisory for something else I need to report.

[deniszh]

Hi @JLLeitschuh ,

Sorry, I'm not really aware of Github security advisores and how it works. Created for both issues, added you to collaborators.

[orangetw]

Oops, I only reported to GitHub at that time. Sorry for that :(

[deniszh]

OK, I checked this send_email function and didn't find any good use for it in the code. It was imported during initial import 12 years ago and also not documented in API docs.

I think we just need to remove it.

Opinions? @DanCech @iksaif @piotr1212 @cbowman0 ?

[alex]

I haven't used graphite in several years, and just filed this since I care about the security and health of the internet. From my perspective, deleting code is a great solution to security issues!

[DanCech]

+1 for just removing it. I don't see anywhere in the code that uses it.

[deniszh]

Please also note that sending email from Dashboard is implemented in completely different commit e2a70d8 and not use send_email function at all.