Thursday, January 16, 2020

Detecting CVE-2020-0601 with Zeek

CVE-2020-0601 is a major security issue affecting recent versions of Microsoft Windows. In a nutshell, NSA found a vulnerability in core Windows libraries that perform certificate validation. This vulnerability can be used to craft certificates that are accepted as valid by Windows - even though they do not have a valid signature of a trusted certificate authority. The vulnerability can, for example, be used to impersonate TLS servers, to fake signature, or to fake email and file signatures.
I will not go into exactly how the vulnerability works; however if you are interested in the mathematical background, check out  this post.
Hours after the announcement of the vulnerability, we published the first package that can detect TLS exploit attempts. This was followed by a second package, that gives a slightly higher quality signal, 24 hours  day later.
In this blog post, I will provide a high-level overview of some of the basics of the exploit,and how Zeek can be used to detect it.

Elliptic Curve Certificates

Elliptic Curve Cryptography (ECC) is a public-key cryptographic scheme. From a user perspective, it works similarly to RSA - there is a public key as well as a private key. In addition, for ECC the participants need to agree on the domain parameters making up the elliptic curve - typically these domain parameters are just referred to as “the curve.” These curves are generally not made up by the participants - instead they are chosen from lists of published curves. For example, a typical curve that is used is secp384r1, which was standardized by NIST in FIPS 186-4 (note: to make things slightly confusing NIST curves have two names - secp384r1 is referred to as P-384 in the NIST publication).
When creating a certificate that uses Elliptic Curve DSA (ECDSA) as the signature scheme, the curve is typically just referred to by name - meaning that in the ASN.1 representation of the X.509 certificate just the name of the curve is given. It is expected that all participants know the parameters of the well-known curves. An example certificate using ECDSA from the Zeek test suite looks like this (unnecessary details omitted):

 


Note the line saying “ASN1 OID: sec384r1” which defines the curve.
There is a second way to share the curve parameters in certificates: by defining them explicitly. Instead of just giving a curve name, in this case all parameters are included in the certificate. This feature nowadays is rarely used for a variety of reasons - and it is also not supported by most software. Indeed RFC 5840, which specifies the use of ECC in X.509 certificates in the Internet, specifically states that “specifiedCurve, which is of type SpecifiedECDomain type (defined in [X9.62]), allows all of the elliptic curve domain parameters to be explicitly specified. This choice MUST NOT be used.”
The following is the OpenSSL output for a certificate that contains an explicitly defined curve.


Note that the generator, order, etc., of the curve is given directly in the certificate. Without going into specifics, the exploit requires a certificate containing such an explicitly defined curve. In addition, the curves that are used by the exploit are manipulated, meaning that they will not be from the list of standard curves.


Detecting CVE-2020-0601 using a Zeek script

To detect if someone is trying to exploit CVE-2020-0601, we need to determine if someone is trying to use a EC-certificate using a non-standard curve. It turns out that this is rather easy to do in a Zeek script. We can just use the x509_certificate event. The X509::Certificate parameter of this event contains both the key algorithm that is used by the certificate - which tells us that the certificate has an elliptic curve key - as well as the curve that is used in a certificate.
So, we can just write a simple test to check if a certificate is an EC-certificate but does not use a named curve and output a notice:



