On Web Security

Compiling WordNet on Windows to use with Emacs

Peter Mosmans — Thu, 24 Jan 2019 10:00:00 +0000

As a non-native English speaker who reads, writes and reviews lots of English texts, I frequently look up definitions as well as synonyms of words. Of course there are numerous online sources available to do this, but I like to decrease my online 'footprint' due to privacy reasons. It also takes extra time to switch to a browser window and enter a search query.

Fortunately the fine folks at Princeton University compiled WordNet [1], a large lexical database of English, which can be used offline - together with a tool to search that database. Even better, somebody wrote a package to use WordNet inside my favorite editor Emacs [2]. This means that just by hovering the cursor over a word inside Emacs, the definition as well as synonyms can be shown. The source code [3] is kindly provided by Princeton University.

Compiling WordNet using MSYS2 on/for Windows

As is usually the case, compiling on/for Windows using the MSYS2 subsystem [4] can be done, with a few minor tweaks.

First, start a MSYS2 shell and install the required dependencies (build tools, as well as the programming language Tcl and its widget toolkit Tk ):

pacman -Sy --noconfirm base-devel mingw-w64-x86_64-tcl mingw-w64-x86_64-tk

Then …

VirtualBox Does Not Automatically Resize Disk Image

Peter Mosmans — Mon, 14 Jan 2019 10:00:00 +0000

I use VirtualBox [1] a lot as (local) virtualization software. It is a full-featured virtualization host, and supports multiple underlying disk image file types for guests.

One of those is VirtualBox' native Virtual Disk Image or VDI file type. An advantage of this type is that one can create a dynamically allocated image. This image will initially be very small and not occupy any space for unused virtual disk sectors, but will grow when a disk sector is written to for the first time. VirtualBox does this by checking for unused sectors.

However, this poses issues for disks with multiple partitions. If the last partition is say a (unused) swap partition, then VirtualBox does not automatically grow the underlying image. Even though the first partition is full, VirtualBox will not grow and therefore the host disk will be full without having reached its full potential.

To solve this issue, the machine needs to be partitioned using one big happy partition. Then VirtualBox will dynamically resize according to expectations.

I use packer [2] to prepare disk images for Debian, together with a preseed [3] file. Using preseeding to partition the disk is limited to what is supported by the partition tool …

Setting Up a New Sphinx Documentation Framework

Peter Mosmans — Wed, 24 Oct 2018 10:00:00 +0000

When having to write documentation for different formats, I always use the reStructuredText [1] (or reST) format. As this is something that happens quite often, it made sense to put some effort in automating the set up of a new documentation framework, a reusable set up script.

The standard documentation framework that I use consists of Sphinx [2], which takes care of converting source pages written in reST into several formats: For example HTML, but also PDF or something more exotic like ePub files. Note that Sphinx already comes with a setup script, sphinx-quickstart [3] - but this doesn't take care of deploying files.

In order to be able to create a reusable framework, I split the necessary files into three groups:

The Sphinx configuration itself,
version information, and
a LaTeX formatting template.

The Sphinx configuration

This part consists of two different files; A generic Makefile [4] to build the different artifact types - as well as a Sphinx configuration file (conf.py [5]) containing basic information about the project, and plugin details. These files rarely change after having initialized the framework.

Version information

The version information (version, or build number) can change per release, and is therefore contained in a separate …

Hacker Summer Camp: BSides Las Vegas and DEF CON 2018 review

Peter Mosmans — Mon, 08 Oct 2018 10:00:00 +0000

Time flies... It's already been a few months ago that BSides Las Vegas and DEF CON 2018 were held.

BSides Las Vegas was nice, although the overall quality of talks seemed to be a little higher in previous editions. This of course can be completely due to me picking exactly the wrong talks: There is simply too much to see.

DEF CON 2018 was also different than previous editions - mostly, because it was now so spread out (Caesars Palace as well as the Flamingo Las Vegas). In practice, this meant a lot of walking between the two locations. When you were attending a talk in one location, it physically wasn't possible to attend the next one unless it was located in the same or surrounding room.

Fortunately DEF CON is all about learning, doing and networking - and in that aspect it didn't disappoint.

Especially for Hacker Summer Camp, I designed and built my own badge - consisting of an ESP32 [1] microprocessor running MicroPython [2], an e-Ink display, some custom Python code, and a retro cassette case. The display rotates numerous fitting images. The image was visible even when the power was disconnected, thanks to the 3-color e-Ink display.

A follow-up …

Customize and theme tmux the easy way

Peter Mosmans — Mon, 11 Jun 2018 10:00:00 +0000

Terminal multiplexers allow you to view multiple separate terminal sessions within a single terminal window. Tmux is my terminal multiplexer of choice, as it has more features than the 'original multiplexer' GNU Screen. The default setup gives you some information, but its appearance is, well...

Fortunately you can theme, or customize pretty much everything: From the colors to the information being shown in the status bar.

In order to make it easier to theme tmux, I split the tmux configuration file into two separate files. One file contains the main configuration (~/.tmux.conf ), and another file contains only theming (visual) variables (~/.tmux.THEMENAME.theme ). This setup makes it easier to switch different themes, without changing the main tmux configuration file.

As I wanted to automatically load a theme based on a shell environment variable, I added a small piece of code to the main tmux configuration file. This executes a shell command, which in turn loads the correct theme file.

run-shell "tmux source-file ~/.tmux.\${TMUX_THEME:-default}.theme"

The theme file is loaded dynamically, based on the environment variable $TMUX_THEME . If the environment variable is not set or empty, then the default theme is loaded: ~/.tmux.default.theme .

Loading a different …

Improving cross-subsystem git workflow: The different git configuration files

Peter Mosmans — Tue, 24 Apr 2018 10:00:00 +0000

Git configuration settings can be stored in three different files: The system configuration file, the global configuration file and the repository's local configuration file. See git on Windows - location of configuration files [1] for their locations.

When you use multiple subsystems on Windows (like MSYS2, Cygwin or any of the the Windows Subsystem for Linux distributions) it can be a chore to keep the git configurations synchronized. In other words: The less configuration files to maintain, the better.

Whether it's git for Windows, or one of the subsystem-specific git binaries:

Each of the git binaries that runs on Windows expands the tilde (~ ) to the home directory, and the path separator is always a slash (/ ).

These features can be used in our advantage in order to simplify the git configuration files between all subsystems.

Re-defining the system

The system configuration file is meant to store all system-specific configuration settings, which will be applied to all users and git repositories on the system.

If you're the only user of your workstation, it makes sense to re-define system as subsystem:

All subsystem-dependent git configuration settings should be set in the system git configuration file.

This means that settings depending on underlying binaries, like …

When to sharpen, and when to cut

Peter Mosmans — Thu, 15 Mar 2018 10:00:00 +0000

When performing a task for the first time, I think of whether it's a one-off, or that it will become a recurring thing. Python scripts for example can be developed blazingly fast, and a little bit of automation can go a long way.

However...

...sometimes, while developing an automated solution that looked so simple beforehand, becomes a wild ride from one rabbit hole into the other. Missing dependencies, compile errors, functions that don't lend themselves very well for automation; Everything that can go wrong will go wrong.

That's why I like The Pomodoro Technique [1] so much, where you work in discrete time chunks of say 25, or 30 minutes. You decide upon the maximum cost for the implementation beforehand. Given the expected return, what is a sane investment ? If the time is up, then it's back to the original task at hand.

I have learned the hard way to always budget some time for documenting the (partial) solution, so that at least there's the profit of knowledge gained. Or, another record of a failed attempt...

[1]	https://francescocirillo.com/pages/pomodoro-technique

Rebase OpenSSL 1.0.2-chacha to use TLS 1.3

Peter Mosmans — Wed, 31 Jan 2018 10:00:00 +0000

Since its inception in 2014, the OpenSSL 1.0.2-chacha fork [1] has been used as standard OpenSSL distribution for numerous SSL/TLS pentesting tools. It includes default support for ciphers that are deemed insecure, and has extensive starttls support.... in comparison with the vanilla 1.0.2 branch.

However, even though 1.0.2 is deemed a Long Term Supported (LTS) version, no new ciphers or functionality will be added to it.

The initial reason to start the fork was a lack of ChaCha20 / Poly1305 support in the 1.0.2 branch. After that, more and more features and insecure ciphers were added or ported back in from other branches.

As ChaCha20 / Poly1305 support has been added to the 1.1.1 branch, which also contains (preliminary) TLS 1.3 support, it might be time for the insecure OpenSSL version to be rebased onto a new branch. The initial goals will still be the same:

