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

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



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.



Wednesday, December 16, 2015

More with smbclient, smbget, enum4linux

More notes because I can never remember and I'm sick of looking it up

Testing open shares/445

List shares with smbclient -L 1.2.3.4

root@localhost:~# smbclient -L 1.2.3.4
Enter root's password: 
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       
        MEMORY_CARD     Disk      FLASH MEMORY PHOTO
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]

        Server               Comment
        ---------            -------

        Workgroup            Master

        ---------            -------

Try to connect to the share

root@localhost:~# smbclient \\\\1.2.3.4\\MEMORY_CARD
Enter root's password: 
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]
tree connect failed: NT_STATUS_ACCESS_DENIED

Boo

When it works

root@localhost:~# smbclient \\\\2.3.4.5\\MDMLOAD
Enter root's password: 
Anonymous login successful
Domain=[DEMO] OS=[Unix] Server=[Samba 3.6.23-20.el6]
smb: \> l
  .                                   D        0  Wed Nov  4 02:42:15 2015
  ..                                  D        0  Mon Oct 12 20:38:40 2015
  input.csv                           A     2024  Mon Nov  2 22:13:18 2015

59400 blocks of size 2097152. 19612 blocks available

enum4linux can help out when you have a bunch of shares to check or just want to do things quickly. -S to check shares, although you probably just want to do a -a for all.


root@localhost:~/enum4linux-0.8.9# perl enum4linux.pl -S 3.4.5.6
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Tue Dec 15 22:34:52 2015

 ==========================
|    Target Information    |
 ==========================
Target ........... 3.4.5.6   
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

 ========================================== 
|    Share Enumeration on 3.4.5.6    |
 ========================================== 
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]

        Sharename       Type      Comment
        ---------       ----      -------
        www             Disk      Public Stuff
        IPC$            IPC       IPC Service (Samba Server Version 4.1.12)

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------

[+] Attempting to map shares on 3.4.5.6
//3.4.5.6/www     Mapping: OK, Listing: OK
//3.4.5.6/IPC$    Mapping: OK     Listing: DENIED
enum4linux complete on Tue Dec 15 22:35:09 2015

root@localhost:~# smbclient \\\\3.4.5.6\\www
Enter root's password:
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]
smb: \> ls
  .                            DR        0  Sat Dec 12 14:23:20 2015
  ..                            D        0  Thu Oct  8 11:53:20 2015

 oops                           D        0  Fri Nov 27 17:38:04 2015
---SNIP---

Want to download a whole folder?


root@localhost:~# smbget -R smb://3.4.5.6/www/oops
Username for www at 3.4.5.6 [guest] 
Password for www at 3.4.5.6: 
Using workgroup WORKGROUP, guest user
smb://3.4.5.6/www/oops/images/defaultpic.gif   smb://3.4.5.6/www/oops/images/ad2.jpg            
---SNIP---

enum4liux is also super handy internally as it tries multiple ways to get a domain SID, if successful it will brute force the SID to enumerate all the SIDs/user accounts for the domain.

Friday, December 11, 2015

Thoughts on the skills shortage

Sorry no meterpreter shells on this one.

Reading Trey Ford's article https://community.rapid7.com/community/infosec/blog/2015/11/19/ciso-guidance-on-building-the-team led me to want to put some ideas onto the blog that I've discussed at work and over beers but never here. So here it goes.

I'm not going to address each point rather I'm going to just share a few observations and opinions on the subject from my life/career.

1. I don't do any hiring but I can agree that their may be a lack of skilled mid to senior people in the market.  At every place I've worked it was always difficult to find qualified people to just to interview let alone hire. The fix, we/us/you/me need to grow them (more below).

1a. What I don't see is a shortage of INTERESTED junior people. There are tons and tons of people that want to get into infosec but sadly everyone wants mid to seniors and they don't want to train juniors.

