After waiting 90 days for the developer to answer or fix it, it’s time to inform the public.

90 days ago…

Today I was about to setup the gitlab-integration extension by blakawk in my Atom Editor. While setting up the integration I had to notice, that this extension can leaks my personal access token with full access to the API of my GitLab instance.

Attack

Preconditions

• A user installed the extension and followed the instructions to setup a personal access token from his GitLab instance which provides API access.

• The user has cloned a repository that is hosted on an attacker’s server.

• The user opens the cloned repository in Atom (e.g. to have a look at the code).

Stealing credentials

The attacker has control over the server and therefore can log all incoming requests. The extension parses the origin link and transforms it into an URL that can run an GitLab API request to check if the project exists.

This request is done by the GET-method that sends the GitLab token to the server to find private projects as well.

request({
    method: 'GET',
    uri: url,
    headers: {
        "PRIVATE-TOKEN": @token,
    },
    resolveWithFullResponse: true,
    json: true,
    agentOptions: {
        rejectUnauthorized: @unsecureSsl is false,
    }

This request is logged by the attack and as it contains the personal access token.

This personal access token has API access which effectively allows an attacker to have full access to every project the user owns or has full access to on the GitLab instance it was setup for.

Proof

To proof my first thought switched the extension into the debug mode and check the requests:

As you can see, I cloned a repository from Github and when opening it in Atom, the extension sends the configured access token to GitHub. This works exactly this way for any other repository and destination.

Mitigation

In order to mitigate the attack it’s required to make sure that the GitLab token is only send to the right GitLab instance.

Therefore I recommended to add a new option that asks for the GitLab hostname (or URL), e.g. gitlab.com. This can be used to verify the request target is correct and the token is not send to the wrong host.

For the malfunctioning code the solution should be something similar to:

--- lib/gitlab.coffee.orig 2019-05-22 20:07:49.859165463 +0200
+++ lib/gitlab.coffee 2019-05-22 20:23:38.172858394 +0200
@@ -53,6 +53,9 @@
         )

     get: (url) =>
+        regex = /^https:\/\/gitlab.com/
+        unless regex.test(url)
+          return
         request({
             method: 'GET',
             uri: url,

Minimize damage

Informing users

Further all currently set API tokens should be reset and users should be notified that their tokens were leaked to literally every host they ever cloned a repository from and that they opened in atom since they setup the extension.

Protecting users

The extension should also remove the current GitLab tokens and introduce the user to the additional field to specify which GitLab instance they want to use the token with.

Broken plugin

Back to today…

While writing this blog article I wanted to take some screenshots of the leaking token. While doing this I had to notice that the plugin no longer works with modern atom versions. But that doesn’t mean it’s no longer a threat. No everyone updates their Editor as regular as I do and a fix for the compatibility with modern Atom versions won’t necessarily fix this security issue.

Conclusion

First of all, the lesson learned from this security issue is that you should make sure you only send credentials to the right endpoint in your programs. It sounds trivial but appears to not be as trivial as one might expect.

Second of all, not every developer will answer you. I don’t know if my mail got lost in their spam filter or they simply no longer use this email account, but I didn’t even get an answer, I only know their mail server picked the mail up.

And of course, check what your plugins do before you provide them with your credentials.

TL;DR

When you use the Atom plugin gitlab-integration you should either patch it with the mentioned workaround above or stop using it. Definitely you should revoke the personal access token you were using with it.

Hint: Wide parts of this article is based on the disclosure mail I send to the developer 90 days ago.

Hint 2: This extension shows up when you search for gitlab on Atom’s extension page as 2nd entry and has by now more than 21,500 downloads.

Photo by Clément H on Unsplash