HTTP Sensitive POST bro policy

Hi all:

For a number of reasons, I elected to write the attached bro policy, which looks at http POSTs and performs regular expression matching on the posted data. The regular expression, by default, looks for the words password or passwd in upper or lower case in an attempt to find HTTP authentications via posted form.

Unlike the heartbleed stuff, it does not require a special version of Bro, just @load it, will create notices of what it finds.

There are a few knobs that can be adjusted that are documented in the script.

The only problem with this script is that it is finding way too much - there are way too many cleartext authentications going on.   If you look at outbound traffic
​,​

 you just might see major corporations with security fails.....

​There's some additional tweaks I want to make to this script, but it is usable as is.  I hope if you run this, there aren't too many alarming​ results in your traffic.

Kudos to the first person who finds the minor inconsistency that I elected not to address.

​Hope this helps,


​Jim Mellander


NERSC Cybersecurity

http-sensitive_POSTs.bro (2.76 KB)

For a number of reasons, I elected to write the attached bro policy, which looks at http POSTs and performs regular expression matching on the posted data.

Thanks for sharing.

Kudos to the first person who finds the minor inconsistency that I elected not to address.

Maybe not what you were referring to, but I had two concerns:

(1) “connection_end” doesn’t seem to be a defined event, maybe it's meant to be “connection_state_remove”.

(2) Having the global “POST_entities” and “POST_requests” tables without &read_expire (or another expiry attribute) makes me nervous. Though I think the clean up in “http_end_entity” should catch everything, if it doesn’t, that will lead to memory usage issues over time (especially since “connection_end” won’t be a cleanup safety net as intended).

- Jon

Thanks for the input.

  1. At some point in the past, ISTR bro did have a connection_end event - at least thats what my failing memory tells me. In any event, it seems like a bug to not even give a warning if you have an event handler for a non-existent event - a typo could cause difficult to detect errors.

  2. Good catch, probably should have an expiration.

The minor inconsistency that I had in mind is the fact that the length of the entity is checked whilst assembling the POST response without unescaping, and checked unescaped in the http_end_entity…

It’s a bit tricky (or maybe noisy) to warn on that because it’s also perfectly valid to define a new event handler like that and then generate the event from a script instead of from Bro’s internals (e.g. there could be some other script that does "event connection_end(c);”). But I agree about it being an error that’s easy to make and hard to find. For what it’s worth, there’s a script-layer option that you can “redef” called “check_for_unused_event_handlers” that will give such warnings in reporter.log.

- Jon

Neat trick Jim. :slight_smile:

This actually brings up something that I've been meaning to work on for quite a while that would make this job *a lot* easier and work better...

  .Seth