This is the exact code that is used by our detection script.
This just leaves us with one question: what happens when a certificate contains a standard curve, but encodes the parameters explicitly?
It turns out that the answer to this question is a bit complex with different OpenSSL installations behaving in various ways. Some OpenSSL versions will automatically convert well-known explicit curves back to their named equivalent. In this case, the Zeek code above will work as expected - and certificates with well-known curves that are explicitly specified will not generate a warning. Other versions will not do this; in this case you will get a false positive with this code when encountering such a certificate. Please note, however, that explicitly defined parameters are highly unusual, so the danger of false positives is very low.
To address this potential of false positives, we added a test to our package which determines if your OpenSSL installation behaves as expected. If not, you will get a test failure. You can still use the package, you just have to be aware that there is a small risk of false positives.
Furthermore, we have a second version of our package, which completely mitigates this issue. In this version, we created a C plugin that uses OpenSSL functionality to test if the curve contained in a certificate matches one of the well-known curves. The source is split across two files, a bif-file which creates a function that can test a certificate from script-land, and a second file that performs the test. The code in the second file is very long (more than 3,000 lines) - because it contains all curve definitions. This code is mostly a copy from the OpenSSL source code - which contains the functionality that we need - but does sadly not expose it directly in their API.
The drawback of this package is the higher complexity. Furthermore the package requires OpenSSL 1.1.1 - which might not be available for your Zeek installation if you are on an older release of your Linux distribution.


Getting Involved

If you have any questions about this script - or if you use it and find exploit attempts - we would love to hear from you. The best way to contact us is to share feedback on our mailing list, or you can email me directly.
The Zeek community is always interested in package contributions! If you write an interesting package that can detect an attack, adds a feature, etc., add it to the package manager and let the mailing list know.

Tuesday, January 14, 2020

Zeek Monthly Newsletter, Issue 1 - January 2020



Welcome to the Zeek Monthly Newsletter, Issue 1 covers December 2019 as well as upcoming events.


In this Issue:
  • ●  General Community News/Updates
  • ●  Development Updates
  • ●  Zeek In the News
  • ●  Interviews
  • ●  Threat of the Month
  • ●  Upcoming Events
  • ●  Contribution/Contributor of the Month
  • ●  Zeek Related Issues
  • ●  Publication Schedule
  • ●  Get Involved 



General Community News/Updates

We’re very excited to publish this first Zeek newsletter. This newsletter will be published monthly on the first full week of each month. The publication schedule can be found below.

In this issue you’ll notice some sections will only have a description as we are actively looking for content and contributors. Please consider becoming an editor. If you are interested please email news@zeek.org





Development Updates

Zeek 3.0.1 release available- This is a bug-fix release that most notably addresses a JSON logging performance regression in 3.0.0, but also fixes other minor bugs. 
http://mailman.icsi.berkeley.edu/pipermail/zeek/2019-December/014845.html




Zeek in the News

This section will be for articles published outside of the Zeek Blog. If you come across articles referencing Zeek in your news feed and you’d like us to share it in the newsletter, please send the link to news@zeek.orgor add it to the Issue 2working document.



Interviews with LT/Core Contributors/Other

What community member or contributor would you like to know more about? If you have suggestions please email us at news@zeek.org.Since there wasn’t any from December and this is our first newsletter below are the links to a couple from earlier in 2019.

* Robin Sommer - https://blog.zeek.org/2019/04/people-of-zeek-interview-series-robin.html 
* Zeke Medley - https://blog.zeek.org/2019/06/people-of-zeek-interview-series.html
* Fatema Bannat Wala - https://blog.zeek.org/2019/07/people-of-zeek-interview-series.html




Threat of the Month

Do you have a threat you’d like to share with the community and how using Zeek in your security stack helped you identify that threat? Please email news@zeek.organd we’ll work with you to get it written up and shared in the next newsletter.




Upcoming Events

If you or your organization would like to host a Zeek event or if you know of any public Zeek related workshops, please send us the links so that we can include those in the newsletter and on the website.

Ask the Zeeksperts

Ask the Zeeksperts is a one hour bi-weekly call that is hosted by various “Zeeksperts” in the community. This is where you can drop by and ask your Zeek Related questions. The webinars are free to attend, but registration is required.

* 16 January 2020 - 12:30pm PT - Hosted by Seth Hall
https://attendee.gotowebinar.com/register/5597309536345352715
* 30 January 2020 - 12:30pm PT - Host Robin Sommer
https://attendee.gotowebinar.com/register/4730628291843942667


How to use a Raspberry Pi as a Network Sensor Webinar

