BSides Leeds Challenge Flag Guide

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!

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

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!

BSides Leeds ESP32 LoRa Badge – Flashing Guide

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).

BSides Leeds LoRa Badge Guide – Usage

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.

BSides Leeds ESP32 LoRa Badge Quick Start Guide

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>

The Internal Bug Bounty Programme*

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.

An early New Year Resolution

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.

WannaCry – When the press pick the wrong boogeyman and nobody listens

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 noobs guide

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

Powershell based Plex “Local Player”

So, imagine a scenario where you’re trying to give a presentation on a customer’s PC, what you are trying to show is a video on a remote Plex server, but the customer’s PC is so locked down (whitelisted apps only) that whilst vlc will work, a web browser won’t! Seriously!!!

However, powershell did work and that gave me a way in.

So, what I thought wouldtake just a few simple lines to download the file from the plex server and play it through vlc, actually became a bit of an epic.

Therefore, in case anybody ever gets stuck in the same hole or wants some sample code demonstrating to do take “streamed” content and convert it back into something a media player will play locally. The code is now on github at https://github.com/glennpegden/PlexLocalPlayer

To use it just pass in the URL of the video details page in Plex, your plex username andpassword and the foldername to dump the video into (also optionally the paths to ffmpeg and vlc, or you can redefine these at the top of the script)

e.g.
.\PlexLocalPlay.ps1 “http://app.plex.tv/web/app#!/server/01380a5c2c9b4290-9c1136b6882a65c1/details/%2Flibrary%2Fmetadata%2F12345” “user@email.com” “yourplexpasswrd” “G:\Users\Glenn\Downloads”

Disclaimer: I’ve no idea if interacting with Plex is this way is against their terms and conditions. I’m also not sure any of how I’m doing it is “the right way” because it was reverse engineered by examining how the Plex Web Player works on a laptop rather than from any official documentation. I’m also not responsible for how you use it. My use case was to download marketing material that I was allowed to distribute, I imagine doing this with your family’s blu ray connection may be illegal in many places.

For anyone writing your own version of this, a few things about the design.

The convoluted background download. This is to address two problema.

  1. The Plex server seems to time out connections, even if they are happily delivering content. Their own web player gets around this by hitting a “ping” end point as a keep alive, we have to emulate that.
  2. Invoke-Webrequest is nice and simple, but it loads the entire downloaded content into memory and saves it upon completion. Fine for tiny webpages, a disaster waiting to happen for huge files. BITS would normally be my go to alternative (BITS support in powershell is great), but it needs a Content-Length header from the server, which we’re not going to get from a stream.

    So, we have to use .net functions to stream the content into a file, in a background task, so the foreground task can hand the keep alive.

    Potions of the stream downloading code are based on this blog post – https://blogs.msdn.microsoft.com/jasonn/2008/06/13/downloading-files-from-the-internet-in-powershell-with-progress/

I also added some hokey support for roughly passing back the progress, but as we only know the size of the file on the remote OS and who knows what the transfer/transcode is going to do with it, it’s far from accurate. It also only updates once every 15 seconds (which is how often the keep alive is sent). Really, only consider this as an indicator something is still happening, not a real estimate of progress.

Obviously simply saving the stream to a file doesn’t generate valid video file, however ffmpeg does a brilliant job or repairing it (or has done in all my tests at least, your mileage may vary).

Enjoy!