Research
pwning asus driverhub, msi center, acer control centre and razer synapse 4
At the beginning of this year I spent a week finding several vulnerabilities in various “bloatware” software. This was after I got suspicious of how my ASUS motherboard’s “DriverHub” behaved. In the end I looked at 6 targets from 6 random vendors (apart from ASUS) and found vulnerabilities ranging from Remote Code Execution to Local Privilege Escalation in all of them. Those were: ASUS, Acer, Lenovo, HP, MSI and Razer.
From a GLPI patch bypass to RCE
Introduction GLPI is a popular software used by companies, mainly in France. GLPI is usually used for two main purposes. Firstly it allows companies to see the inventory of their different equipment (such as: computers, software, printers, etc…). Secondly it is used for its ticketing system, allowing users to create tickets about their issues. It also has different roles for each user, those who can only create tickets (low privileges user), and those who get central access (again there are different roles here). During an internal penetration test, chances are that if you got an account, you will be a low privilege user, known as Self-Service.
Targeting an industrial protocol gateway
Inside industrial systems (also known as Operational Technology, or OT), devices communicate with each other and can be accessed over IP using familiar IT protocols (such as SSH, web services, etc.), as well as with a variety of industrial network protocols. Among them, you may have heard of Modbus, maybe S7comm, OPC-UA and a few others, but do you know all the industrial protocols you could find on industrial networks? It would take a lifetime to list them all, considering the field-specific standards, the manufacturer-dependent protocols and variations, the association-promoted specifications, and their numerous versions, layers, extensions and adaptations. In the end, an industrial process typically involves a collection of devices, servers and workstations that are likely to use many different protocols and still need to understand each other.
Jumping into SOCKS
On a recent internal assessment, we ran into a problem. While holding low-privileged access to an internal Windows host, we realised the software on the host was communicating to a remote API endpoint over HTTPS. However, the remote endpoint was enforcing authentication using client SSL certificates.
Normally, the above scenario is easily fixed by exporting the local client SSL certificate from the host and importing it into either Burp Suite or Postman. In Burp Suite, when you want to use a client SSL certificate, you must manually load the certificate and private key into it. This implies (on Windows, at least) that you’ll need to export the client SSL certificate. However, this is only possible if you hold appropriate permissions to the certificate and its private key and it allows exporting.
Attacking smart cards in active directory
Introduction Recently, I encountered a fully password-less environment. Every employee in this company had their own smart card that they used to login into their computers, emails, internal applications and more. None of the employees at the company had a password at all – this sounded really cool.
In this post I will detail a technique used to impersonate other users by modifying a User Principal Name (UPN) on an Active Directory domain that only uses smart cards.
Analysis of a 1day (CVE-2019-0547) and discovery of a forgotten condition in the patch (CVE-2019-0726) – Part 1 of 2
This post will cover my journey into the analysis of CVE-2019-0547 (Affecting the windows DHCP client), a vulnerability discovered by Mitch Adair of Microsoft Windows Enterprise Security Team and how I found a new issue in the same function.
Part 1Patch extractionPatch diffingProgram flow to the functionDHCP Options0x000x00Part 2Integer overflowNobody respects RFCs0xC0 “compression algorithm”Final conclusions Patch extraction Even though these first steps around patch downloading, extraction and diffing are already heavily documented over the internet, I will cover them here in any case.
Waiting for goDoH
or DNS exfiltration over DNS over HTTPS (DoH) with godoh “Exfiltration Over Alternate Protocol” techniques such as using the Domain Name System as a covert communication channel for data exfiltration is not a new concept. We’ve used the technique for many years at SensePost, including Haroon & Marco’s 2007 BH/DC talk on Squeeza. In the present age this is a well understood topic, at least amongst Infosec folks, with a large number of resources, available, online that aim to enlighten those that may not be familiar with the concept. There are also practical techniques for detecting DNS Tunnelling on your network.
tip toeing past android 7’s network security configuration
In late Jan, someone opened an Github issue in the objection repository about Android 7’s Network Security Configuration. The issue author included a blogpost from the NCC group about this very topic which included some very helpful bits of information (which you should totally read).
Naturally, I wanted to enhance objection to be able to get past this new security feature, so the testing began. I installed a Burp CA as one would normally do for assessments as well as a small test application with certificate pinning disabled and quickly realised that literally no network traffic was passing through. Inspecting the output of adb logat, one would see messages such as the following for our failed requests:
The TRITON Won’t Protect You From Our Punches
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.
Liniaal – Empire through Exchange
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.
Page 1 of 8
Next