Research and Development


Those of you that have been following the UK infosec market recently will have noticed an upturn in talk relating to “Red Team” style engagements. Unlike a traditional penetration test, the object of such an exercise is not to locate vulnerabilities (though of course that helps) but rather to exercise the “Blue Team” i.e. the internal users at an organisation responsible for defending their network. This change has been driven by CBEST and the associated STAR exam offerings from CREST, which have certainly raised the bar. Whilst most IT security consultancies are happy to talk about phishing, the level to which they go to mimic the target can vary. Continue reading

As a pentester, there are days when you’ll get asked to look at the ordinary, and there are days that you’ll be asked to look at something more challenging. This week was full of days that met the latter criteria and not the former. Whilst I can’t share the scope, Portcullis was asked to examine a network implementation using the MPLS protocol and comment on the security, or otherwise, of it. Continue reading

Consider the case of a setUID binary that runs as root and allows the caller to execute certain other scripts and binaries from a given restricted directory. The Portcullis Labs team recently spotted such a case and I was asked to take a look to determine exploitablity. What follows is a short analysis of what I found. Continue reading

As many of our regular readers will know, the Portcullis Labs team have a good deal of experience with reviewing the security of POSIX alike OS, and as a result, we’ve made some interesting discoveries in terms of how easy it can be to escalate ones privileges. As I discussed some time ago at CRESTCon, one particular avenue of attack that we like is the runtime linker itself. As part of our ongoing research, I’ve recently issued a request for comments for a patch that tackles a number of systemic weaknesses in the Linux (glibc) runtime linker that we often exploit. A few further points on the rationale… Continue reading

Today I was looking at how plugins could safely be incorporated into a J2EE application server. The plugins in this instance are executed server side, rather than on the client and are, in the main, provided by 3rd parties (digital advertising agencies etc). The aim was to limit the scope in which they operate. The implementation I looked at is pretty much the first instance where I’ve seen these techniques used, so I thought it was worth sharing. Continue reading