RocketChat RCE, Flickr, and a Critical Smart Contract Bug
nodeIntegration being enabled).
Rocket.Chat will add a
tl;dr There are two key issues with Flickr’s use of AWS Cognito for their authentication, first, is that only the
sub attribute is guaranteed to be unique and should be used to identify users, second is that the
access_token provided can be used to modify user attributes. These issues can be chained to modify the
Not all SSRF vulnerabilities are equal, a common mitigation is to limit the locations that can be accessed; in the case of WebSphere Portal, this is exactly what was found, yet it could still be exploited.
In the Portal server they found a proxy endpoint that would proxy requests to Portal to a set of whitelisted domains:
As the configuration also allowed following redirects, the author was able to chain this with an Open redirect in Lotus Domino running on
redbooks.ibm.com to redirect to an arbitrary location.
There is not much said about exploiting this issue, though if running within a cloud envrionment, the metadata server is a good target. They also looked at targeting the Admin control for WebSphere which runs on the local machine, but shouldn’t be exposed to the internet. Unfortunately they did not manage to find an attack path, but local resources are another good target to escalate an SSRF.
Polygon places the blame for this bug on not checking that the
from address in a transfer actually has the balance to cover the transfer in the first-place. While I don’t doubt that as a core issue it feels like that may only be part of the issue, the other part being a lack of error checking, or perhaps improper error handling.
Getting into the actual issue, the root issue is that the it is never checked if
from is able to fulfil the transfer. Beyond that it seems that error handling might also be an issue, in that
transferWithSig does not check if
ecrecovery returned an appropiate address, as it returns
address(0x0) on error conditions. It also seems noteworthy that
ecrecovery itself only raises an error its call to
ecrecover fails and returns 0x0. I’m not too familiar with dapp development so I’m not sure if this is expected but it seems that it should be raising an error in all error situations rather than just returning a special value.
address(0x0) without any other error indicator when the length of the hash is not 65 is can very easily be triggered.
transferWithSig will use this address as the
from address, resulting in a transfer from the “genesis contract” of any amount.
Patch: This was resolved by switching to a fork and entirely disabling the