Still SSRF vulnerability in external feed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
Medium
|
Aaron Wells | ||
15.04 |
Fix Released
|
Medium
|
Aaron Wells | ||
15.10 |
Fix Released
|
Medium
|
Aaron Wells | ||
16.04 |
Fix Released
|
Medium
|
Aaron Wells |
Bug Description
While taking another look at Bug 1397736 (SafeCURL) and Bug 1394820 (SSRF in external feed) I realized there are some problems with the patch https:/
As a refresher here, the idea is that an attacker can do this:
1. Log in to Mahara
2. Create a page
3. Put an "External Feed" block on the page
4. Set the "Feed location" to "localhost:389"
Expected result: This meaningless URL does nothing, and the block config harmlessly errors out and asks them for a valid URL.
Actual result: They see an error message that tells them whether the web server has port 389 (unencrypted LDAP) open or not. If the error they see ends with "Recv failure: Connection reset by peer", they know the web server has a process listening on 389. If they see "Failed to connect to... Connection refused" they know it is not.
It's called an SSRF (Server Side Request Forgery) attack ( http://
My patch 4029 was to add the "CURLOPT_PROTOCOLS" option to our Curl requests. This has the main effect of preventing an attacker from using an HTTP redirect to make Curl send a request to a non-HTTP protocol. But it doesn't at all mitigate all the information-
As such, it didn't mitigate any of those information-
information type: | Private Security → Public Security |
Changed in mahara: | |
status: | Confirmed → Fix Committed |
Changed in mahara: | |
status: | Fix Committed → Fix Released |
Fortunately, I've also realized it should be fairly easy to prevent those information gathering attacks through two steps:
1. Stop printing the underlying Curl error message in the form. The different Curl error responses are the main way the attacker can gather information from this attack. We should instead print something generic like "That feed URL appears to be invalid."
2. Add a random sleep interval to this process, to hinder detection based on timing.
If we do that, then the external feed block will become mostly useless for network exploration. (It'll still have some potential for abuse, but only the much less useful capability of sending HTTP "GET" requests without being able to see the response.)