Thank you Alex; this was the conclusion I came to as well...I was hoping I
missed something in my ignorance of certs...
Now, to harass everyone I can find associated with Mandiant in the hopes of
getting those md5's... :)
Cheers,
Jesse
On Wed, Feb 20, 2013 at 3:57 PM, Alex Waher <alexwis(a)gmail.com> wrote:
> The most consistent/least-false-positive/sustainable way would be to use
> the public certificate's fingerprint, which bro calculates into an md5 and
> logs within ssl.log as 'cert_hash'. Unfortunately Mandiant's report does
> give us the cert hashes-- there might be intelligence communities out there
> that will soon release an appendix supplement with these fingerprints.
>
> Bro is not by default logging the cert serial number (btw, serial is
> controlled by whom issues the cert), so you'll have to dig through the
> issuer and subject strings to find a match based on the info in the APT1
> report.
>
> -Alex
>
>
> On Wed, Feb 20, 2013 at 12:18 PM, Mike Sconzo <sconzo(a)visiblerisk.com>wrote:
>
>> There are a couple different things you can look for.
>>
>> The serial number works pretty well in a lot of cases (I use this 99%
>> of the time w/o issue). The subject and issuer are useful for finding
>> odd SSL certs to begin with. A lof of their subjects and issuers are
>> pretty trash looking. If you were really paranoid you could combine
>> the 2 for a more accurate match. I'd also say having a 5 year validity
>> isn't too normal, but I don't have any hard data to back this up (just
>> from what I remember from doing analysis). Not to mention when subject
>> = issuer is also a give away for self signed, and while not
>> immediately malicious it tends to raise my eyebrow (for example, a
>> self signed mail.aol.com or mail.yahoo.com cert?). For the default bro
>> logs I'd look at servername, subject, not valid before and not valid
>> after; that should give you a reasonable starting place.
>>
>> As an aside this might be one of my favorites:
>>
>> C=US, ST=Washington, L=Anytown, O=ACLU, OU=A@@hole,
>> CN=NoName/emailAddress=iamnot(a)home.com
>>
>> Just by looking at subjects and/or issuers that should stand out
>> because that is not normal for legit network traffic. Sorry for the
>> tangent, but personally I'd be less worried about the specifics in the
>> report and more about the chances that it's something not in this
>> report on your network <FUD alert! :) >
>>
>> -=Mike
>>
>>
>>
>> On Wed, Feb 20, 2013 at 1:11 PM, Jesse Bowling <jessebowling(a)gmail.com>
>> wrote:
>> > Hi,
>> >
>> > So quite a few infosec folks are looking at Mandiant's APT1 report,
>> myself
>> > included...When I saw that they included some information on SSL certs
>> in
>> > use I thought "Oh, I'll bet I can check my Bro logs for that!".
>> > Unfortunately, I don't see a way to correlate the info from these
>> reports
>> > with my Bro logs (which is pretty vanilla).
>> >
>> > So I suppose my question(s) is/are:
>> >
>> > *Has anyone else seen a reliable way to correlate the report data with
>> Bro
>> > logs?
>> > *How might I change my Bro logs so that if I were given this info in the
>> > future I could reliably correlate it?
>> >
>> > I'm fairly ignorant about how much of an X509 cert one can see on the
>> wire;
>> > serial number seemed promising but is only "required" to be unique per
>> CA,
>> > Signature Algorithm seems promising, as does Public Key Modulus...
>> >
>> > Any suggestions/thoughts from the group?
>> >
>> > Cheers,
>> >
>> > Jesse
>> >
>> > http://intelreport.mandiant.com/
>> > http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf
>> > http://intelreport.mandiant.com/Mandiant_APT1_Report_Appendix.zip
>> >
>> > --
>> > Jesse Bowling
>> >
>> >
>> > _______________________________________________
>> > Bro mailing list
>> > bro(a)bro-ids.org
>> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>>
>>
>> --
>> cat ~/.bash_history > documentation.txt
>> _______________________________________________
>> Bro mailing list
>> bro(a)bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>
>
--
Jesse Bowling
Hey guys,
This group doesn't seem to mix with the hacker culture as frequently,
however I did a presentation at Shmoocon in DC this weekend.
I really tried to do a good job representing a lot of the things I have
seen in the Bro Community over the last few years. Please feel free to
give me any comments or sugestions.
http://www.youtube.com/watch?v=7DCPuHdCbpw
So far the response has been overwhelmingly positive; I really hope to
see a large number of interested parties- hackers, companies, and
administrators start to look into Bro as the result of this talk.
Thanks,
Liam Randall
Hi all,
I have a problem with logrotation under bro-ids. I use a rsyslog to
forward all bro-ids logs to a third syslog central server. Problem
appears when, every hour, broctl cron job rotates all bro logs. Rsyslog
fails queueing bro-ids logs if third syslog central server is down for
example.
Is it possible to rotate bro logs using logrotate program?? If not, is
it possible to launch a rsyslog restart when broctl cron rotates logs??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Hi,
In my /usr/local/bro/etc/broctl.cfg I've specified:
LogExpireInterval = 14
Additionally in /etc/cron.d/bro I've specified:
0-59/5 * * * * /usr/local/bro/bin/broctl cron
However I've found that I have more daily directories present that 14
days...What configuration options should I be checking to troubleshoot this
problem?
Thanks,
Jesse
--
Jesse Bowling
Hi,
When I need to search my bro log files, I find myself using 'zfgrep' quite
a bit...Out of the box this works fine, however I lose the ability to
translate epoch time to 'human readable' time. The examples I've seen
suggest "zcat $file | bro-cut -d" however this means that every line must
be run through awk, which greatly increases search times. for an example
search of a one hour http file, my 'bcut' method runs in 6.9 seconds, while
using bro-cut properly(? "zcat file | bro-cut -d | fgrep string") takes 5
minutes, 1.2 seconds. Doing my zfgrep before the bro-cut causes only blank
lines to be printed (I assume because there are no description fields to be
read).
The workaround I've been implementing is to:
# alias bcut
alias bcut='awk -f /usr/local/bin/epoch_to_human.gawk'
# cat /usr/local/bin/epoch_to_human.gawk
#!/bin/gawk
{
val=strftime("%Y-%m-%dT%H:%M:%S%z", $1, 0)
$1=val
print $0
}
# zfgrep '10.10.10.10' /usr/local/bro/logs/some_log.txt.gz | bcut
This works well enough. Tt would be nice if there were a switch to bro-cut
that would implement this functionality, however I'm unsure of how to
integrate it myself (most of my awk programs are one line throwaways). The
key would be make it clear that you cannot specify field selections with
bro-cut, that this would only attempt to translate the first field into a
"human readable" format. Some error checking is likely in order as well...
So, I suppose I'm requesting that someone with more gawk chops than myself
give a shot at integrating this into bro-cut, or give me some pointers and
I might be able to stumble through creating a patch for submission...Or,
perhaps I'm approaching this problem in the wrong way, and could use a
pointer on a better way to go about it (aside from "ship the logs elsewhere
that indexes searches"; we'll deal with that scenario later) :)
Cheers,
Jesse
--
Jesse Bowling
I have enabled cron from brocontrol and have this line in roots crontab:
0-59/5 * * * * /usr/local/bro/bin/broctl cron
> /dev/null 2>&1
On a reboot, bro never starts but I do get a bunch of these (5 minutes apart):
root 79339 0.0 0.3 91252 13940 ?? Is 2:10PM 0:00.08
/usr/local/bin/python /usr/local/bro/bin/broctl
if I start broctl from here and try to do anything I get 'cannot get
lock'. A killall python and I can do a start however the
"/usr/local/bin/python /usr/local/bro/bin/broctl"
processes keep on coming.
Am I missing something?
Thanks.
--
Paul Halliday
http://www.pintumbler.org/
So I wanted some Bro to capture the contents of HTTP POST's, and found in
the archives that Seth had already written such a thing:
module HTTP;
export {
## The number of bytes that will be included in the http
## log from the client body.
const post_body_limit = 1024;
redef record Info += {
post_body: string &log &optional;
};
}
event http_entity_data(c: connection, is_orig: bool, length: count, data:
string)
{
if ( is_orig )
{
if ( ! c$http?$post_body )
c$http$post_body = sub_bytes(data, 0,
post_body_limit);
else if ( |c$http$post_body| < post_body_limit )
c$http$post_body = string_cat(c$http$post_body,
sub_bytes(data, 0, post_body_limit-|c$http$post_body|));
}
}
So now my question is: in the output of the data, can we ensure that ALL
data is hex encoded, even if it's part of the ASCII character set? I need
to put this data into a feed, and not being able to count on a delimiter is
problematic...
Thanks,
Jesse
--
Jesse Bowling
Hi,
I believe what you're seeing is a result of how those timestamps are defined.
In conn.log[1]: "This is the time of the first packet."
In http.log[2]: "Timestamp for when the request happened."
The conn record doesn't get written until the connection closes (or times out). It happens during the connection_state_remove[3] event. By handling it at connection close, you get duration, byte/packet counts, etc.
Also, the times for when the first packet was seen, and when the actual HTTP request was seen can be slightly off.
Does this line up with what you're seeing?
--Vlad
[1] - <http://www.bro-ids.org/documentation/scripts/base/protocols/conn/main.html#…>
[2] - <http://www.bro-ids.org/documentation/scripts/base/protocols/http/main.html#…>
[3] - <http://www.bro-ids.org/documentation/scripts/base/event.bif.html#id-connect…>
On Feb 7, 2013, at 5:11 PM, <keqhe(a)cs.wisc.edu>
wrote:
> HI Everyone,
>
> We observe that the flows'timestamps in Bro log file are not strcitly in
> time order. Also we note that for the same flow, the timestamp in conn.log
> and the timestamp in http.log are not the same. Does anyone notice the
> problem before and have ideas on this? Thanks!
>
> _______________________________________________
> Bro mailing list
> bro(a)bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
HI Everyone,
We observe that the flows'timestamps in Bro log file are not strcitly in
time order. Also we note that for the same flow, the timestamp in conn.log
and the timestamp in http.log are not the same. Does anyone notice the
problem before and have ideas on this? Thanks!
