un-excogitate

What was it like enabling Google Advanced Protection?

Sun, 04 Mar 2018 15:00:00 -0800

tldr; Boring.. it was really boring.

It's the 27th of January, 2018. And yes, I've just signed into Google's Advanced Protection.. let's see how this goes.

Fast-forward to now.. March

I think the only hurdle was that apparently I had signed into YouTube on the TV. I don't even really remember doing that. Apart from that, this hadn't changed my usage of my gmail account (which I effectively live out of) at all. Oh, and the OS X native integration (which apparently I'd turned on to use the native calendar?) also stopped working.

I should probably provide some context. For those that don't know, Advanced Protection is an optional security configuration for your Google account that does a few things. First and foremost, it requires the use of hardware 2FA to sign in, no more SMS or Authenticator (aka: time-based one-time-pins) 2FA logins. The only reason I actually did this is because during the Enigma conference, Google were handing out these rad little kits which included the following:

Bluetooth, USB (with cable) and NFC dongle
USB-A, NFC dongle

So after having a chat with the mostly bored Google engineer behind the counter, I grabbed a kit and went on my way. A week or so later, I sat down with my devices and got cracking. Now, your mileage may vary, especially if you have old, or non-Google devices. My setup is fairly conducive to Advanced Protection, namely:

Google Android Pixel 2 phone
MacBook Pro (personal and work), running the Chrome browser
A Samsung ChromeBook (the same as from this great blog on the $169 development Chromebook blog)

The other key controls that Advanced Protection enables include:

You can only sign in to Google services, like Gmail, Photos, and Drive, from Chrome OS or the Chrome Browser
Third party apps that want to access your Gmail or Drive will no longer work
iOS Apple Mail, Contacts and Calendar apps do not currently support hardware keys, and currently won't work
Restoring your account if you get locked out can take longer (apparently)

The dongles themselves must adhere to the FIDO Universal Second Factor (U2F) protocol, but apart from that you can choose any, including those from Yubico. The two that came with the Google kit include the: Feitian MultiPass FIDO Security Key and the YubiKey NEO (or something very similar).

When Google first released (see blog) this feature it was primarily targeted at a small subset of users. Particularly those that they deemed at higher risk, such as campaign staffers, journalists, CEOs etc. I definitely don't fit into that demographic, but considering how much I depend on their services, the extra layer has been a great relief without any detrimental impact.

During the conference Google actually presented about the adoption of 2FA, and other facets of their authentication systems. I was somewhat surprised at how low their adoption was of 2FA (Less than 10% of active Google accounts use it). So, I expect that the number of people using Advanced Protection to be incredibly small. I'm also wondering of the other people that use it, how many have disabled it again, or whether their experience is similar to mine.

Given some recent research by my good bud @antisnatchor on Phishing YubiKeys would I still recommend this? Sure, why not.

So, want to check it out? Buy yourself some keys and head over to https://landing.google.com/advancedprotection/.

Dormant DOMination

Sun, 20 Aug 2017 15:20:00 -0700

Introduction

In the midst of "trying to be creative", I thought I should finally pull my finger out and catch up on some work that I haven't had a chance to blog about. Especially as Michele has progressed from bugging me about pushing up this code, to simply ignoring me entirely (still love you dude :P). So I've taken some time over the past couple of weeks to put together my thoughts on abusing dormant tabs (or other running JavaScript contexts) to detect when browsers change network. Not to mention that I presented this at BSidesSF months ago! I have to preface that like most of the code I write, it's fairly hacky, and there's certainly a few bits that aren't as complete as I'd like. And I'm constantly time-poor (nb: I really struggle to open the laptop outside of work these days), so the idea of maintaining this code makes me want to cry. With that said, here it goes.

The idea was simple enough. Why not adjust BeEF's (beef from here on in because .. capitalization fatigue) Autorun Rules Engine (ARE) such that instead of just running a set of modules upon hook, how about we prepare some modules, and wait for the network-context of the browser to change, and THEN run some modules. Even better, how about we try and store the results of those modules locally until the browser returns back to the original context.

This scenario becomes particularly interesting in the context of different networks with altering risk profiles, such as a public network versus a corporate network, or even airgapped networks. From an attacker's perspective, these non-Internet-accessible networks are a juicy target. It's also these sorts of scenarios that really highlight the importance of addressing CSRF vulnerabilities, especially on internal networks.

I've run into some networks where inline security appliances have halted the beef payload from downloading. Sure, bypassing these is not that difficult, such as using TLS, or obfuscating the JS payloads. But it's also in the face of these controls that the dormant-forward method really shines. Imagine hooking a browser whilst it's on a public wifi with no perimeter controls. That tab, if it remains open, will continue to run. If that computer then changes network to a more critical network, there's nothing preventing the already in-memory JS from continuing to run. Even though the SOP is great at preventing JS from interacting freely with other origins, the control doesn't prevent all information from returning to differing origins. We can still gather information based on whether cross-origin requests fail, how quickly they fail. Plus, there's plenty of other 'blind' CSRF attacks that can exploit internally-accessible systems, regardless of the SOP preventing the hooked browser from directly accessing the HTTP responses (See: whatsinmyredis).

But, before we get into the specifics, for those that haven't spent time in beef lately feel free to check out a presentation I was lucky enough to present at CactusCon last year for a quick refresher of WTF beef is..

The History of the Autorun Rules Engine

To try and provide a bit of context of the ARE, we have to delve into the history of beef. Back in the dark ages (when beef was written in PHP), one of the standard features was the autorun configuration. It was simple; when a browser is hooked to beef, run a module. It took a while until the same feature reappeared in the ruby re-write of beef, but it exists. And it's as simple as updating either your global (or module-specific) config.yaml to ensure that in the module definition you have defined autorun: true. You can see this demonstrated over here.

ARE is similar, but provides a lot more 'logic' around when modules run, and how to run multiple modules. The wiki provides a lot more context around ARE, and how to use it. But in short, modules can either be sequentially chained (i.e. they run one after the other) or nested-forward chained (i.e. each module depends on the previous module to have completed properly, and can take the output of the previous module too). The nested-forward example is perfect, in that, it first gathers the internal IP of the browser, then takes that and uses it to configure and run the internal network fingerprinting module.

Dormant-forward Chain Mode

The new dormant-forward chain mode has the following phases:

Setup
Monitor for network changes
Run arbitrary beef modules

The Setup phase itself goes through two steps:

Gather information about the current network I'm on. This is a combination of the existing Get Internal IP WebRTC module, and a new beef service to allow a browser to gather information about its external network. Such as ASN, ISP etc.
Initiate timers to help detect when the network has changed, and prepare subsequent modules

The Monitor phase is composed of methods that run when the browser's network connectivity appears to have changed. This includes checking things like:

Are we not offline or online?
Are we back on the original network or a new network?

If we're on a new network, then lets kick off the network detection methods and determine if we have queued modules to execute.

Once we've determined we're going to run new modules there are a few configurable options that modify how we execute the modules. This includes:

How stealthy do we want to be on the network? i.e. do we want to cache module results locally in the browser until we return to the original network, or do we want to just send the results straight out
What are we going to do when we return home? Are we going to just kill all the timers and network-change detection, or do we keep on going

The stealthy parameter directly ties back into wanting to minimize our presense to perimeter network detection devices. With this enabled, we could have a browser hooked, connect to an internal network. Gather information about that network. Wait for a public network, and then send the results back to beef. Any perimeter network detection may not even be aware that there WAS a hooked browser on the network.

The Setup

For our example scenario the setup is like this: Let's assume a mobile browser gets hooked to beef on a public network.

View post on imgur.com

The browser meets the ARE targeting and is sent the dormant-forward payload.

View post on imgur.com

.. some time passes ... The browser ends up on a different network.

View post on imgur.com

Beef modules are run against local subnets, based on the new internal IP of the browser. The modules include ping-sweep on a subset of the local subnet, and then a port scan against discovered hosts. Again, this port scan is only against a sub-set of ports.

View post on imgur.com

The browser does NOT send the results of these modules back to the beef server.

View post on imgur.com

.. some more time passes ... The browser returns back to the original network, and sends its cached module responses back to the beef server.

View post on imgur.com

Here is an example of the ARE JSON file:

Closing

Overall I was happy with the proof of concept, especially highlighting risks of devices crossing network boundaries with malicious JS in-memory, in the DOM. There are some loose-ends and a few implementation details which may not make this capability immediately usable by everyone. The biggest issue discussed at Bsides was accurate detection of networks. There were some suggestions to adjust when to send module-data back to beef. For instance, instead of waiting for the original network, perhaps just wait for the network to change to any network, then send the data.

Another issue that needs a bit of work is the new /aslookup capability in beef. The fact this is currently served from beef, and is used to detect the network, may divulge the beef server to detection technology. The idea was to make this capability as small as possible and perhaps allow it to be quickly deployed to Heroku or AWS. This would provide another avenue of obfuscating the location of your beef server from network perimeter devices.

Currently the dormant-forward option can only run either 1 or 2 modules. The original nested-forward mode can run 1+n modules, but I haven't reimplemented the module insertion logic exactly the same, and have been trying to think of nicer ways to accomplish this with JS.

Due to these issues, the code is available in the airgap branch. But, hopefully after a bit more tidying up, this will be available in master.

You can download the presentation from here: https://un-excogitate.org/presentations/bsidessf2017-dormantdomination.pdf [PDF]

The demonstration video is here:

And a recording of my BSidesSF 2017 presentation is available here:

Keeping Up-to-date

Fri, 21 Jul 2017 03:00:00 -0700

One of my favourite questions to ask an interviewee is "How do you keep on top of all the security news?" Sure, it's not a technical question, it's not even really much of a cultural question. But given 1 or 2 minutes, I think this is a quick and interesting way to get an insight into how an individual seeks out information, and how this may influence their problem solving. Yes, it's often that candidates will describe similar methods, but you'll always be surprised by the occasional different technique, or even perhaps hearing of something new.

So, how would I answer this question? Easy.

First, is twitter. Yes - there is low signal to noise in the platform, especially if you follow a lot of accounts (like I do), but there are a few ways to manage this. I use a handful of private lists which I use to refine the accounts that I will generally check each day. These are broken into 'favs', which I absolutely can't miss. Then down into topics, such as Linux, or web app sec and so on. I've setup an IFTTT rule to email me all the tweets I Star (or <3). Once in email, I generally tag with a handful of labels, such as #ctf or #testing or #burp and so on. This provides a quick and easy way to see all the tweets in a specific category. This expands a relatively simple twitter feature into more of a database.

First (and a half), hearing people talking about things at work!

Second, I read a bunch of blog articles. These used to ENTIRELY reside in Google Reader (RIP). But now I find these are cross-posted on twitter, fav'd, once in my inbox, they remain there until I've had a chance to read them. Only once read do I archive the email. I also fairly regularly then redistribute this information out through more tweets, and through internal and external slack channels.

Third, Slack. I'm in 5 instances (a few more that I'm not active in) on the desktop version of Slack (yep, that's why I need all the RAMs). I often star posts or topics that people share.

Fourth, conferences - or conference recordings / PDFs etc. Often these will be seeded from when people start to tweet about their availability. Even if I attend sessions, I'm usually there to be entertained (i.e. the InfoSec Style or Presentation).

Fifth, emails. Or, email distributions. The only two that I really pay attention to are @DanielMiessler's Unsupervised Learning, and the Team Cymru Dragon News Bytes. Bonus points for Warren Ellis' Orbital Operations. This is the only email that I regularly look forward to and general read from top to bottom.

Of hackers and musicians

Sun, 28 Aug 2016 21:00:00 -0700

What qualities do you look for when you're hiring information security professionals, and in particular ‘hackers'? I won't pretend to be an expert at this, and certainly would prefer you read material from both Cory Scott and Thomas Ptacek on hiring talent if you haven't already. But I think I have a fairly good radar for identifying people that have the knack for being great hackers. Similar to Parisa's post, I don't think this has anything to do with certifications, and in fact, in many circumstances I don't think university degrees matter much either.

I find that two of the most important indicators are creativity and scrappiness. Two different attributes that aren't the easiest to measure. While creativity is not all that surprising (you think people breaking software aren't leverage tremendous amounts of creativity?), scrappiness is a little bit more obscure. Don't worry though, I'm not talking about scrappy or inconsistent work, I'm talking about getting shit done with limited resources. The idea of scrappiness is not all that unique to security, and has been referred to in a number of different contexts, for instance it's often seen as a critical attribute for successful entrepreneurs as well.

