Anyone spending a decent amount of time in Kali is going to want a GUI code editor, and they’ll probably want something a little more advanced than gedit (which is currently unmaintained as of writing). My preference is Visual Studio code, though others swear by Atom or Sublime Text.

Visual Studio Code running in Kali Linux

Since Kali is a Debian-based distribution, you can add it much as you would Debian or Ubuntu:

If you have previously installed the VSCode .deb package, you will likely get some warnings that dpkg can’t remove some directories that aren’t empty, but this won’t interfere with the operation of the program. You will get a warning each time you open it as the root user, since that’s generally not a good idea on most systems – I haven’t found a way to suppress this thus far, but maybe that’s not a bad thing.

I’m recording this because I haven’t come across any other good explanations in my googling. If you are using WSL for web development, it’s likely that you are going to want to install mysql. Unfortunately, when you run it, you start to get errors like “Can’t start server: Bind on TCP/IP port: Address already in use”. If you do get these, it’s most likely because you’ve followed a set of instructions and skipped something in the preamble – you need to be on the latest version of windows.

I assume you have joined the Windows Insider Program, and installed WSL in the first place. Next, make sure you have the most recent version of windows using the upgrade tool.

Once that is installed, and you have been through many reboots, upgrade WSL:

If you run into any problems reinstalling mysql, it might be this bug, and you can find suggested solutions in the comments. That got it working for me, but if you still have problems, you can always reinstall WSL from scratch by opening an administrative powershell window, then running lxrun /uninstall , then lxrun /install . Remember that if you have installed MySQL for windows, you’ll need to run WSL on a different port (change in /etc/mysql/mysql.conf.d/mysqld.cnf ), or uninstall it.

(First posted on the Agile Australia blog, 19/07/2017)

At least once a fortnight I find myself filling out a Request for Proposal (RFP) describing my team’s development approach, and how we secure our Systems Development Life Cycle (SDLC). We have a formal security framework; they’re great for filling out RFPs. When you are trying to build products in an agile format they are less so. The traditional process looks something like this:


Traditional Secure SDLC


Security is often an afterthought and never bolts on as well as when it has been considered from the start. This is to our advantage as well – we want each iteration to be shippable, and the sooner we can find issues, the cheaper they are to fix. Fortunately, with a little thought, building with security can become an agile process itself. Consider the following:

Incorporate Threats with Personas

If you use personas, try adding some who don’t have your best interests at heart. A few of these will be example attackers, along with the motivations they might have for hacking your product, and others will be legitimate users. Try including the potential harm that your authorised personas could inflict unintentionally, such as deleting the wrong information, or setting a password of ‘123456’. Ideally, your product should protect the personas from themselves. If you do UX research, consider asking users questions about mistakes with sensitive data that the software has allowed them to make.

User Security Stories

Incorporate User stories that model the behaviour the product should have: e.g. “As a user, I want my information to be private so that other users cannot view it”. Also, consider the attackers as sources for stories – e.g. “As an attacker, I should not be able to deny access to the site, so that legitimate users can reach it”. The stories don’t need to define the controls to be implemented, so they can be written without technical security knowledge, and focus on the behaviour that’s important to users. The team can then decompose the story into specific technical requirements as the backlog is refined.

Definition of Done

Include security criteria into the Definition of Done. This is a good opportunity to include minimum security criteria (the OWASP Proactive Controls are a good reference for this) on input validation and other common security issues that should always be considered. This provides clear guidance on what should be in place before a feature is considered shippable. You will need to walk a fine line between adding too many implicit security requirements, and breaking security jobs out into their own stories so that you can still break your backlog down into manageable chunks.

The team should evaluate the delivered code at every Sprint Review, and have the authority to decide if they are done. This allows people with the best technical understanding to make a decision on whether the product is safe to ship. If all the security criteria have been met, then it’s up to the Product Owner to approve any residual risk before the iteration is shipped, or to add further backlog tasks to address those risks.

Avoid Bottlenecks

Security adds overhead, so to keep the process as lean as possible, automation needs to be used wherever practicable. Static code analysis should be incorporated into the build process so that it becomes part of the engineering process. This brings the discovery of common problems into the developer’s IDE and allows them to be fixed much faster than the same problem discovered in testing. Security should then be considered during manual code review to catch the issues that static analysis cannot find.

