09:58 < jasoncallaway> #startmeeting Red Team (2017-10-06)
09:58 <zodbot> Meeting started Fri Oct 6 14:00:48 2017 UTC. The chair is jasoncallaway. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
09:58 <zodbot> The meeting name has been set to 'infrastructure_(2017-10-05)'
09:58 < jasoncallaway> #meetingname red-team
09:58 <zodbot> The meeting name has been set to 'red-team'
09:58 < jasoncallaway> Ok, everybody, we're going to get started in a few minutes
09:58 < jasoncallaway> The agenda for today is at https://fedoraproject.org/wiki/FRT_meeting_20171006
09:59 < jasoncallaway> We'll also capture and post a log of this meeting for folks who might miss it
10:00 < jasoncallaway> #topic review
10:00 < jasoncallaway> First, a quick review
10:00 < jasoncallaway> The Fedora Red Team is a Fedora Project Special Interest Group (SIG)
10:01 < jasoncallaway> Our SIG page is at https://fedoraproject.org/wiki/SIGs/Red_Team
10:01 < jasoncallaway> We're doing our source control at https://github.com/fedoraredteam
10:01 < jasoncallaway> Our goal is to be Red Hat's cybersecurity upstream community
10:01 < jasoncallaway> We get a lot of questions about what that actually means
10:02 < jasoncallaway> On the SIG page we talk a bit about the etymology of the term
10:02 < jasoncallaway> But these days, "cyber" could be described as Computer Network Operations (CNO)
10:02 -!- MikeCamel [~mbursell @81.141.162.32] has joined #fedora-security
10:02 < jasoncallaway> That's broken down into Computer Network Defense (CND)
10:02 < jasoncallaway> Computer Network Exploitation (CNE)
10:02 < jasoncallaway> And Computer Network
10:02 < jasoncallaway> Comput Network Attack (CNA)
10:03 < jasoncallaway> So the name "Fedora Red Team" is a bit of an intentional misnomer
10:03 < jasoncallaway> But in a way, offensive R&D is a superset of defensive
10:04 < jasoncallaway> You can't do the former without also understanding (and developing) the latter
10:04 < jasoncallaway> For anybody reading the log of this, we're on Freenode IRC #fedora-security
10:04 < jasoncallaway> And you can subscribe to the Fedora Security list at security @lists.fedoraproject.org
10:05 < jasoncallaway> If you'd like to blog about Fedora Red Team, we'd encourage you to add your blog's category to Planet Fedora
10:06 < jasoncallaway> You can find instructions on how to do so here https://fedoraproject.org/wiki/Planet?rd=Planet_HowTo
10:06 < jasoncallaway> We're on the Security subplanet here http://fedoraplanet.org/security/
10:06 < jasoncallaway> #topic projects
10:06 < jasoncallaway> Ok, let's talk about our projects
10:06 < jasoncallaway> We have two that are actively going at the moment
10:07 < jasoncallaway> The Enterprise Linux Exploit Mapper (ELEM) is coming along nicely
10:07 < jasoncallaway> k6n: you're the lead developer for ELEM, could you describe it a bit?
10:07 < k6n> certainly
10:07 < jasoncallaway> #topic elem
10:07 -!- lkerner [~lkerner @ip72-196-202-69.dc.dc.cox.net] has joined #fedora-security
10:08 < k6n> There are a number of sources of information for vulnerabilities as well as exploits.
10:08 < k6n> When a vulnerability is scored, often with CVSS, it is against theoretical exploits.
10:09 < k6n> And with the vulnerability is scored by the US NIST, it is scored only once and never updated.
10:10 < k6n> Some vulnerabilities are relevant to enterprise Linux, many aren't.
10:10 < k6n> So the point of ELEM is to help correlate, test and score exploits on enterprise Linux systems.
10:11 < k6n> The objective is to build a library of curated exploits that have each been tested on different enterprise Linux platforms.
10:11 < k6n> The ELEM tool is at https://github.com/fedoraredteam/elem.git
10:11 < k6n> The curation information is at https://github.com/fedoraredteam/elem-curation
10:12 < jasoncallaway> k6n: maybe we should describe the curation process
10:12 < k6n> The tool is beta at the moment.
10:12 < k6n> Yup.
10:12 < k6n> When we score the exploit, we are interested in a couple of things.
10:12 < k6n> What does the exploit do?
10:13 < k6n> How well does the exploit do it?
10:13 < jasoncallaway> If it works at all...
10:13 < k6n> We have to use an ontology that is comprehensive and comprehensible.
10:14 < k6n> We've chosen the STRIDE scheme.
10:14 < k6n> spoof, tamper, repudiate, information disclosure, denial of service, elevation of privilege
10:14 < jasoncallaway> Here's the link from Microsoft https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
10:15 < k6n> The approach right now is to assign a number 0-9 to each of the letters.
10:15 < k6n> For example, a shellshock exploit is an example of tampering.
10:15 < jasoncallaway> FWIW, we think we're ok using STRIDE. It's still unclear if it's license-encumbered in any way. We're researching.
10:15 < k6n> if an exploit works on a host, we would score it 090000
10:16 < k6n> Likely it would only do tampering very well, but not any of the others. However, the scoring schema allows for that
possibility.
10:17 < jasoncallaway> k6n: could an exploit ever have values in multiple columns? For example, what if the reverse shell works sometimes
but most times it crashes the process? Would that have a value in D?
10:17 < k6n> If that was the intent of the exploit, yes.
10:17 < jasoncallaway> (Obligitory "it's over 9000!" comment)
10:18 < k6n> But if it is an accidental side-effect of a tamper, then no
10:18 -!- MikeCamel [~mbursell @81.141.162.32] has left #fedora-security ["Leaving"]
10:19 < k6n> I'll pivot to the curation
10:19 < k6n> Our intent is to assess exploits mapped to CVE's on each of the enterprise Linux platforms (RHEL, Fedora, CentOS)
10:19 < k6n> We are starting with RHEL.
10:20 < k6n> Furthermore, we want to look at both RHEL 6 and 7.
10:20 < k6n> And desktop, workstation and server.
10:20 < k6n> This is no small undertaking.
10:20 < jasoncallaway> So I ran an elem refresh and elem assess on a RHEL 7.0 system
10:20 < jasoncallaway> It mapped 138 CVEs to known exploits
10:21 < jasoncallaway> I think we've curated 12 of those
10:21 < k6n> It takes some time.
10:21 < jasoncallaway> So there's a lot of work to do with testing these
10:22 < jasoncallaway> We need to crowdsource that
10:22 < k6n> As I mentioned earlier, we've separated the tool from the data
10:22 < k6n> Initially it was all in one repo, but that didn't work for long.
10:22 < k6n> The curation information will remain under version control.
10:22 < k6n> We welcome pull requests.
10:23 < jasoncallaway> I've set up a public Trello board at https://trello.com/b/1fbRYkiQ/exploit-curation
10:23 < k6n> Please note that we will only accept pull requests with commits signed with a GPG key
10:23 < jasoncallaway> I'll be writing some Python to create all cards for mapped EDBID->CVE relationships
10:23 < k6n> cool
10:23 < jasoncallaway> Then it'd be great if folks could find an untested mapping and test it
10:24 < jasoncallaway> There's value in re-testing these, as well. It could be we'll score something with a 4, as in, it's hard to get to
work reliably, but maybe we did something wrongly and somebody else was able to get the exploit to work nicely
10:25 < jasoncallaway> There's also some challenge in setting up the test harness
10:25 < k6n> That's right
10:25 < k6n> In order to expedite testing, we've created an Ansible role to help
10:25 -!- Jesin [~Jesin @wsip-72-194-198-163.dc.dc.cox.net] has joined #fedora-security
10:25 < k6n> https://github.com/fedoraredteam/cyber-test-range-target
10:26 < k6n> By specifying a list of CVE's, the role will ensure the target host is vulnerable by downgrading packages if necessary.
10:26 < jasoncallaway> Oh, cool
10:26 < jasoncallaway> So it'll downgrade a fully patched system?
10:27 < k6n> Potentially, yes.
10:27 < k6n> So in the Red Hat Security API, the "fixed" package is listed for a CVE
10:27 < k6n> Using Yum and Ansible, we can determine which package is one step down from that version
10:28 < k6n> If a host is already vulnerable to a CVE, the role happily ignores it.
10:28 < k6n> If not, it will yum downgrade that package.
10:28 < k6n> This done by a combination of custom facts as well as a custom lookup plugin
10:29 < jasoncallaway> Should we consider an enhancement PR to the yum Ansible module for package downgrade?
10:29 < k6n> So the Ansible role has a Red Hat Security API lookup plugin
10:29 < k6n> It already does that for us
10:29 < jasoncallaway> Oh, but we need the version number first? It would be nice if we could just do version-1 or something
10:29 < jasoncallaway> Or latest-1 I mean
10:30 < nsabine> You're assuming latest-1 is what you want
10:31 < nsabine> You might want a version from 6 months ago
10:31 < jasoncallaway> Ah, good point
10:31 < k6n> Indeed
10:31 < k6n> so the way it works at the moment is...
10:31 < k6n> First, Ansible runs the setup module and builds custom facts per the role
10:32 < k6n> The available_packages.fact results in a dictionary of all packages available
10:32 < k6n> including the "next" and "previous" version
10:32 < k6n> Kind of like a double linked list
10:32 < jasoncallaway> Ooooh, ok cool
10:33 < jasoncallaway> +1 for your Ansible kungfu, k6n
10:33 < k6n> When the lookup plugin grabs the package info from the api, we know what the dowgrade version is
10:33 < k6n> *downgrade
10:33 < k6n> The role uses the yum module to install that version
10:34 < k6n> As an aside, I hadn't put this on Ansible Galaxy yet.
10:34 < k6n> Should we?
10:34 < jasoncallaway> Totes mcgrotes
10:34 < jasoncallaway> Ok, so we're looking for community members to help out with curation crowdsourcing
10:35 < jasoncallaway> I think this is a good place to point people when they say, "cool, how can I help?"
10:35 < jasoncallaway> Also, it's a good introduction to cybersecurity for folks new to the field
10:35 < jasoncallaway> Anything else on ELEM, or should we move on?
10:36 < k6n> nope
10:36 < jasoncallaway> Ok
10:36 < k6n> let's move along
10:36 < jasoncallaway> #topic fctl
10:36 < jasoncallaway> Fedora Cyber Test Lab
10:37 < jasoncallaway> I really wanted this to be FTL, by the way, for "faster than light"
10:37 < jasoncallaway> But we're not testing all of Fedora, so it seemed wrong
10:37 < k6n> ^Can you approve my Git org request when you get a chance?
10:37 < jasoncallaway> yup
10:37 < jasoncallaway> So FCTL is our open source implementation of the Cyber-ITL approach to risk quantification
10:37 < k6n> Sorry, didn't mean to hijack your thought process
10:38 < jasoncallaway> np
10:38 < jasoncallaway> The git repo is here https://github.com/fedoraredteam/cyber-test-lab but it's empty
10:38 < jasoncallaway> I have a 0.1 ready to go but haven't pushed it yet
10:38 < jasoncallaway> Meant to do that last night but got busy with our FRT datasheet for BSidesDC tomorrow
10:39 < jasoncallaway> Which, for anybody who wants it, is here https://jasoncallaway.fedorapeople.org/frt_datasheet.pdf
10:40 < jasoncallaway> I need to double-check with the Fedora Design Team that we're good on logo usage. I reviewed their usage page, which
is here https://fedoraproject.org/wiki/Logo/UsageGuidelines, and I think we're good, but I'd like a confirmation
10:40 < jasoncallaway> I'll take that action for Tuesday (I'm on PTO on Monday since BSides is all weekend)
10:40 < jasoncallaway> Ok, back to FCTL
10:41 < jasoncallaway> The Cyber-ITL approach was described at Def Con 24 (https://youtu.be/GhO9vyW1f7w)
10:41 < jasoncallaway> They're trying to quantify the risk of using certain binaries via static and dynamic anlysis
10:41 < jasoncallaway> It looks awesome
10:42 < jasoncallaway> But I don't think they plan to open source their implementation
10:42 < jasoncallaway> And from a Fedora perspective, we might say, ok, how can we improve our score? But not have a way to easily check the
result
10:42 < jasoncallaway> So as I said, I'll be pushing my attempt at recreating their methodology
10:42 < jasoncallaway> It's not exact, but I think I can get close
10:43 < jasoncallaway> The plan track many of the same things the CTIL is
10:43 < k6n> cool
10:43 < jasoncallaway> Cyclomatic complexity, branch frequency...
10:43 < jasoncallaway> Binary hardening features like use of ASLR, RELRO, immediate binding, etc.
10:43 < jasoncallaway> Also just function size is important
10:44 < jasoncallaway> We can do this with a number of FOSS tools
10:44 < jasoncallaway> Capstone Engine gives us a nice SDK for decompiling
10:44 < jasoncallaway> Radare2 takes things a little further and gives us an easy way to measure cyclomatic complexity since it can generate
a function call graph
10:45 < jasoncallaway> An awesome engineer at Google named Kees Cook wrote a tool called hardening-check that looks for binary hardening
10:45 < jasoncallaway> Oh, function fortification and use of bad functions are another metric
10:45 < jasoncallaway> The latter is harder for us to score
10:46 < jasoncallaway> Because we have some idea of good and bad functions, but we don't really have a spectrum of bad function riskiness
10:46 < jasoncallaway> And that's just the static analysis
10:46 < jasoncallaway> The next step is to assemble a score on a per-binary basis using those metrics
10:46 < jasoncallaway> And we need to dial in the weight of each
10:47 < jasoncallaway> Then we look at the low-hanging fruit
10:47 < jasoncallaway> And start fuzzing
10:47 < jasoncallaway> Which should turn up all sorts of interesting crashes
10:47 < jasoncallaway> At DC 25 this year, Sarah Zatko provided a CITL update
10:47 < jasoncallaway> I haven't been able to find a video of it
10:47 < jasoncallaway> If anybody has one, I'd love it
10:48 < jasoncallaway> She described the number of crashes they were able to generate
10:48 < jasoncallaway> I believe in the CITL blog they mentioned their fuzzing environment has about 100 cores
10:48 < jasoncallaway> Maybe 80, I can't remember
10:48 < jasoncallaway> I have about 50 at home in my lab here I can use
10:49 < jasoncallaway> Still, there's lots of work to do, and I'm sure I'm getting lots of stuff wrong
10:49 < jasoncallaway> But that's the point of doing it open source
10:49 < jasoncallaway> I'll also post the results to some static analysis runs for RHEL 7, CentOS 7, and Fedora 26
10:49 < jasoncallaway> Probably as JSON objects
10:49 < jasoncallaway> Right now I'm dumping stuff into Mongo
10:50 < jasoncallaway> But I think ELK will be a better choice with nicer vis options
10:50 < jasoncallaway> Any questions or comments on FCTL?
10:50 < jasoncallaway> We're running low on time so let's blast through the last parts
10:50 < jasoncallaway> #topic roadmap-projects
10:50 < jasoncallaway> Projects on the road map
10:51 < jasoncallaway> Fedora needs its own Security Data API, so we'll be working on that
10:51 < jasoncallaway> Folks ask me if we're making a Kali for Fedora, the answer is NO
10:51 < jasoncallaway> I don't see any value in that
10:51 < jasoncallaway> Kali is great, and there are already many other security distros
10:51 < jasoncallaway> Fedora Security Lab, too
10:52 < jasoncallaway> But I would like to see more granular container images for Kali tooling
10:52 < jasoncallaway> Right now the Kali docker image is like a full install
10:52 < jasoncallaway> What if I just wanted an individual tool like nmap?
10:52 < nsabine> jasoncallaway: You said you have 0.1 almost ready to push. When do you expect to push that?
10:52 < jasoncallaway> (Bad example, that's already packaged in rpm)
10:52 < nsabine> (on the FCTL)
10:52 < jasoncallaway> nsabine: good question. I hope to do that tonight, possibly this weekend while on booth duty at BSidesDC
10:53 < nsabine> ok, thanks
10:53 < jasoncallaway> So a containerization of infosec tools effort is what we meant by Red Container
10:53 < jasoncallaway> We're going to participate in the Pen Testing Execution Standard
10:53 < jasoncallaway> I got a chance to chat with Dave Kennedy of Binary Sec this week
10:54 < jasoncallaway> Hey keynoted our Defense in Depth conference
10:54 < jasoncallaway> And killed it, BTW
10:54 < jasoncallaway> He's a cofounder of PTES
10:54 < jasoncallaway> So we're looking forward to dusting that project off together
10:54 < jasoncallaway> We're going to work on reference architectures
10:55 < jasoncallaway> Two at first
10:55 < jasoncallaway> 1) A Definition of the Cyber Range, and 2) Next Generation Malware Analysis Cloud
10:55 < jasoncallaway> Both are about 50% done from proposal efforts
10:56 < jasoncallaway> We just need to clean up that content and make it ready for release
10:56 < jasoncallaway> Moving onto pen testing
10:56 < jasoncallaway> We're talking to the Eclipse Foundation about helping them out with a pen test of their infra
10:56 < jasoncallaway> In return, they might be able to help us with legal and IP stuff
10:56 < jasoncallaway> At which they kick ass
10:57 < jasoncallaway> Once we finish the pen test, and they get a chance to remediate, we'll open source the pen test report
10:57 < jasoncallaway> Everything will be tied back to PTES, and we'll use this as an oppotunity to update the latter
10:57 < jasoncallaway> So, our hour's almost up, and I want to be respectful of everybody's time
10:57 < jasoncallaway> #topic actions
10:57 < jasoncallaway> Just actions now
10:57 < jasoncallaway> #action I need to get some swag ordered now that we have a team logo
10:58 < jasoncallaway> https://pagure.io/design/issue/546
10:58 < jasoncallaway> #action We also need a team calendar
10:58 < jasoncallaway> Yesterday we had a great call with charcol on documentation
10:58 < jasoncallaway> So we're hoping to make the ELEM docs better
10:59 < charcol> I'm hoping to work on them this week sometime
10:59 < jasoncallaway> Hey, charcol!
10:59 < jasoncallaway> Thanks! You're awesome!
10:59 < jasoncallaway> #action charcol to write some elem documentation
10:59 < jasoncallaway> I've got that Trello board up for ELEM curation crowdsourcing
10:59 < jasoncallaway> #action I need to populate the cards with elem assess output
10:59 < jasoncallaway> And I think that's it
11:00 < jasoncallaway> Anybody else have anything to add?
11:00 < k6n> nope
11:01 < jasoncallaway> #action I'll get with Fedora Design on the data sheet
11:01 < jasoncallaway> Ok, thanks very much, everybody
11:01 < jasoncallaway> Hope to see the local folks at BSidesDC this weekend
11:02 < k6n> cool cool
11:02 < nsabine> thanks jason!
11:02 < jasoncallaway> #endmeeting