Add as much ciphers and functionality as possible
Keep the source aligned as much as possible to the vanilla version
Keep the patches atomic, transparent and maintainable
Write as little custom code as possible

This will be quite the challenge, as the architecture and …

Tools for setting, tracking and achieving long term goals

Peter Mosmans — Thu, 18 Jan 2018 10:00:00 +0000

Immediately after reading an article on David Allen and his brainchild Getting Things Done, I started with implementing his methodology. I loved it. I still love it - especially the Getting Things Done concepts of inbox ZERO, maintaining lists, and periodic reviews.

Inbox ZERO for me is not so much about having empty email inboxes, as well as making sure that input is collected from multiple locations and stored into one dedicated location. An inbox can also be a notebook, or note taking software like Google Keep.

Electronically stored lists have the benefit of being available on a multitude of devices, the ability to synchronize between them, backups, and their biggest advantage - providing dynamic views.

Both tools that I have been using so far (the open source Java application ThinkingRock [1], and Emacs in Org mode [2]) for maintaining lists of actionable items and projects were great in that perspective. Using those tools for periodic reviews was a different story. After trying numerous configurations I never got the hang of using ThinkingRock and Emacs for that purpose. Items become abstract letters on a screen. Views never fully captured what was important or which project served which goal.

Periodically reviewing projects and …

Diff binary files like docx, odt and pdf with git

Peter Mosmans — Sun, 19 Nov 2017 10:00:00 +0000

Working with binary file types like the Microsoft Word XML Format Document docx , the OpenDocument Text odt format and the Portable Document Format pdf in combination with git has its difficulties. Out of the box, git only provides diffing for plain text formats. Comparing binary files in textual format is not supported.

With a simple configuration change and some open source, cross-platform tools, git can be adapted to diff those formats as well.

Installing the tools

First, one needs the tools which can convert the binary files to plain text formats. For most formats like docx and odt , the open source tool Pandoc [1] will do the trick. It can even export those files to Markdown format, or (my personal choice) reStructuredText [2]. A markup language like reStructuredText makes it possible to make a detailed comparison between structured documents, for instance when the heading level changed.

For PDF, there's the open source tool pdftotext , which is part of the Poppler [3] utils package and available for (almost) all operating systems. This can convert a PDF file to plain text.

There's a tiny catch with pdftotext , as it has issues using stdout as output, instead of writing to files. This is …

Structure research, talks and trainings using mindmaps, reStructuredText and Emacs Org mode

Peter Mosmans — Wed, 18 Oct 2017 11:15:00 +0000

Researching new vulnerabilities, techniques or concepts can be time-consuming and sometimes chaotic. A streamlined workflow is necessary to make the process as efficient as possible. This article describes the open source tools and well-known standards that I'm currently using for that purpose.

Properly encoding and escaping for the web

Peter Mosmans — Wed, 13 Sep 2017 10:15:00 +0000

When processing untrusted user input for (web) applications, filter the input, and encode the output. That is the most widely given advice in order to prevent (server-side) injections. Yet it can be deceivingly difficult to properly encode (user) input. Encoding is dependent on the type of output - which means that for example a string, which will be used in a JavaScript variable, should be treated (encoded) differently than a string which will be used in plain HTML.

When outputting untrusted user input, one should encode or escape, based on the context, the location of the output.

And what's the difference between escaping and encoding ?

Encoding is transforming data from one format into another format.

Escaping is a subset of encoding, where not all characters need to be encoded. Only some characters are encoded (by using an escape character).

There are quite a number of encoding mechanisms, which make this more difficult than it might look at first glance.

URL encoding

URL encoding is a method to encode information in a Uniform Resource Identifier. There's a set of reserved characters, which have special meaning, and unreserved, or safe characters, which are safe to use. If a character is reserved, then the …

Hacker Summer Camp: BSides Las Vegas and DEF CON 2017 review

Peter Mosmans — Thu, 10 Aug 2017 22:57:00 +0000

The 2017 edition of Hacker Summer Camp is over... Blackhat, BSides and DEF CON: Arguably the best security conferences in the world, being held during a week in Las Vegas. And wow, what an amazing edition it was this time.

I tried to learn, network, enjoy and soak up as much as possible - which unfortunately means not seeing each and every talk, and (probably) missing out on amazing content. That's why I'm so glad that recordings and slidedecks are being released by BSides and DEF CON, so that you can see where you should have been - after the fact.

The biggest draw for me personally to BSides and DEF CON is that you can immerse yourself in fields and interests that are outside of your daily work or routine. Car hacking, lockpicking, the Internet of Things, this year even voting machines: It's all there. You can learn from and play with everything.

As with playing Capture the Flag, it's a great way to touch a lot of surfaces in a short amount of time.

Josh Corman's BSides Las Vegas keynote was amazing - each time I hear him speak, he manages to get everybody even more enthusiastically about cooperation, about personal …

Generate list of used content tags for Pelican

Peter Mosmans — Sun, 09 Jul 2017 20:25:00 +0000

If your Pelican-generated site uses lots of different tags for articles, it can be difficult to remember or use tag names consistently. Therefore I needed a quick method to print (comma separated) unique tags that were stored in text files.

This shell one-liner from within the content directory will sort and show all tags from reStructuredText (*.rst ) files:

grep -h '^:tags:' *.rst | sed -e 's/^:tags:\s*//;s/\s*,\s*/\n/g' | sort -u

First grep will filter on the :tags: property and will only print out the matching line (without filename, thanks to the -h flag).

Then sed will remove the :tags: keyword (and trailing spaces), and all tags will be split using newline characters.

Finally, sort takes care of sorting and only printing unique entries.

Analogous, one can do the same for categories:

grep -h '^:category:' *.rst | sed -e 's/^:category:\s*//' | sort -u

As Pelican only allows one category, this is somewhat simpler.

For maximum readability, tr can convert the newlines into spaces, so that the output is one big line:

grep -h '^:tags:' *.rst | sed -e 's/^:tags:\s*//;s/\s*,\s*/\n/g' | sort -u | tr '\n' ' '; echo

The last echo is meant to end …

Convert WordPress to static site generator Pelican

Peter Mosmans — Tue, 27 Jun 2017 00:00:00 +0000

After a number of years using WordPress as blogging software, I converted the site to a static site generator: Pelican.

Pelican converts reStructuredText into static HTML. No more PHP, no more databases, but straight static HTML.

The process of converting the site was relatively painless. The conversion tool did a great job of converting an XML export of WordPress into reStructuredText pages.

What needed (and still needs) some manual care were/are the code blocks (the biggest reason of the move from WordPress to Pelican) in articles, and the escaping of variables. WordPress gets pretty complex once you're trying to use it for code snippets and console outputs. The reStructuredText is much more flexible and allows you to edit the site using any text editor. There are tools to do that with WordPress and its API, but it always felt like a difficult workaround.

I thought about keeping the URLs as-is: Over the years the number of visitors of the site has steadily risen, as has the level of indexing by search engines. You don't want dead links - but on the other hand, a transition to another content management system would be the perfect moment to 'clean up' the category …

Write once, present anywhere in every format: preparing an interactive secure coding workshop

Peter Mosmans — Tue, 06 Jun 2017 08:42:00 +0000

How to use reStructuredText and Sphinx to convert a single source into multiple formats for security workshops. Generate a dynamic website, a PDF handout and more, all using the same plain text files.

zsh shell inside Emacs on Windows

Peter Mosmans — Fri, 19 May 2017 02:11:00 +0000

Configuring Emacs (on Windows) to use the zsh shell can be tricky, especially when you use ( oh my zsh) plugins or fancy prompts. Emacs sets an environment variable when running a shell, which can be used to selectively disable plugins and change prompts. Configuring the SSH client and server to set and accept that variable makes ssh-ing inside Emacs to remote servers possible as well.

The complexity of securing Docker versus Vagrant

Peter Mosmans — Wed, 03 May 2017 04:40:00 +0000

There are many, many comparisons out there on the Internet of Docker versus Vagrant. Usability, scalability, portability, you-name-it-ability.

This blogpost is about some different security aspects about the current implementation of Docker versus Vagrant. It's a high, high-level comparison of the security impact for the host system.

Can you compare the two ? Not really, they're being used for completely different reasons. Docker is wildly popular for medium to large scale production webserver deployments and microservices, where each service has its own process, or container. Vagrant is more being used during design and development by individual developers, or in teams at companies.

So, having said that, let's compare the security differences in high-level:

Docker