Hacking, both building and breaking, wasn't the first industry to leverage these qualities. In fact, we straight up stole them from all the other arts; painting, sculpting, music, writing and so on. As a drummer I find the parallels between hacking and music most interesting. Ask yourself this: how many of the hackers that you respect and network with are also musicians? Chances are a handful. If you're fortunate, it might be even higher. I'm finding that I'm not even that surprised anymore when late into the evening after a few beers (when security conferences get interesting) I'll find that some hacker I'm chatting with turns out to be a bassist or a DJ or an MC.

I definitely consider my approach to both drumming and hacking as ‘scrappy'. What does that mean? Firstly, after studying jazz for a year I spent a lot of time ad-libbing. This ability to think on your toes, or ‘wing it' is critical for both performing as a musician and hacking. Sure, musicians rehearse, or record to a click-track. But you'll find the good musicians are those that in the face of catastrophe can turn it around. Great musicians can recover from screw ups with no one even noticing. The best musicians don't need rehearsals to simply get on stage and create amazing music. Similarly, the ability to respond quickly to changes in your environment are the only way effective hackers can keep up. You think penetration testers just simply give up if they're thrown in the deep end with new technology to break? Of course not. They'll figure it out.

Secondly is that of ‘equipment'. In both music and hacking having top of the range equipment can help, sure, but great musicians (and hackers) can be amazingly effective with shitty equipment too. You don't need to spend big bucks on AppScan (or equivalent) to be great at finding vulnerabilities. In fact, most of the great hackers I know come in with nothing more than their browser and a bunch of hacked together scripts. Similarly, great musos can pick up any instrument and make it sing. I know the best gigs I ever played were often cobbled together with sub-par PA setups and no foldbacks etc. Thanks to open source software everything you need is freely available.

