add kolide_jwt parsing table #1440

zackattack01 · 2023-11-06T20:23:51Z

This adds a kolide_jwt table to parse claims from a JWT when queried against a file path containing one. The general functionality is similar to the kolide_json table, requiring a valid path to an existing file, and parsing the contents where available:

osquery> select * from kolide_jwt where 1=1;
Error: error generating table: The kolide_jwt table requires that you specify a single constraint for path
osquery> select * from kolide_jwt where path='/tmp/data.zta';
+---------------------------------+-------------------+---------------+----------------------------------+-------+---------------+
| fullkey                         | parent            | key           | value                            | query | path          |
+---------------------------------+-------------------+---------------+----------------------------------+-------+---------------+
| verified                        |                   | verified      | false                            | *     | /tmp/data.zta |
| claims/iat                      | claims            | iat           | 1614791923                       | *     | /tmp/data.zta |
| claims/platform                 | claims            | platform      | Windows 10                       | *     | /tmp/data.zta |
| claims/serial_number            | claims            | serial_number |                                  | *     | /tmp/data.zta |
| claims/sub                      | claims            | sub           | 99999c489c1a499999ef5b213ee99999 | *     | /tmp/data.zta |
| claims/typ                      | claims            | typ           | crowdstrike-zta+jwt              | *     | /tmp/data.zta |
| claims/assessment/os            | claims/assessment | os            | 77                               | *     | /tmp/data.zta |
| claims/assessment/sensor_config | claims/assessment | sensor_config | 30                               | *     | /tmp/data.zta |
| claims/assessment/version       | claims/assessment | version       | 2.0.1                            | *     | /tmp/data.zta |
| claims/assessment/overall       | claims/assessment | overall       | 48                               | *     | /tmp/data.zta |
| claims/exp                      | claims            | exp           | 1616001523                       | *     | /tmp/data.zta |
| header/typ                      | header            | typ           | JWT                              | *     | /tmp/data.zta |
| header/alg                      | header            | alg           | RS256                            | *     | /tmp/data.zta |
| header/kid                      | header            | kid           | US-1/v1                          | *     | /tmp/data.zta |
+---------------------------------+-------------------+---------------+----------------------------------+-------+---------------+
osquery> select value from kolide_jwt where path='/tmp/data.zta' and fullkey='claims/assessment/overall';
+-------+
| value |
+-------+
| 48    |
+-------+

This closes #1327

directionless · 2023-11-06T20:32:28Z

pkg/dataflatten/jwt.go

+
+	// attempt decode into the generic (default) MapClaims struct to ensure we capture
+	// any claims data that might be useful
+	token, _, err := new(jwt.Parser).ParseUnverified(string(tokenRaw), jwt.MapClaims{})


What's the second return value?

this is parts = strings.Split(tokenString, ".") - we are essentially just base64 decoding parts[1] in the remaining bits

Is there anything to extract from the other parts?

we will get the header now too per the conversation below. I can include the raw signature as well if you think that would be helpful?

I don't think we should return the raw signature. Or the contents of the file

directionless

Doing it in pkg/dataflatten is a little weird, but I think okay. Mostly, I think of things down in here as low level, and we can build atop them. And I'm not sure what's going to want to build on this. But 🤷 it's no different than plist. So it's probably fine?

OTOH, if we wanted to bring in validation, we'd need to refactor. OTOH, we could refactor if/when we care.

pkg/dataflatten/jwt.go

directionless · 2023-11-06T20:35:39Z

pkg/dataflatten/jwt.go

+	for k, v := range claims {
+		results[k] = v
+	}


Do we need results or can we pass claims straight to Flatten?

And is there any more data we should pass back? Like, this is claims, but is there more? I kinda want to return

struct { Claims: map[string]any }

Because then if we add validate, or file metadata, or ???, we won't need to change the structure.

I can try that out! we could additionally include the header (likely containing the signing algo) but in general its just:

Header Payload Signature

algo claims signature

type (=JWT)

Algo seems interesting. An issued timestamp if one exists...

And someday I think it would be super interesting to get a validation in, and that would give us a place to hang it. I guess we could preemptively add validated: false or similar.

we can't pass claims to flatten directly but that will work for the header and signature. the registered claim for timestamp will be at claims->iat if included. and I will add a validated false for clarity here, thank you!

PR description is updated with the new format discussed here

RebeccaMahany

I'm good with this as-is, but also like seph's suggestion https://github.com/kolide/launcher/pull/1440/files#r1383951951 -- happy to reapprove if you update

pkg/dataflatten/jwt.go

… header

directionless

Sweet!

As a side note, GitHub has special syntax for how to link PRs to Issues and have them mark them as closed and whatnot. https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

zackattack01 added 2 commits November 3, 2023 16:13

add JWT parsing table logic

950ba19

re-implement similar to ini and json tables

71f83d8

directionless reviewed Nov 6, 2023

View reviewed changes

RebeccaMahany previously approved these changes Nov 6, 2023

View reviewed changes

pkg/dataflatten/jwt.go Show resolved Hide resolved

PR Feedback: nest claims in jwt JSON and include anything parsed from…

6b76a97

… header

zackattack01 dismissed RebeccaMahany’s stale review via 6b76a97 November 6, 2023 21:19

Merge branch 'main' into zack/jwt_parser

e0946d5

directionless approved these changes Nov 7, 2023

View reviewed changes

RebeccaMahany approved these changes Nov 7, 2023

View reviewed changes

zackattack01 added this pull request to the merge queue Nov 7, 2023

Merged via the queue into main with commit 837a7c8 Nov 7, 2023
24 checks passed

zackattack01 deleted the zack/jwt_parser branch November 7, 2023 14:45

directionless added the component:table label Nov 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add kolide_jwt parsing table #1440

add kolide_jwt parsing table #1440

zackattack01 commented Nov 6, 2023 •

edited

Loading

directionless Nov 6, 2023

zackattack01 Nov 6, 2023

directionless Nov 6, 2023

zackattack01 Nov 6, 2023

directionless Nov 6, 2023

directionless left a comment

directionless Nov 6, 2023

zackattack01 Nov 6, 2023

directionless Nov 6, 2023

zackattack01 Nov 6, 2023

zackattack01 Nov 6, 2023

RebeccaMahany left a comment

directionless left a comment

add kolide_jwt parsing table #1440

add kolide_jwt parsing table #1440

Conversation

zackattack01 commented Nov 6, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

directionless left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RebeccaMahany left a comment

Choose a reason for hiding this comment

directionless left a comment

Choose a reason for hiding this comment

zackattack01 commented Nov 6, 2023 •

edited

Loading