Monday, January 18, 2016

Purple Teaming - Lessons Learned & Ruxcon Slides


Note:
I wrote a bunch of this while still at Facebook but have since changed jobs.  Anything FB is now replaced with $previousjob since I cant speak for them anymore. This was supposed to go on  their Protect The Graph post but never happened. The content was useful (I hope) so hopefully people will get something from it.  Also slides release here and at the bottom.

---


Recently Chris Gates from the $previousjob Incident Response team presented at Ruxcon (https:// ruxcon.org.au) on “Purple Teaming: One Year After Going From Full Time Breaker To Part Time Fixer”. The talk was used to highlight some of $previousjob’s experiences “Going Purple” over the last 18months.

What is Purple Teaming?
Purple Teaming is “Putting more Offense in your Defense” and “More Defense in your Of-
fense”. We do this to iteratively improve the quality of both our Red and Blue Teams by conducting focused Red Teams with clear training objectives for the Blue Team.


The talk highlighted observations and lessons learned during this process.
  1. Acknowledging the need for the creation of an internal Red Team. The maturity of the security program coupled with the complexity of the organization made it necessary to have internal knowledge to craft more interesting attacks for Red Team exercises.
  2. The creation of an internal Red Team and the location of the internal Red Team on the organizational chart. Many companies have both Red and Blue teams operating as separate entities. This frequently causes animosity between the two teams that can lead to growth stagnation because the two teams become focused on catching or defeating each other rather than innovating together in order to better defend their company. $previousjob’s Red Team is a component of the Incident Response team giving both the Red an Blue teams the same reporting structure. This placement was intentional as an attempt to avoid animosity and the “us vs. them” mentality that can frequently plague internal Red and Blue teams.
  3. Changing the typical definition of a “Red Team” to be less focused on vulnerability discovery and instead serve as a training event for the Blue Team. For $previousjob, a Red Team exercise tests our ability to respond to an incident and find broken tools and processes. The offensive part of the exercise is required to tell a good story, model the chosen attacker profile, and craft real world attacks for the Blue Team’s training objectives. The Post Exploitation, Persistence, Lateral Movement portions of the attack are far more important than the initial method of exploitation. With this is in mind, it is deemed “OK” for a trusted insider to be the initial exploitation vector (phish, browser attack, etc) and for the Incident Response manager to suppress any initial alerts that may come about from the initial exploitation vector in order to let the attack play out and allow the Red Team to move on to the post exploitation, persistence, and lateral movement pieces of the attack.
  4. Having a Red Team in-house allows $previousjob the ability to test vs. believing assumptions or information provided from other teams. It allows us to more easily validate answers to really important questions like “where can an attacker go if they had a certain set of credentials” or "what can an attacker REALLY do with a certain level of access" vs. what we THINK they can do with that access. The in-house Red Team is also required to stay up to date with the latest tools and techniques and can use that information to write detection signatures to catch these tools.
  5. Our Red Team reports have both the Red and Blue narrative making the report more valuable as readers see both sides of the attack. Red Team reports are typically only offensive oriented with no mention of incident response, defense, or how well the organization fared against the attackers. By having both the Blue and Red teams tell their respective sides of the story, we tell a much more complete story in our reports. This has the added benefit of highlighting to leadership and the company as a whole the value of the Incident Response team and show wins with new initiatives, gear, training, etc.
The talked wrapped up with a walk-thru of one of the latest Red Team exercises. The slides are available here:


link
CG

Saturday, January 2, 2016

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 2)


Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 2)

MAME

The RetroPie readme on ROM Management is here:
https://github.com/RetroPie/RetroPie-Setup/wiki/Managing-ROMs

Prepare to spend a bunch of time here.  You basically drop the ROMs for the appropriate emulator in its folder inside of RetroPie/roms/mame-*

Ah but whats the appropriate emulator?  I'm still muddling through this but from what I've read so far, the community has upgraded rom sets over the years. MAME emulators in RetroPie support multiple ROM sets although you might not be able to download that specific set anymore.  For example I've been using this site: http://edgeemu.net/browse-mame.htm to download a bunch of the image. They are romset 1.58 which if you notice is not used by RetroPie!