Automated tests should be written to verify controls in the business logic so that each user can only perform those actions they are supposed to. Further automation should include fuzzing and vulnerability scans, though this may involve changing products, as only some support being scripted into a CI/CD process.

There is quite a bit of work in setting all of this up, then tuning it so that you aren’t overwhelmed with false positives. You can’t build a massive verification infrastructure before actually working on the product, so adopt the agile approach for this too, and iteratively improve what you have automated in each sprint, then maintain it once it’s in place.

After Delivery

Regardless of what process you use, once you release your software into production, you need to have an incident response plan in place. This is likely to involve every part of the business, and for the team building the product, it means thinking through how issues will be identified, escalated, fixed and redeployed. This becomes a DevOps process and may be handled by a different team, but ideally, it should not be. It’s important that the team takes ownership of security, and learns from any incidents that occur.

Meaningful metrics in software development is difficult, but you need to be able to measure the impact that you are having. Some practical metric examples include: mean time to fix security bugs found in production, mean time between failures/application crashes in production, and mean time to recovery afterwards. You can produce many objective metrics from code analysis tools, but unless you are bringing a legacy codebase into line, they provide limited insight.

Hopefully, some of these ideas will resonate with those who are moving away from a process heavy security SDLC. As a parting thought, having a dedicated specialist in your sprint teams is ideal, but you aren’t going to get anywhere if security becomes that one person’s problem. Everyone needs to be aware of it, everyone needs training, and it needs to be a team responsibility.

Resources & References:

Last week in the US the FCC privacy regulations were repealed, which, amongst other things, allows ISPs to track your internet usage and sell it to third parties. It’s a good time to think about privacy.

Windows 10 doesn’t have the best record on privacy. Most app teams need to get data about their users to improve their products, and Microsoft is no different in that respect. If you want to look deeper into the issue, you can read Microsoft’s reasoning for their data gathering, and the EFF’s criticism of it.


Improve your Windows Privacy

There are multiple tools to turn off Windows 10 telemetry, depending on what services you are prepared to go without. There is a slightly melodramatic naming convention for these tools that ever so subtly hints at what their authors might say on this topic if you got a few beers into them.

  • Destroy-Windows-10-Spying adds host entries to block telemetry servers, and shuts down a range of Windows tasks that try to report your data
  • O&OShutup10 gives you a fast way to disable all the privacy affecting settings in Windows, and provides guidance with each one. Don’t tick everything, especially the ones with red exclamation marks next to them
  • fix-windows-privacy will disable a wider range of tracking via the registry, including removing OneDrive

Remember to run these after any major Windows update, as Microsoft has turned tracking back on with some of these in the past.

If you have an NVidia card, they send telemetry home as well, but it seems to be mostly harmless so far. Instructions to turn it off are here.

Depending on where you are living, the sites you visit may also be logged by your ISP, for government use. In Australia, that metadata is held for two years, in the UK it’s 1-2 years, and if you live in the US it’s now a commercial product that can be sold to, well, anyone really.

A VPN is the only real defence against this, but it is of limited use if you still refer to your ISPs DNS for name resolution. You can lower the amount of data collected about you by selecting a DNS provider that does not keep logs, and uses the dnscrypt protocol to sign communications, making the responses harder to spoof. Note that dnscrypt does not provide privacy without a VPN.

For a simple solution, you can change your DNS servers to OpenDNS or Google DNS. Both keep logs, which isn’t ideal, but they aren’t exactly known for handing them over. A better solution is Simple DNScrypt, which gives you non-logging options, and implements the dnscrypt protocol


Improve your browser privacy

Your browser broadcasts a lot of information. If you are signed in on Facebook, and you visit another site that has placed an link on their page, Facebook knows about it.

There is a ‘Do Not Track’ setting in most browsers these days, but the best approach is to install EFF’s Privacy Badger extension, which will detect and block sites tracking you. Privacy Badger is available for Chrome and Firefox. If you use Safari, consider installing Ghostery instead. What if you’re using IE? Stop using IE. There. I fixed it for you.

While you are there, you should install HTTPS-Everywhere and uBlock Origin (Chrome / Firefox) to remove potentially malicious ads and upgrade insecure connections where possible.


Improve your social media privacy

Make sure you are happy with the list of apps connected to each of your social media accounts, because each of them is likely to be recording as much information as possible.

And if you live in the US, I’d also recommend opting out of the various services who index information on you from publicly available records. This article eloquently explains how to do that.


The last point I’d make about privacy is that it’s something that is important to maintain, even when you have nothing to hide. If 99% of mail was postcards, envelopes would be suspicious. There plenty of people with legitimate reasons not to want their privacy invaded, and by protecting your privacy, you protect theirs.

I recently decided to change my laptop over to Kali Linux. The Dell XPS 15 is a great laptop, but it has had a number of issues running Linux over the last few months. This time around it seems there have been enough upstream changes that you can get Linux running smoothly enough for everyday use.


Before you start

You need to change the following two settings in the BIOS. Now is a good time to set a BIOS password if you haven’t already.

  • BIOS > Secure Boot > Disabled
  • BIOS > System Configuration > SATA Operation > Switch RAID to AHCI

You can still upgrade the BIOS using the boot menu and a flash stick, but versions 1.2.10 through 1.2.16 of the firmware have been associated with a series of bugs, so if you are going to update, make sure it’s to 1.2.18.



Install Kali Linux with a USB. I used rufus on Windows to DD a copy of the amd64 ISO directly onto the USB stick. I chose to use the whole disk – I’ll virtualize Windows rather than dual boot it.
Whilst installing, you will get a request for additional firmware – brcmfmac43602-pcie.txt, which I’ve been unable to find. Some guides reference using brcmfmac43602-pcie.bin instead, but the installer doesn’t accept that in place of the .txt file. Regardless, wireless works fine, so I’ll figure that out later.
After the initial installation, make sure your installation is up to date.

This will take some time, and it’s worth rebooting afterwards.


Since this laptop has an intel and nvidia graphics card, installing optimus will allow you to access the nvidia card for those programs that require it. Reboot after installing. In my case I had to reboot twice – it failed to boot the first time for some reason.

Once that’s done, it’s time to update some config files. Firstly, edit /etc/bumblebee/bumblebee.conf and change line 22 from:

Then run ‘lspci | grep NVIDIA’ to get your graphics card’s BusID. Mine is:

Then edit /etc/bumblebee/xorg.conf.nvidia, uncomment the BusID line, and update it if yours is different.

This should get everything working. You can see the two cards working by running:

If you run glxgears with both, you’ll notice the performance is about the same, which isn’t right. To fix this, install VirtualGL, which has to be downloaded separately. Go to and download the latest amd64.deb, and install it:

After that, you can run glxgears / optirun glxgears, and you should see a noticeable difference. If you have an everyday user account you want to use in a similar fashion, you’ll need to add it to the bumblebee group. This now gives you the ability to use the nvidia card for password cracking, but note that in most cases, offloading password cracking to a cloud instance is a better approach than running it on a laptop.



So that the OS can tell the temperature it’s operating at, and control the fans, you will need to install lm-sensors, and activate them

When sensors-detect asks if you want to make changes to /etc/modules automatically, say yes.


The hidpi display is readable in its initial state, but I prefer some scaling. Open up gnome-tweak, go to fonts and set the scaling to 1.25, then windows and set the scaling to 2.

In a similar vein, to avoid a tiny GRUB screen, edit /etc/default/grub, and add GRUB_GFXMODE=640×480. Once that’s done, run sudo update-grub. Higher resolutions are available, but they don’t look great.

QT programs, such as VLC will also render with tiny controls. You can improve this by creating a script in /etc/profile.d/, called In that file, put:

The end result isn’t perfect, but it’s very usable. See this article for more info.


Everyday user

Some programs (VLC, Google Chrome, Visual Studio Code, etc.) object to being run as root, and I want to use different programs depending on what I’m doing, so I create a normal user for daily use.


And that’s it! Kali should be ready to fill with your preferences and utilities of choice. If I run into any further issues, I’ll update this article.


Security ‘hardening’ is the process of raising the baseline security of a device. I harden every device I use. It’s not my intention to provide a hardening guide here (I’ve linked several good ones at the end), but I did want to go through some of the resources available if you need to do this for a group of computers (your organisation, for example).

Locking things down

When most people think of security hardening, they picture covering the basics – uninstall programs that aren’t needed, install the ones that are, get any available updates and add an antivirus program. Hopefully this includes a fresh windows installation, checking the BIOS settings, adding some sort of full disk encryption (Bitlocker, FileVault, etc). Depending on your approach it might also include EMET and a variety of vendor-based solutions.

But where do you go from there?

There are an number of settings you can change to improve security in Windows 10, but some of them will be reset any time there is a major windows upgrade. The one type of setting Microsoft seems to honor over time is anything set by Group Policy Objects (GPOs).

This should be familiar territory for most systems administrators, any you can get secure baseline settings for each Windows 10 build from Microsoft at their Security Guidance site. Be aware that, depending on your requirements, Microsoft’s settings will probably not go far enough, since they want to get telemetry from your systems. This isn’t sinister, but it should be understood.

This makes a good starting point and the next steps should be to source additional settings advice from a the below organisations, then finish with a manual inspection of the policy settings.


Building a Baseline

Various Governments offer advice on what a secure baseline should look like. Settings/GPOs are part of this, but aren’t the only steps that should be taken. Here are some guides from the countries I currently deal with:


The Australian Signals Directorate provides high level advice in the form of their Information Security Manual, but once that gets down into details, it directs the reader to the Whole-of-Government Common Operating Environment build guidelines, the public version of which is only for Windows 7 SP1, and still in draft state. This is apparently produced by the Department of Finance, whose cyber security credentials I am unaware of. In practice, I expect the ASD consults directly with the organisations they are protecting, rather than publishing their defaults.



The NSA has provided a significant quantity of advice, including information on Windows 10, broken down into short advisories. Unfortunately this doesn’t provide a comprehensive blueprint for building a security baseline, unless you want to read all 112 documents and assemble something cohesive out of them.

Also produced by the US government, NIST provides baseline settings, including importable GPOs, but it doesn’t yet include Windows 10. NIST also produces a range of standards (SP 800-53, etc) which are considered an industry benchmark, but they are also some of the least readable.

The USA is also home to a non-profit organisation, the Center for Internet Security, which does produce baselines for Windows 10, including importable GPOs. This is the best advice I’ve found thus far.


Probably my favourite of the government guidance websites, the UK government’s National Technical Authority for Information Assurance (CESG) has produced a readable Windows 10 guide. It’s still relatively bare-bones, and doesn’t include importable GPOs, but it’s still ahead of the curve, since it actively attempts to communicate the risks and solutions in a concise format.


Manual Review

Once you have a My preference is to build a custom baseline that fits what you do (Press Win + R and run gpedit.msc to review individual settings). A quick walk through google shows a range of resources for Windows 10 hardening, but if you take one at random, you are trusting that they are complete, and correct. That’s not to say they aren’t of use, but confirm everything before you add it to your baseline configuration. If you are thinking this sounds like a lot of work to do and keep up to date, you are correct.

If you are just securing your own machines, consider Tron Script as a starting point.


Securing the User

Ultimately, the easiest point of attack will always be the user. There is a limit as to how much you can do this via a secure baseline, but you can enforce policies on access, on mobile devices, etc.

If that user is you, you should at a minimum be using a recognised, commercial VPN when outside your home/office network, and enable two factor authentication (2FA) for any service you use. I tend to advise people to start with the least important services first, since that increases the chance the user will cover off all their social media accounts. has a comprehensive list of what services can have 2FA enabled, and via what methods. If you are securing a group of other people, then there is significantly more to do, which is beyond the scope of this post.


Rolling it out

If you are imposing these limitations on someone else, then make sure they are involved in the decision process, and accountable for the end result. You can add a significant amount of protection without sacrificing much usability, and if you start with a locked down baseline, and roll back protections depending on what is required, you can achieve a reasonable compromise. Lastly, make time to keep it up to date – these things change.


More info:


