Ruler has become a go to tool for us on external engagements, easily turning compromised mailbox credentials into shells. This has resulted in security being pushed forward and Microsoft responding with patches for the two vectors used in Ruler, namely rules and forms. These were patched with KB3191938 and KB4011091 respectively. This puts us back into the cat and mouse game of attack versus defence, with attack needing to find a new vector. Turns out the rules of three holds true, and where two vulnerabilities lurk, a third surely exists.
We’ve spent a lot of time creating Ruler and turning it into, what we think, is a useful attack tool. The goal behind the project was to highlight the command execution potential around weak credentials when combined with Exchange and Microsoft Outlook. That goal has largely been met, with the ability to now demonstrate that compromising user credentials can be much more than “just” reading email. Microsoft has also been great in their response to the issue, with both client-side rules and forms having been effectively mitigated through patches to Outlook.
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.
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.
Ruler at Troopers17 We are taking Ruler and the abuse of Exchange on a road trip to Germany in March. Troopers have accepted our talk, “Ruler – Pivoting through Exchange” and we are looking forward to sharing the exciting extras that we’ve been building into Ruler, along with some secrets for using Exchange in your recon, exploitation and post-exploitation phases.
https://www.troopers.de/events/troopers17/779_ruler_-_pivoting_through_exchange/
Passing the Hash A while back I was asked (I think by @singe, but there were others as well) if it was possible to do Pass the Hash (PtH) with Ruler.
01 September 2016
~7 min
By etienne
History In December 2015 Silent Break Security wrote about “Malicious Outlook Rules” and using these to get a remote shell. This was great, we could now use those credentials found through brute-forcing OWA instances or a phishing page. The only issue I had with this was the fact that you needed to setup a local instance of the mailbox, which at times could be time consuming and also felt like overkill.
Mobile assessments are always fun as the environment is constantly evolving. A recent trend has been the use of custom protocols for communication between the application and server. This holds particularly true for financial institutes who are aiming to protect both the confidentiality and integrity of data. Most of these custom protocols are over TCP, wrap data in custom crypto, which usually includes signing of the payload to prevent tampering. Even when transmitted over HTTPS, we have noticed a trend where data within the HTTP body gets encrypted and signed using some custom crypto. Both of these processes can greatly frustrate testers using standard network intercepting tools.
SensePost Training in the Cloud Picture this. Every year, a group of Plakkers (our nickname for those who work at SensePost) descended into Las Vegas with more luggage than Imelda Marcos on a shoe shopping spree. In recent years, our kit list was immense. 200+ laptops, 25 servers, screens, switches and more backup disks than one should ever carry past TSA. Often we got there days before Blackhat started and spent 24 hours making sure our networks and servers started (inevitably they never did, which meant late nights debugging).
Every now and then you run into a new file format and you find that you may not have a tool to parse that file. Or you are looking for an easy to use solution for you mom to access the photo’s you sent her in a .tar archive. This is where file conversion services come in, a quick Google for “online file converter” will yield multiple results. One thing to keep in mind when converting files, is that different file formats may support different features.
03 September 2015
~5 min
By etienne
But, Websockets! The last week I was stuck on a web-app assessment where everything was new-age HTML5, with AngularJS and websockets. Apart from the login sequence, all communication happened through websockets. Now intercepting websockets can be done in Burp and you can modify the requests/responses as you wish. There were however multiple issues with this.
Polling – the webapp did a ‘ping’ request and if this was held up (intercept in burp) the app would timeout and I had to start from scratch. This timeout period was relatively aggressive, so by the time I finished modifying a request, the app had timed out and my changes meant squat. Intercept/Replace rules- ping messages were irritating and Burp had no way to not intercept these. It also wasn’t possible to configure out replace rules. And according to this, it isn’t coming to Burp anytime soon… https://support.portswigger.net/customer/portal/questions/11577304-replace-text-in-websocket-operations Replay/Intruder – there is no way to replay a websocket request in Burp. This also means no Intruder :( At this junction, three options were available to me. Use ZAP (which does have intercept rules but not replay/replace/intruder). Use Internet Explorer and force the app into non-websocket mode or write a custom proxy. So the choice was obvious, write a custom proxy.