So as you read the Managing Roms page you'll see it recommends to use Clrmamepro to convert one version of a ROM to another.  The instructions are on the page.  Most confusing thing so far has been split vs merged.  Merged ROMs will lump multiples into one zip file that may or may not give you all the versions of the game you want to play.

For example; If you download all the Galaga ROMs and do merged you'll get ONE Galaga game spit out in the output folder even though there are like 10 different ones (I like the fast shoot one).  If you do split you'll get the 10 different ones spit out and you'll have to check the scanner output (Step 6) will tell you by each folder which ROMs you are missing.

Once it builds and scans without errors you put it in the appropriate emulator folder you are building for. I ended up with multiple MAME instances for different versions of ROMS.  My trackball doesn't work for advmame-1.4 but does for mame4all.

If you need some motivation for games to download, THIS is pretty good:




How to get the thumbnails and metadata

All the cool screenies show the thumbnail and metadata in emulation station.

Example:



It's not super clear how to get this data.  There is a scaper built into emulationstation but it was slow. I gave up.  Some searching around lead to https://github.com/sselph/scraper. This worked great.

Make sure emulationstation is not running.

My Pi distro didn't have go installed so I just downloaded the binaries listed in the readme and it worked.  Afterwards I cd'd into the roms directory and did a scraper -scrape_all -thumb_only.  This worked for everything but the MAME roms, see the readme or just get into the MAME rom folder and do scraper -mame -thumb_only. Make sure emulationstation is not running. It puts a lock on the gamelist.xml file and it wont update.  Once its done you'll have the cool picture and metadata when you browse your games. :-)


Happy Dance


Themes
You can install background themes in Emulationstation. Everything you need is here:

https://github.com/RetroPie/RetroPie-Setup/wiki/themes



CG

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 1)


Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 1)

I've been wanting an arcade system every since Rec Room Masters posted an ad on my Facebook feed last year.  It's very much a want vs. need so I waited over a year to purchase one. Below is the setup

Purchase Tankstick and Raspberry Pi 2 (see below)

The RetroPie for the RaspberryPi does all the heave lifting for you on getting the emulators set up. It even automates making the tankstick work. It was pretty much plug and play.

Steps:

Downloaded and installed  Raspbian Wheezy. Instructions here:
https://www.raspberrypi.org/documentation/

Upgrade the distro once its booted up:

apt-get update
apt-get upgrade

To get Retro-Pie up and running I followed the Retro-Pie instructions here:
https://github.com/retropie/RetroPie-Setup
https://github.com/RetroPie/RetroPie-Setup/wiki

I picked to install the binaries vs install from source it still took about 4 hours to get all the packages downloaded and installed.

RetroPie also has a image you can use but I didn't go that route, it would probably be faster though
http://blog.petrockblock.com/retropie/retropie-downloads/

Running Total:
TankStick 149.99 + 19.99 (S/H) => $169.98 USD
Raspberry Pi 2  34.99 + 3.89 (S/H) => $38.88 USD

There is a separate wifi adapter and case for the Pi on their way; both technically optional

Raspberry Pi Case (it's going to eventually go in Arcade Cabinet) $8.79 + S/H
Small WiFi Adapter (inconvenient to ethernet to the Pi) $9.99 + S/H
Total for the above => $26.84

You'll also need a USB keyboard and mouse to log in to the pi and do some configuring. I had several laying around the house.

Starting Up

Connect everything up. Initially you'll probably need keyboard and mouse. Once things are set up the tankstick will take up 2 USB ports, keyboard 1 USB port and your USB wifi adapter the last one.



Log into your Pi  pi/raspberry



Type emulationstation to get to the Emulation Station Menu





Optionally you can type startx to do linux-y stuff. You'll need to plug the mouse in if you do this.


Getting Games

You can torrent most of the SNES, NES, Sega *, Atari games.  A decent starting point is here:
https://pirates-forum.org/Thread-Cylum-s-ROM-Sets-Collection-Packs

Those torrent links are still active and downloaded pretty quick.

 
Follow the wiki on where to put the respective ROMs for various systems. Put them in the right folder and the emulator will be active in the Emulation Station menu:





Atari, NES, SNES, Sega systems just work if you drop them in their folders.  MAME games are a whole another pain in the ass I'm going to do a separate post for those.  But at this point you should be able to play your favorite game console games.



CG