So what are you doing? Wanna be a better hacker, go pick up a guitar, build some tools and put them on Github, or write a short story. I'm also really interested to know about all the different ways you all keep your creative, scrappy parts of your brain ticking!

Brain from Primus drums on a POS kit h/t to @caseyjohnellis for the vid

How I Dumped Sublime for Vim

Mon, 15 Feb 2016 09:00:00 -0800

Like most people that spend a lot of time working in source code, I'm a huge fan of Sublime Text. Sure, for years @antisnatchor and @wadealcorn used to try and convince me to shift to RubyMine, or other IDEs, particularly when working on things like www.beefproject.com where debugging issues would get significantly easier. But as most of my work was done on an older model 11" Macbook Air, as soon as I opened RubyMine, the performance hit was too much, and I found myself back in familiar Sublime with a few terminal windows open for debugging, tailing logs and so on.

During my brief period of not working last year, I thought to myself: everything I do now in Sublime, while feeling very natural to how I work, is probably something I could do in Vim. Having now been motivated by @0x1c's transition to a full-fledged Vim-thought-leader, I thought I should write down some of the things I used to do in Sublime, which I now do in Vim, and the benefits I'm seeing.

I should disclaim though, I'm no Vim expert. I learn new things every week, and do have a few bad habits that I'm struggling to change. But this is one of the things I like about Vim, and there's a few people I know (in addition to @0x1c) that always do things that I see and go: whoa.