* 16 January 2020 - 2:00PM EST

This webinar is being hosted by Black Hills Information Security and presented by Bill Sterns,
from Active Countermeasures.

This webcast will cover running a network sensor using a Raspberry Pi, a miniature single-board computer that runs most anything you can run under Linux.

Bill will show you how to install and use the Zeek IDS and cover the performance aspects you'll need to know. Setting up IDSs that cost about the same as a bike means you can monitor far more network segments simultaneously, and hide them behind a power brick if you have to.

Register for this webinar at: https://attendee.gotowebinar.com/register/2540509980495221261


Zeek Days Workshops

18 February 2020 - Portland OR

This is a one day Zeek workshop hosted by Portland State University and sponsored by Corelight, Inc.

This workshop is free to attend by registration is required.

In this workshop we'll introduce you to Zeek, best practice around deploying and running Zeek then we'll take a deeper look at the Zeek logs and how to use the data derived from the Zeek logs.

And for those who want to know more and become an active contributor and participant in the Zeek community we'll get you started.

Registration and more information -
https://www.eventbrite.com/e/zeek-days-workshop-portland-or-tickets-89780043527




Contribution/Contributor of the Month

Check out packages.zeek.org Every month we’ll pick a package to highlight. Consider contributing a package during January 2020, so we can highlight your contribution on the Zeek Blog and in the February 2020 Zeek Newsletter.

If you’d like to review the packages and interview the contributors, please email news@zeek.org.





Zeek-related Jobs

If you or someone you know have any Zeek related job postings you’d like us to share in the monthly newsletter please send links to news@zeek.org.




Publication Schedule

* Issue 1 - January 2020 (Covers December 2019) - 14 January 2020 
* Issue 2 - February 2020 (Covers January 2020) - 3 February 2020 
* Issue 3 - March 2020 (Covers February 2020) - 2 March 2020
* Issue 4 - April 2020 (Covers March 2020) - 6 April 2020

* Issue 5 - May 2020 (Covers April 2020) - 4 May 2020
* Issue 6 - June 2020 (Covers May 2020) - 1 June 2020
* Issue 7 - July 2020 (Covers June 2020) - 6 July 2020
* Issue 8 - August 2020 (Covers July 2020) - 3 August 2020
* Issue 9 - September 2020 (Covers August 2020) - 7 September 2020
* Issue 10 - Special Issue 1 - September 2020 (Covers ZeekWeek 2020) - 21 September 2020 

* Issue 11 - October 2020 (Covers September 2020) - 5 October 2020
* Issue 12 - November 2020 (Covers October 2020) - 2 November 2020 
* Issue 13 - December 2020 (Covers November 2020) - 7 December 2020 
* Issue 14 - Special Issue 2 - (Year End Review) - 21 December 2020




Get Involved

If you are interested in getting involved with the Zeek Newsletter, please email news@zeek.org

More information about the newsletter can be found here.


Stay up to date by subscribing to the Zeek Mailing List.


Follow us on Twitter

Thursday, January 9, 2020

Getting started with Zeek (Docker-style): Part 1


by David Lapsley Ph.D. 

Introduction

First of all, welcome to the community! If you are reading this, then you’ve heard all about how great Zeek is and you are interested in finding out for yourself by getting it up and running and playing with it. Good move!

The goal of this article is to make the process of getting Zeek up and running as easy as possible for you, so you can spend more time exploring Zeek, and less time running over speed bumps. To do this, we are going to leverage the extremely convenient Docker toolchain in combination with some cool Docker work that has already been done in the open source community.

Good luck and have fun!

Dockerizing your computer

Some good news: most of the work to get Zeek up and running has already been automated! However, in order to leverage that automation, we need to get your computer to the point where the foundation has been laid for the automation to kick off. Fortunately, that is quite easy: all you need is to have Docker installed and running. In the following, I am going to assume you are running a Mac OSX computer like me (Windows and Linux users, we love you too, but this is the only platform I have validated this on so far -- the automation we will review will work on any platform that supports Docker -- I just haven’t verified that yet!).

