From Fedora Project Wiki

Time: 1400 UTC

Location: Freenode IRC #fedora-security

Agenda

  • State of the SIG
  • Active projects
    • ELEM
      • Enterprise Linux Exploit Mapper
      • Ken Evensen lead developer
      • Quick description and update
      • Exploit curation crowdsourcing (Trello board)
    • FCTL
      • Replication of Cyber-ITL methodology and results in an open source and repeatable way
      • Using a handful of open source tools to analyze binaries
      • Radare2
      • Capstone Engine
      • hardening-check
      • Results currently go into Mongo
      • Looking to transition to ELK for better vis layer
      • Plan to analyze RHEL, CentOS, and Fedora
      • Would love community contributions for other OSes
  • Roadmap projects
    • Fedora Security Data API
    • Red Container
      • Kali is great, the world doesn’t need another security distro
      • OCI makes packaging efforts obsolete
    • PTES
      • Spoke with David Kennedy (cofounder), who keynoted our Defense in Depth event this week
      • We’re going to work with the project, no need to fork
      • Plan to migrate to GitHub / RTD interface
      • Next touchpoint is late October, should have an update by next SIG meeting
    • Reference Architectures
      • Two planned
      • Using GitHub / RTD for this as well to support collaboration
      • Definition of Cyber Range
        • About 50% complete
        • Much of the diagrams and copy can be taken from proposals we’ve written
      • Next-Generation Malware Analysis
        • Also about 50% complete
        • Can re-use proposal work
      • For each, targeting similar structure to NIST SP800-145
        • Essential characteristics
        • Deployment models
        • Service models
      • Should be active by next SIG meeting
    • Pen tests
      • Eclipse Foundation
        • Partner closely with them on other topics, JEE, Geospatial
        • Started coordination with Eclipse for a pro bono pen test
        • Need to pick this back up
        • Plan to use this to flesh out PTES needed updates
        • Will open source pen test report after findings are remediated
      • Looking for other clients who would like a pen test so we can better update PTES
  • Team to-do
    • Order swag, looking for recommendations, probably hats
    • Need to get team calendar set up
    • Better document ELEM
    • Add more instructions to Trello for curation crowdsourcing

Minutes

 08:44 -!- Topic set by Sparks [~Sparks@redhat/sparks] [Mon Nov  9 13:50:48 2015]
 08:44 [Users #fedora-security]
 08:44 [ _0x5eb_   ] [ Caterpillar ] [ hkario       ] [ mhayden  ] [ patricku   ] [ tyll_   ]
 08:44 [ anthraxx  ] [ charcol     ] [ ingvarha     ] [ mmercer_ ] [ pbrobinson ] [ warren  ]
 08:44 [ Astranox  ] [ cliff-hm    ] [ jasoncallaway] [ muep     ] [ pjp        ] [ zodbot  ]
 08:44 [ athmane   ] [ danofsatx   ] [ Jesin        ] [ N3LRX    ] [ puiterwijk ] [ zoglesby]
 08:44 [ awestin1  ] [ davidstrauss] [ jonatoni     ] [ nb       ] [ relrod     ]
 08:44 [ bowlofeggs] [ dazo        ] [ jtaylor90    ] [ nirik    ] [ Shad0w_Crux]
 08:44 [ bress     ] [ dgilmore    ] [ kushal       ] [ noctavian] [ simo       ]
 08:44 [ c0mrad3_  ] [ dmalcolm    ] [ linuxmodder  ] [ OsakaFoo ] [ skamath    ]
 08:44 [ Casper_v2 ] [ FranciscoD  ] [ mbag         ] [ oszi     ] [ Sparks     ]
 08:44 -!- Irssi: #fedora-security: Total of 49 nicks [0 ops, 0 halfops, 0 voices, 49 normal]
 08:44 -!- Channel #fedora-security created Sun Nov 26 01:43:28 2006
 08:44 -!- Irssi: Join to #fedora-security was synced in 16 secs
 08:57 -!- Jesin [~Jesin@pool-72-83-138-15.washdc.fios.verizon.net] has quit [Quit: Leaving]
 09:09 < linuxmodder> I'll be traveling damn near till start time but be there in spirit if nothing else and catch up at bsidesdc
 09:26 < jasoncallaway> linuxmodder: no worries, see you tomorrow
 09:27 < linuxmodder> not coming today for day 1 jasoncallaway
 09:31 -!- nirik [~nirik-fre@96.71.165.137] has quit [Ping timeout: 246 seconds]
 09:39 -!- nirik [~nirik-fre@96.71.165.137] has joined #fedora-security
 09:46 -!- mode/#fedora-security [+o jasoncallaway] by ChanServ
 09:47 -!- jasoncallaway changed the topic of #fedora-security to: Fedora Red Team meeting 1400-1500 UTC
 09:47 -!- mode/#fedora-security [-o jasoncallaway] by ChanServ
 09:55 -!- k6n [~k6n@pool-100-15-218-58.washdc.fios.verizon.net] has joined #fedora-security
 09:58 -!- nsabine [~nsabine@pool-173-66-170-163.washdc.fios.verizon.net] has joined #fedora-security
 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> 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> 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 -!- 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> 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 anlysis
 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> 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> Just actions now
 10:57 < jasoncallaway> 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> 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> I've got that Trello board up for ELEM curation crowdsourcing
 10:59 < jasoncallaway> But 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> Oh, and 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 -!- mode/#fedora-security [+o jasoncallaway] by ChanServ
 11:02 -!- jasoncallaway changed the topic of #fedora-security to: Fedora Security help room | We try to answer security questions here. | DO
         NOT DISCUSS EMBARGOED INFORMATION HERE. | Additional information: https://fedoraproject.org/wiki/Category:Security
 11:03 -!- mode/#fedora-security [-o jasoncallaway] by ChanServ
Retrieved from "https://fedoraproject.org/w/index.php?title=Fedora_Red_Team_meeting_6_October_2017&oldid=502988"