The other benefit of this period of transition to Vim is that in my new setup, I use a Macbook Pro for all my desktop work, but I have a dedicated Linux workstation with way more oomph than I need, which I do 90% of my development work on. While there are tricks that allow you to use Sublime directly on remote files via SSH (see Rsub), and NoMachine is great for responsive remote desktop, I've found it's much easier to simply use Vim over SSH. And this is where I introduce my second life-saver, tmux.

Similar to my transition to Vim from Sublime, my transition from using screen to tmux is something that I've only done recently (in the past couple of years). When I first started playing around with Linux, if you ever needed to leave a task or app running and wanted to be able to disconnect from the server, screen was the defacto way to achieve this. Tmux to me feels like screen on steroids. Particularly when it comes to window and pane management in a terminal environment. Using tmux is relatively straightforward, after you've opened up your terminal (I use iTerm2 on OSX), or SSHed into your server, you simply start tmux (or reattach to a previous session with tmux attach). By default tmux uses the Ctrl+b command for it's hotkey, a lot of people remap it to Ctrl+a to work the same way as screen, but I've just adjusted to Ctrl+b. So for instance, to detach from tmux you hit Ctrl+b then d. To see a list of available keys you can hit Ctrl+b then ?.

Tmux commands I frequently use:

Ctrl+b c - create a new window
Ctrl+b 1-9 - changes window
Ctrl+b n - changes to the next window (p changes to the previous)
Ctrl+b , - renames the window
Ctrl+b % - splits the current window vertically
Ctrl+b " - splits the current window horizontally
Ctrl+b z - zoom the current pane fullscreen - I use this a LOT to focus on a particular Vim session

View post on imgur.com

Tmux also has a command interface available in Ctrl+b then : Once in this mode you can execute longer tmux commands (of course you can re-map these too). One of the commands I frequently use within here is the movew -r command, if I happen to have exited out of a window and the numbers are out of order this renumbers the available windows in sequential order.

In general what I'll end up with is two iTerm windows, one with a tmux for my local machine, the other with a tmux for my workstation. To differentiate between them I've adjusted the status background colour to red on my workstation. This is done within tmux's config file, located at ~/.tmux.conf. On each of these I'll have multiple windows, usually named in the project or workspace I'm currently working on. More often than not, the window will be filled with Vim, but when I need to tail files, or run other commands, I'll use tmux split commands to split the window in half, or quarters etc. Moving around tmux panes is as simple as Ctrl+b h, j, k or l, similar to moving in Vim, mapped within my tmux.conf file. When I need to focus on just the development work I'll zoom that pane (Ctrl+b z). Tmux is great because it'll indicate in the window's name whether a pane is zoomed or not. This window splitting, focusing & zooming is primarily how I'll work within a particular project.

Enough about tmux, let's talk about Vim.

Firstly, the power of Vim, even without plugins, is astounding. Just look at some of the ridiculous things you can do here. Now, I'm not going to cover too much of the basics, but let me just say that over time, while I used to really enjoy the ‘tab' interface within Vim, I realised that it was just a poor-person's way of using Vim's buffers. To help navigate buffers, I'll usually use the CtrlP plugin (see below), but I've also installed the Buffergator plugin. Buffergator provides a <Leader> b command shortcut to open a simple list of open buffers. I'll often then use the Ctrl+n or Ctrl+p commands within Buffergator to quickly change the buffer in the active pane. And if you haven't played around the Leader commands, you can read more here (Thanks to @hipikat for talking to me about this years back).

To help install plugins, I use Pathogen, which allows me to simply git clone Vim plugins into ~/.vim/bundle folder.

The first functionality I liked in Sublime that I wanted to cater for in Vim was the file explorer. Now, I know that Vim has an in-built explorer, but I've settled on the Nerdtree plugin. Nerdtree is great, is opened/closed with Ctrl+n (in my config), and behaves much like a file explorer should. Within Nerdtree, I'll often use s to open the highlighted document in a vertical split, or i for a horizontal.

With regards to splits, I've mapped Ctrl+h or j or k or l keys to navigate Vim windows. Other window commands I'll use include window resizing, for instance to evenly size windows with Ctrl+w =, or to resize windows with commands such as Ctrl+w + or - to change the height, or Ctrl+w > or < to change the width. You can prepend a number in front of the +, -, > or < signs to change the size but that amount.

