“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data” - graphql.org The GraphQL query language allows developers to easily write front-end queries, using a JSON like syntax, to retrieve data from the back-end. The big plus here that a single API end-point can return multiple types and formats of data based on the contents of the query. This simplicity has resulted in a steady adaption of GraphQL.
Before creating this blog, I had the opportunity to create numerous posts under the SensePost blog. These cover a few topics including mobile apps, web apps and infrastructure. Here is a list of those posts, in chronological order, with a brief abstract about each post.
Recently I was doing an assessment in a locked down and restricted environment. One of the first actions you tend to do when landing a shell on a [linux] box is to do some reconnaissance. This is both on host and network, as you want to determine what new access this host has given you. Normally you would run netstat, ifconfig, ip route etc to determine if the compromised host is connected to any other hosts and to determine if there are other network segments you do not know about.
When doing external assessments you spend a decent amount of time footprinting your target and finding possible avenues of attack. Given a large corporate, you are pretty likely to hit video conferencing end-points. This post details a vulnerability in one of these video conferencing systems, the Polycom HDX series. I identified this vulnerability while still at SensePost and reported it to Polycom. The vulnerability was acknowledged and we were informed that a patch would be issued.
A few weeks back Saif El-Sherei and I posted on the SensePost blog about DDE and getting command exec in MSWord without macros. This post got way more attention than we initially expected it would. Since then DDE has been used in phishing and malware campaigns, as well as legitimate red-team engagements. With the rapid rise in attacks using DDE, detection has been stepped up and most AV engines have basic DDE detection built in.
Typically phishing has provided a low tech approach to getting access to credentials and services. The mainfocus up until now has been on getting username&passwords or tricking users into executing code. Subsequently, user awareness has gone up and users are better at identifying suspicious pages. Experience has shown that the click-through rate on emails have remained high, while users have been (slightly) less likely to enter credentials and more likely to report the phishing page.
A recent research project/idea required me to look into setting up a NAT-to-NAT VPN. The basic idea being that two NATed networks are able to communicate through a VPN and share resources. While researching possible VPN solutions, I remembered reading about WireGuard a new VPN that aims to be fast, secure and lightweight. This seemed like the perfect opportunity to both try out a new VPN implementation and accomplish the goals of the research project.
XXE - FTP OoB basics XXE offers a great attack avenue for reading files from a vulnerable web-app. One of my favourite XXE attacks involves protocol handler abuse, where you use FTP to do an out of band read. This is useful in those cases where you have XXE but it is blind. Unlike the normal OoB retreival through HTTP, FTP works with newer versions of Java (>1.7) and there are fewer characters which break the retrieval.
On numerous occasions I’ve run into custom binary network protocols that I’ve wanted to reverse. The usual goto here is to fireup wireshark/tcpdump and view the traffic as it goes accross the wire. This works really well in most cases, but how about traffic that uses TLS to encrypt the traffic? Unless you have the private key for the server, you are stuck with viewing encrypted traffic in wireshark. Not ideal for reverse engineering.
It’s been a while… I figured it’s about time I post something here again. A while back I was required to see how much damage can be done by a malicious staff member. The one caveat here was that I had to test directly from the Windows box and had extremely limited outbound comms. For various reasons the usual tool-suites were out and I took this as a challenge to see how much damage I could do by coding tools on the “employee machine”.