July is our favourite time of year, when thousands descend into Las Vegas for Blackhat/Defcon, or more commonly referred to as ‘Hacker Summer Camp’. This year, our camp councillors have been working hard to bring you all our latest creations.
BlackHat Training We’re running our usual training at BlackHat, and as usual have been working hard to build new courses and update others. Here’s a list:
BLACK OPS HACKING FOR PENTESTERS – MASTER LEVEL PENTESTING ENTERPRISE INFRASTRUCTURE – JOURNEYMAN LEVEL SECDEVOPS: INJECTING SECURITY INTO DEVOPS (NEW) TACTICS, TECHNIQUES AND PROCEDURES FOR HACKERS We’re pretty excited about the new SecDevOps course, which reflects what we’ve learned about transitioning old-style project pentesting into an agile world.
Intro Recently, I reported CVE-2017-7668 (Apache Server buffer-over-read). This is a cross-post from my personal blog where I explain how to fuzz network programs with AFL by porting techniques learned in honggfuzz into AFL. After a small chat with Dominic he asked me to re-post it here which, for me it’s an honour to do so!
The reported CVE was obtained with code analysis and instrumentation of the right parts of the code (mainly core and parsing) – First, with honggfuzz I got the initial dirty test cases and then, through radamsa generated a few thousands mutations and finally AFL with the technique described here.
Intro Hi there (again)! This series are going to an end as the next and feasible step is the widely known buffer overflow and its analysis in the heap and, I am not too convinced about it since the unsafe unlink method is long gone. But don’t be sad, today we are going for a bonus one! During the last post (double free attacks) one I stumbled across some weird behaviour that caught my attention by functions of the vfprintf.c family (for example printf or puts functions).
Sophisticated attacks aim to hide from endpoint solutions
Advanced hacking.
Expert approaches
We are inundated by advanced this, expert that, when it comes to hacking and hacking training. When a breach occurs, the media portray it as some epic hack that mere mortals would struggle to comprehend, when in reality it’s actually a run of the mill SQLi attack. Often it’s not advanced, but makes use of a series of vulnerabilities chained together, using Tactics, Techniques and Procedures (TTP) often used by attackers when owning networks.
SensePost and BlackHat are proud to announce a new scholarship initiative for a woman in the information security field. The scholarship will include a ticket to Black Hat USA 2017 in Las Vegas, complimentary access to one of our training courses, airfare, and accommodation.
The scholarship will be awarded to a woman who demonstrates a strong desire to hone her InfoSec skills (more below).
How To Enter?
To enter, send us reasons as to why you believe *you* should attend one of our training courses and Blackhat USA. This could be in the form of an essay, examples of projects you are working on, stuff you’ve built or building or generally anything you think supports your claim for a place.
Introduction Towards the end of last year, I found myself playing around with some basic amplitude modulation (AM)/On-off keying (OOK) software defined radio. That resulted in ooktools being built to help with making some of that work easier and to help me learn. A little while ago, the Metasploit project announced new ‘rftransceiver’ capabilities that were added to the framework with a similar goal of making this research easier.
How things fit together First things first. I had to try and understand how this new functionality actually works. From the Metasploit blog post, it was possible to see that the additions allowed you to communicate with a RFCat capable device from Metasploit and run modules over a session. A session is started by connecting to a small JSON API (with a python helper) that bridges HTTP requests to rflib methods.
-1 – Pre-Intro When looking at heap exploit tutorials most of the time I found myself lacking knowledge on the actual implementation and, soon, had the urge of knowing how it’s allocated and freed and why it’s done that way, memory wise.
-0.9 – ptmalloc2 The best source of knowledge with regards to the implementation of the heap is itself, the source code. Do not fear it, thankfully it is widely commented!
Using MS Exchange and Outlook to get a foothold in an organisation, or to maintain persistence, has been a go to attack method for RedTeams lately. This attack has typically relied on using Outlook Rules to trigger the shell execution. Although Ruler makes accomplishing this really easy, it has, up until now, required a WebDAV server to host our shell/application. In most cases this is not an issue, but once in a while you run into a restrictive network that does not allow the initial WebDAV connection to be established. In such instances, the attack sadly fails. Another downside to Outlook rules is that we are limited to only providing an application path, and no command-line arguments, meaning none of our fancy Powershell one-liners can be used.
06 April 2017
~8 min
By saif
Whilst on a Red Team assessment back in 2015, we were faced with a tough Data Leak Protection (DLP) and web content management gateway system called Forcepoint TRITON. One of the goals, besides gaining full access to the client, was to see if sensitive data could be exfiltrated from the internal network to attacker controlled servers. The first logical step was to analyse how this device functioned and identify any flaws.
Getting access to an internal network is always great, keeping this access can be a whole other challenge. At times we want to fly below the radar and ensure our access doesn’t get detected or blocked by traditional network based solutions. To this end, communicating directly through an Exchange server can be very beneficial and solve both challenges.
Technical details Ruler provides us with a means of getting a shell on an internal network. This is all done through Exchange and ensures our “trigger” for getting a shell back is usually only an email away. To a large degree this gives us the desired persistence we may want, however, we are still dependent on our traditional communication channels, be it DNS, HTTP(s) or TCP. This means our tools can need to traverse the traditional network boundary, aka, the web-gateway. Defenders place all their in-line defences here and should be able to detect and block our traffic. Exchange usually falls outside of this monitoring, as it should only be sending and receiving email. Sure there can be DLP and in-line scanning for malicious mail attachments, but this is usually aimed at the actual email messages. Do you have or have you seen in-line inspection of the Exchange/Outlook transport? Not the IMAP/SMTP traffic, the MAPI/HTTP or the RPC/HTTP channel that external Outlook clients use to communicate with the Exchange server. In my experience, the answer is usually no, there is no inspection of these transports.