For those who have used Sublime for a while have likely come across Ctrl+p (or Command+p), also known as the Goto Anything capability. Great feature, and makes it very quick to open files in the current workspace or directory structure. Luckily, the ctrlp plugin for Vim recreates this functionality, plus a few extra things I use a lot. First and foremost is the fuzzy file searching, by simply hitting Ctrl+p and start typing the filename. I've also mapped ; to open ctrlp in buffer mode. This allows a quick way to find open buffers. From within the ctrlp interface, you move up and down the available options with Ctrl+j or k, and then open with Enter, or Ctrl+v for vertical split (x for horizontal). Ctrlp also allows you to select multiple documents, and then open them all.

Another great feature in Sublime is the search all file feature. This is where the ag plugin comes to the rescure. Ag is actually a frontend to The Silver Searcher, a code searching tool similar to Ack. Ag is a quick way to find references or other text quickly within the current Vim folder (you can see where this is by the :pwd command). To execute, you run :Ag! <searchterm>. I use the ! to not automatically open the first selected document, my preference is to use the Quickfix to navigate up and down with j and k, and then v or h to open the selected document.

The final feature which I occasionally use is Tagbar, this opens and dynamically builds a tags sidebar, allowing you to quickly see functions, methods and so on. The use of tags, and ag come into play is where I need to quickly find reference code, or where functions are defined. If you're fortunate and have all the libraries and dependencies in the same workspace, you can generate your ctag references from the shell ($ ctags -R .) and then simply Ctrl+] on functions to find their definitions. Often if this doesn't work, what I'll often do is yank the selected word or function into a register, and quickly drop that into ag for searching. For instance, I'll shift the cursor to the start of the word (b can quickly move the cursor for you), then yank the word into the unnamed register with yw. Then entering :Ag! Ctrl+r " <enter> will execute the Ag command, against the last item in the register. You can see what's in all your registers with the :reg command. Registers are super handy if you want to copy and paste different content around.

I'm likely to look back on this post in a year or so and have drastically changed my approach, but that's one of the great things about Vim.

Not that I keep it up to date, but some of my config is cloned to https://github.com/xntrik/dotfools

Enjoy!

Reflections on 2015 and LinkedIn

Sun, 20 Dec 2015 09:00:00 -0800

If I were to capture 2015 with a single word it would be: transform. The family and I had started the year celebrating our daughter’s 1st birthday, always amazed and in awe watching her continue to grow. Tenille was still re-integrating into her work-life pattern as a working mum, and we were surrounded by our best friends who were also undertaking incredible life changes, such as marriages, having kids and so on. Outside of family, things were getting very exciting at Asterisk as we were drawing more highly skilled talent to the team in our continued vision to bring pragmatic, passionate security results to our clients. All in all, life was humming along perfectly.

When the opportunity arose to join the application security team of LinkedIn my initial reaction was: this is a spam message. When I realised it was legitimate, my next immediate thought was that there was no way us, as a family-unit, would want to go through this sort of upheaval. But the opportunity was too exciting to not discuss with the family. To my surprise, Tenille was more excited about moving to California than I was! Even to this day I’m blown away with the support I receive from her. It was only at this point that I started to seriously look at what I had to do to make this happen. As the onboarding process continued my biggest concern started to weigh heavy on me; how was I going to part ways with Asterisk. Yes, it was emotional, but true to the character and integrity of each of my partners, Dave, Steve, Cole & Greg, they all saw the positive in what my family and I were embarking on.

It’s no surprise that the difference between Perth and the Silicon Valley, as far as app sec goes, is huge. It’s taken me a while to put my finger on it, but I believe I was starting to stagnate as an app sec professional back home. It’s not anything in particular, just the size of the security industry, the nature of the primary businesses (resources and mining, which have a focus on re-use, before buy, before build - and therefore not much of an application development focus) and the general focus on 'compliance' as a primary infosec tool. While a large portion of more tech savvy/Internet businesses have embraced the benefits of bug bounty-style additions to their security arsenal, as a level of measuring app sec maturity, it’s still fairly common for a lot of Australian businesses to be worried about any style of offensive application security assessments, let alone penetration testing or red-teaming.

This was why I needed to surround myself with the best application security people in Perth, and then subsequently Australia. Most of this is a result of another one of these pragmatic application security professionals, Wade Alcorn, who invited me to help out with BeEF 6 years ago. Working on BeEF opened my eyes to a few things, notably the importance of web app security and how complex web-browser technology has gotten, the impacts on attack surfaces, and also the power of open source software, specifically open source security software. I’m never happier than when I’m building stuff, and while I spend most of my time trying to break stuff, I’m a firm believer of the principle of ‘being a better builder makes you a better breaker.’ But without even realising it, I had an itch for something more.

