herding sheep

It goes without saying that Pokemon GO is a craze of magnitude that we haven’t seen for a long time, and undoubtedly one that will be around for quite some time. If memory serves me correctly, not even Angry Birds grew in popularity this rapidly – and it didn’t have the same positive effects (e.g. getting gamers outside and socialising with others).

“prepare for trouble, and make it double”

Whilst most observers may see the primary negative effect as the game being yet another contributor to mobile phone addiction – diluting what are likely already diluted “real world” skills – those of us with a more nefarious view of the world will see this as a prime opportunity to pop some shells. Just as the Rio Olympics have spurred a wave of phishing and malware attacks, it comes as no surprise that Pokemon GO has too. So, this made me think… exactly how covert can you make Android malware?
Continue reading “herding sheep”

held to ransom

As of late I’ve been keeping fairly busy, unfortunately with not a lot that I can blog about. I’ve built a new house, planned some overseas travel for later in the year, am in the midst of planning a security conference with some of the other ISIG and OWASP blokes (more on that later) and have been incredibly excited about Battlefield 1. I could have been left for another month and probably remained quiet on the blogging front, alas someone has prompted me to break the silence.

After a recent incident I was quizzed by this someone about how I approach handling situations where defenses fail and malware does make an impact – and they suggested I make a blog post to explain this. Well, I’m feeling pretty motivated today so let’s make that happen.

Most days I receive a couple of suspect files, emails or URL’s passed my way for inspection (the thought of those that I don’t receive is what keeps me awake at night), so I’ve selected one to illustrate my basic analysis process: a pretty standard case of ransomware via email, sent to one of our helpdesk staff.
Continue reading “held to ransom”

building a higher wall

IISFortify is a suite of scripts I produce to optimise the configuration of Windows Schannel and IIS. It bolsters cryptographic standards and HTTP response headers. As my workplace is beginning to dip it’s feet in Server 2016 along with IIS 10, it is about time that the scripts for Server 2012 were updated, along with introducing scripts for Server 2016/Windows 10.
Continue reading “building a higher wall”

revisiting the watering hole – again

One of the most popular developments of mine, and in my opinion one of the most effective at what it is aimed to do, is the Pond Security Awareness Framework. In the last post I made regarding it, I had introduced the concept of mutliple campaigns and collaboration via SignalR. Multiple users could work on the same campaign, saving and resuming work on them whenever they please. My problem was, however, that the attack vector was still limited to email – I wanted more. So, I have introduced an API, meaning that any method of attack can be used where code can be executed to POST to a URL.

Further to this, the code has now – finally – been made public under the Apache license.
Continue reading “revisiting the watering hole – again”

building stronger walls

Speaking at OWASP NZ Day 2016 was certainly quite an experience. Prior to it I had only really spoken to local user groups: 30-50 people max – so being thrown in front of 600 pretty clued up people was, as some would say, akin to being thrown into the deep end. Sadly, I remain quite disappointed that I didn’t manage to catch many of the afternoon talks due to having a bright idea of taking the 6:30am flight to Auckland and subsequently falling asleep in my hotel room during the lunch break. However, what I did manage to see made one thing very clear: the only way a higher standard of security can be produced by your developers is by working alongside them as opposed to taking the stance of a dictator – shooting down their code, questioning their competency and generally doing anything that makes it clear you’re the boss.

In this post I’ll provide a recap on the main content of my talk: the ideas and solutions behind making security a core focal point of your development with minimal disruption to standard processes.
Continue reading “building stronger walls”

revisiting the watering hole

Earlier this year, in May, I wrote about a phishing framework that I used to mount a company wide phishing campaign – for testing purposes, of course. Since then several other companies have used the application for the same purpose, and there has been some real interest in it within the local security community. This interest sparked a revival of the project: complete rearchitecture, redesign and rethinking of how it should be used. Whilst the code isn’t quite ready for public release and I haven’t started on documentation, in this post I’ll outline the new architecture and demonstrate a campaign from beginning to end. Continue reading “revisiting the watering hole”

lord of the flies

The popularity of a security consultant within a development oriented organisation is most certainly bi-polar. Occasionally, after thwarting a breach or reporting a bug directly to a developer rather than through JIRA (where it would expose their incompetence), we are gifted the opportunity of feeling a little more human and receive – for once – some warmth from our fellow compatriots. Most of the time, however, we’re that troll under the bridge pulling at peoples ankles, standing in their way and grunting orders at them as they try to cross. On the other hand, the reality is that the very nature of our jobs is to protect and help others, and to do so requires a solid understanding of all layers of the stack. So, for the most part we’re not grunting orders whilst having no clue as to what we’re talking about: we’re making well informed observations that warrant attention.

Many a dev shop I’ve stepped into can be likened to the Lord of the Flies, where the developers are so focused on design, functionality and UX that they lose touch with what really makes a product: engineering. Design may sell a product, but without solid engineering it will almost certainly see a short lifespan, significant downtime, no sales via word-of-mouth and/or reputational harm. What I’ve been trying to teach developers is that security not only has the function of protecting data and users, but it also promotes robust engineering. Making security a priority throughout the entire design and development process ultimately forms a more reliable product that will require less ongoing downtime to patch bugs – allowing developers to focus more on functionality and design during post go-live sprints. Think of it this way: if you cut corners when constructing the foundations and frame of a house, only to later discover that there is a critical issue with either, you’re going to have one hell of a time trying to address the issue without seriously impacting it’s occupants. So, the key to forcing a shift toward secure development practices is education: knowing vulnerabilities and their impact, coding securely, testing and how to efficiently integrate standards into projects. An effective tool to illustrate this and to get developers adopting more of a hacker mindset are HackMe applications. Previously I developed and released vuln_demo, however I’ve recently ended this project and created FooBl0g. Continue reading “lord of the flies”