Having delivered security consultancy as part of Portcullis/Cisco for over 15 years, I’ve seen a variety of shades of broken. Since I recently spent some time on secondment to one of our customers to help them design, build and operationalise security as part of their digital transformation programme, I got to thinking: what would I do if I wanted to get projects delivered right? With apologies to grsec, Jericho Forum, BeyondCorp and Trusted Computing, what followed was part philosophy, part technical brain dump, the result being my take on security engineering and how to build defensible systems. This talk includes the following hits:

• Helping the blue team – a case study in 3 parts…
• Blue doesn’t have the man power to adopt gift wrapped improvements let alone offensive research thrown over the wall
• Static passwords – why the hell are we still using them?
• Vulnerability management – didn’t we say blacklists were bad?
• Forget about penetration testing – what are your controls?
• Is there another way to report – why don’t businesses listen to us?
• Monetising MITRE – can we make money out of CVEs?

SEAMFDS.pdf
June 28, 2019

311.8 KiB
MD5 hash: 185701fbc113ca2a676e802b61df53e2
Details

Date:

June 28, 2019

The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.

This talk will not help you build a SOC in only 60 minutes, but it will help you build a functional security operation over time.

Building a SOC can be daunting. This talk will look at how to pick your fights and the key battles (authentication, logging, etc.) that any operational security team needs to win. The session will discuss how to ensure you formalize existing good practices and just as importantly what gaps may exist in the team’s processes. The session will look at the next steps that any organization intending to set off down this road ought to consider.

TTRS19SYWTBASLFTFL.pdf
June 20, 2019

1.6 MiB
MD5 hash: 9fd544a63fcac10688d82d4cec24df44
Details

Date:

June 20, 2019

The post So you want to build a SOC: Lessons from the front line appeared first on Portcullis Labs.

Simon Crocker, Cisco’s EMEAR lead for SOC Advisory looks at what goes into making a SOC work effectively.

This talk discusses the core SOC requirements around monitoring and incident response function, but also touches on some of the other services that SOCs can also provide.

Learning outcomes:

1. The challenges that SOCs face and approaches to overcome them
2. The array of services that SOCs provide
3. The roadmap to build a SOC
4. Learn how to threat hunt proactively to root out hidden threats
5. Discover best practice on threat hunting from the largest non government threat intelligence team

I2019DTSOTC.pdf
June 18, 2019

925.6 KiB
MD5 hash: 904adc3b1b54f73227ad53807bac5004
Details

Date:

June 18, 2019

The post Discover the secrets of the SOC appeared first on Portcullis Labs.

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.

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.

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:

• Linikatz
• JohnTheRipper dynamic.conf rules
• metasploit-framework post-exploitation modules
• auditd policies
• fuzzers

eu-18-Wadhwa-Brown-Where-2-worlds-collide-Bringing-Mimikatz-et-al-to-UNIX.pdf
December 6, 2018

724.9 KiB
MD5 hash: cc712c5e46b16fbff22a2566b1248a91
Details

Date:

December 6, 2018

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

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.pdf
October 31, 2018

463.7 KiB
MD5 hash: 390c1d8b29e74f2c15df434b4d0d9f99
Details

Date:

October 31, 2018

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

The original piece of data analysis was performed by two of our interns (Daniel and Chris) as part of Cisco’s intended contribution to the next Top 10 publication from OWASP however due to time constraints, our data points were not submitted. As a result, the co-authors (Simone and Isa) chose to compare the EMEAR team’s statistics from 2016 against the now public 2017 Top 10 published by OWASP. Additionally, they also took a look at the most common web application issues reported by the Team during the last year and analysed their impact and severity.

WAW.pdf
September 6, 2017
Version: 1.0

925.6 KiB
MD5 hash: 0986d3ab7f6f55c71199296189ce5f62
Details

Date:

September 6, 2017

The post Web Application Whitepaper appeared first on Portcullis Labs.

The first thing I did once I had it installed was look at how the Windows process tree had changed. Running it results in two new branches to your process tree. The first contains the Windows bash.exe instance which hosts your new terminal:

• explorer.exe (runs as your user):
  • bash.exe (runs as your user):
    • conhost.exe (runs as your user)

Whilst the second contains the Linux process tree:

• svchost.exe (runs as SYSTEM):
  • init (runs as your user, no disabled privileges, locked into a job):
    • bash (runs as your user, disabled privileges, locked into a job, break away set to true)

As you might expect, new code compiled to support this is well hardened and uses Windows 10′s advanced mitigations. Specifically, bash.exe has the following mitigations enabled:

• DEP enabled
• ASLR high entropy, bottom up
• CFG enabled

Digging a little further, the same can’t be said for init, bash and other parts of the Linux process tree. Whilst DEP is enabled, ASLR and CFG are not. In fairness, this shouldn’t come as any great surprise – they’re Ubuntu packaged binaries however it does start to show show how introducing WSL to your system can change the systems posture.