Now that I’ve settled into the amazing security team at LinkedIn I want to spend a moment to focus on why it’s amazing. The culture of the company, filtering all the way down to the culture of the team, aligns very strongly with my approach to information security. In particular, getting shit done. I’ve never worked in a team that was entirely focused on application security in this way, with such unbelievable talent, and such drive to ensure that the team, and each other, succeeds. Back in Perth, I could count on two hands the number of people I would trust with the delivery of app sec capability. To be in a single team in a single company with the same amount of people is nothing short of inspirational. Every day I get up, jump on my bicycle, and ride to work looking forward to a day of learning new tech (at scale), breaking and fixing stuff, having copious laughs, insane perks (jam room, amazing food, free-transport, InDays, tools-of-trade, massages, and so-on), all supported by management who aren’t interested in focusing on what certifications you have - only interested in making sure that you can provide the best app sec expertise to the business as possible.

So here I am now, sitting in my pyjamas at home with the daughter running around my ankles on this month’s InDay, LinkedIn’s monthly day of focusing on important themes, usually combined with community outreach and on-site courses etc. Today’s InDay is focused on "reflection", and so this is how I’ve spent my morning. It’s a big world out there, don’t put up with the status-quo. Take intelligent risks, get out of your comfort zone and push yourself to the next level.

Facebook iOS App Scrapes Your Clipboard?

Sat, 17 Oct 2015 10:00:00 -0700

I noticed yesterday that the Facebook iOS app appears to scrape your clipboard for URLs, offering to paste the URL into your next Facebook status update. You can see an example of this at the bottom of this post. I wasn't alone in thinking that this felt a little creepy, similar sentiment appears to have popped up on reddit.

So what does this mean, and what can we do? Well, firstly, there isn't a permission to control access to the clipboard. The NSPasteboard Class is used to access the pasteboard server in AppKit used on OS X apps, while iOS uses the UIPasteboard Class. In iOS, this class can be used to access the General pasteboard used for copy-cut-paste operations (and has existed since iOS 3.0). What this means is that any app has a means to access items in your clipboard. This itself is not as much of as a surprise compared to the likelihood that I've never seen this functionality used in such a creepy way before. Apparently Pocket and Chrome have similar behaviors, just not that I've seen.

Why is it creepy? Well, for the App to know what is in the clipboard it has to pop the latest value, and determine if it's a URL or not. I did a few experiments and it didn't seem to scan beneath the item on top of the general clipboard. I.e. if I copied a URL, then copied a simple string, the feature wouldn't enable. In addition, after the app has extracted the URL, it doesn't often handle the same URL again, so the app itself may have an internal buffer. Data in the clipboard itself is either represented as an object (NSString, NSArray, NSURL etc) or a binary type. I'm assuming that mobile Chrome copies the selected URL as an NSString object as I used the text field select all and copy options, as opposed to the application's 'share' capability. If this is the case, then the Facebook app pops the top pasted object, and analyzes it (greps?) it to determine if it's a URL or not. Which means that the app is potentially accessing any strings in the clipboard.

URLs aren't the only thing I put in my clipboard. In fact, apart from URLs and other snippets of random content, other stuff I'm likely to copy and paste is content I can't remember, things like passwords (from a password management app) or one-time PINs. To assume that the Facebook app would do something malicious with this content is silly, but the fact that their app (and any other app) can access that content without user-interaction or permission is slightly unnerving.

So, should this feature be disabled? Perhaps. Should iOS have a permission ACL to limit which apps can arbitrary read the general pasteboard? Probably. Is this likely to occur anytime soon? I don't really think so. When I tweeted this, a few of the comments that came back included: use Facebook web instead; or, don't use Facebook you dick. Are these options I'm going to take. I don't really know. At least it's something to be mindful of. I can't imagine seeing this trend continuing without some kickback from privacy-minded people..so I guess we'll wait and see.

View post on imgur.com

Mentors

Fri, 03 Jul 2015 04:08:44 -0700

I've taken a bit of time over the past week or so to contemplate my life and how it is I've gotten to this point in my professional career. This opportunity for reflection came about in the calm before the storm. In a week or so, my small family and I are jumping on an airplane to relocate to California; stepping away from business-ownership and consulting life in Perth, Australia, to join an app sec team in a large "Internet" organisation. While the past few days of packing up the house have been frantic, I did get a chance to clear my mind and relax slightly after my last day.

In our industry of information security, and I presume in others too, it's unusual for people to accomplish anything without mentors. While I understand that the term can sound 'official', and may carry some baggage, when I talk about mentors, I refer to the formal and the informal. If you're lucky, you've worked somewhere where they have formal mentoring programmes, and while I do believe in their value, I think in the end the more informal mentor-relationships will yield stronger results. It's the relationships with these people where it's almost unspoken, but the message is clear: I want to learn from you.

Since I started working in the security field, about 12 years ago now - which is still fresh compared to many, I've had two distinct people I would call mentors. Lets call these people Peter and David. Because that's their names.