So, let’s get started. On your Mac, you’ll need to install the following:

You will also need to make sure you have git installed on your Mac. If it’s not, install it with the following command:

$ brew install git

We’re almost ready to get started. One thing we need to do first is to make sure we give Docker enough RAM to be able to compile Zeek. Docker Desktop for Mac uses a VM behinds the scenes to host the Docker runtime environment. By default it allocated 2 GB of RAM to the VM. That’s not enough to compile Zeek! If you try compiling with the default RAM settings, you will hit a compile error that looks something like this:

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.

This is due to the VM hitting an Out Of Memory condition. To avoid this you will need to allocate more RAM to the VM. Click on the Docker Icon in your menubar and select "Preferences". Click on the "Advanced" tab and then use the slider to select 8 GB of RAM (6 also works, but use 8 just in case). Docker Desktop will restart and then you will be ready to go!




Checkout the Code

The zeek-docker repo (https://github.com/zeek/zeek-docker) hosts a number of Dockerfiles that can be used to build your favorite version of Zeek. Dockerfiles like the one at https://github.com/zeek/zeek-docker/blob/master/3.0.0.Dockerfile have all the instructions you need to build your Zeek container in a completely repeatable, reliable, and convenient manner. It’s definitely worth taking a read through the Dockerfile to see the steps involved in building and installing Zeek.

If you are new to Docker, the docker documentation is worth checking out. The main documentation page is https://docs.docker.com/. If you are a first timer, the getting started section is very useful: https://docs.docker.com/get-started/. If you’ve had some experience, the Dockerfile reference is always handy to have nearby:  https://docs.docker.com/engine/reference/builder/.

Ok, time to download the code so we can start doing cool stuff! Use the following command to clone the code onto your laptop:

$ git clone https://github.com/zeek/zeek-docker.git

Building your first Zeek Container

It’s time! Type in the commands below to build your first Zeek Container (in this case we are building a version 3.0.0 container):

$ cd zeek-docker
$ make build-stamp_3.0.0

That’s all you need to do! Now watch as the wonders of automation unfold, and your Zeek container is built. You should see something like this on your terminal console:


...
Step 24/24 : CMD /bin/bash -l
 ---> Running in c1263b7d2ea3
Removing intermediate container c1263b7d2ea3
 ---> 5bc774250a9a
Successfully built 5bc774250a9a
Successfully tagged broplatform/bro:3.0.0
touch build-stamp_3.0.0
$

Once the container has been built, you will see the container image is available in your local docker registry:

$ docker images  | grep -e broplatform -e REPO
REPOSITORY       TAG   IMAGE ID     CREATED        SIZE
broplatform/bro  3.0.0 5bc774250a9a 8 minutes ago  215MB

Hello Zeek!

We are ready to run our first Zeek container!

The command below executes the container and sets up an interactive bash shell within the container.It also mounts the current host directory (currently inside the zeek-docker repo) in the /pcap directory of the container so you can copy files into/out of the container.

$ docker run -it -v `pwd`:/pcap broplatform/bro:3.0.0 /bin/bash

At this point we are inside the container. Type the command below and you can see there is a freshly built zeek executable ready to use!

root@3535953ccd99:/# which zeek
/zeek/bin//zeek

The /pcap directory inside the container corresponds to the host working directory (this can be anywhere on your computer, for me it happens to be the zeek-docker repo directory). You’ll probably want to put pcap files in here as well so you can process the data inside the container using zeek while storing the logs in the mounted directory for later access (e.g. after the container is gone!).

root@3535953ccd99:/zeek/bin# ls -1r /pcap
master.Dockerfile
master-dev.Dockerfile
common
build-stamp_3.0.0
Makefile
3.0.0.Dockerfile
...

Congratulations! You are now the proud owner of a brand new Zeek container, which contains an installed Zeek deployment in its own execution environment. (And you built it all by yourself !)

Putting Zeek to Work

There are two ways we can use Zeek:

  • Run it from the command line against a pre-captured PCAP file
  • Run it against a live network interface

For this post, we’ll be going through the first use case. In a follow up post, we’ll walk through how to run Zeek against a live network interface.

Now that our execution environment is all setup and we have a Zeek container, let’s process some PCAP files! (My colleague keith.jones@corelight.com has some interesting PCAPs you can take a look at in his article: https://blog.zeek.org/2019/12/how-to-add-jpeg-file-analyzer-to-zeek.html?m=1). Copy your favorite pcap file (let’s assume it’s “test.pcap”) into your current working directory and execute the following:

$ docker run -it -v `pwd`:/pcap broplatform/bro:3.0.0 /bin/bash
root@5ea58f4bb9be:/# cd /pcap
root@5ea58f4bb9be:/pcap# ls *.pcap
test.pcap

Cool! Now we’re running inside the container, and we can see our test.pcap file residing on our host computer via the mounted filesystem on our container’s /pcap.

Time to run Zeek! Execute the following command.

root@5ea58f4bb9be:/pcap# zeek -r test.pcap
root@5ea58f4bb9be:/pcap#

Done! Zeek has quietly processed the pcap file, and output a bunch of data to log files in the current directory. Let’s take a look.

root@5ea58f4bb9be:/pcap# ls *.log
conn.log  dnp3.log  packet_filter.log

So now we have the log files generated by Zeek using its default set of scripts, cool! If these logs are new to you, then you might want to head over to the official Zeek documentation which contains a deep dive on the various log files and fields: https://docs.zeek.org/en/stable/script-reference/log-files.html.

As an example, we’ll take a look at the contents of the conn.log file (https://docs.zeek.org/en/stable/scripts/base/protocols/conn/main.zeek.html#type-Conn::Info).

root@5ea58f4bb9be:/pcap# cat conn.log
#separator \x09
#set_separator        ,
#empty_field        (empty)
#unset_field        -
#path        conn
#open        2019-12-04-04-38-26
#fields        ts        uid        id.orig_h        id.orig_p        id.resp_h        id.resp_p        proto        service        duration        orig_bytes        resp_bytes        conn_state        local_orig        local_resp        missed_bytes        history        orig_pkts        orig_ip_bytes        resp_pkts        resp_ip_bytes        tunnel_parents
#types        time        string        addr        port        addr        port        enum        string        interval        count        count        string        bool        bool        count        string        count        count        count        count        set[string]
1252963725.444796        Cn0OCi3r0R0aO5nAda        192.168.10.204        1413        192.168.10.140        20000        tcp        dnp3_tcp        1.049805        15        17        SF        --        0        ShADadFtf        8        343        7        322        -
1252963725.788546        CbSrUpY4Adua4a6Ad        192.168.10.204        1400        192.168.10.21        5450        tcp        -        9.006836        60        140        OTH        -        -0        DdA        10        460        5        340        -
#close        2019-12-04-04-38-26



There you have it! Success!

Conclusion

Here we are at the end of today’s journey, and the beginning of your Zeek journey! We have been able to Dockerize our computer, build a Zeek container, execute Zeek within the container, and process a PCAP file using the Zeek container we built.

I hope this has been useful to you, saved you a lot of time and helped to accelerate you on your Zeek journey. I also hope you had as much fun going through this as I had writing it!

I would love to hear from you, so please feel free to drop me a line (david.lapsley@corelight.com). I really appreciate feedback (especially if it helps to make this tutorial easier for folks to read/follow).

Thank you for following along, good luck, and Happy Zeeking!


About David Lapsley, Ph. D. 


Dr. Lapsley has over 20 years of industry experience. Roughly a third of
that has been spent doing applied research for various government agencies,
a third working for large telecom vendors, and a third working at startup
companies. Dr. Lapsley's expertise includes software development,
data analysis, distributed infrastructure, open source, cloud computing,
and forming and leading high performing teams.

Dr. Lapsley holds a Ph. D. in Electrical and Electronics Engineering from
the University of Melbourne, Australia. He also holds a B. S. (Computer
Science) and B. E. with Honours (Electrical and Computer Systems
Engineering) from Monash University, Australia.


Monday, December 23, 2019

How To Add A JPEG File Analyzer To Zeek - Part 4

by Keith J. Jones, Ph.D

Introduction

The last three blog posts demonstrated how to add a JPEG file analysis plugin into the core Zeek source code or as a package.  This part will demonstrate how you can add tests to your code when distributed as part of the Zeek source code (blog posts 1 and 2) or as a package (blog post 3).  First, this post will introduce Btest, the testing mechanism used by Zeek.  Next, this post will walk you through the mechanisms you will use to test either the Zeek core source code or packages you write for Zeek.  Although this post is specific to our JPEG example from the prior three posts, it is important to note that the testing concepts presented in this post can be used for other source code development within Zeek.  Therefore, this post should be relevant no matter what type of source code development you may be performing on Zeek.  Read on to learn more.

How Does Btest Work?

You can think of btest (https://github.com/zeek/btest) as a generic driver to automate testing using whatever language is appropriate for the task.  While that explanation sounds vague, it is actually a very powerful concept.  Btest can be used to test Zeek with pretty much any language that appropriate; so for some tests you can use shell scripting, and for other tests you can use Zeek scripts.  Such a powerful testing framework would seem complex, and it is, but using the framework is nearly trivial once you learn the basics of how it works.
Btest operates by reading any file in the current directory and executing the btest commands within them that are prefixed by “@TEST-EXEC” tokens.  Therefore, by placing the btest commands in comments for whatever language we want to use to test our code, we are able to test Zeek using pretty much any Unix command line tool we like.  The documentation explains this process better than I could reproduce it here, so at least skim the concepts introduced here:
Stop here and read the documentation at the link above before you continue further on this post.  No, really; it’s important.  I will wait.  I will now assume you know the basic concepts of btest before I describe how we are going to test the JPEG plugin we have been working on.
For this blog post, we will demonstrate some tests that will use shell and Zeek scripts to ensure our JPEG plugin is performing as expected.  Our inputs to btest will be the shell and Zeek scripts, and our tests will use the PCAP files we used to test our code in the prior blog posts.  Our commands used to run the tests will be defined in the comments of the shell and Zeek scripts.  This will make more sense as we look at a concrete example applying the concepts in the Zeek testing documentation above.
Note that some additional documentation for Zeek testing can be found at https://www.zeek.org/development/projects/testing.html.

Writing Tests For The JPEG Analyzer Plugin

If you read parts 1-3 of this blog series, you will remember that we coded the JPEG analyzer twice.  The first time, we coded it directly into the Zeek core source code tree.  Then, we took the same logic and made it into an installable package.  We will discuss testing for both methods in this post, but we will start with the package deployment method first since it is the easier of the two methods to distribute your logic.  Then, I will show how to add some tests to the Zeek core source code method for completeness.

Package Deployment

When we ran “init-plugin” in the last post, it automatically created a test for us in the “tests” directory:
The first file we will want to discuss is the “btest.cfg” configuration file:
Line 2 says that the test directories includes “jpeg”.  This is the directory we will add our new test to.  Line 15 shows where we can store pcap files.  The symbol “TRACES” is expandable within btest tests, so we do not have to discern the parent path.  We will use the trace we downloaded earlier in this series from the Wireshark project to create some tests, and this is the path we will place it in.
After running “init-plugin”, from the last blog post, one test is added to our package:
This file is a zeek script.  Inside the comments, “@TEST-EXEC:” says to run zeek in the following manner:
zeek -NN FileAnalyzers::JPEG |sed -e 's/version.*)/version)/g' >output
This line runs Zeek in a mode where the plugins are searched for FileAnalyzers::JPEG, then the “sed” command is used to find the version, and it is all output to a file called “output”. Then, the second line says to run “btest-diff” on the “output” file generated previously.  As you recall from the btest documentation, if the output file were to change between testing, the test would fail.  It is the output that defines the tests, and deviations from the output signal a failed test.
In order to detect changes between tests, baselines must be created.  Baselines can be created with the following btest command from within the “tests” directory:
$ btest -U
After that, any subsequent runs of “btest” will detect changes from this baseline run.
Now, let us add a simple test to our plugin.  Create a file called “jpeg.zeek” in the “tests\jpeg” directory with the following content:
# @TEST-EXEC: zeek -r $TRACES/http_with_jpegs.pcap %INPUT >jpeg.out
# @TEST-EXEC: btest-diff jpeg.out
# @TEST-EXEC: btest-diff jpeg.log
event file_jpeg_marker(f: fa_file, m: FileAnalyzers::JPEGMarker)
    {
      print m;
    }
The first line above tells Zeek to run with a traces file in the “$TRACES” directory, we discussed previously in the btest.cfg file.  This command uses the current file (%INPUT) as the input script.  The second two testing lines detect changes on jpeg.out and jpeg.log from the baseline.  Lastly, the event defined here outputs some of the marker information detected from the trace file.  Simply printing the marker data to the output adds it to the test because we are looking for differences in the output to the Zeek command.
We will need a PCAP file, so place the following trace file in “Traces” directory and call it “http_with_jpegs.pcap” once you have decompressed it:
Now, record the baseline with the following command:
$ btest -U
From this point forward, running “btest” again will detect changes and fail the test if the output is different.  The changes between the last blog post and this post to add these tests can be found at the following link:

Core Zeek Source Code Deployment

Adding the same test to the core Zeek source code deployment method is pretty much the same as the package version once you are able to locate the key areas to add the tests.  The new code we are adding is available at:
The “jpeg.zeek” script from above will be located at the path “testing/btest/scripts/base/frameworks/file-analysis/http/jpeg.zeek” based upon the matching directory structures between the code we added and this path.  Note that there are a few changes between this version of “jpeg.zeek” and packaged version.  The changes are mainly associated with record pathing and the path to our pcap file.
The trace from above needs to be placed at “testing/btest/Traces/http/http_with_jpegs.pcap”.  Now, enter the “testing/btest” directory and update our new baseline for this one test only:
$ btest -U scripts/base/frameworks/file-analysis/http/jpeg.zeek
Next, you can test our new test with the following command:
$ btest scripts/base/frameworks/file-analysis/http/jpeg.zeek
If there has been a change to the baseline, btest will notify you.  If you decide to test all of Zeek by simply executing “btest”, be warned that there are many and not all of them will pass.  You will need to find your plugin’s test out of many, so for development purposes you will likely want to run single tests to save time.

Conclusion

This blog post demonstrated how to add testing to our JPEG file analyzers.  We tested the core source code with Zeek if we choose to deploy that way, and we also tested the package we created in the last blog post to cover that deployment method.  With testing added, your new custom JPEG file analyzer is ready to be consumed by the open source community.  You can either apply to add your source code to the core Zeek source code distribution on GitHub, or you can add your package to https://packages.zeek.org/ so that other users can benefit from your work.

-------------

About Keith J. Jones, Ph.D

Dr. Jones is an internationally industry-recognized expert with over two decades of experience in cyber security, incident response, and computer forensics. His expertise includes software development, innovative prototyping, information security consulting, application security, malware analysis & reverse engineering, software analysis/design and image/video/audio analysis.

Dr. Jones holds an Electrical Engineering and Computer Engineering undergraduate degrees from Michigan State University. He also earned a Master of Science degree in Electrical Engineering from MSU. Dr. Jones recently completed his Ph.D. in Cyber Operations from Dakota State University in 2019.