2. It CAN be hard to afford people, especially  in expensive places like SFO/Silicon Valley, DC Metro Area, NYC, etc.  However, there is a real reluctance to allow remote workers, so when you base your HQ in an expensive area, or a place with a crappy commute AND don't allow remote employees then you don't get to complain that people are asking for lots of $$$.  Valsmith touched on this in a post as well; (http://carnal0wnage.attackresearch.com/2015/06/hard-to-sprint-when-you-have-two-broken.html).

That being said, I know a lot of people want to make a difference and do cool shit and they are willing to take slight pay cuts to do this (also mentioned in Trey's article). Management should keep this in mind.  Also, maybe its less the pay and more the sense that it's going to be impossible to make impact in your organization. That's what keeps me from wanting to go back to doing gov work.

3. There is a clear problem with senior people getting upset that people "get trained" and leave the company.  Bottom line, we shouldn't get upset.  Every person that goes from junior to mid or mid to senior and moves on to another company brings those skills with them and improves the other company and Security as a whole. Less companies getting pwned or more companies being able to react better/faster to attacks is a good thing.

We should reframe our thinking of not wanting to pay to train someone else's employee and more on we need to grow literally as many security people as we possibly can for our industry. Every company should think this way.

4. Have a FORMAL plan to grow your security people. An unamed CISO mentions this in Trey's article but saidly no details are given; 
“I like to work with entry level candidates on a 2-5 year growth path. I realize they may not be here forever, but I want to focus on giving them the right tools and a good experience.”
 I've  never had a job outside of the military that had a written plan to grow a security engineer/pentester from junior to mid or mid to senior. No required tasks or knowledge identified, no listed skills for my job role, no specific training to take, books to read, or anything to prove I was ready for that next level.  It has always been On the Job Training (OJT).  To be fair there is no replacement for OJT and its absolutely required to gain experience but there is no "growth path" when you rely on the whatever pentest comes in as what guides a person's development or whatever internal projects come up or fires to put out. I think we have attempted to rely on certifications to do some of this, and it does to an extent, but its general knowledge and not going to be organization or position dependent. Not to mention the whole value of certifications dilemma. 

You know who does have a plan to grow people from zero to competency? The military.  They take someone with aptitude (usually) but zero experience (well... assumes zero experience) and put them through training and testing with specific objectives and at the end they demonstrate proficiency in those specified tasks.

I'm not saying we need to get THAT formalized in our training but we need SOME plan on how to take someone with aptitude (and i'm going to make the assumption that if you got through college with a CS degree or demonstrate aptitude some other way) and repeatably train and grow that person from one level to another.

I don't know if we can do this collectively in a broad security community/PTES type sense (maybe we should try?) but i'd certainly like to see it implemented at a team level inside companies.

The second part of the article is also worth a read:
https://community.rapid7.com/community/infosec/blog/2015/12/07/ciso-guidance-on-building-the-team-part-ii


Thoughts?

CG

Friday, November 20, 2015

CVE's & My Vuln Disclosure Experience

Back in January I received my first CVE; CVE-2014-9354

Reference: https://kb.netapp.com/support/index?page=content&id=9010021

The reference above, like usual, gives no actual information. Luckily, the bug was simple enough. Once you log in to the Netapp interface, on the page that contains the page (Active Directory tab) to enter in some domain credentials, you can view source and see the starred out credentials in the source of the HTML. Party like its 1999!

Netapp was responsive and easy to work with, I asked that they request a CVE which they did, they were forthcoming with fix information and the time line for patch release. The overall experience went, more or less, like I think it should.

The second experience was much worse. I attempted to obtain another CVE for some vulnerabilities myself and @javutin found with the Steelcase RoomWizard product.

I discovered the RoomWizards were running a vulnerable version of Apache Struts making them vulnerable to CVE-2013-2251. This led to Remote Code Execution as root.  We found another issue where the HSQL database with sa/null is exposed by default. This allows you to retrieve the administrator password which then allows you to ssh into the device. A CVE (CVE-2015-2879) has been reserved for this issue after directly contacting CERT/CC as the vendor declined to request one. The struts vulnerability was slightly more interesting because the device runs as root.  An example of the vulnerable request requesting the output of whoami (and response) is shown below.



The exploit was simple enough, I just had to add the arm payload to the existing Metasploit struts module and add the vulnerable URI.  Module is here. Screenshot below:



My Initial contact with them was March 5th, 2015 and the fix came out Oct 19th 2015 (8 months). I’ve included the vulnerability timeline below for additional information and lolz.

Disclosure Timeline

3/5/15 - Initial contact with Steelcase and request PGP key to send details
3/10/15 – Receive PGP key
3/11/15 – Send vulnerability details and request Steelcase request CVEs for the issues
3/16/15 – Send follow up email requesting confirmation of receipt of vulnerability details
3/16/15 – Confirmation Steelcase received and could view the vulnerability details
3/30/15 – Request an update
3/30/15 – Steelcase responds they will fix in June/July with next firmware update
4/23/15 – Follow up on CVE request
4/28/15 – Received no response to 4/23 email, emailed again
4/28/15 – Receive response from Product Manager. States “As you know, we are implementing a fix in the next firmware version, slated for release later this Spring. We plan on holding communication and publishing a CVE until that time.”
6/18/15 – Request clarification on Spring answer as it is now June
6/18/15 – Receive response that Firmware is in alpha testing and expect release July/Aug
6/18/15 – Ask again if Steelcase will be requesting CVEs for the issues
6/18/15 – Receive an Affirmative response “Yes, to my knowledge we will but I’ve cc’d some principals who would be involved in the actual submission to be sure.”
7/8/15 – Received no reply from the principals, asked again
7/14/15 – Received no reply to 7/8 email, emailed again
7/16/15 – Email again stating lack of response is disappointing since they were 30+ days over the normal 90 day fix/disclosure timeline
7/20/15 – Receive reply. Steelcase will not apply for CVE. States “After internal discussions, we have decided not to apply for a CVE. No other devices are built upon the RoomWizard platform and the device itself is generally in a controlled environment.” Also states 4.5 move into Beta testing next week.
8/20/15 – Request an update as no updated firmware had been released and no other communication from Steelcase
8/20/15 – Receive response “We are going to Beta testing next week with anticipated release two weeks later, assuming positive results.”
8/20/15 – Reply back : “30 days ago you said it was going to beta testing next week?!?!”
8/20/15 – Steelcase replies “We found some bugs in Alpha testing that we felt it was imperative to fix before releasing at customer Beta sites.” Asks if we want the beta software, we decline.
9/28/15 – Request update as it has been another 30 days
9/29/15 – Steelcase replies the updated firmware should be available on Oct 19th 2015 along with a new version of the Administrative Console (required to install the new firmware)
10/19/15 – Steelcase emails me (!!) that the updated firmware has been released


-CG

Thursday, November 5, 2015

The Reason Why

If you are curious as to they the Government and big business are discussing infosec skill gaps, the ability to fill contracts and get quality work, the following video outlines it pretty well: https://www.youtube.com/watch?v=essNmNOrQto 

-Valsmith