Thanks to IoT and other developments, we’re having to review more and more non-HTTP protocols these days. While the hardware is interesting to look at, one can often find vulnerabilities at a network layer too. With many of the non-HTTP-only proxies having fallen out of maintenance or requiring a significant amount of custom code to be written for each unique protocol encountered, we decided to build a tool to make such work easier.
Sometimes on an engagement, you’d like to construct a believable certificate chain, that you have the matching private keys for. An example might be that a mobile app is doing cert pinning, based on attributes of the signing certificate, such as the Canonical Name (CN), serial number, or Issuer, or that you are intercepting an embedded app that only supports a particular algorithm. Whatever the reason, it’s a fairly complicated process if you are not familiar with X509 certificates. And trying to kludge it together with OpenSSL and some shell scripts under time constraints will only make you tear your hair out! While Metasploit can do some of this, it only clones a single certificate and self-signs it, rather than cloning the entire chain. If you need more than that, keep reading!
Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo – long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?
On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.
First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn’t find the exact IP they were being NAT’ed to. Not wanting to stop there, I tried out Vlad’s Skype IP disclosure trick, which worked like a charm. What’s cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don’t even need to be “friends”, you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.
26 November 2012
~2 min
By vlad
When performing spear phishing attacks, the more information you have at your disposal, the better. One tactic we thought useful was this Skype security flaw disclosed in the early days of 2012 (discovered by one of the Skype engineers much earlier).
For those who haven’t heard of it – this vulnerability allows an attacker to passively disclose victims external, as well as internal, IP addresses in a matter of seconds, by viewing the victims VCard through an ‘Add Contact’ form.
BackupExec agent is often among common services found on the internal pen tests. The agent software stores an encrypted “logon account” password in its backend MS SQL database (LoginAccounts table). These accounts include the “system logon account” which is used to run agent services and an optional number of active directory accounts that are used to access resources over the network. The following scenarios can result in access to encrypted passwords: