I’m old and a social media junkie. I ran a BBSs in the late 80s, built and ran dozens of community forums and websites since the 90s (some of which are still going strong today), I blogged on Mono before the term blog was coined and live journal existed, I was on Facebook back when you needed a university email address to access it and my twitter account dates back to 2008. I even spent 6 years working for one of the leaders in online content moderation, working with many world renowned brands with colossal global userbases. I’ve seen virtually every type of online community and witnessed the widest possible range of attempts by those communities to tackle toxic users of every kind

Do you know what I’ve never seen? An entirely effective way to manage toxic behaviour, other than running what is essentially a very small online gated community of very similarly minded people. I’ve not seen a single solution that works at scale.

The oft-touted solutions, especially for global platforms like Facebook and Twitter is mandatory verified ID. This on the face of it seems like a great idea, surely the world would be a better place if people couldn’t hide behind anonymity and had to publicly own their opinions. There are just two problems with it, it doesn’t fix the problem and it puts a whole bunch of vulnerable people as risk.

Why doesn’t it fix it? Well whilst I’m not disputing Penny Arcade’s G.I.F.T theory (warning: possibly NSFW language), that if you take a normal person, give them anonymity and an audience then you end up with something altogether different, what it doesn’t cover is how much the anonymity is needed if the person isn’t absolutely “normal”.

I’m writing this blog the day England lost in the Euro 2020 finals to Italy and rather than blame the defeat on out lacklustre second half performance, some people took to twitter and blamed it on three young, black, players who failed to score in the penalty shoot out that eventually decided the competition.

But the tweets that hurled racial abuse at the players weren’t coming from an army of hard to trace anonymous sock puppet accounts, these were coming from easily identifiable real people. People who listed their employers in the bios, who mentioned their wife and kids in their previous tweets. Anonymity made zero difference.

And this isn’t a one-off, generally these attacks aren’t well pre-planed campaigns where users are attempting cover their tracks, they are angry spur of the moment things done in the open. Tracing them is rarely hard (even without the help of the platform or the police), it’s convincing the CPS that it’s worth chasing for a conviction that’s the problem.

I’ve moderated public forums, where not only are people using their real names and have disclosed their real home addresses, but actually regularly meet up in person, where this toxic behaviour is still rife. The people responsible generally don’t feel they did anything wrong and if they did, nothing will actually happen to them.

There is an exception to “anonymity solves nothing” and that’s in the case of organised pre-planned trolling and cyber bullying. In these cases the perpetrators too often rely on anonymity and yes a platform with strong verification processes may be less of a target, so why wouldn’t we do it?

Simple. The cost. Not the financial cost, that’s easily absorbed, but the cost to other users.

Social Media has been a massive tool for self help and peer support, especially in situations where people may not feel comfortable discussing their issues with their own peer groups. from the LGBTQ+ community to people questioning their religious upbringing, from people in abusive relationships to those scared about not understanding parts of their job others assume they know, and those seeking help with an addiction or simply unable to find better mental health support; anonymous communities have been a haven for people who feel it may have a detrimental impact on their real lives if their online persona was associated with the real life one. Currently they can escape to a whole new world online, knowing that those who would look to hurt or ridicule them could obtain little more “real world” info on them beyond burner email addresses and phone numbers.

In the UK, since 2014, online services that allow user generated content have been legally obliged to facilitate anyone who claimed they have been defamed to get in contact with their alleged defamer. I’ve been involved with multiple cases where knowledge of this law has be used as a mechanism to obtain contact details of potential victims (generally of harassment) and I’ve been very glad that all I can provide is a gmail address.

It’s obvious why storing additional personally identifiable information (linking back to real world details) would be very dangerous in this situation. Not to mention what would happen in the case of a data breach (please don’t come at me with “technical controls” for this, that’s my day job and I stand by, the more data you hold, the more data you can lose).

Where anonymity isn’t possible, terrible things can and do happen, I’ve had a project colleague forced to move out of their home and into a hotel as racially motivated death threats against them were deemed credible. I’ve had a friend physically assaulted in front of his family as he was (wrong it turned out) identified as a social services worker involved in a child being placed into care and I myself have had a vexatious third party instruct his lawyers to send legal papers to my employers (claiming he couldn’t find my address, despite it being clearly listed in multiple places). Why on earth would we make this EASIER to achieve, especially when the targets are particularly vulnerable?

So, is pushing a few trolls off a few platforms (it won’t stop them, it’ll just limit where they ply their trade a little) worth placing all those vulnerable groups who rely on anonymity to seek help, at significant risk?

I’m not advocating that every platform should support anonymity, there is a place in the world for both anonymous and verified ID platforms, what I’m against is removal of the ability to choose. Both already exist in abundance, covering every possible niche and thanks to COPPA Verified Parental Consent (so by extension, that includes ID) is common on platforms permitting under 13s and on the other side many services simply require an easily obtained free email address, so if one or the other is the obvious solution, why do the masses continue to use this middle group where a level of anonymity is still possible, but the platforms discourage it, not for online safety reasons, but because your online personal data is worth so much more when it’s associated with a real life persona?

So when the noise has died down, the likes of the BCS have stopped jerking knees and start talking to the experts they have amongst their own members, and the pros and cons are are being discussed in parliament (which I feel is inevitable) I expect there will suddenly be groups of influence and power pushing for mandatory verified ID. When they ask yourself “What’s in it for them, are the REALLY doing this for online safety“?

If you dig into the UK election in-person voting system, you’ll find it’s designed around a brilliantly balanced ideal, making voting as easy as possible whilst ensuring that fraud can not be committed at a scale that will normally make any kind of difference.

I’m a hacker by trade, I may work for the good guys, but my job is to look at systems and processes and work out how they could be abused (ideally before the bad guys do) and a few years ago I was a polling clerk at a very quiet polling station, with no internet access and only the Electoral Commission Polling Staff Handbook as reading material, so I spent most of the day studying the guide and working out ways I could subvert the in-person voting system.

One thing is obvious reading the guide, everything possible is done to keep the barrier to voting as low a possible, especially for that that impromptu last minute decision to vote. No polling card, no problem, kids or dog with you, no problem, need physical assistance no problem. It’s all about ways to facilitate voting, not prevent it.

So what about fraud? You may be surprised to know I came up with many ways I could commit voter fraud, but none fitted an important part of my original statement “committed at a scale that will normally make any kind of difference“. Sure I could see numerous ways I could fraudulently cast a single vote, but none that scaled. You’d either need multiple visit to the polling station times (increasing the chances of being noticed or the person you were impersonating having already voted) or have a conspiracy of many people and given each one could only cast a small handful of votes, you’d need a big conspiracy (and even small conspiracies are a big risk as humans are generally not great at keeping secrets).

So, how does mandatory voter-ID change things? Firstly is raises the barrier to entry, unlike polling cards, if you didn’t receive it (in time or at all), no vote. Lost it, no vote. Left it at home, no vote. Unplanned chance to vote as you were near, no vote. But more importantly, abusive spouse or parent who feels that if afforded a secret ballot you may not vote the way you want, they simply hide your voter-ID and boom, no vote.

What do we get on the other side of the scale in return, technically some improved security, but as it’s almost impossible to pull off in-person voter fraud at scale, the number of actual votes changed would be zero and the number of results changed would almost certainly zero. In 2017 44.6m votes were cast, there were 28 allegations (not proof) of fraud, that’s 0.000063%.

It’s spending money and ensuring people who could and would have legitimately voted, don’t, for no real benefit.

I’ll spare you the political analysis on who this would impact the most and why, as I hope even supporters of the parties who may gain from disenfranchising voters will think it’s an abhorrent idea, and just say …..

If you care about electoral integrity, focus on the postal voting system. It’s far easier to abuse (especially at scale) and doesn’t offer many of the same protections (i.e. from coerced or intimidated voting or ensuring the secrecy of the vote). Anyone who thinks fixing in-person voter should take priority over mail-in voting either doesn’t understand the UK election voting system, or has something to gain from a higher barrier to entry when it comes to in-person voting.

One of the many many awesome things @LargeCardinal and co did for BSidesLeeds this year was a challenge to collect as many hidden flags as possible. Sadly nobody reported collecting any flags on the day (probably because there were so many other things for people to do and see) so they decided of offer an additional week for people to find them.

I found out at the closing ceremony that not only had I found a flag, because I didn’t recognise it as such I’d displayed it all lunchtime to the entire dining room and also unwittingly tweeted it out. I decided as I’d stumbled across 1 flag, I’d spend my weekend looking for the remaining ones.

Here’s where I found them.

Flag 1 – “The Programme Polyglot one”

The day before the event, the BSides Leeds website was updated with a link to the event programme, When viewed as a PDF the file works as expected, but if you download it and run strings against it, it reveals some interesting secrets

Hum, an interesting couple of filenames found after the %%EOF marker that normally indicates the end of a PDF.

Those people at the BSides Leeds 2018 closing ceremony with exceptional memories may remember that the challenge prize was POC || GTFO , which I was lucky enough to already own. However, I remembered one of the articles in there was was on a ZIP/PDF polyglot.

Unlike last time I came across this puzzle, where I wrote a lot of code to extract the zip file from the pdf, I now knew the true power of a polyglot file format and just unzipped it and viewed the contents to get the first flag!

Flag 2 – The Bandersnatch One

So, whilst the obvious intention was to find it via the programme, LargeCardinal had obviously realised nobody was looking for Flag 2, so tweeted out the link.

The website was obviously riffing on the excellent Netflix Black Mirror “Choose Your Own Adventure” retro gaming episode Bandersnatch, but seemed to have no hidden features, so instead I started examining the linked .wav file.

Now, whilst the BBC Master and classic Microvitec CUB monitor I’d spotted downstairs and the fact Tom Hargreaves was talking about Acorn Hacking, should have been an obvious clue, I genuinely recognised the wav file as probably a BBC B tape image from it’s sound alone (whilst most 8 bit micros had similar tape formats the all had distinctive “noises”).

Over lunch I returned to the BBC Master (the enhanced version of the BBC C) disconnected the mp3 player that was connected to the tape port and hooked up the headphone socket on the MacBook.

Despite it being nearly 3 decades since I’d last used a real “Beeb”, muscle memory took over and all it took was

Ctrk+break (hard reset the machine*)
*TAPE (disable the default floppy disk system and instead use the tape input)
*LOAD “” (load from tape, but do not run)

Once I’d actually loaded the software, I realised that CHAIN “” (load and run) would have been more efficient, but it was job done, regardless.

The software then loaded this amazing image and some wonderful 8-bit tunes from the tape.

Now, what I hadn’t realise when I tweeted this picture and left in on display to everyone over lunch, was the the Herman Houser quote above the owl was in { braces } and there actually a flag!

Props to @hexwab and @BSidesLeeds – This is frickin awesome! pic.twitter.com/f6sntoCjZP

— Glenn Pegden (@GlennPegden) January 25, 2019

You can see and here the full thing in all it’s glory at

*The speed at which is rebooted had my colleagues believing it was only a BBC Master case, but had much more modern hardware inside. The didn’t realise that in the 8-bit world sub-second boot times were the norm

Flag 3 – “The first BLE One”

This years conference badge was designed to house an ESP32 LoRa dev board. As SBG were doing a badge flashing station, I’d seen an early version of the software, but it seems LargeCardinal added a bunch of hidden features and most importantly FLAGS in the version we didn’t get until the very last minute.

The firmware was available from https://github.com/unprovable/BSidesLeeds2019
and from the filenames and sizes it looked like bsides-bade.ino.bin was likely to be the most interesting, so as normal I started with strings and immediately hit some interesting stuff.

So, by just hooking the badge up to a terminal by doing screen /dev/ttyUSB0 115200 and using the chat functions of the software, a number of the strings we found were triggered, but as few more stood out as NOT things we’d seen on screen including

• deadbeef-1337-h44x-f1a9-b51d3sb1ef1g
• HiddenFlagIsNotAFlag
• Bluebird
• beb5483e-36e1-4688-b7f5-ea07361b26a8
• SNEK
• SNAAAAKE!
• LargeCardinalFeelsBlue
• … and something referring to Bluebird/Blue stuff.

It also showed the output of the help command

Supported Commands:
? – this message…
n – change Tx nickname…
d – print Tx nickname…
c – [TODO – put what c does here…]

The first two I discounted as intentional red herrings, the fourth one a little googling told me was a common string used in Bluetooth low energy (BLE). So lots of Blue references and 2 Snakes.

It didn’t take long to realise that typing either SNEK or SNAAAKE! caused the badges of everyone in radio range to turn into a game of snake! Very very cool (and quite annoying I’m sure) but ultimately, no flag.

So, one of the features of the board is it’s a BLE transmitter and we have a load of Blue reference, so l decided try and find something to start it.

/c (as hinted at in the help) doesn’t seem to do much, but some experimenting showed /b outputted a different error message to other commands and a little more experimentation led me to trying

/b LargeCardinalFeelsBlue

which worked and started a BLE server

Hah! Finally triggered the other hidden feature of the @bsidesleeds badge (i.e. not snake).

(I still can't get radare to give me a meaningful disassembly though) pic.twitter.com/KonCCKamOn

— Glenn Pegden (@GlennPegden) January 27, 2019

Now, as the only BLE stuff I had handy was a BlueFruit board that wasn’t soldered up, I took a bit of a short cut and purchased an iPhone app the scanned for BLE. It was money well spent as I got the following

I have to admit, it took me far too long to realise that Blue DA BA D33 DA BA DA 1 was a reference to the Eiffel 65 tune

Flag 3 – “The Second BLE one”

I also have to admit that whilst I was one click away from the next flag, I missed it for quite some time. If once you discovered the BLE Service, you attempted to connect to it an enumerated the services, another key would jump out at you.

Flag 4 – “The Easy One”

A couple of people had mentioned on twitter that they found “the easy flag”, but do far I’d not found a flag that stood out as particularly easy.

It took me far far too long to notice there was one command on the badge I’d missed.

Simply entering /flag (or even just /f) rewarded you with {Easiest-flag-ever}

Flag 5 – “The One that nearly sent me blind”

On the day a few people noticed some tiny black on black writing on the badge and text on the back that hinted towards an XORing against a hex key

The text was incredibly hard to read by a old guy like me, but after trying dozens of light sources, magnifying glasses, etchings, high res cameras, play-doh and pestering family members to have a look, I eventually caught the light at just the right angle to give me a hex string, when when XORed against 0x5ca1ab1e give the final flag!

Summary

I can’t finish this without a massive Thank You to LargeCardinal and all his helpers, the challenge was very very fun and was very much the cherry on top of an awesome con.

Additional

LargeCardinal has told me I missed a flag, not just me, but EVERYONE did. Apparently the Black Badges worn by Mark and award to Chloe and Emlyn for their help over the last 2 years, actually had a different challenge on them to the white badges, but nobody thought to check them!

Firstly Install the Arduino IDE from https://www.arduino.cc/en/main/software

Once installed go to Files -> Preferences under “Additional Board Manager URLs” add https://dl.espressif.com/dl/package_esp32_index.json

Then go to Tools -> Board -> Board Manager and search for ESP32. You should have ESP32 by espressif, install this set of boards.

You should then be able to go Tools -> Boards and select “Heltec_Wifi_LoRa_32”

Next to to Tools -> Port and select the apropriate port the dev board is connected to (Windows users will probably need to installed the USB to UART drivers from https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

Note the board will normally need to be plugged in for the serial port to be present.

Next go to Tools -> Upload Speed to 115200.

Finally got to Sketch -> Manage library and add
ESP8266 and ESP32 Oled Driver for SSD1306 by Daniel Eichorn, Fabrice Weinberg and LoRa by Sandeep Mistry

This should give you an IDE capable of sending compiling the firmware and flashing it onto the dev board

You can obtain Mark’s firmware from https://github.com/unprovable/LoRaChat <Check, the final build may move>

Once you have the .ino file open in the UI, select Sketch -> Upload to send it (it’ll compile it first if needed).

A few seconds later, the firmware should be on the device.

If you’re struggling, there is a more complete guide at https://robotzero.one/heltec-wifi-kit-32/ (just remember to select the LoRa board).

This Info is also available online at<insert URL>

First get yourself a ESP32 LoRa board (details, including a link to get the next-day via Amazon Prime can be found <link to SBG Engineering Blog for page for Quick Start Guide>) and pop along the the SBG Flashing Station to get BSides Leeds 2019 custom Challenge firmware on it.

Receiver Only

To receive broadcast messages (both from BSidesLeeds and other attendees) just apply power to the USB connector and watch the messages appear on the mini OLED screen.

Transmitter & Receiver

Connect the USB port to some kind or serial terminal. The guide assumes they’ll be some kind of Windows, Mac or Linux host, but we’re sure other people will be more creative.

Connecting

Start by lugging the board into your computer then :-

Windows

Install USB UART driver from https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers and check you have a new port in device manager when the board is plugged in (normally COM3)

Next install PuTTY, from https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html and configure as follows (Connection Type: Serial, Serial Line: <from above, normally COM3>, Speed 115200)

Hit open and you should get something like the screen below

OSX & Linux

Doing screen /dev/ttyUSB0 115200 in a shell should give you something line the screen below

<Insert Pic>

Usage

LoRa is a low-power, low-bitrate but very long range radio protocol suitable for sending small amounts of data a long way.

Your badge is a LoRa based chat system. Choose a Nick then type away. Message received will be shown on the OLED screen on the badge.

Look out for special BROADCAST announcements during the day.

Beyond simple chat

The firmware source is available from https://github.com/unprovable/BSidesLeeds2019 . Feel free to take it and modify it.

It’s probably no great surprise that once again the BSides 2018 Badge is also a PCB.

However most people don’t get the chance to have fun with their badges until the get home, but as this years badge is all about interaction, SBG have teamed up with BSidesLeeds to help you actually take part on the day.

What you need?

The heart of the badge is a LoRa ESP32 Board. These were originally designed by Heltec as “ESP32 OLED LoRa Development Boards” intended for IoT device/sensor development. For this badge, an original or any of its 23mm pitch pin-compatible copies are fine.

You can get them much cheaper of Ali Express, but to get them in time for the conference and if you’re an Amazon Prime customer you can get them from here (though any board with a compatible pin-out is likely to work)

https://www.amazon.co.uk/gp/product/B078M74NNN

You then need need something to act as a keyboard interface and power source, a laptop works fine with a USB cable works fine, but we’re sure some of you will come up with inventive alternatives.

It would be nice to solder them on the day, but the venue doesn’t allow for that, so the good new is, you can actually get it working without the board.

Then what?

The easy way? Just turn up to the SBG Firmware Flashing Station (located in the <insert place> with your LoRa board and we’ll drop @LargeCardinal’s custom firmware on it, pass you some info <link tbc> on how to hook it up to a PC/Mac/Linux box and let the magic begin.

Easy as that!

However, if you want to do it all yourself, see this guide <link tbc>

Please see this post before reading, for important caveats about the sources of information used to help construct this post.

Introduction

One of my favourite Security subjects is Bug Bounty Programmes, mainly because I was lucky enough to start work somewhere big enough to already have an internal programme in place and where I was wholeheartedly encouraged to get involved with its operation and help transform it into an external programme by its architect and implementer Dan Adams.

Internal Bug Bounty Programmes

The inspiration for this post came from this post on LinkedIn from the Product Security Engineering Manager of Lyft

As internal programmes are something I have experience with, but aren’t talked about publicly much, I figured it would make a decent blog post to start the New Year.

So, for those new to the idea of internal Bug Bounty Programmes, they are essentially private (invite-only) programmes, where invites are only available to staff members of the company offering the bounty payments (often an implicit blanket invite to all technical staff).

Doing this has some real big benefit and a few draw backs, so lets run through each in turn.

Learn as you go

Getting a Bug Bounty Programme right first time is very hard. An internal programme genuinely lets you develop robust processes and procedures ahead of an external launch.

If you’re upfront about the programme being a learning exercise then internal staff can be much more forgiving of slow triage, poor communication, vague or confusing scopes, and inconsistent or slow payments (all common problems with newly launched programmes). Making your internal hunters an important and valued part of your process can be the dividing line between “they listened to our feedback” and “they constantly keep moving the goalposts”.

Everything from your scope, your rules of engagement and your payment structure may need refining or even completely rewriting once you programme is live. That’s MUCH easier to achieve when it won’t cause disruption outside your organisation.

Flow Control

One lesson I learnt early from both Dan and from Bug Bounty Pioneer Katie Moussouris** is that one of the keys requirements of launching a bug bounty programme (or even knowing if you’re ready for one) is understanding your ability to handle the flow of incoming info the programme will bring. Having the resource to efficiently triage, remediate and pay bounties on new vulnerabilities is often a key differentiator between the launch of a successful programme and an embarrassing, expensive or unproductive one, but for many organisations launching as internal-only can limit that risk somewhat.

If you find you genuinely can’t keep up with the flood of new vulnerability reports, then being internal-only makes it much easier to change which classes of vulnerability are in-scope, refine the process or pause the programme altogether without upsetting the wider bug bounty community.

Unfair Advantage

When planning to launch a programme it’s not uncommon to lose sight of WHY you’re doing this. People try to create a fair and level playing-field so all hunters have the same chance of getting a bounty. If your aim is creating a challenge to find the best bug bounty hunter or simulate specific attacks then great, but it’s safe to say that ISN’T your aim. Most people are in it to collect the high quality vulnerability info they don’t already get from other sources, so why tie hunters hands behind the back.

The most successful internal programmes I’ve seem leverage the home-field advantage of internal hunters to go harder and deeper with less time wasted on dead ends by allow/encouraging hackers to review source code and design documents as well as going and talking with the development teams directly. Remember, even if you only care about public facing vulnerabilities and demand a PoC from a public network, that doesn’t mean your hunters need to be limited to doing their initial investigations from only public networks. It may be your website has a serious inject issue that’s currently mitigated by a WAF rule, but what happens when that rule is updated or you switch to a new vendor with a different vendor?

That said, it’s not uncommon to put the same Bounty Conditions on Internal hunters as you would on external ones, such as the vulnerabilities must be exploitable from the public internet.

Obviously achieving this may vary vastly from organisation to organisation, it’s not unusual for smaller organisations to have access controls that give all engineers the same flat access to all your source code repositories, design documents and network segments etc, but in larger organisations it may be necessary to allow hunters to apply to temporarily gain access to other teams’ resources to aid investigation.

Remember when it comes to paying, the value to you is in the information you receive, not the effort that was put into gaining that info, the fact internal hunters may have an unfair advantage and easier time doesn’t make their information any less valuable, so I’m therefore a big advocate of making internal payment structure identical to any external/public offerings you may have.

Dupes

One of the big annoyances for bug bounty hunters that has never really been addressed effectively is that of duplicate reports***. Most programmes only pay for the first reported instance of a vulnerability (otherwise not only are they paying for info they already have, but it would be possible for news of the vulnerability to pass from hunter to hunter) and understandably programmes don’t want to share publicly what vulnerabilities have been found but not yet fixed, so inevitably you end up with hunters using their time and talents to hunt down valid vulnerabilities, only to be told that they’ll get no reward as it’s already been reported.

In many cases internal programmes can lessen the pain, either by allowing staff to their internal bug trackers or encouraging communication between hunters and triagers can at least feedback if there have been reports for classes of vulnerabilities in the areas hunters are hunting.

Better Signal to Noise Ratio

Internal schemes can be much easier for internal triagers as the quality of the reports can be much higher and obtaining elaboration on unclear points can be so much easier to obtain.

Never underestimate the time that can be saved when the reporter has a decent understanding of your estate, the technology you use, your internal processes and your organisations general risk appetite. You tend to find that not only will you get high quality reports of the actual vulnerabilities, but often pointers to the source of the vulnerability.

Of course there will always be exceptions, but as a general rule internal reports are generally much quicker and easier to triage, contain much more info helpful to the team doing the remediation and contain far fewer false positives and incorrect assumptions.

Subterfuge and collusion

Whenever I talk about internal programmes the first question is “How do you stop people adding bugs so they can report them?”.

Whilst a rule that nobody can report any problem in a part of the code base they’ve worked on (or in some cases they were part of a team that worked on that area) is common, the real answer is much more cultural. Do you have a hiring policy that would attract people who would risk their employment and their reputation for a few thousand dollars in bounty payments?

The cons

So far I feel I’ve put forward a fairly compelling case that if you are in a position to launch a programme, start it as internal only, but what about the cons?

Over burdening hunters. Bug Bounty Hunting is fun, but it can also be infuriating, stressful and time consuming. Do you want your engineers spending all their free time thinking about finding vulnerabilities in your codebase? Or do you want them to switch off and think about something else entirely? Are you confident they’ll limit their hunting to just their free time, or will they actually be picking up a second job that impacts their first once. However, as with “Subterfuge and Collusion” if you feel this might be a problem, are you hiring the right people?

Rapidly Declining Interest. Whilst a new internal programme may introduce many new people to the world of bug bounty hunting, for the majority of people interest will wane over time and the flow of new vulnerability info will reduce. Things like short term incentives and events like charity hack days can garner increased participation but at some point it’ll stop being the cool and new thing and you’ll have to start looking externally for new participants.

Disillusioning external hunters. Bug Bounty hunters hanker for new programmes where all the low hanging fruit has been hoovered up and everything the find isn’t already reported and therefore a dupe. So, when you’re ready to move from internal to external, having it known amongst external hunters that your programme has already been ravaged by bug hunters and there the effort/reward balance will be more favourable elsewhere

Final Tips

Don’t launch an Internal Bug Bounty Programme, build an internal Bug Hunting Community, with the programme at the heart of it.

Plan for the future, always ask yourself “Would this also be Ok if the programme was a public one?”

Fix problems at source. It’s easy to use the Bug Bounty Programme as a ticket creation factory, but ensure you’re collecting data on the root cause of vulnerabilities and feeding that data back into the SDLC

Define your metrics, goal and reporting from the start. Even internal Programmes are expensive to run, so ensure you can prove the value of the scheme. Remember knowing about 1000 unmitigated make you at no less risk the knowing about 10 unmitigated ones, be able to prove programme is actually lowering risk.

Make the journey from your Bug Bounty Platform as frictionless as possible, so people choose to report things via the bug bounty platform, even if they are not sure if they actually qualify for bounties, rather have them sat on bugs where they can see something isn’t right, but can’t exploit it in a way that would guarantee a bounty

Don’t be afraid to change things. Launching as an Internal Programme gives you more freedom to change things that aren’t working as well as you’d hoped, use that to your advantage.

* You’ll notice that when referring to Bug Bounty Programmes I use the older English (British) spelling of the word Programme, but when referring to computer Programs I use the newer (US) one. This is intentional, though I can’t really justify it, other than I’ve always felt it was correct

** If you’re interested in Bug Bounties and you don’t know who Katie is, stop reading now and go read everything she’s written on the subject first.

*** Whilst it doesn’t really help on-going programmes for their events (where certain sites are put in in-scope to a limited period to an invited set of hunters) HackerOne have an initial window (normally 1hr) where hackers can report all the low-hanging-fruit they found during reconnaissance before the event and they all the share the bounty payment, which is an interesting way to tackle the inevitable dupes where when of the best bounty hunters in the world are given the same target and some advanced warning.

Previously, I had a job whose Social Media policy pretty much prevented me from talking about Security related stuff on Social Media / Blogs / Cons etc as people might believe it was pertaining to their specific environment and concerns (even if it wasn’t). So I cleared down my blog of anything technical and let this site go fallow.

I’m now very grateful I work somewhere much much cooler about such things, in fact we’re positively encouraged to blog and speak at events etc, but I’ve never really taken advantage of it, until now. So my New Year Resolution (one of several) is to blog much more.

However, one thing it’s very important to keep in mind is that whilst some writing may be based from my current role, much of it isn’t. Much of it is learnt from third parties who I’ve gone to, to understand a subject more completely, so don’t assume anything best practice or worst practice, witty anecdote or cautionary tale is actually indicative of any employer past or present.

It was weird watching the events around WannaCry unfold on Friday in the context of my current job role as for the first time since, the ILOVEYOU worm (which turned 17 years old earlier this month) my role meant that I didn’t have any responsibility for any potentially impacted hosts. After a lifetime of working in small companies in either a security, IT, incident response or management, there was now a major bit of malware propagating that people were unprepared for and I now worked somewhere big enough that we had other people to manage such things.

So, rather than being in the middle of the fire-fight, I sat back, glued to twitter and watched things unfold. It was great to watch some of the worlds (or at least in the early hours, the UKs) best security researchers dig into whats happening and share their findings in real time on twitter.

It became apparent that the world’s tech journalists were also following them and a lot of non-technical ones too. But as we saw a few weeks ago when the latest ShadowBrokers cache was dropped, stuff goes from 140 chars of “current thinking” to being reported worldwide as fact, pretty quickly.

The same seems to have happened again with this, only this time the misapprehension of some early tweets is leading to the blame for the rapid propagation being laid fairly and squarely at the feet of Windows XP and other EoL software. Whilst they are undoubtedly contributing, they are far from the only culprits and come Monday morning there are going to be a lot of people who thought “We don’t have any XP machines, nothing to worry about” who’ll be facing a huge infection.

Now, XP didn’t become the boogey man by accident, there are some reasons why XP was mentioned a lot in those early tweets,

1. Unlike newer versions of Windows, at the time of the the outbreak there was no patch to prevent infection for XP (Microsoft released a patch for newer OSs in March, but has also now released an XP patch)

2. The infection requires SMB v1, a protocol that can happily be disabled in a Windows environment if you don’t have XP/Server 2003 machines on your network.

It’s also noted that NHS is notorious for running legacy software like XP.

However, what the journalists on the whole have failed to take into account is

1. Just because you can (and should) disable SMB v1, it doesn’t mean people have done. Many people won’t know to, others will have non-windows devices using SMB v1 and for some, it’s just too much of a risk to change anything unnecessarily on a production network.

2. Just because Windows OSs newer than XP/Server 2003 have had a patch available since March, it doesn’t mean people have applied it.

3. Most big corps will have perimeter firewalls that prevent direct infections, but how many people have their work laptops getting infect on public wifi this weekend, only to plug that laptop onto the corporate LAN on Monday morning.

So, this ISN’T about XP,  people could have removed their last XP machine decades ago, but unless they’re getting patch management right and are on top of their network configuration (disabling unnecessary features and segmenting as much as they practically can) then come Monday morning the could be met with a rather unexpected headache.

Pentestit.ru noob guide

Whilst I’m a “blue teamer” (I specialise in the defensive side of InfoSec), I do enjoy doing Pentesting challenges both for fun and because “know your enemy” & “always think like an attacker” are invaluable bits of advice for any defender.

One of my favourites is Pentestit.ru Labs which closely mimic real environments you may come across in actual pentests and are designed in such as way that whilst they have a gentle learning curve, they normally require you to have decent IT and security fundamentals, rather than being aimed at people who have installed Kali and are watching “How to be a hacker” YouTube videos.

However, for the last year or so I’ve been sat in the pentestit.ru Telegram channel and whilst there are and awful lot of very knowledgeable people in the channel (far more knowledgeable than me, many are professional pentesters or prepping for things like OSCP exams) there are also a lot of people who join the channel that are really struggling with the basics. So I thought I’d put together a quick FAQ for those guys.

Do I need to use Kali Linux?

No. In fact, I intend to do the next lab entirely from a Windows Box to prove it’s possible (and because I love Powershell). However, if you’re asking that question, I strongly recommend you do as it’s probably the easiest starting platform to attack from.

Do I need to use PentestIt.ru’s downloadable Kali VM?

Again, no.  I’d wager almost everyone completing the labs is doing so using a vanilla Kali build. The only difference with the one on the Pentestit.ru website is it come pre-configured with everything you need to connect to their vpn.

If you’re going to struggle connect to a vpn from Kali when then instructions are on their website, you’d probably be better spending your time reading some linux vpn guides first.

The vpn is connected and I can ping their gateway machine(s). Now what?

Start your pentest! Normally these labs only start with one (or possibly two) gateways machines exposed, so don’t expect to be able to access the servers behind the gateway directly. However, usually these labs do have port forwarding set up for some services, so for example hitting port 25 on the gateway machine is likely to be forwarded to port 25 on the “email host” on the internal network.

You’re normally looking for some way to compromise the gateway machine (or some machine port forwarded to from it) and then pivot to the internal hosts.

I’m on the vpn, but I get disconnected constantly. Why?

Check you don’t have more than one vpn connection active to their labs as this will normally cause them to disconnect. Failing that, check out the Pentestit.ru Service channel for service outage notifications.

I’m on the vpn, but I get disconnected hourly. Why?

Many of the hosts reset on the hour. so may disconnect you and remove any changes you have made. This in intentional. If you have something running on a host that takes over an hour (i.e. some kind of brute force attack) you are probably approaching the problem in the wrong way.

I used “<insert tool name>”  and it found nothing. Why?

One of the great things about these labs is that they are often engineered to make life harder for people using automated tools (especially with the default options) and easier on those actually doing the attacks manually. So, just because sqlmap fails to find an sql injection point, a given password isn’t in the default john the ripper list, nmap doesn’t find an open port on a default scan or a folder isn’t found by dirb doesn’t mean that that approach isn’t going to work. The lab designers know these tools well too and want to give you more of a challenge than “can you run the right tool with the default options”.

How do I get admin/root?

I’m sure they’ll prove me wrong at some point, but it’s not likely you ever need admin or root on a host to get the token. This actually makes sense, as with root access you could easily screw over the challenge for other people. However traversing between users with different privs is quite common, often using techniques more commonly associated with escalating to root.

I’m stuck, now what?

Try Harder!

Seriously, that’s probably the first response you’re likely to get in the Telegram channel. Possibly with a link to this

It’s good advice. Go away, make a coffee, have a smoke, play Hello Kitty Island Adventure … whatever works for you. We’ve all got stuck on a challenge, then come back later with a fresh bunch of ideas.

But keep trying. These challenges are usually pretty logical and based on real world exploits, so take what you know about the situation and go hit the books (or google) and see if there is something more to learn.

Seriously, I’ve been trying for days, now what?

Well, the telegram channel is always there, but most of the people in it try to keep it spoiler free, so the usual etiquette is to ask for somebody to DM you about whatever you are struggling with.

Also, once the winners of a challenge are announced, people start publishing their solutions, these are great for getting you past you’re current hurdle, however, be very cautious as once you’ve cheated and taken a peek that first time, it becomes much easier to cheat every other time.

I’ve finished this lab, now what?

Try this list, or come hang out in the telegram channel and see what others are currently working on.

Obviously Disclaimer: I’m not part of the pentestit.ru team, just a fan of their work and this does not constitute official pentestit.ru documentation or is in anyway endorsed by them