Category Archives: Uncategorized

Postmark is an email distribution company. They provide SMTP relay services for transactional and bulk email messaging. Transactional is a bit of a confusing concept in this space as they are actively marketing for web application integration opportunities. They also provide an API that is compatible with things like Postfix and so it is also possible to use Postmark as your normal, boring, everyday, business, personal (however you describe it) outbound email provider. This means it is possible to run your own infrastructure, but, offload the difficult bit of maintaining a reputation to someone else.

This post doesn’t go into the detail about how to set that up as there is plenty online about that already and the guys at Postmark are pretty helpful in getting up and running. Instead, this post is specifically about how to deal with using Postmark when sending GPG encrypted emails.

Modern GPG usage encapsulates the encrypted portion of the message into a multipart mime envelope. You might have seen something like this before:

Content-Type: multipart/encrypted;
 protocol="application/pgp-encrypted";
 boundary="------------rOANLThIL6qhf9A1ZqSvr0h1"

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--------------rOANLThIL6qhf9A1ZqSvr0h1
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--------------rOANLThIL6qhf9A1ZqSvr0h1
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----

The above is the structure definition of the encrypted portions on the email. There is no plaintext or HTML elements that get sent with such an email. Unfortunately Postmark errors when sending messages that it perceives as having no content. Makes sense, but, their definition of no-content is perhaps a little narrow.

One of the support desk guys at Postmark and I did a bit of Googling and came across someone dealing with a similar situation. That guide uses a tool called ‘altermime’ and essentially gets Postfix to allow Altermime to add a disclaimer / footer to the end of the message thus meaning that there is content. Sadly this does not work for GPG encrypted emails as altermime can’t cope with encrypted multipart messages either.

I set to work and using the same principals I modified their altermime handler script to do what I needed:

#!/bin/sh

# enable debug or not
DEBUG=false

# Localize these.
INSPECT_DIR=/var/spool/filter
SENDMAIL=/usr/sbin/sendmail

# Exit codes from <sysexits.h>
EX_TEMPFAIL=75

# Clean up when done or when aborting.
trap "rm -f in.$$" 0 1 2 3 15

# Start processing.
cd $INSPECT_DIR || { echo $INSPECT_DIR does not exist; exit
$EX_TEMPFAIL; }

cat >in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }

# check if message is has a mimetype that indicates it is encrypted

## get content type
content_type=`grep -m 1 "Content-Type:" in.$$`
boundary_flag=`grep -m 1 "boundary=" in.$$ | cut -d "=" -f 2 | cut -d '"' -f 2`

## debug output
if $DEBUG; then
   cp in.$$ /tmp/disclaimer.in.$$
   echo `date` >> /tmp/disclaimer
   echo "Temp file is: " in.$$ >> /tmp/disclaimer
   echo "Content type is: " $content_type >> /tmp/disclaimer
   echo "Boundary is: " $boundary_flag >> /tmp/disclaimer
fi

if echo ${content_type} | grep -iqF encrypted; then
   if $DEBUG; then
     echo "Found mimetype for an encrypted email" >> /tmp/disclaimer
     echo "Replacement command: sed -i \"s/$boundary_flag--/$boundary_flag\\\n\\\nEncrypted email\\\n\\\n$boundary_flag--/\" /tmp/disclaimer.in.$$ " >> /tmp/disclaimer
   fi

   # add the extra mime boundary with content
   `sed -i "s/$boundary_flag--/$boundary_flag\n\nEncrypted email\n\n$boundary_flag--/" in.$$`
fi

$SENDMAIL "$@" <in.$$

exit $?

This script doesn’t use altermime at all, so you don’t need that tool. Instead it does some string manipulation to add an additional multipart section with the plaintext “Encrypted email” and then hands the mail back over to Postfix.

To make this work, follow this guide, but don’t install altermime, ignore the stuff about addresses, you don’t need /etc/postfix/disclaimer.txt and in /etc/postfix/disclaimer, use the above script instead.

In a previous post we discussed the merits of using JavaScript source maps inside the browser to assist in debugging and web application penetration testing. Today we are delighted to announce the publication of a new Burp Suite App (BApp) called Source Mapper. This tool is free to all users of Burp Suite and can be downloaded directly from the BApp Store within Burp, or manually via GitHub.

It has become common place for JavaScript and CSS files to be “minified” in order to reduce the amount of data transfer required when a user visits a web application. This is particulalrly likely when the web application is a Single Page Application (SPA) or other heavy user of client-side code. Unfortunately, minification makes the code very difficult to debug. The process of minification removes all functionally-unnecessary whitespace and reduces variable and function names to as short a value as possible, often down to a single character.

The plugin is relatively simple, it injects a fragment of code into any JavaScript files it detects which causes the browser to request the script’s source map file. Once the browser requests the source map file, the plugin checks to see if one has been provided by the server. If it hasn’t been provided, the plugin checks to see if it has one locally and then injects it if it can!

Download the plugin now and get debugging!

What is a Source Map?

Modern web applications can include large quantities of JavaScript (JS) and Cascading Style Sheets (CSS) to enable a great user experience. We all appreciate a slick web app, and these technologies are significant components for achieving that.

When web applications have large amounts of JS and CSS, the web developer will often consider how to deal with two side-effects of having all this code:

• the speed the application loads and the level of expectation from the user
• the cost and load of transferring all that extra code across the Internet

To help combat this, developers will often “minify” their code. Minification is the process of removing as much as possible from the code, including long variable names and superfluous white space. This practice reduces transmission across the Internet, improves loading times, and lowers costs.

There are a few ways to achieve minification. One such method is to write using another language, such as TypeScript or CoffeeScript, which gets used to machine-generate the code sent to the user’s browser.
Source Maps are a converter that takes minified code and returns it to the complete state of the original code. Using a Source Map means that the code becomes human-readable again.

Why do Source Maps matter to Penetration Testers?

When performing a cyber security assessment of a modern web application, it can often be crucial to fully understand how the code behaves within the user’s web browser. It can be challenging to understand minified code, especially when identifying security flaws.

It is not unreasonable to suggest that the developers could send a copy of the original code to the penetration tester, but this would be stand-alone code not processed alongside the rest of the web application. The original code is rebuilt and can be read and understood using Source Maps. Crucially, this is also then possible within the web browser. Having the original code within the browser allows the penetration tester to understand the inner mechanics of the code during execution.

It is possible to complete the work without the Source Maps as the executed code is still present. However, it will likely just take more time to complete the task. With all of this in mind, we recommend that Source Maps are shared with penetration testers to ensure they have as comprehensive visibility of the web application as possible. There is also the question about allowing Source Maps to be available publicly. The context of the web application will dictate whether providing Source Maps openly to the public is acceptable. However, most developers are cautious on this matter and only provide them if there is a justifiable reason.