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