red_team
LOGS
14:01:18 <jasoncallaway> #startmeeting Red Team
14:01:18 <zodbot> Meeting started Fri Nov  3 14:01:18 2017 UTC.  The chair is jasoncallaway. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:18 <zodbot> The meeting name has been set to 'red_team'
14:01:46 <jasoncallaway> Hi, everybody. Welcome to our Red Team monthly meeting
14:02:12 <jasoncallaway> #topic agenda
14:02:23 <jasoncallaway> Couple of things I wanted to cover today
14:02:34 <jasoncallaway> We've got some updates on our projects ELEM and CTL
14:02:49 <jasoncallaway> We're working on a Python SDK
14:03:02 <jasoncallaway> We've got some new core team members
14:03:10 <jasoncallaway> And some really cool +1s from the community
14:03:27 <jasoncallaway> #topic elem update
14:03:43 <jasoncallaway> Reminder that ELEM is the Enterprise Linux Exploit Mapper
14:04:04 <jasoncallaway> For those of you that are new to the team, this is a tool that lets you scan a local host for vulerabilities
14:04:12 <jasoncallaway> Then mapps those vulns to known exploits out in the wild
14:04:28 <jasoncallaway> You can find the project at https://github.com/fedoraredteam/elem
14:04:49 <jasoncallaway> Whoops, bad zodbot kungfu
14:04:59 <jasoncallaway> #link https://github.com/fedoraredteam/elem
14:05:25 <jasoncallaway> Ken Evensen, the lead developer for ELEM, demoed it at our Defense in Depth event a few weeks ago
14:05:48 <jasoncallaway> Demo went really well, we were able to show ELEM find some Shell Shock exploits on a RHEL 7.0 host
14:06:04 <jasoncallaway> We staged a php shellshock POC and got a reverse shell
14:06:25 <jasoncallaway> Then we installed and elem from the reverse shell, scanned for privilege escallations and popped root
14:06:50 <jasoncallaway> And then we updated the RHEL host and made the vuln go away
14:07:08 <jasoncallaway> Interestingly, shell shock doesn't work with SELinux enabled, or at least that POC that we were using
14:07:14 <jasoncallaway> Which makes sense given the httpd policies
14:07:27 <jasoncallaway> So don't disable SELinux, people :)
14:07:46 <jasoncallaway> Ken has been updating ELEM, and will have some cool stuff to talk about at our next team meeting in December
14:08:03 <jasoncallaway> #topic exploit curation
14:08:15 <jasoncallaway> Part of the ELEM project is what we call "exploit curation"
14:08:34 <jasoncallaway> We're testing the exploits that get mapped, and scoring them based on the STRIDE standard from Microsoft
14:08:48 <jasoncallaway> There are lots that map, about 130-ish on a RHEL 7 base install
14:09:04 <jasoncallaway> So we're crowdsourcing the exploit curation process
14:09:07 <jasoncallaway> #link https://trello.com/b/1fbRYkiQ/exploit-curation
14:09:21 <jasoncallaway> These Trello cards get generated by our new Python SDK
14:09:32 <jasoncallaway> which is a little buggy, but we're working on that
14:09:57 <jasoncallaway> So when you find new mapped exploits, you can feed the SDK a csv that spits out Trello cards
14:10:08 <jasoncallaway> In the mean time, this is a great place for folks to jump into the project
14:10:14 <jasoncallaway> We need help testing the exploits
14:10:33 <jasoncallaway> And scoring them
14:10:39 <jasoncallaway> #topic STRIDE
14:11:02 <jasoncallaway> Like I said, Microsoft has a nice standard for describing exploits
14:11:06 <jasoncallaway> STRIDE is an acronym
14:11:10 <jasoncallaway> Spoofing
14:11:14 <jasoncallaway> Tampering
14:11:18 <jasoncallaway> Repudiation
14:11:30 <jasoncallaway> Information disclosure
14:11:33 <jasoncallaway> Denial of Service
14:11:36 <jasoncallaway> Elevation of Privilege
14:11:44 <jasoncallaway> In the Microsoft model, each one is boolean
14:12:05 <jasoncallaway> So Shell Shock, for example, would be sTride
14:12:12 <jasoncallaway> Reverse shells being tampering
14:12:20 <jasoncallaway> We're using a spectrum, instead
14:12:26 <jasoncallaway> Of 0-9 for each category
14:12:45 <jasoncallaway> So something that results in a reverse shell every time would be 090000
14:13:12 <jasoncallaway> If it's buggy, and results in a crashed service, it might be 050020
14:13:25 <jasoncallaway> If say, only 50% of the time you get the reverse shell, and 20% of the time it crashes the listening daemon
14:13:45 <jasoncallaway> #action jasoncallaway to determine if STRIDE is license or TM encumbered
14:13:59 <jasoncallaway> Still don't know for sure if it's safe for Fedora to use this, I'll look into it
14:14:21 <jasoncallaway> #topic Cyber Test Lab
14:14:33 <jasoncallaway> Ok, onto CTL
14:14:54 <jasoncallaway> This is our open source implementation of the Cyber-ITL approach to risk quantification
14:15:18 <jasoncallaway> If you want to read more about the Cyber-ITL, I wrote a blog post about it a while ago
14:15:21 <jasoncallaway> #link https://blog.jasoncallaway.com/2016/11/02/cyber-itl-round-up/
14:15:52 <jasoncallaway> We've been pushing some alpha code for this to GitHub
14:16:02 <jasoncallaway> #link https://github.com/fedoraredteam/cyber-test-lab
14:16:15 <jasoncallaway> It works, kind of. It's super buggy
14:16:21 <jasoncallaway> But I've got issues open to track the various problems
14:16:34 <jasoncallaway> We also have some preliminary results
14:16:47 <jasoncallaway> #link https://github.com/fedoraredteam/ctl-results
14:17:06 <jasoncallaway> We're checking for a number of metrics right now
14:17:19 <jasoncallaway> We've got the output from hardening-check(1)
14:17:32 <jasoncallaway> Which tells us about binary hardening, things like
14:17:51 <jasoncallaway> Position independent exection, which indicates whether or not a binary is taking advantage of ASLR
14:18:21 <jasoncallaway> Immediate binding
14:18:30 <jasoncallaway> Read-only relocations (RELRO)
14:18:33 <jasoncallaway> Stack protection
14:18:41 <jasoncallaway> Function fortification
14:19:10 <jasoncallaway> hardening-check is able to print out the various functions being called, and whether or not they're the fortified versions
14:19:29 <jasoncallaway> One thing we don't have yet is a scoring mechanism
14:19:34 <jasoncallaway> For example
14:19:39 <jasoncallaway> How bad is sprintf?
14:19:53 <jasoncallaway> Is it worse than an unbounded memcpy?
14:20:01 <jasoncallaway> Dunno yet
14:20:14 <jasoncallaway> #action create function risk scoring system
14:20:34 <jasoncallaway> We're also getting cyclomatic complexity and cycle cost numbers from radare2
14:20:41 <jasoncallaway> Which is awesome and very easy
14:20:45 <jasoncallaway> The only problem is that it's slow
14:21:51 <jasoncallaway> So we need to either, a) create function call graph generation logic so we can calculate CC ourselves, or b) brute force the r2 approach with a distributed architecture
14:22:04 <jasoncallaway> We could do a with Capstone Enginer, which I believe r2 uses anyway
14:22:25 <jasoncallaway> But I favor b, because we could potentially be much faster than a more-efficient single threaded approach
14:22:49 <jasoncallaway> #action add a distributed architecture to ctl
14:23:08 <jasoncallaway> I've been talking a lot, any questions on stuff so far?
14:23:57 <jasoncallaway> Cool cool, ok moving on
14:24:01 <jasoncallaway> #topic PTES
14:24:33 <jasoncallaway> The Pen Testing Execution Standard was started by a few pentesters back around 2014
14:24:39 <jasoncallaway> Dave Kennedy was a co founder
14:24:52 <jasoncallaway> We were lucky enough to have him keynote our Defense in Depth event
14:24:54 <jasoncallaway> He killed it
14:25:18 <jasoncallaway> But we got a chance to talk about PTES and how we'd like to reinvograte the project
14:25:36 <jasoncallaway> Last year I took a stab at modernizing the source
14:25:43 <jasoncallaway> Which right now lives on a MediaWiki server
14:25:48 <jasoncallaway> There's no easy way to contribute changes
14:25:55 <jasoncallaway> So I threw this together
14:25:56 <jasoncallaway> #link http://pentest-standard.readthedocs.io/en/latest/
14:26:16 <jasoncallaway> The idea is to use GitHub and some modern vis layer to make it easier to collaborate with the community
14:26:32 <jasoncallaway> Right now it's using RTD and Sphynx with reStructured Text
14:26:37 <jasoncallaway> There are probably better options
14:26:52 <jasoncallaway> Like GitHub Pages
14:27:02 <jasoncallaway> Or ASCII Binder
14:27:14 <jasoncallaway> So we've got a couple actions there
14:27:39 <jasoncallaway> #action circle back with PTES project leadership to migrate official project to GitHub
14:27:56 <jasoncallaway> #action decide on vis layer -- RTD, GitHub Pages, ASCII Binder, etc
14:28:24 <jasoncallaway> #topic Reference Architectures
14:28:42 <jasoncallaway> We talked about this at our last meeting, we have two reference architectures we want to address in the near term
14:29:03 <jasoncallaway> Cyber Range defintion, eseential characteristics, deployment models, Ansible automation, etc
14:29:13 <jasoncallaway> And Next Generation Malware Analysis, which builds on the previous
14:29:22 <jasoncallaway> We've got a bunch of copy and diagrams ready to go internally
14:29:38 <jasoncallaway> But we haven't been able to close on getting that out
14:29:52 <jasoncallaway> #action post initial cut at Cyber Range reference architecture
14:30:35 <nsabine> We're working on an initial reference archtecture whitepaper
14:31:33 <nsabine> the initial architecture will use virtualization technologies to provide logical separation of tenants
14:32:22 <nsabine> this will provide protection for some categories of malware, but obviously with logical separation, there are cases where breakouts can still occur
14:33:21 <nsabine> so the architecture must provide a mechanism for physical separation to allow for research of hypervisor exploits
14:34:50 <nsabine> so the planned architecture will have an automation layer that will be able to destroy and provision new logical clouds on to physical hardware
14:35:34 <nsabine> There is an open question on how to properly clean the hardware layer - if a breakout has subverted a hypervisor, what is sufficient to "clean" the hardware so that it ready for reuse
14:35:52 <nsabine> as in, how do you know if the firmware layer is trustable?
14:35:53 <jasoncallaway> Oh interesting. Like firmware malware?
14:35:57 <jasoncallaway> Yeah
14:35:58 <nsabine> exactly
14:36:09 <nsabine> how do you prove that the hardware is trustable...
14:36:14 <jasoncallaway> Would that be firmwalware? :)
14:36:23 <nsabine> infirm?
14:36:29 <jasoncallaway> infirmware!
14:36:31 <jasoncallaway> TM
14:36:31 <nsabine> :)
14:37:08 <nsabine> so research is needed to determine how to effectively do that... is reflashing the firmware necessary?  Does it matter?
14:37:33 <jasoncallaway> Maybe some platforms let you do that with IMPI?
14:38:09 <nsabine> so there are open questions, but we are taking a first stab at an framework that enables automated provisioning of the software layers on bare metal
14:38:17 <jasoncallaway> Cool
14:38:33 <nsabine> re: IPMI .... maybe?
14:38:34 <jasoncallaway> Do you have a timeframe on when you might be able to push an initial cut?
14:38:51 <jasoncallaway> Or does that depend on the general Cyber Range one being sorted first?
14:39:57 <nsabine> I haven't committed to a timeframe yet :)  I'd love to have a decent draft out by the calendar year
14:40:10 <jasoncallaway> Cool
14:40:30 <jasoncallaway> #topic Pen Tests
14:40:46 <jasoncallaway> We had talked last time about a probono pentest of the Eclipse Foundation
14:40:57 <jasoncallaway> Do we have any folks from Eclipse online?
14:41:28 <jasoncallaway> They were mostly tied up prepping for and attending EclipseCon EU
14:41:54 <jasoncallaway> So we're trying to close the loop there
14:42:11 <jasoncallaway> #action nail down timeframe for Eclipse pentest
14:42:24 <jasoncallaway> #topic Community Development
14:42:31 <jasoncallaway> Just a couple quick community annoucements
14:42:35 <jasoncallaway> We have a few new core team members
14:42:48 <jasoncallaway> Lucy Kerner and Nathaniel McCallum have joined
14:42:53 <jasoncallaway> It's great to have them
14:43:22 <nsabine> Welcome Lucy & Nathaniel!
14:43:39 <jasoncallaway> Lucy's got some cool experience with hybrid cloud automation, and she's showing deep inspection of VMs and cloud instances, scanning for regulatory compliance, cool stuff
14:43:56 <jasoncallaway> Nathaniel comes to us from our security engineering team, and is a true cypherpunk
14:44:10 <jasoncallaway> I don't know many folks who have crypto key exchange mechanisms named after them
14:44:18 <jasoncallaway> But he does :)
14:44:34 <jasoncallaway> So we're looking forward to working on supply chain security issues with the CTL stuff
14:44:50 <jasoncallaway> We also plan to become active in the Core Infrastructure and CHAOSS projects at the Linux Foundation
14:45:09 <jasoncallaway> We'll have more to share in December there
14:45:19 <jasoncallaway> Also, we got a pretty epic +1 for CTL
14:45:38 <jasoncallaway> Mudge himself gave us a shout out on twitter
14:45:41 <jasoncallaway> #link https://twitter.com/dotMudge/status/921751325485907968
14:46:13 <jasoncallaway> So that's awesome, and I'm super pleased that Cyber-ITL proper has noticed and cares about our little corner of the world
14:46:41 <jasoncallaway> We were at BSidesDC and had a great time
14:46:50 <jasoncallaway> Handed out a ton of FRT data sheets
14:47:03 <jasoncallaway> #link https://jasoncallaway.fedorapeople.org/frt_datasheet.pdf
14:47:20 <jasoncallaway> We'll be at BSidesDE (Deleware) next weekend
14:47:28 <jasoncallaway> So I'll get that on our Fedocal
14:47:36 <jasoncallaway> #action be sure BSidesDE is on the red-team Fedocal
14:48:03 <jasoncallaway> #topic Review of previous action items
14:48:13 <jasoncallaway> Ok, winding down here, let's just loop back on stuff from last time
14:48:30 <jasoncallaway> I had an action to get Red Team swag ordered, but haven't closed that out yet
14:48:42 <jasoncallaway> I'm thinking about hoodies for folks who contribute cool code
14:48:47 <jasoncallaway> Kind of a team cred thing
14:48:49 <nsabine> sweet
14:49:01 <jasoncallaway> So I'll continue working that
14:49:19 <jasoncallaway> #action design and price-out Red Team swag
14:49:45 <jasoncallaway> Like I mentioned, the Red Team Fedocal is up!
14:49:48 <jasoncallaway> #link https://apps.fedoraproject.org/calendar/red-team/
14:49:56 <jasoncallaway> So you can subscribe to that for calendar updates
14:50:23 <jasoncallaway> Last time charcol offered to help with ELEM documentation, so I'll reach out to her on that topic and see if she's had any cycles to work it
14:50:48 <jasoncallaway> I know this isn't a super-convenient timeslot for some TZs, so apologies to those who can't make this interactively
14:50:55 <jasoncallaway> #action check with charcol on ELEM documentation
14:51:30 <jasoncallaway> And like I mentioned earlier, the Trello board for exploit curation crowdsourcing is up at https://trello.com/b/1fbRYkiQ/exploit-curation
14:51:45 <jasoncallaway> That's everything I've got
14:51:52 <jasoncallaway> Anybody else?
14:53:50 <nsabine> Jason, I think we need a write-up on how to curate an exploit on trello
14:54:04 <jasoncallaway> Oh, that's a good point
14:54:09 <nsabine> it's not clear what steps a community member needs to take to contribute
14:54:16 <jasoncallaway> Yeah, totally
14:54:33 <jasoncallaway> #action write up curation crowdsourcing how-to article
14:54:41 <jasoncallaway> Great catch, nsabine, thanks!
14:55:07 <jasoncallaway> Cool, thanks for joining!
14:55:13 <jasoncallaway> #endmeeting