I was fortunate at university. A lot of people I studied with didn't directly go to work in the field. But during a computer forensics unit I met Pete, who was driven to expand his security knowledge from the physical-realm into the logical and so was taking a bunch of computer security units as a mature-aged student. Pete firmly believed that you couldn't protect physical assets (such as diamonds) without appropriate logical and IT controls as well. Just as university was finishing up he happened to have a position opening up in his team and he invited me to interview. Over the next 3 years, Pete took me under his wing and taught me so much. He brought me into the corporate environment and showed me how large enterprises work (politics and all), he really helped me understand the importance of quality and rigour, especially when dealing with high-value assets (be it expensive IT systems, managing downtime, relationships, business information and so on). He also introduced me to the wider world in ways I would never have imagined as a student - projects in Antwerp and the Arctic circle in the Northwest Territories of Canada. I wouldn't be where I am now if it wasn't for Pete, and his patience and willingness to teach me and challenge me in ways that university couldn't.

Towards the end of my time with Pete, I had a drive to learn more about pure information security, and while Pete was always a manager of mine - I would still consider him one of my most important mentors. I still understood the importance of physical security, but I had a passion for application development that wasn't getting itched. This is around the time I met Dave, and got my introduction to the exciting world of security at a bank.

While Pete had driven me to expand and broaden an understanding of networks, windows environments and digital security systems, my time with Dave really expanded the concepts of 'thinking like a hacker'. Through my career working with Dave I've only formally reported to him once, and while we never discussed his role as a mentor of mine, that's exactly what he became. Dave was the first person I met that demonstrated to me a clear process in divulging in something really fun and challenging, of breaking stuff. As the years flew by, he was probably one of the best people I knew that helped me turn my understanding of software into an understanding of how to break software, how to find vulnerabilities, and more importantly, how to describe these weaknesses to the people that could do something about it. No matter how often I'd shake my head at how he did things behind a computer, his strive for pragmatism has left a mark on my approach to security that I'll never shake.

When Dave asked me to start a security consulting company with him it was a no-brainer. The person that I was learning the most from was going to start something else, and I had to be there. It's gut-wrenching when I stop and think about leaving the company I helped start, but I've got that itch again, and when an amazing opportunity presents itself I'm generally not the kind of person that wants to look back with regret.

So if you want to become a better practitioner, try and understand who your mentors are, and do everything you can to leech as much of their experience and wisdom as you can, whether it be in a formal or informal manner. Don't worry yourself with whether their older than you or not, I've been constantly surprised with younger hackers I've met over the past year or so. Just find that person who inspires you to be better, and is willing to lend you a hand in improving yourself, and latch onto them.

Collective noun for 'hackers'

Fri, 12 Jun 2015 04:58:15 -0700

Sometime last year I pinged out on twitter what people thought were appropriate collective nouns for 'hackers'. There are a few that had done the rounds, the rest are collected here from various people.

I don't know why I didn't post this last year, but the conversation came up again on twitter (thanks @wireghoul).. so in no particular order, here they are!