The kernel

So what does the “kernel” version look like. Well, at the point I examined it:

x@DESKTOP-L4857K3:~$ uname -a
Linux DESKTOP-L4857K3 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

This version of the Linux kernel should be vulnerable to dirty cow, so what of it? It doesn’t work which again isn’t a huge surprise. As Alex has alluded to there is a quite a substantial amount of mapping going on to implement the Linux system calls on Windows and whilst they should be API compatible, the implementations between a real Linux kernel and what WSL gives up may be quite different.

This does however bring up the first critical point: There is no relationship between the patches supplied as part of Windows Update and what goes on with WSL. If you don’t patch regularly you’ll still be vulnerable to a whole plethora of Ubuntu (userland) vulnerabilities.

Memory corruption mitigations

Some Linux mitigations are in play however (as they would be on any real Ubuntu system) as can be seen with checksec.sh:

• System-wide ASLR (kernel.randomize_va_space): On (Setting: 2)
• Does the CPU support NX: Yes

And of course binaries are compiled with whatever Ubuntu hardening is currently supported:

	COMMAND    PID RELRO             STACK CANARY           NX/PaX        PIE
	  init      1 Full RELRO        Canary found           NX enabled    Dynamic Shared Object
	  sudo     14 Partial RELRO     Canary found           NX enabled    Dynamic Shared Object
	    su     15 Partial RELRO     Canary found           NX enabled    No PIE
	  bash     16 Partial RELRO     Canary found           NX enabled    No PIE
	  bash      2 Partial RELRO     Canary found           NX enabled    No PIE

Shared memory

So what does WSL look like more generally. Well, since I’ve had some fun with shared memory, I wondered how this was implemented. Well, it turns out that it’s not:

root@DESKTOP-L4857K3:~# ipcs

kernel not configured for shared memory

kernel not configured for semaphores

kernel not configured for message queues

Whether this will have any security implications, it’s difficult to say but at the very least it may stop certain applications from working. Other applications may revert to using other less well tested IPC mechanisms which may expose security issues along the way.

Debugging

Moving on, how about debugging something. A simple tool which exercises the ptrace() system call is strace. Here’s what happens when strace is run on a normal process:

root@DESKTOP-L4857K3:/sys# strace -f printf "test" 2>&1 | head -n 5
execve("/usr/bin/printf", ["printf", "test"], [/* 15 vars */]) = 0
brk(0)                                  = 0xa9d000
...

However you can’t strace PID 1 (as would have been possible on real Linux), instead ptrace() returns an error: “Operation not permitted”.

File systems

Whilst /mnt doesn’t show up as a different file system, /mnt/c is actually used to map the underlying Windows system disk. This is immediately peculiar since it is mapped with permissions of 0777 (world readable, world writable amongst others). Moreover any files created under it are created with an owner of root. You’d think this might be a problem but from what I’ve seen so far, assuming the Windows file permissions are set right then (because everything (even setUID processes) runs as you from Windows’ perspective) you won’t be able to access anything inappropriate (think SAM etc). It. Just. Looks. Weird.

Furthermore, the way that WSL implements umasks too is an oddity. umask doesn’t work on all file system types and in particular the aforementioned /mnt/c. Observe the following:

root@DESKTOP-L4857K3:/# umask 666
root@DESKTOP-L4857K3:/# touch foo
root@DESKTOP-L4857K3:/# ls -la foo
---------- 1 root root 0 Mar 28 23:10 foo
root@DESKTOP-L4857K3:~# rm foo
root@DESKTOP-L4857K3:~# cd /mnt/c/Users/x/
root@DESKTOP-L4857K3:/mnt/c/Users/x# touch foo
root@DESKTOP-L4857K3:/mnt/c/Users/x# ls -la foo
-rwxrwxrwx 1 root root 0 Mar 28 23:10 foo

Umask is honoured in the first location but not the second (a umask of 0666 should mean that files are created with no permissions). Whilst there’s a fundamental Windows reason why this is the case, there is nothing to indicate this to the Ubuntu instance’s userland and thus files created within your home directory might be created with undesirable permissions. Microsoft are tracking this in the GitHub as issue 352.

Authentication

Unlike on a real Ununtu there’s no terminal level authentication (whilst user accounts within the Ubuntu instance do have passwords, they’re not needed unless you want to access the system remotely or gain root privileges via sudo). Moreover, from Windows’ perspective there is no difference between UID 0 and UID 1000. You can start a terminal and then use sudo to elevate your privileges and Windows will be none the wiser (Linux capabilities aren’t mapped into Windows user rights or special tokens). That might mean that users won’t care too much about their Ubuntu instance’s passwords but as you can imagine with no password policy enforcement, users might be tempted to reuse their Windows passwords.