Partial isolation from the host
Shares the kernel with the host.
Resources aren't guaranteed, they're shared.
Uses runC/libcontainer as runtime (before version 1.8 it used linux containers (lxc) under the hood, then libcontainer, and since the inception of the Open Container Initiative it uses runC which abstracts even further away from libcontainer). System resources can be allocated using control groups (cgroups): block devices (blkio), CPU (cpu), CPU accounting (cpuacct), individual CPU and memory nodes (cpuset), devices, task management (freezer), memory usage (memory), network packets (net_cls …

Security through obscurity means better operational security

Peter Mosmans — Sun, 16 Apr 2017 06:04:00 +0000

What I personally like so much about being a penetration tester, is
that (I'd like to think that) we make the world a safer place. Better
security means better privacy means more democracy.
It's not about telling people what "they" did wrong. On the contrary,
it's a learning process for all of us. No single application, network
or system is the same. Each company has its own risk model, which
means that there often is no one-size-fits-all solution.

It's about "how can we improve the security" for everybody. That's why I think it's so important that penetration testers should lead by example. Apply proper operation security procedures themselves.

Recently my first Pluralsight course was published, operational security for penetration testers. It deals with what opsec is, and how to apply it to your penetration testing workflow. The trailer of the course can be found at https://www.youtube.com/watch?v=DSF6XbCxYGY. The course itself can be found on Pluralsight's site, https://www.pluralsight.com/courses/opsec-penetration-testers

As beautifully stated by the third law of OPSEC: "If you are not protecting it, the adversary wins".

Use Emacs to create OAuth 2.0 UML sequence diagrams

Peter Mosmans — Thu, 23 Feb 2017 03:11:00 +0000

It seems that the OAuth 2.0 framework is more and more being used by web (and mobile) applications. Great !

Although the protocol itself is not that complex, there are a number of different use-cases, flows and implementations to choose from. As with most things in life, the devil is in the detail.

When reviewing OAuth 2.0 implementations or writing penetration testing reports I like to draw UML diagrams. That makes it easier to understand what's going on, and to spot potential issues. After all, a picture is worth a thousand words.

This can be done extremely easy using the GPL-licensed open source Emacs editor, in conjunction with the GPL-licensed open source tool PlantUML (and optionally using Eclipse Public Licensed Graphviz).

Emacs is worlds' most versatile editor. In this case, it's being used to edit the text, and automatically convert the text to an image. PlantUML is a tool which allows you to write UML in human readable text and does the actual conversion. Graphviz is visualization software, and optionally - in this case, it's used to show certain images.

Download the compiled PlantUML jar file, Emacs and optionally download and install Graphviz.

Once you have Emacs installed and running …

It's about the journey: Compiling 64-bit Unison / GTK2 on Windows

Peter Mosmans — Sat, 24 Dec 2016 03:23:00 +0000

The excellent MSYS2 (mingw64 and mingw32) subsytem makes compiling native Windows compilations "as easy as compilation can be". However, as with everything in life, sometimes when trying to do one thing (compile a program), you end up chasing other vaguely related issues (one exotic compile error after another).

For synchronizing files between servers and workstations I use the open source GPLv3 licensed Unison File Synchronizer [1]. Although the text interface version of Unison compiles straight-out-of-the box on mingw64, the GTK2 interface proved to be a bit more cumbersome.

To compile Unison with the GTK2 interface, lablgtk [2] is needed, an OCaml interface to GTK.

So, the journey began with firing up a shell in a fresh mingw64 environment, and installing the build prerequisites:

pacman -Sy --noconfirm base-devel git \
mingw-w64-x86_64-{glib2,gtk2,ocaml,pango,toolchain}

After downloading the latest source (2.18.5 [3]) and trying to compile it (using make ) after running

./configure --prefix=/mingw64 --disable-gtktest

the first error message is shown:

mingw64/include/gtk-2.0/gdk/gdkwin32.h:40:36: fatal error: gdk/win32/gdkwin32keys.h: No such file or directory

It seems that GTK2 version 2.24.31 contains an error [4], and incorrectly still references the file …

Why Sharing Improves Us

Peter Mosmans — Fri, 16 Dec 2016 05:38:00 +0000

If you're a perfectionist, it's difficult to release a product: Whether that's source code, a pentest report or a blogpost. It's always a work in progress, and never finished.

That's why I like open sourcing code for example, releasing it for everybody to see. Knowing beforehand that the code, your work will be read by others (while you're working on it) forces you to think longer, deeper and harder about the variable names, the structures, function names and coding styles.

I'm the lead pentester for a company where we allow the customer to peek over our shoulder while we're working. The customer can see everything that we try, do and find out during the pentest. This improves the relationship with the customer, as s/he sees what we're doing and even can think along with us.

It also improves the customer satisfaction, as they know exactly what they're getting. And, it improves the mutual respect. Instead of becoming a classical us-versus-them pentest (the pentesters versus the developers), it becomes a 'let's improve the overall security together' exercise.

According to all the positive feedback we're receiving, we're onto something here. A win-win.

Sunlight is not only a great disinfectant, it's also …

Verify security vulnerabilities: A collection of Bash one-liners

Peter Mosmans — Fri, 25 Nov 2016 02:09:00 +0000

There's manual pentesting and writing reports, and there is blindly
copying the output of automated scantools. I am fortunate enough to
write and review a lot of pentest reports, as well as read pentest
reports of a other companies.
Nothing looks as bad as "vulnerabilities" in a report that haven't
been verified as such. This really degrades the quality of the report.

Below is a number of simple one-liners that can help with verifying vulnerabilities. All examples can be run in a basic shell (Bash, zsh), where the TARGET variable contains the hostname of the target that needs to be verified (without protocol).

SSL/TLS: BREACH

for compression in compress deflate exi gzip identity pack200-gzip br
bzip2 lzma peerdist sdch xpress xz; do curl -ksI -H "Accept-Encoding:
$compression" https://$TARGET \| grep -i "content-encoding:
$compression"; done

*Might* be vulnerable when: one or more compression methods are shown.

SSL/TLS: Client-Initiated Secure Renegotiation

echo "R\nQ" | timeout 10 openssl s_client -connect ${TARGET}:443

Vulnerable when: Renegotiation is successful (exit code == 0)

HTTP: TRACE enabled

for proto in http https; do echo testing ${proto}://${TARGET};
curl -qskIX TRACE ${proto}://${TARGET}\|grep -i TRACE; done;

Vulnerable when: the verb TRACE is shown

HTTP: Open …

Zen provisioning: Bootstrap the installation of Ansible using Vagrant

Peter Mosmans — Fri, 07 Oct 2016 04:20:00 +0000

I'm a big fan of the DevOps attitude of "cattle" versus "pets": machines should be built in a repeatable, automated and consistent way. If there's something wrong, don't be afraid to replace a sick "cow" instead of trying to revive your "pet".

This Zen mindset also helps when preparing for demos, trainings and workshops: Usually I need a number of machines, and what better way than create them by using automation ? For that I'm using the tools Ansible, Packer, Vagrant and VirtualBox - they are all Open Source and can be used on a number of platforms (e.g. Windows, Linux and Mac OS X).

Ansible is a tool for managing systems and deploying applications, licensed under the GNU General Public License version 3 (my personal favorite).

Vagrant is a tool for managing virtual machines and is licensed under the MIT license.

VirtualBox is a virtualization environment for local use, licensed under the GNU General Public License version 2.

Packer creates a machine image by installing an operating system to a multitude of local and cloud platforms, for example VMWare, VirtualBox as well as Docker, Amazon EC2 and DigitalOcean. Packer is licensed under the Mozilla Public License Version 2.0.

How …

Compile Emacs for Windows using MSYS2 and mingw64

Peter Mosmans — Mon, 19 Sep 2016 14:25:00 +0000

Emacs 25.1 was officially released on September 17th, 2016. The excellent MSYS2 subsystem and the open source gcc compiler make it super-easy to build binaries on/for Windows (7, 8, 10). In three easy steps from source to binaries:

1: Install and prepare the MSYS2 subsytem

Download and run the installer at http://repo.msys2.org/distrib/msys2-x86_64-latest.exe After installing, run MSYS2 64bit which drops you in a Bash shell. Update all packages using the following command:

pacman -Syuu

Sometimes updates of the runtime/filesystem can cause update errors. This is no cause for panic - kill and restart the terminal. For building 64-bit Windows binaries, always use mingw64.exe to start the terminal.

Install all packages necessary for building:

pacman -Sy --noconfirm base-devel git \
mingw-w64-x86_64-{giflib,gnutls,jbigkit,lib{jpeg-turbo,png,rsvg,tiff,xml2},toolchain,xpm-nox}

2: Clone the Emacs source

To simplify building, you can define the environment variables BUILDDIR (where the binaries are built), INSTALLDIR (where the binaries will be installed to), and SOURCEDIR (where the source lives, the git repository). Note that since you're in the MSYS2 subsystem, paths are Unix-style, using forward slashes. This command creates SOURCEDIR if it doesn't exist yet, clones the …

Are you a PenTexter ? Now in BSidesLV

Peter Mosmans — Tue, 26 Jul 2016 08:15:00 +0000

If you're around in Las Vegas during BlackHat / BSidesLV / DefCon, I'll be presenting at BSidesLV 2016 together with Melanie Rieback on an open source pentest reporting framework.

The talk will announce a new OWASP project: PenText, a fully open-sourced XML-based pentest document automation system. The PenText system is a document automation framework that supports the entire pentesting lifecycle: from the initial inquiry, through pentest scoping, quotations, pentesting, and reporting, through the final invoice.

During this talk, Melanie and I will demonstrate the OWASP PenText system live, in the context of our larger Pentesting ChatOps infrastructure (RocketChat, Hubot, and Gitlab). We will describe the basics of how the OWASP PenText system is architected (XML, XSLT, XSL-FO), and show how the system can be used to manage the entire lifecycle of pentesting data, including the automatic generation of documentation at various points in the process (including quotations, pentest reports, and invoices).

Lots of ChatOps in combination with pentesting and open source.

See https://bsideslv2016.sched.org/event/7azc/are-you-a-pentexter-open-sourcing-pentest-reporting-and-automation

See you there ?

Verifying webserver compression - BREACH attack

Peter Mosmans — Tue, 28 Jun 2016 03:21:00 +0000

A few lines of Bash script let you check which compression methods are supported by a SSL/TLS-enabled webserver.

 target=URL-OF-TARGET
for compression in compress deflate exi gzip identity pack200-gzip br
bzip2 lzma peerdist sdch xpress xz; do
curl -ksI -H "Accept-Encoding: ${compression}" https://${target} | grep -i ${compression}
done

If you see any output (and the server supports one of these compression algorithms), the site might be vulnerable to a BREACH attack. Might, because an attacker has to 'inject' content into the output (and have some control over it): This is called a chosen plaintext attack.

By carefully injecting certain content to the page, an attacker is able to deduce (parts) of the page content by merely looking at the response size (speed). An attacker therefore also has to be able to observe the server's response. A third prerequisite is that the secret (that an attacker wants to steal) is contained in the server response's body, and not 'just' in the response's header. Cookies are therefore out of scope.

The easiest mitigation is to disable HTTP compression completely. Other less practical mitigations are adding random content to each page, which changes the compressed size per page request, rate limiting the …

Automating OAuth 2.0 / JWT token retrieval for pentests

Peter Mosmans — Tue, 21 Jun 2016 02:50:00 +0000

Recently I was pentesting a complex API which used the OAuth 2.0 framework for authentication. Each API call needed an Authorization: Bearer header, containing a valid JSON Web Token (JWT).

To access the API I needed a lot of JWT tokens, as the tokens had a very short expiry time. To facilitate the quick generation of tokens I created a basic script that automated the OAuth authorization: It logs on to a domain, requests an authorization code, and converts that token to an authorization token.

One or more of these steps can be circumvented by command line options (e.g. by specifying valid cookies), to speed up the process.

Another feature of the script is that it automatically performs GET, POST, PUTs and DELETEs with valid tokens against a list of API endpoints (URLs). This preloads all API calls into a(n) (attacking) proxy, and helped the pentest speed up tremendously.

JSON Web Tokens

A JSON Web Token (JWT) is basically a string, representing a collection of one or more claims. Claims are name/value pairs which state information about a user or subject. The claims are either signed using a JSON Web Signature (JWS) or encrypted using JSON …

Getting to know your pentesting tools - curl and the HTTP/1.0 protocol

Peter Mosmans — Fri, 27 May 2016 03:32:00 +0000

When pentesting, it's always handy to have a bunch of automated scanner do the grunt work for you. Using automated tools saves time and can help in spotting potential vulnerabilities. Usually I run analyze_hosts.py, a wrapper around the open source tools droopescan, nmap, nikto, Wappalyzer and WPscan, with a bit of intelligence built in.

Recently I had a pentesting engagement where nikto flagged a IIS server as leaking the internal IP address (see https://support.microsoft.com/en-us/kb/218180 for more information).

This is a very common issue with older, unhardened IIS servers. The issue is triggered when a HTTP 1.0 request is made to the server, without supplying a Host header. The resulting Content-Location header will contain the server's (private) IP address, thereby leaking information which can subsequently be used for other attacks.

Example of a server's partial response:

HTTP/1.1 200 OK Content-Location: http://1.1.1.1/Default.htm

I ran into an interesting observation when I needed to reproduce this using curl. Curl is a great tool do do all kinds of HTTP requests on-the fly, and it's very well suited for scripting. It has flags to specify the protocol (e.g …

Automating repetitive git / setup tasks

Peter Mosmans — Thu, 14 Apr 2016 06:57:00 +0000

Imagine you work on a large number of projects. Each of those projects has its own git repository and accompanying notes file outside of the repo. Each git repository has its own githooks and custom setup.

Imagine having to work with multiple namespaces on different remote servers. Imagine setting up these projects by hand, multiple times a week.

Automation to the rescue ! Where I usually use Bash shell scripts to automate workflows, I'm moving more and more towards Python. It's cross-platform and sometimes easier to work with, as you have a large number of libraries at your disposal.

I wrote a simple Python script that does all of those things more or less 'automated'. Feed the script the name of the repository you want to clone, and optionally a namespace, patchfile and templatefile variable (either command-line or using a configuration file). The script will then:

clone the repository
modify the repository (e.g. apply githooks)
optionally modify the repository based on given variables
create a new notes file from a template
optionally modify the notes file based on given variables

The advantage is that you can use a configuration file containing the location of the remote git repository, the patchfile …

Bash vs Python (dependency hell)

Peter Mosmans — Sun, 31 Jan 2016 04:11:00 +0000

For a number of years I maintained a small collection of open source security scripts, written in Bash. The main purpose of these scripts was to act as a wrapper around other open source tools. Why try to remember long and awkward command line parameters, when you can ask a script to do that for you ?

Bash was chosen, as it was distribution-independent. It works almost everywhere (although sometimes OSX support is troublesome, due to outdated Bash versions).

After more and more (requested) features crept in, the

analyze_hosts.sh

Bash script became more and more complex. That's why I decided to port the script to Python. In my experience, it's at-least-as portable, and the usage of third party (pip) packages means that less time is spent on re-inventing the weel, and more on the actual functionality.

Yes, sometimes people talk about the dependency hell of Python, and in some cases, the usage of third party packages means you have to be careful of what you're doing.

However, when using virtual environments each Python script and its dependencies can be safely separated from the 'main' Python. For example, the following commands create a separate virtual environment for the security scripts repo …

Open secure redirect

Peter Mosmans — Tue, 08 Dec 2015 07:33:00 +0000

Aren't those RFC docs amazing ? Reading up on standards ?

I needed plenty of time for them, as I encountered some interesting issues. As it turned out, some websites / loadbalancers are overly optimistic in encrypting all the things - actually, in redirecting all the things.

TL;DR

Never trust HTTP(s) clients, and be careful when setting up redirection rules. A non-RFC compliant client can trigger a (difficult to exploit) open redirect vulnerability, due to a non-RFC compliant server.

This vulnerability can be tested using

analyze_hosts.py --http TARGET

See https://github.com/PeterMosmans/security-scripts/ for the latest version of analyze_hosts.py

Be warned, long post ahead: A while ago I came across some servers that, when being sent insecure requests, responded with a redirect to the secure version.

Request:

% curl -sI http://VICTIM/

Response:

HTTP/1.1 301 Moved Permanently
Connection: close
Location: https://VICTIM/

So far so good, nothing fancy going on here. In fact, this is excellent behaviour. Insecure requests are immediately upgraded to secure requests.

However, the server seemed to be overly happy in redirecting, as it listened to the client-supplied Host parameter:

% curl -s -I -H "Host: MALICIOUS" http://VICTIM/

And the server responded by

HTTP/1 …

automatic XML validation when using git

Peter Mosmans — Tue, 29 Sep 2015 13:51:00 +0000

Recently I worked on a project which involved manually editing a bunch of XML files. Emacs is my favorite ~operating system~ editor, and it has XML validation built in (using the nXML mode). It highlights validation errors while-you-type. Unfortunately, even with Emacs showing potential issues in RED COLOR, I managed to commit a number of broken XML files to my local git repository. Subsequently when I pushed my errors to the remote 'origin' git repository, the errors broke builds.

Of course this can be completely prevented by locally using pre-commit hooks. If your local git repository validates XML files before you can commit them, and denies invalid XML files, then one part of the problem is solved.

A pre-receive hook on the receiving server side can do the same as a pre-commit hook locally: Validate XML files before letting somebody push a commit which can break the build process.

I looked around the Internet but couldn't find a lightweight quick script to do only and exactly that. That's the reason I whipped up a basic pre-commit and pre-receive hook, written in Python.

You can find the very basic and rough code at https://github.com/PeterMosmans/git-utilities. By changing the …

Preparing your team for a CTF competition - Defcon style

Peter Mosmans — Sat, 15 Aug 2015 14:35:00 +0000

Playing Capture The Flag with a team on location is something completely different than performing penetration tests, security assessments or even trying to solve CTF challenges over the Internet.

At Defcon 23 I joined a team of really knowledgeable, nice and friendly people for the OpenCTF competition. It was an exhilarating ride from setting up all equipment to the glorious finish. Playing Capture The Flag on Defcon was educational but foremost fun, fun and fun.

So why would you spend a good chunk of 48 hours sitting in a chair behind a screen while there is so much more to see and experience at Defcon ? In one word: The undescribable exciting atmosphere of playing during a conference, of competing against all these bright people from all over the world, desperately trying to solve the challenges.

Here are some of my personal notes on how to get the most out of competing in an OpenCTF competition with a team:

Allow plenty of time before the competition to set up (and harden - don't be a fool like me) your machine. Make sure you have all necessary tools and notes.
Make sure beforehand that all team members have one communication channel (eg. IRC …

Defcon 23 was great - people are great

Peter Mosmans — Sun, 09 Aug 2015 21:51:00 +0000

For quite a while now, I work in the security industry. One of the things I do is providing security advice for companies on all sorts of guidelines, policies and hardening stuff. Web penetration tests is also something I do very regularly. In other words, a disclaimer before you read on: I should have known better...

VirtualBox, Packer, Vagrant and Ansible are tools that I use a lot.
These four tools make virtualizing and provisioning really easy. You
can create new machines, experiment with them and test different
setups in a repeatable and automated way.
As I sometimes organize pentesting workshops, I have several virtual
machines with Kali (a penetration testing distribution) installed on
them readily availabe.
So, I connected my laptop to the network of the 23rd Defcon conference
in Las Vegas, when one of these standard Kali virtual machines was
(still) running as guest on my machine. Not only was Kali running, the
guest was also configured to run in bridged networking mode. This
means that Kali got it's own network IP address assigned.
What I hadn't changed on that machine was Kali's default root
password. To make matters worse, what I had changed was the ssh server …

The future is here: HTTP/2

Peter Mosmans — Fri, 31 Jul 2015 22:26:00 +0000

Last month I held a number of presentations on the latest and greatest HTTP/2 protocol. It's an area where there's currently a lot of demand for knowledge and practical tips. Most people are surprised to find out that the're actually already using it on a daily base.

If you're interested you could check out an Ansible role which installs a number of client-side and server-side tools all HTTP/2 enabled:

curl - A data transferring tool with HTTP/2 support
h2load - A benchmarking tool for HTTP/2 and SPDY servers
nghttp - A HTTP/2 client with SPDY support
nghttpd - A HTTP/2 server with SPDY support
nghttpx - A transparent HTTP/2 proxy with SPDY support
openssl - A cryptographic library with ALPN support (1.0.2-chacha)

The following libraries will be installed:

libcrypto - OpenSSL
libcurl - CURL library
libnghttp2 - A HTTP/2 and HPACK C library
libspdylay - A SPDY library
libssl - OpenSSL

You can find the role at https://github.com/PeterMosmans/ansible-role-http2

Safely storing Ansible playbook secrets

Peter Mosmans — Tue, 23 Jun 2015 06:30:00 +0000

More and more organizations use dedicated software to safely handle the creation and management of secrets (for example SSL certificate keys, private variables and passwords). Three 'well known' solutions are Square's Keywhiz, Hashicorp's Vault and crypt in combination with etcd or consul.

As with all security solutions the roll-out can be quite cumbersome. The correct implementation (think key management, think audit trails, think key recovery) of any one of these solutions is difficult. And difficult means that most people won't use it, at least not right away (remember SELinux ?).

There are a number of tools available to encrypt secrets within (Ansible) repositories. One of them for instance is Ansible Vault (look here for a more in-depth review). Although the idea of selectively encrypting data is a good one, text-oriented version control systems like git or Subversion aren't meant to store binary blobs of encrypted data. Moreover you still run the risk of accidentally uploading or sharing unencrypted files. Mitigations like adding filenames of unencrypted secrets to a .gitignore file are error-prone.

How to facilitate developers and system operators to store secrets in a safe place, outside the repositories where Ansible playbooks and configuration files are kept ?

This article describes a …

OWASP AppSecEU 2015 review - more and more DevOps

Peter Mosmans — Mon, 15 Jun 2015 06:32:00 +0000

This year, the European edition of OWASP AppSec conference was held in
Amsterdam, The Netherlands.
One of the things I really like about OWASP conferences is the
atmosphere. Usually it consists of a nice blend of IT people from
literally all over the world, and this conference didn't disappoint.
One of the added values of visiting such a conference is that you hear
stories from the trenches from peers and likeminded people. It makes
it easier to (try to) spot trends in the security world.

Some observations:

DevOps

I'm a big fan of the DevOps movement, and what it means for security. More cooperation plus more automated testing means more secure systems. Thankfully there were a lot of presentations that focused on how to integrate automated security testing into the continuous deployment pipeline. As the O from OWASP stands for open, mainly open source testing tools were covered, like OWASP ZAP, Arachni and the Gauntlt framework. Some tools still need quite some tweaking to be successful, but the landscape surely is promising.

Dev is running faster than Ops

I'm still under the impression that the DevOps movement is mainly led by developers. The tools that are improving faster are the …

OpenSSL the Ansible vault... using PBKDF2

Peter Mosmans — Sat, 25 Apr 2015 12:38:00 +0000

Ansible is a popular open-source software platform for configuring and managing computers. It helps sysadmins to provision new servers in a reliable and repeatable way, and helps developers who want to push their code as fast as possible. It takes scripts (playbooks) as input, which a lot of people can and do share with each other. The beauty of open source. Playbooks can contain sensitive data like passwords and SSL keys - stuff that you don't want to share, or incidentally upload to GitHub.

Last year Ansible added a tool to its arsenal to easily encrypt structured datafiles (containing sensitive data), called Ansible Vault. You can specify a key or keyfile when running a playbook, which decrypts the data on-the-fly. Encrypted data can still be edited

I love it when people make it easier to use encryption. The easier it becomes, the more people will use it, the safer everybody will be.

Another beauty of open source is that you can inspect the code. And modify it! I wanted to be able to encrypt and decrypt the data where/when you cannot use Ansible vault, by using other tools and languages like OpenSSL and Bash script.

Under the hood Ansible vault …

Replacing ChaCha20/Poly1305: a new owner

Peter Mosmans — Tue, 07 Apr 2015 02:27:00 +0000

A post back I wrote about the 'design goals' of the 1.0.2-chacha fork of OpenSSL - see https://www.onwebsecurity.com/openssl/the-work-flow-of-the-full-featured-openssl-fork-chacha20poly1305.

The ChaCha20 / Poly1305 code in the 1.0.2-chacha fork is originally from the OpenSSL repository, but has since been abandoned there. BoringSSL became its new home, where it's actively being maintained by Google (primarily Adam Langley and David Benjamin). Over time I applied several patches that BoringSSL applied to the ChaCha20 / Poly1305 code, to keep it as up to date as possible.

The issue now is that BoringSSL diverges more and more from the OpenSSL code, which makes it more difficult to maintain (error-prone), and, more important, makes the fork itself diverge too much from OpenSSL.

That's why it's my intention to replace the current ChaCha20 / Poly1305 code from 1.0.2-chacha with more recent attributions that align better with the official OpenSSL code. As far as I understood the official OpenSSL distribution will add ChaCha20 / Poly1305 at some time in the future, which of course would be the best possible outcome. Official support.

Until that time I will do my best to maintain the 1.0.2-chacha branch.

The workflow of the Full-Featured openssl Fork (ChaCha20/Poly1305) 1.0.2-chacha

Peter Mosmans — Fri, 13 Mar 2015 08:49:00 +0000

As you might know I maintain a fork of OpenSSL at https://github.com/PeterMosmans/openssl The 1.0.2-chacha fork started out of adding the ChaCha20/Poly1305 ciphers to the official fork, and slowly more and more ciphers and features were added.

The main goals of the fork are

add as much ciphers and (test)functionality as possible
to keep the source as aligned to the original as possible
keep the patches transparent (easily applicable to the original source)
keep the patches maintainable
write as little custom/new code as possible

For 2 (to keep the source as aligned to the original as possible) I try to merge and test the code as often as I can, so that the fork is never too far behind the official repository.

As it was my first idea to start a feature branch I used no-fast forwarding git merges. This kept it transparent when I merged the code, and what the history of the commits was. However, since I'm probably going to maintain this fork besides the official fork I'm going to use fast-forwarding merges from now on (March 2014) whenever possible. I think this will keep the commit history cleaner - see …

FREAK!

Peter Mosmans — Wed, 04 Mar 2015 11:40:00 +0000

As you probably read somewhere else, and on another place, and another... on March 3rd 2015, another attack on SSL/TLS was published. Following the tradition of BEAST, CRIME, Heartbleed, LUCKY13 and POODLE this one also has a catchy name: FREAK (Factoring RSA Export Keys).

It's a man-in-the-middle attack where a man in the middle can decrypt a SSL/TLS connection between a client and a server.

Vulnerable *servers* are servers that accept export-grade ciphers (RSA-EXPORT). Checking whether a server is vulnerable can be done in many ways.

Take for example analyze_hosts.py, a Python wrapper around several tools:

analyze_hosts --ssl HOST

If you see any EXPort ciphers, the server is vulnerable.

Another way is by using cipherscan

cipherscan HOST:443

If you see any EXPort ciphers, the server is vulnerable.

Yet another way is by using nmap:

nmap --script ssl-enum-ciphers -p433 HOST

If you see any EXPort ciphers, the server is vulnerable.

You get the idea...

Mitigate this vulnerability server-side by making sure that your server doesn't allow export ciphers in the OpenSSL configuration: add the following expression

!EXP

There are also vulnerable clients...

Clients using OpenSSL are not vulnerable if they were built after CVE-2015-0204 was published.

The …

Us versus them: CrikeyCon 2015 review

Peter Mosmans — Thu, 26 Feb 2015 11:27:00 +0000

I had the chance to visit CrikeyCon February 2015, which was held in Brisbane

It was the second time this event was held, but it already got the looks and feel of a professional organization behind it. The program was really diverse, from social engineering and awkward hugs to iOS runtime hacking, and everything in between.

Takeaway ? Well, it surprised me to hear that there's still a general feeling of us versus them. We the security gods who lay bare all the faults and stupid mistakes the others make.

As a security professional, especially as a pentester, it's your job to find vulnerabilities and weaknesses. It's your job to hunt for other people's mistakes, lack of knowledge, or constrained security budgets. Security falls into the quality assurance department.

This means that most of the time you're telling other people what's wrong with an application. Unfortunately it's not your job to tell them how awesome their web application is, how well it scales, or the nifty features it has.

One of the more challenging issues when for instance presenting a pentest report to a group of developers is to get everybody on board, to get everybody to work together. And if …

OpenSSL 1.0.2 - now with less whitespace!

Peter Mosmans — Sun, 08 Feb 2015 15:34:00 +0000

On January 22 2015, version 1.0.2 of OpenSSL was released. Besides
some new bugfixes and features, the biggest change under the hood was
a complete
reformatting
of the source code. An official coding style
document was
published, and as a result primarily buckets and lots of tabs and
newline characters have been converted into whitespaces.
Personally I hope that this action, which affected the majority of
lines(!) of code, will help the project for the best and will make it
easier to maintain the project in the future.
One disadvantage of reformatting code for instance however is that it
makes it a lot harder to spot differences in code between certain
versions, as almost all files have most of their lines changed.
Another disadvantage is that merging additional patches (like the
ChaCha20 and Poly1305 ciphers) back into OpenSSL took a great deal of
extra time. Unnecessary time, one might say.

The OpenSSL 1.0.2 fork including the ChaCha20 and Poly1305 ciphers has been pushed to the github repo at https://github.com/PeterMosmans/openssl/

As always, you can find compiled Windows 32 and 64 bit binaries at https://www.onwebsecurity.com/cryptography/openssl.

February 2015 update: read …

CVSSv2 rating of new vulnerabilities patched in OpenSSL

Peter Mosmans — Sat, 10 Jan 2015 04:45:00 +0000

On January 8th, 2015, the OpenSSL team published an OpenSSL Security Advisory containing 8 previously unknown vulnerabilities in OpenSSL.

Unfortunately, as with most large software suppliers/vendors nowadays, OpenSSL uses its own severity classification system for vulnerabilities. There are many classifications systems out there, which results in less transparent patching policies and procedures for system administrators and end users. Fortunately NIST publishes the CVSSv2 Severity Base Score of most, if not all vulnerabilities with a CVE entry. This makes it easier to classify.

Two of the eight vulnerabilities (CVE-2014-3571 and CVE-2015-0205) have the OpenSSL vulnerability rating 'moderate'. This corresponds to a CVSSv2 base score of 5.0 (MEDIUM) for CVE-2014-2571 as well as CVE-2015-0205 Both of these vulnerabilities could be exploited for a Denial of Service attack of the OpenSSL service. The remaining six vulnerabilities have a lower rating.

The 1.0.2-chacha and 1.0.1-chacha branches of the ChaCha20 - Poly1305 fork of OpenSSL have been patched for all of the published vulnerabilities.

As always, see https://www.onwebsecurity.com/cryptography/openssl for the Windows 32 and 64 bit binaries, and more information.

MSYS2 - successful successor of MSYS ?

Peter Mosmans — Fri, 05 Dec 2014 09:34:00 +0000

MSYS can best be described as a Bash shell and some GNU tools, which facilitate compiling sources under and for a Windows environment. It's the environment to use when compiling for instance OpenSSL or Emacs on Windows.

MSYS2 is the 'new and improved' version of MSYS.

One of its biggest advantages is better package management. MSYS2 has pacman, a package manager from Arch Linux. Upgrading can finally be done from within the shell session itself, with only a few basic commands.

# download package descriptions from the remote repositories
pacman -Sy
# upgrade MSYS2 core components and the shell itself
pacman --needed -S bash pacman msys2-runtime
# restart MSYS2 if any package needed updating, then update the rest
pacman -Su

This was 'somewhat more difficult' under MSYS.

Another advantage is the Bash version - currently at 4.3.30 versus 3.1.17 on MSYS. Bash 4 means support for functions like associative arrays and fancier redirections:

# redirect stdout and stderr at the same time
command &> output

# same command in Bash 3 syntax
command > output 2>&1

# pipe stdout and stderr at the same time
command |& someothercommand

# same command in Bash 3 syntax
command 2>&1 \| someothercommand

The third big plus is that it's …

OpenSSL: Fatal SSL alert number 47 (Illegal Parameter)

Peter Mosmans — Tue, 25 Nov 2014 06:33:00 +0000

As a pentester, I regularly test the configuration of SSL servers. For this purpose I use my customized OpenSSL fork which contains a lot more ciphers than the official version, and wrapper scripts (easier than remembering command line options).

Last month I ran into an issue with servers behind a SSL terminator from a well-known network equipment supplier. As soon as the SSL Client Hello offered 128 or more ciphers to the server and the tls1_2 protocol was specified, the handshake was aborted with the following error message

9304:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:s3_pkt.c:1481:SSL alert number 47 9304:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:636:

The supplier hadn't heard of this bug yet - I suspect that not that many browsers or generic SSL clients offer 128 or more ciphers. A bugreport has been filed.

To facilitate the testing of SSL/TLS handshakes I created a script, which can be found at GitHub. Currently 3 handshake bugs are identified.

Of course you can test for this bug using a version of OpenSSL with enough (128 or more) ciphers, and the command

openssl s_client -connect host:port -tls1_2

Black Hat Europe 2014 review

Peter Mosmans — Tue, 11 Nov 2014 12:56:00 +0000

Black Hat Europe was held in Amsterdam in October, 2014. The so called Briefings (tech talks) were extremely versatile, ranging from Android pentesting to SCADA hacks. It was difficult to choose which talk to attend - there were around 50 or so, each title vying for your attention ("Hack Your ATM with Friend's Raspberry.Py" [sic], or "Endrun - Secure Digital Communications for Our Modern Dystopia").

I really enjoyed the technical depth of some talks, and it was great to hear someone like Adi Shamir, one of the inventors of the famous RSA algorithm, talk about his current research.

Because of the sheer size I couldn't find one generic takeaway, or see the, or a current bigger picture in information security land. Even all of the vendors' offerings looked similar.

Now that I come to think of it, that actually IS the key takeaway: Genericity.

Creating and verifying digital signatures of files

Peter Mosmans — Tue, 28 Oct 2014 06:51:00 +0000

Digital signatures can be used to establish the authenticity and integrity of a (binary) file. These signatures can also be used for non-repudiation purposes, but that's usually not the intention when you're distributing or receiving files. (Note: non-repudiation means impossible to reject; to make sure beyond a doubt that the signer's key has been used to create that signature).

The easiest and most secure way of creating and verifying digital signatures is by using PGP. The following commands assume that you have downloaded and configured GPG, the free and complete implementation of the OpenPGP standard.

Create a digital signature of FILENAME

gpg --armor --detach-sig --output FILENAME.sig FILENAME

`--armor`	make sure that the file is ASCII armored (Radix-64 encoded)
`--detach-sig`	create a separate signature file
`--output`	the name of the signature file

Paranoid options

`--no-version`	don't show which software version has been used to create the signature
`--comment`	don't show which software has been used to create the signature

Verify a digital signature

gpg --verify FILENAME.sig

This command assumes that the original file is FILENAME and resides in the same location as the signature file FILENAME.sig. To verify a signature you also need the signer's public key. If …

Patched openssl SSLv3 downgrade attack (POODLE) with ChaCha20 and Poly1305 support

Peter Mosmans — Sat, 25 Oct 2014 07:35:00 +0000

The OpenSSL team published a security advisory on October 15th 2014,
see the OpenSSL
site for more
information.
In short, SSLv3 using Cipher Block Chaining mode (CBC) has a weakness,
which can be exploited using the POODLE attack having CVE entry
CVE-2014-3566.
The POODLE attack depends on SSLv3 and tries to downgrade a connection
to that specific, really old protocol. This downgrade can be mitigated
by using the signaling cipher suite value (SCSV) TLS_FALLBACK_SCSV,
which is implemented in the/this latest version of openssl. Please be
advised that not only the server, but the client itself also has to
support this relatively new method.

All vulnerabilities in the advisory have been patched in the latest versions of OpenSSL 1.0.2-chacha. Moreover, the new binaries/source are aligned with the latest beta release (3).

SRTP Memory Leak (CVE-2014-3513)
Session Ticket Memory Leak (CVE-2014-3567)
SSL 3.0 Fallback protection
Build option no-ssl3 is incomplete (CVE-2014-3568)

As always, check https://onwebsecurity.com/cryptography/openssl for the latest Windows 32 and 64 bit binaries, and https://github.com/PeterMosmans/openssl for the latest sources.

Patched vulnerabilities in OpenSSL with ChaCha20 and Poly1305 support

Peter Mosmans — Thu, 07 Aug 2014 14:49:00 +0000

The OpenSSL team published a security advisory on August 6th 2014, see the OpenSSL site for more information. All vulnerabilities in that advisory have been patched in the latest versions of OpenSSL 1.0.1-chacha and 1.0.2-chacha:

Information leak in pretty printing functions (CVE-2014-3508)
Crash with SRP ciphersuite in Server Hello message (CVE-2014-5139)
Race condition in ssl_parse_serverhello_tlsext (CVE-2014-3509)
Double Free when processing DTLS packets (CVE-2014-3505)
DTLS memory exhaustion (CVE-2014-3506)
DTLS memory leak from zero-length fragments (CVE-2014-3507)
OpenSSL DTLS anonymous EC(DH) denial of service (CVE-2014-3510)
OpenSSL TLS protocol downgrade attack (CVE-2014-3511)
SRP buffer overrun (CVE-2014-3512)

As always, check https://onwebsecurity.com/cryptography/openssl for the latest Windows 32 and 64 bit binaries, and https://github.com/PeterMosmans/openssl for the latest sources.

DevOps 2014 Brisbane and security

Peter Mosmans — Mon, 28 Jul 2014 13:10:00 +0000

DevOps is a worldwide phenomenon, which is reflected by the global popularity of its major event, the DevOps Days.

I was fortunate enough to attend the DevOps Days 2014 in Brisbane.

The keynote speaker was Sidney Dekker, a Dutchman who has extensive experience on human factors and safety. He argued that a lot of major incidents don't have any precursor events.

You can have a clean track record with regards to security and still suffer a huge incident. Do I agree ? Not completely, but nonetheless thought provoking.

Personally I think that the inverse will always hold true: There is a higher chance on a major security incidents after a number of several minor security incidents. Cluttered desks mean cluttered minds after all.

Some buzzwords and issues that were (frequently) discussed:

Docker - A lightweight virtualization platform (can it live up to its sky-high expectations ?)
Microservices - Build small, independently deployable services
ChaosMonkey
Terminate random virtual machines to test (and improve) resiliency
Edwards Deming - The godfather of Devops ?

For me the key takeaway was that DevOps doesn't really changes your (level of operational) security. Whether system administrators deploy code built by developers or developers push their own code to an environment - in both …

Should you disable RC4 in SSL/TLS ?

Peter Mosmans — Wed, 23 Jul 2014 11:22:00 +0000

I'm by no means a crypto expert. Still I'm frequently getting (and answering) questions regarding the use of RC4 in SSL/TLS. Should you disable it? Or keep it enabled?

March 2015 update - A 'new' attack method (Bar Mitsvah Attack) using a previously known RC4 vulnerability was presented, thereby reducing the RC4 security even more.

February 2015 update - RFC 7456 has been published, which effectively prohibits the use of RC4 in TLS.

This document requires that Transport Layer Security (TLS) clients

and servers never negotiate the use of RC4 cipher suites when they

establish connections. This applies to all TLS versions.

See http://tools.ietf.org/html/rfc7465

Here is my reasoning to disable all ciphersuites using RC4:

RC4 is a stream cipher that has been around since 1987. The number and quality of attacks on RC4 (in SSL/TLS) increases. Fact: Attacks on encryption algorithms only get better, they never get worse.
A lot of sites still enable RC4 in their ciphers, to support a wide browser base. Fact: Even Internet Explorer on Windows XP supports DES-CBC3-SHA (an alternative to one of the RC4 ciphers)
RC4 is one of the few ciphers that is resistant to the BEAST attack …

git on Windows - location of configuration files

Peter Mosmans — Wed, 09 Jul 2014 09:10:00 +0000

Git is used as distributed version control system for the majority of projects I work on. On Windows I use the official Git for Windows version, as well as the 'native' mingw/MSYS2 git binary when using the MSYS2 shell.

The location of the system and global gitconfig configuration files varies, depending on which environment (native Windows command, Windows shell or MSYS2 shell) you're using, and depending on which binary (Git for Windows versus native git). There's a logic to it, but it can be hard to figure out...

Git version 2 introduced a much easier method of finding where the git configuration files are stored, the --show-origin flag. This parameter tells you exactly where each of the configuration files can be found.

Retrieve the locations (and name value pairs) of all git configuration files:

git config --list --show-origin

Retrieve the location (and name value pairs) of the system git configuration file:

git config --list --system --show-origin

Retrieve the unique locations of all git configuration files:

git config --list --show-origin | awk '{print $1}' | uniq

Local

Regardless from where you use git on Windows, the repository (local) configuration always resides at the same location, in the root directory of your repository …

OpenSSL 1.0.2-chacha

Peter Mosmans — Thu, 26 Jun 2014 14:04:00 +0000

Note: see `http://www.onwebsecurity.com/cryptography/openssl <https://www.onwebsecurity.com/cryptography/openssl>`__ for the latest binary. The version below is obsoleted by newer builds

Windows 64-bit binary build from a 26-06-2014 snapshot of https://github.com/PeterMosmans/openssl/tree/1.0.2-chacha. This is the official 1.0.2 branch (OpenSSL_1_0_2_stable), merged with support for the ChaCha20 and Poly1305 ciphers. Some minor build patches for Windows compatibility were applied. See the git repo for the full source.

Build commands:

mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c\:/programs/openssl -DOPENSSL_NO_HEARTBEATS
make depend
make util/libeay.num
make util/ssleay.num
make
make report

Compiler used:

gcc version 4.9.0 (x86\_64-posix-seh-rev1, Built by MinGW-W64 project)

All tests passed

OpenSSL 1.0.1-chacha

Peter Mosmans — Wed, 18 Jun 2014 05:54:00 +0000

A Windows 64-bit binary build from the 1.0.1 branch of OpenSSL
(OpenSSL_1_0_1-stable), including (assembly code for) ChaCha20,
Poly1305, J-PAKE, NIST P-224, NIST P-256 and the relatively unsafe
ciphers MD2 and RC5 and broken protocol SSLv2. All available engines
are provided as separate DLLs.
If you're using this in a production environment, don't forget to
explicitly enable only ciphers that are considered safe.
The code for this build can be found at
https://github.com/PeterMosmans/openssl/tree/1.0.1-chacha

Example openssl.cnf cipher string:

`` HIGH:!SSLv2:!IDEA:!RC4:!MD5:!ADH:!aNULL:!eNULL``

Build commands:

Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c\:/programs/openssl -DOPENSSL_NO_HEARTBEATS
make depend
make util/libeay.num
make util/ssleay.num
make
make report (all tests passed)

http://www.onwebsecurity.com/files/1.0.1-chacha-latest.zip

md5sum: d890de1ab4eba13c7d39139c5726144f

Compiler used:

gcc version 4.9.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project)

OpenSSL 1.0.2 (10-06-2014)

Peter Mosmans — Tue, 10 Jun 2014 07:37:00 +0000

Note: see http://www.onwebsecurity.com/cryptography/openssl for the latest binary. The version below is obsoleted by newer builds

A Windows 64-bit binary build from a 10-06-2014 snapshot of the official 1.0.2 branch (OpenSSL_1_0_2_stable). This means that 'the latest OpenSSL vulnerabilities' that were disclosed on June 5th 2014 are fixed - see https://www.openssl.org/news/secadv_20140605.txt for more information.

I applied some minor patches for Windows compatibility and changed the version string.

Build commands:

Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 \
enable-rfc3779 enable-ssl-trace enable-ec_nistp_64_gcc_128 \
enable-static-engine --openssldir=c:/tools -DOPENSSL_NO_HEARTBEATS \
-mtune=native
make depend
make util/libeay.num
make util/ssleay.num
make
make report

Compiler used:

gcc version 4.9.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project)

OpenSSL on 64 bit Windows with ChaCha and Poly1305 support

Peter Mosmans — Mon, 19 May 2014 09:09:00 +0000

Note: see https://www.onwebsecurity.com/cryptography/openssl for the latest binary. The version below is obsoleted by newer builds

The main development branch of OpenSSL doesn't have support yet for the (relatively new) ChaCha 20 and Poly1305 ciphers. These can be found however on the 1.0.2-aead branch.

By slightly modifying some makefiles the source can be compiled for 64-bit Windows using mingw64 and msys.

Please find a binary build from a 27-05-2014 snapshot of the source code (1.0.2-aead branch) with assembly code enabled (imported from the 1.0.2 stable branch), and a lot of insecure, new and experimental ciphers enabled. I added the GOST engine gosteay32.dll as well.

The source code for this build can be found at https://github.com/PeterMosmans/openssl

Build commands:

Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c:/tools
make depend
make util/libeay.num
make util/ssleay.num
make
make test

Enabled ciphers:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-AES-256-CBC-SHA
DH-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DH-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DH-RSA-AES256-SHA256
DH-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DH-RSA-AES256-SHA
DH-DSS-AES256-SHA
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
DH-RSA-CAMELLIA256-SHA
DH-DSS-CAMELLIA256-SHA
GOST2001-GOST89-GOST89
GOST94-GOST89-GOST89
AECDH-AES256-SHA
SRP-AES-256-CBC-SHA
ADH-AES256-GCM-SHA384
ADH-AES256-SHA256
ADH-AES256-SHA
ADH-CAMELLIA256-SHA
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA …

test_bn fails for OpenSSL on Windows

Peter Mosmans — Tue, 06 May 2014 02:16:00 +0000

Compiling OpenSSL on Windows using MSYS and mingw64 is pretty straightforward. However, one of the tests (test_bn) to verify OpenSSL fails: The temporary file that test_bncreates contains Windows newline characters (\r\n) instead of the Unix type newline charater (\n).

The original regular expression checks for a zero (0) at the beginning of a line, and a newline character (\n).

(!/^0$$/)

A change to the regular expression that test_bn uses fixes this problem, and can be used on Unix as well as Windows environments. This makes the Makefile more cross-platform friendly. The modified regular expression checks for a zero (0) at the beginning of a line, an optional Windows newline character (\r) and a newline character (\n).

(!/^0\r?$$/)

File: openssl-test-Makefile.patch

md5sum: 1032dff7f957c4d1cdfa96af305c152b

Here's the patchfile (can be applied in the source directory using patch -Np1)

--- openssl-1.0.1g/test/Makefile 2014-04-07 16:55:44 +0000 +++ patched/test/Makefile 2014-05-06 00:07:20 +0000 @@ -227,7 +227,7 @@ @../util/shlib_wrap.sh ./$(BNTEST) >tmp.bntest @echo quit >>tmp.bntest @echo "running bc" - @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' + @) {if (/^test (.*)/) {print STDERR "\nverify …

analyze_hosts

Peter Mosmans — Thu, 23 Jan 2014 03:57:00 +0000

If you're like me, you don't want to spend your precious memory on remembering awkward command line parameters. However, lots of tools require exactly that: awkward command line parameters.

To simplify scanning of hosts for network vulnerabilities I wrote a simple wrapper script around several open source security tools. The script lets you analyze one or several hosts for common misconfiguration vulnerabilities and weaknesses.

My main objective in writing the script was to make it as easy as possible to perform generic security tests, without any heavy prerequisites, make the script as informative as possible, and make use of open source tools.

Note that the latest version is the Python version - please use that one.

How to install

Clone the git archive using the command

git clone https://github.com/PeterMosmans/security-scripts.git

Needed

Linux, and nmap

Optional

```
curl
```
for fingerprinting and to test for TRACE
```
dig
```
to test for recursive DNS servers
```
git
```
to update the script
```
nikto
```
for webscanning
```
testssl.sh
```
to check the SSL configuration

Usage

Oh irony - the command line parameters for the tool:

usage: analyze_hosts.sh [OPTION]... [HOST]

Scanning options:
 -a, --all perform all basic scans
 --max perform all advanced scans (more thorough)
 -b, --basic …

securing AMFPHP

Peter Mosmans — Thu, 30 May 2013 09:13:00 +0000

I regulary run into Flash applications when I perform a web application penetration test. One of the most widely used server frameworks for communicating with a Flash object is AMFPHP.

Unfortunately the default installation of AMFPHP is insecure. A system administrator or developer actively has to secure the installation, which is often forgotten.

There are some tips lying around the Internet how to secure an AMFPHP installation. The summary:

In the root of your AMFPHP deployment,

delete the DiscoveryService.php file
Delete the browser folder and its contents
Edit gateway.php and set the PRODUCTION_SERVER property to true

Of course it's at least as important to write secure code, harden your server and implement proper patch and maintenance procedures.

unsafe HTTP methods

Peter Mosmans — Wed, 20 Mar 2013 09:01:00 +0000

Vulnerability name: Unsafe HTTP methods

Aliases

Web server HTTP Trace/Track method support
Cross-site tracing vulnerability
Dangerous HTTP methods

Scope

Although this is a server configuration issue, the client is at risk here

Remediation

Disable TRACE and/or TRACK and/or DEBUG methods

Verification

Using curl , one can employ one of the methods by hand:

curl -sIX TRACE $TARGET | awk 'NR==1 {print $2}'

Vulnerable when: the result is 200

One should expect (not vulnerable) 405 (Method Not Allowed) or 501 (Not Implemented) results.

This executes the TRACE method against $TARGET , and prints out the HTTP status code using awk . The -I parameter fetches the head only, -s stands for silent mode, and -X specifies the method.

The easiest way to test whether a server is vulnerable is by using the script analyze_hosts.py [1].

This script uses curl as well as nmap to perform multiple tests.

analyze_hosts.py --trace http://www.target.com

Note

When an OPTIONS method is issued, the webserver should return the supported methods. Some web servers have a habit of replying with methods that are in fact not supported - which does not combine nicely with inferior security scanners (and pentesters, I might add) that relying …