Applications interacting with blockchain networks can be an attack surface to malicious actors and therefore need to be reviewed thoroughly.
This post discusses a vulnerability in a web application on top of a Substrate-based blockchain. The vulnerability was found, reported, and fixed during a security audit for the SocialKYC service before its release. The application is built on KILT Protocol and has been initially developed by B.T.E. BOTLabs Trusted Entity GmbH. In the past, SRLabs also audited KILT Protocol and a number of other networks in the Polkadot ecosystem.
Insights into (potential) vulnerabilities like this one are especially important since blockchains are employed for more and more use cases. The claim that blockchains offer a secure way of storing data and therefore can create trust between different parties is one reason for these developments.
Nevertheless, blockchains come with their own set of security challenges. In other posts we investigated common mistakes found in Substrate blockchains and shared insights into our best practices for the review of such blockchains. This post highlights how applications on top of blockchains can have a significant impact upon the overall security of blockchain technologies.
The web application we investigated is an identity verification service called SocialKYC which provides users with authentication claims for various social media platforms. With these credentials users can prove to other entities that they are the owners of the accounts. Therefore, the users’ credentials are verified by SocialKYC, anchored in a Substrate-based blockchain, and stored in KILT’s Sporran wallet – a browser extension. Sporran has a lot in common with crypto wallets, tools that store data to confirm asset ownership. Wallets are a sensitive spot of blockchain technologies since they hold the keys to the data that is stored on the blockchain. Our example shows how to create a key for something that is not in one’s possession.
We conducted this audit during the QA phase of the service, before go-live. At this time, two credential types were available – email and Twitter. If a user wants to attest their ownership of an email address, a one-time verification link is sent to the address. As soon as they click the link, the user will get a credential representing this email address. This can later be used for authentication in other services.
For the verification of a Twitter account, users must tweet out a message containing a one-time code and the @social_kyc_tech account handle. Once this tweet is published the user can claim the credential of this Twitter handle as theirs. They are now able to “Log in with Twitter” on various services without having to input their Twitter account credentials and without Twitter even knowing that they logged into the service. This is meant to increase privacy for the user as well as to give them back control over their credentials.
To keep the application extensible, since the implementation of more social media credentials is planned soon, the developers kept the code as general as possible. Therefore, both types of authentications use the same basic secret generation mechanism and share some of the verification logic.
More specifically, this means the secret in the email’s confirmation URL is stored in the same structure as the secret that one needs to tweet out to verify their Twitter handle. This can lead to critical vulnerabilities if anything is omitted.
Here is the vulnerability we found in action that enabled us to verify a Twitter handle that does not belong to us:
First, we enter the SocialKYC website to start the attestation of the Twitter handle (Figure 1).
The authentication method is to tweet out a message containing a secret (Figure 2) – notice the long number at the end of the tweet.
We can see that the attestation is now pending in KILT’s Sporran wallet (Figure 3).
Here comes the trick: We navigate to the link that was sent to us earlier via email to attest our email address, but we replace the number in the link with the number in the tweet (Figure 4). This will start the email authentication process.
After a bit of waiting our credential is ready (Figure 5). Let us have a closer look at it.
Success! We have an attested credential for a Twitter handle we do not control (Figure 6).
So, why were we able to do that? Simply because the claim type was not verified during the email attestation process. This made it possible to trick the server into attesting our Twitter identity using the Twitter secret code as the secret in the email verification URL.
Three lines of code fixed this issue:
During the email attestation process it is now verified that the claim’s type is “email” and if it is not, the attestation process will stop.
Blockchain systems pride themselves on the fact that we can trust them. Nevertheless, they need to be reviewed and – as we have shown – the applications on top of them as well. In our example, a trivial omission in the code caused the whole SocialKYC Twitter attestation mechanism to become untrustworthy; three lines of code fixed the issue. Our example highlights that unspecified claim types can make identity verifications unreliable.
This research was done by our blockchain team at SRLabs. If you like to solve riddles and to fix the security challenges of blockchain technologies, get in touch or consider joining our team.
Editing by: Maria Bühner