PCI DSS is the Payment Card Industry Data Security Standard, and it is required for any merchant, payment processor, or service provider that interacts with cardholder data. I recently went through the process of implementing this standard, and I thought I would share some of my observations on the process.


Do your due diligence – Several times I heard statements to the effect of “Surely XYZ payment provider is compliant – they’re owned by a bank!” and I found myself nodding in agreement. Then on checking the VISA and MasterCard websites, it turns out that some of the people who claim to be compliant are not. Maybe they were once, but it’s a big process to keep up to date with new versions of the standard, and clearly not everyone does it. The chain of compliance in PCI isn’t always as good as you would expect, so check who you are working with. Often it’s just a difference between trading name and the registered PCI name, but you don’t know unless you find out.

Similarly, I had assumed an existing secure architecture would be able to be plugged into PCI DSS without much modification. It didn’t turn out to be that simple, and a lot of reasonable assumptions we had made about our vendors turned out to not be entirely correct. For example, I learned that Azure SQL databases can’t be firewalled from Azure services owned by other customers, including people who set up a new trial account. There are other means of performing traffic isolation, but that isn’t something you want to find out just as you are going into implementation.


Communication is oxygen – Emotions tend to run high when change occurs, especially with a security framework  that most stakeholders won’t understand unless they have taken time to read it, which isn’t a realistic expectation. Without frequent and tailored communication, It can seem to others that PCI threatens their productivity and the stability of their processes.

This applies to external stakeholders too; depending on their familiarity with the standard, they may need to be educated on what they need to provide. If you can give effective, concise information to the people maintaining those relationships, then the process of ensuring stakeholders are compliant can be made less combative, and will happen faster. With PCI DSS, this can add up to a big impact on the overall length of time it takes to become compliant, since your company is only one part of the puzzle.


Don’t write a novel – Reams of documentation are not necessary; effective processes are. I’ve come across a number of people who champion putting together a giant slab of documentation, to cover every possible scenario. If your aim is purely certification, then that is an approach that will get you there. But people don’t read giant slabs of information, especially about security. Build a central matrix of where you meet the compliance documentation requirements, then locate the instructions for each process with that process. If you can back this up with workflow automation and some well thought out procedures, your policies will be followed because they are the path of least resistance.


Whilst compliance isn’t the same as security, PCI DSS does create a good baseline to work from, and is a reasonable standard to hold other companies to. Where you go after that depends on what your company needs from its security program, but before you move onto another standard, consider some basic steps such as using a vulnerability scanner on your full internal network, not just your CDE. Compliance works best when it’s partnered with practical tests.


More info:

I’ve spent the last weekend attending Ruxcon 12, which is a technical security conference in Melbourne. For the benefit of those who weren’t there, and because it helps me consolidate my own thoughts, I’d give the following review.


Ruxcon 12


All of the presentations focused on technical detail, and ranged from being quite accessible through to highly specialized. One example of an accessible presentation was a talk by Jack Forshaw of Google’s Zero Day Initiative, who ran through how he had downloaded documentation from MSDN and searched it for API calls with ‘reserved’ parameters for future use. These calls are a fruitful hunting ground for vulnerabilities, and he walked through the process of using differences between the documentation and implementation that lead him to reporting two zero days to Microsoft. On the other end of the scale, there was an excellent fuzzing presentation by Richard Johnson of Cisco Talos who presented a fuzzing framework that has recently incorporated IntelPT (Process Trace) and American Fuzzy Lop, which would be hard to follow for anyone not already somewhat familiar with the area.

The conference is two days in length and was held in the CQ function centre on Queens St. The age profile of most of the attendees ranges from early twenties to late fifties, with the majority clustered around late twenties, early thirties. Most people were quite friendly, though if I’m being honest, the crowd was light on extroverts. There are lots of pentesters, incident responders and reverse engineers.

Is there much here for someone who isn’t directly working on the tools? I would say yes. Most talks featured demonstrations of recently found zero days, and describe the research process in some detail. For anyone who hasn’t had much experience on the red team side of things, it’s a very useful perspective to add.