I should also note that whilst sudo prompts for a password on each new instance of bash.exe/conhost.exe pair hosting a terminal however if you authenticate to sudo, close the terminal and then reopen it, then your sudo ticket may still be valid – this requires exact co-ordination as sudo sessions are tracked by PID, however the first terminal opened will always have a Linux bash process with a PID of 2 which may well be blessed from a previous sudo session.

Privileges

Finally, as per issue issue 561, because everything runs as you from Windows’ perspective, the only way to successfully execute ping (which requires an ICMP raw socket on Linux) is to run bash.exe in elevated mode (as Administrator). This, despite the fact that a non-elevated user can quite happily execute ping on the Windows host. WSL doesn’t even implement concept of root in any real sense, let along implement the necessary Linux syscalls to support capabilities in any useful fashion. This in turn means that everything else spawned from the elevated shell also runs with Windows administrative privileges. For comparison, here’s what the new branches of your process tree will look like:

• wininit.exe.exe (runs as SYSTEM):
  • services.exe (runs as SYSTEM):
    • svchost.exe (runs as SYSTEM):
      • RuntimeBroker.exe (runs as your user, disabled privileges, not elevated):
        • bash.exe (runs as your user, disabled privileges, elevated):
          • conhost.exe (runs as your user, disabled privileges, elevated)

The first contains the Windows bash.exe instance which hosts your new terminal, whilst the second contains the Linux process tree:

• svchost.exe (runs as SYSTEM):
  • init (runs as your user, no disabled privileges, locked into a job, elevated):
    • bash (runs as your user, disabled privileges, locked into a job, break away set to true, elevated):
      • sudo (runs as your user, disabled privileges, locked into a job, break away set to true, elevated):
        • ping (runs as your user, disabled privileges, locked into a job, break away set to true, elevated)

Microsoft’s stock answer is that the Ubuntu instance (or rather the bash.exe instance hosting the terminal and accompanying lxss.sys kernel implementation) is locked down, effectively sandboxed by a combination of Windows DACLs, the concept of jobs (touched upon at the start and akin to Linux cgroups) and syscall mapping that effectively uses lxss.sys to proxy most syscalls onto their corresponding NT kernel implementation.

Conclusion

The design of WSL seems to be relatively robust if slightly odd, however time will tell, particularly if offensive teams pick up the whiff of a new opportunity. If nothing else, take this article as a reminder that WSL should not be considered a security boundary and that it will remain unmanaged irrespective of how you administer your Windows hosts.

The post Exploring Windows Subsystem for Linux appeared first on Portcullis Labs.

Let’s start by defining what VIOS is. VIOS is a subsystem that runs on a logical partition (LPAR) which manages shared hardware such as disks and network adaptors and allows other LPARs to access them. VIOS is managed via a special padmin account which gives access to a restricted shell from where the hardware can be managed. In practice, however it’s just another AIX LPAR and as the blog post from IBM notes, setup_oem_env can be used to move from the padmin user to the root user.

Firstly, note that setup_oem_env is not setUID. So how does it work? Examining the padmin user we see that it has a single role (PAdmin):

The membership of a role is determined by /etc/security/user but we can examine a specific use using the rolelist command like so:

$ rolelist -u padmin
PAdmin

You can also find your current active role using the -e flag to rolelist. Moving on, what does the PAdmin role mean?

Roles are defined in /etc/security/role but as with role membership, we can also use shell commands to enumerate them. For example, the following shows what authorisations the PAdmin role has:

$ lsrole PAdmin
PAdmin
authorizations=vios.device,vios.fs,vios.install,vios.lvm,vios.network,vios.security,vios.system,vios.oemsetupenv,vios.system.cluster,aix.system.config.artex
rolelist= groups=staff visibility=1 screens=* dfltmsg= msgcat= auth_mode=INVOKER
id=23

In the context of getting root, vios.oemsetupenv is the charm. This and other AIX authorisations are defined in /etc/security/privcmds. It is possible to specify what commands the possessor of the vios.oemsetupenv authorisation can run (and indeed the privileges with which those commands will ultimately be executed).

You see, AIX like Solaris, is gradually getting rid of the concept that uid=0 is god. IBM haven’t taken this as far as Oracle yet but there’s nothing to stop a dedicated administrator from leveraging this functionality. So, if you’re auditing an AIX box, I would very much recommend checking what roles users have (via /etc/security/user) to ensure that no appropriate roles have been assigned.

PS I’ve never seen this used in practice (outside of VIOS), but I’m sure there will be a first time.
PPS rolelist -p will tell you what roles a given process has.
PPPS esaadmin has the SysConfig role but it’s not normally an active account.

The post padmin to root: Roles on AIX appeared first on Portcullis Labs.