A Cloud @mikeforbes
An Array @wince84 & @Ar0xA & @wireghoul
A Murder @VirtualTal (plus some offline peeps .. I'm unsure what these people are trying to say..)
A Cruft @bringer128 - apparently the top GOOG hit, from Eric S. Raymond (Thanks @wireghoul)
A Gaggle @Kxyne
A Con @lordparody (and a Conartist - the guy who does the advertising? - @silviocesare)
A 'Know-it-all' @TheColonial
A Vendor @TheColonial
A Buffer @TheColonial
A Fnord @TheColonial
A Fumble @TheColonial
A Heap @andrew_barratt & @wireghoul
A Drunkard @nanomebia
An Overflow @mdjnewman & @RobertWinkel & @sintixerr
A Cough @luddite_sue
A Permute (or Permutation) @TomSellers
A Cacophony @TheColonial < OJ is on a roll
A Horde @0x6D6172696F
A Kernel @TheColonial < he's pretty much unstoppable at this point
A Conference @jack_daniel
A Corporation @jack_daniel
A Trouble @jack_daniel
A Shot @TheColonial
A Bottle @TheColonial
A Crawl @TheColonial
A Hangover @TheColonial < now he's just saying random words...
A Bastard @rich0H
A Mischief @pipes
An Ugh @OaklandElle
A Heckle @Jofo
A Slosh @OaklandElle
A Coven @thedarktangent
A Den @thedarktangent
A Conspiracy @thedarktangent
A Hive @0x6D6172696F < you can see Mario is keen on alliteration.
A Schadenfreude @TheColonial < yep, OJ has lost his marbles.
An Escalation @nopulent
A Litre (41337R3) @Joflixen
A Disagreement @bonsaiviking
A Hacki @ethicalhack3r < although .. I'm unsure if this is what I think it means?
An Intrusion @psiinon
A Gaggle @securitysetup
An Exploit @hacks4pancakes
'Anonymous' @fabiospelta
A Packet @astcell
A 'Defcon' (According to Maria at the Rio http://it.toolbox.com/blogs/securitymonkey/lesson-learned-never-ask-strangers-about-defcon-lulz-edition-47809) @0x7eff
A Cluster Fuck @mattrix_
A Spoof @sintixerr
An AND @sintixerr
A Curiosity @sintixerr
A Flood @sintixerr
A Leet @munin
A Set @_ZPH
A Bar @dhw

Bonus points to @wireghoul for nominating that it's obviously a 'ring' of phreakers.

UPDATE 12:02pm
A cyber .. thanks 0x1c

UPDATE 12:52pm 13th June
A Stack @CaptainQwark and @greymaiden
A Hash @JPatONeil
A System @wireghoul (Did I miss this last time? can't remember)
A Packet @greymaiden (Once again, surprised this didn't come up last time)
"A Fix A Patch A Root A Snark Or, like alcohol, a Solution" -@marasawr < hahaha
A Bus @dlitchfield (Dave was surprised this hadn't come earlier too)
"A 2600 of hackers, a hacker collective, a community... ...actually, it depends on how they're organized (if at all)" -@XioNYC
A Foo @carmoca
A Kludge, an 'optimise' @mhackling
A Glitch, a Brood @pegasusepsilon (A Brood sounds like vampires?)
A Clan, a Band @paulpols

As is highlighted, this list could potentially go on .. FOREVER EVER ever ever...

Thoughts on 2013

Thu, 09 Jan 2014 10:29:04 -0800

I awoke at the start of 2013 and life was spectacular. I was a few months married (bank accounts reset), had put together a rough plan for honeymooning around the US and even started executing the purchasing of flights etc (bank accounts reset take two). I had also recently had some really interesting discussions with @WadeAlcorn regarding a potential "little" side-project, and of course all the other bits and bobs I was spending time with, various Rails, jQuery and AWS projects. I can't forget to mention my continued efforts on what I was doing in the 9-5, providing the absolute best information and application security consulting advice and services to our customers that I could.

On the personal front, 2013 saw my love and adoration for my wonderful wife Tenille continue to grow and flourish. We had our highs and lows, moments of despair and absolute joy. Some of the best times of my life I've experienced over the past few years, and 2013 was no different. Our trip to LA, Portland, Seattle, New Orleans and Hawaii was nothing short of absolutely spectacular. We got to experience some fantastic music events (The Bronx in their hometown, LA, in an amazing art deco theatre; Local Natives in a 100 year old ballroom in Portland; The New Orleans Jazz Festival), some fantastic meals (in particular the cuisine we sampled in Portland and New Orleans), some breathtaking beers (once again, thank you Oregon you wonderful state of beer) and amazing scenery, particularly in Hawaii.

Shortly after returning home we were welcomed with the news that we would be having a little baby within about 9 months. With excitement and trepidation we both knew that our lives were about to change for ever.

Throughout the entire year I also found myself spending more and more time on that side-project with Wade, co-authoring the Browser Hacker's Handbook. Working so closely with Wade and Michele @antisnatchor was also filled with amazing highs and lows. As far as challenges go, working on this book has easily been one of the more difficult things I've been involved with. Not just from a research point of view, but re-discovering how to apply a high degree of rigour in writing in a consistent, concise and clear manner. Oh, and lets not forget the endless cycles of reviewing and reviewing and reviewing. I would be lying if there weren't a few moments where I wanted to throw in the towel, but working with these two brilliant security researchers and professionals (not to mention the other talented contributing authors and reviewers we've been fortunate enough to get involved) has been such an amazingly fulfilling experience I'm glad I didn't. Over 1,100 emails and 2,000+ commits later and the book is getting very close to completion.

On other projects I continued my efforts with BeEF (various back and frontend commits, with a focus on the rex console UI, (mobile) browser detection, LastPass SE modules, and an implementation on the WebRTC internal IP detection).

I also released my first version of the SAMM Self Assessment tool, which immediately got some interest from the OpenSAMM project leads for further inclusion with the official OWASP Project. I really enjoyed hacking this together, not only because I got to spend some time with jQuery, but also getting a really good opportunity to play with deploying and scaling this Rails app on AWS services with the excellent Rubber tool (a cloud-wrapper for capistrano). With a few clicks of a button I'm able to scale app servers and DB servers, and then add/remove them from the Amazon's Elastic Load Balancers. Combine this with S3 and CloudFront to provide a CDN for all the static assets (once again, automatically pre-compiled during a deploy to EC2) and voila. I must admit, it was really fun to spend some time seeing how the app would go throwing loader.io against it.

I can't forget the ongoing maintenance of the Devise Google Authenticator gem for Rails' Devise. Hopefully one of the quicker ways to provide 2FA to your Rails apps. The GH project has 83 stars and the gem has been downloaded over 7,000 times from rubygems, so that's not too bad.

I've also been spending a fair amount of time working on a simple threat modelling application, but you'll have to watch this space for more on this throughout the year.

On the professional side of my life Asterisk has continued to grow and grow. We're in the process of moving into new premises and we've grown by a couple of excellent consultants too. Our first employee is not only someone I deeply respect, but I would consider a good friend, so I'm super happy that Jarrod agreed to dive into the exciting ocean of boutique information security consulting with us. We've been beating our targets, and things are feeling really positive, I'm very excited to see how we continue to grow in 2014.

2013 ended on the highest peak when Tenille brought our little baby girl into the world. We've only been home with her for a few days now, but I'm so amazed with how well both she and Tenille are doing.

Here's to 2014 being even better!