Some of the presentations don’t provide actionable information (unless you are reverse engineering malware) but they do give an interesting look behind the scenes at some of the services we use in enterprise. For example, Sean Park of Trend Micro gave a presentation on using neural networks with Fourier transforms to detect malware. He ran through how malware is normally detected in ‘outbreaks’ being transmitted over email, and how they go about building a template to detect that malware. Building these templates is made extremely difficult due to the metamorphosism built into the malware, which is where his research has been applied. His team have captured over 2000 binaries using honeypots, and uses a neural network that leverages the Fourier transform to compare machine behaviours to identify the same malware with different patterns.

There were talks on infrastructure, such as a presentation by Trevor Jay from Red Hat on the recent vulnerabilities that have been found in containers, and what defences containers add or expose.  The overall thrust of the talk was to persuade the attendees to go bug hunting, as the codebase for containers is still relatively immature, and the bugs being found are still large and to some extent reasonably basis. For those who use VMs rather than containers, there was a presentation by Qiang Li of Qihoo 360 on QEMU escapes that identified 50 bugs in the last year, 30 of which have resulted in CVEs. Layered defence is probably the key takeaway here, with Trevor Jay suggesting that if you need to use containers in a multitenant environment, having one VM for a container may be inefficient, but it does provide the isolation necessary to have confidence in preventing an attacker from moving laterally between containerized applications.

One of my favourite presentations was on the topic of dangers within AWS, presented by two Atlassian employees, Daniel Grzelak and Mike Fuller. They outlined a range of issues, from users mistaking the AuthenticatedUsers group to be their users as opposed to all AWS accounts (including new signups), to assumptions in security via roles. When you grant a 3rd party a role within your account, you are actually granting anyone in their account access to that role, including anyone who they have granted access to a role within their account, and so on. Worse, role assumptions are only logged in the assumer’s account, so you will have no logs of who is assuming that role within your environment, except that it happened. They also detailed issues such as cloud trails not logging a number of things, including Route 53 calls and Lambda functions, and some of the dangers of using pre-canned AWS roles, which can be updated to include permissions to new API calls when Amazon updates them, even if you never intended the 3rd party to get them.

If you haven’t been to a convention like this before, you should expect presentations with a lot of code examples in c & python that interact directly with syscalls, as well as a lot of dissassemblies. If that isn’t your thing, don’t let that scare you off – many of the presenters summarise the information presented very effectively.

If anyone is interested in going to Ruxcon next year, let me know – it’d be great to meet up.


More Info:

Checking things at part of due diligence is rarely the most fun activity in the world, but it does have a habit of turning up some surprising things. I’ve been doing some compliance checking for PCI DSS recently, and it turns out a lot of the providers I thought were PCIDSS compliant (and claimed to be) aren’t.

MasterCard and VISA (doesn’t work in Chrome) both maintain authoritative PCI DSS lists, so if you use any payment providers, it’s worth checking them in there. A lot of the institutions that we take for granted must be compliant are no where to be found on that list. I was surprised to find that Microsoft Azure isn’t on that list.

It turns out there are extenuating circumstances in Azure’s case, and they have been audited to the standard by Coalfire, they just aren’t part of the program… I do feel like there is some marketing spin in there somewhere; my suspicion is that all-windows infrastructure doesn’t lend itself to single-tenanted environments on the scale that Azure needs to achieve, so they probably multi-tenant a lot of their systems more than PCI DSS is comfortable with.

The other thing that has got me thinking is the discovery that Azure SQL servers can be connected to by anyone inside Azure, whether they are part of your organisation or not. As stated in Azure’s documentation:

To allow applications from Azure to connect to your Azure SQL server, Azure connections must be enabled.

Theoretically that means anyone could spin up an Azure VM and try and connect directly to your database, something which most enterprises would be deeply uncomfortable with. I still haven’t formed any long term conclusions, as this is still something I’m researching, but it is food for thought.

Due diligence is not something to skip.

The unthinkable has happened, and it looks like linux is coming to Windows. I think a lot of people have imagined what the conversation was like where they decided to do that. It’s a great idea. The Microsoft of old positioned Linux as a competitor, but really it’s just a tool, and one they can add to their toolset in a way that no one else can. Having a separate blog on Cygwin doesn’t make much sense in light of this news, so I’ve imported all the posts, with the intention of continuing my main blog on things that interest me; technology, security, digital trends and cat pictures.