Security Advisory for Squert

Introduction
Jeffrey Medsger reported several command injection and SQL injection vulnerabilities in Squert.  Wes Lambert also discovered some XSS vulnerabilities in Squert.

These issues are resolved in the following package:
securityonion-squert - 20161212-1ubuntu1securityonion26

Resolution
To resolve these issues, simply install the new Squert package according to our normal update instructions:
https://securityonion.net/wiki/Upgrade

Release Notes
If you start seeing "Prepared statement needs to be re-prepared" in /var/log/apache2/error.log, please see the following:
https://github.com/Security-Onion-Solutions/security-onion/wiki/MySQLTuning#table_definition_cache

Thanks
Special thanks to Jeffrey Medsger for responsibly disclosing these security issues per our Security page (https://securityonion.net/security) and for submitting patches for some of the issues!

Timeline
All times below are in Eastern time.
12/31/2017 6:22 PM - Received notification from Jeffrey Medsger concerning Squert command injection vulnerabilities.
12/31/2017 6:43 PM - Confirmed receipt of email.
1/1/2018 2:47 PM - Asked Jeffrey Medsger for clarification on some details.
1/2/2018 1:19 AM - Jeffrey Medsger provided additional details and reported additional SQL injection issues.
1/2/2018 6:05 PM - Confirmed receipt of email.
1/3/2018 4:35 PM - Asked Jeffrey Medsger to test new package to confirm it resolves command injection vulnerabilities.
1/6/2018 2:09 AM - Jeffrey Medsger confirmed command injection issues resolved.
1/8/2018 2:05 PM - Asked Jeffrey Medsger to test new code to confirm it resolves SQL injection vulnerabilities.
1/9/2018 9:14 PM - Jeffrey Medsger confirmed SQL injection issues resolved but reported unrelated error messages.
1/9/2018 9:19 PM - Confirmed error messages.
1/10/2018 1:32 PM - Asked Jeffrey Medsger to test new code to confirm it resolves error messages.
1/11/2018 12:25 AM - Jeffrey Medsger confirmed all issues resolved.
1/11/2018 4:44 PM - Confirmed receipt of email.
1/12/2018 8:00 AM - Began working on packaging to support both Elastic and non-Elastic systems.
1/20/2018 8:02 AM - Completed packaging.
1/22/2018 8:00 AM - Started regression testing.
1/23/2018 8:57 AM - Completed regression testing.

Security Advisory for ELSA

Introduction
Jeffrey Medsger reported multiple Cross-Site Scripting (XSS) vulnerabilities in ELSA.

These issues are resolved in the following ELSA packages:
securityonion-elsa - 1205chartsjsd3-1ubuntu1securityonion12
securityonion-elsa-extras - 20151011-1ubuntu1securityonion58

Resolution
To resolve these issues, simply install the new ELSA packages according to our normal update instructions:
https://securityonion.net/wiki/Upgrade

Thanks
Special thanks to Jeffrey Medsger for responsibly disclosing these security issues per our Security page (https://securityonion.net/security) and for submitting patches for some of the issues!

Timeline
All times below are in Eastern time.
1/2/2018 1:19 AM - Received initial notification from Jeffrey Medsger concerning ELSA XSS vulnerabilities.
1/2/2018 6:05 PM - Confirmed receipt of email and confirmed issues.
1/3/2018 4:35 PM - Asked Jeffrey Medsger to test new packages.
1/10/2018 12:26 AM - Jeffrey Medsger confirmed original XSS issues resolved and reported additional XSS issues.
1/10/2018 1:32 PM - Confirmed receipt of email with new XSS issues.
1/12/2018 2:02 PM - Asked Jeffrey Medsger to test latest packages.
1/13/2018 4:00 PM - Jeffrey Medsger confirmed issues resolved.
1/13/2018 4:03 PM - Confirmed receipt of email and began regression testing.
1/18/2018 8:32 AM - Completed regression testing.

Security Advisory for Xplico 1.2.0

Introduction
Mehmet D. İNCE discovered several vulnerabilities related to Xplico. He identified three different vulnerabilities, two classified as "High severity" and one as "Medium severity". The CVE number assigned for these vulnerabilities is CVE-2017-16666:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16666

We've resolved these issues in a new Xplico package:
xplico - 1.2.0ubuntu1securityonion9

Resolution
To resolve these issues, simply install the new Xplico package according to our normal update instructions:
https://securityonion.net/wiki/Upgrade

Mitigations
Since 2015, our Setup wizard has disabled Xplico by default when choosing the "Best Practices" option:
https://github.com/Security-Onion-Solutions/securityonion-setup/blob/dd9c8e098af3e6bc253570b75b789ff928c10323/debian/patches/streamline-Setup-with-new-defaults-and-add-new-Custom-option

Since March 2016, our Setup wizard locks down the host-based firewall to block remote connections to Xplico:
http://blog.securityonion.net/2016/03/securityonion-setup-20120912.html

Additionally, we recently made some changes to make it easier to totally remove the Xplico package from your system:
http://blog.securityonion.net/2017/11/securityonion-nsmnow-admin-scripts.html
http://blog.securityonion.net/2017/11/securityonion-iso-20151016.html
http://blog.securityonion.net/2017/11/securityonion-setup-20120912.html

Future Security Onion ISO images will no longer include Xplico.

Thanks
Special thanks to Mehmet İNCE for responsibly disclosing this security issue per our Security page:
https://securityonion.net/security

Special thanks to Gianluca Costa for patching these issues so quickly!

Timeline
All times below are in Eastern time.
11/8/2017 2:32 AM - Received initial notification from Mehmet İNCE.
11/8/2017 6:30 AM - Confirmed receipt of email and confirmed issue.
11/8/2017 6:39 AM - Notified Gianluca Costa of Xplico.
11/13/2017 2:36 AM - Received patches from Gianluca Costa.
11/13/2017 8:56 AM - Built new Xplico package and sent to Mehmet İNCE for review.
11/13/2017 9:04 AM - Received confirmation from Mehmet İNCE.
11/13/2017 9:09 AM - Sent email to coordinate disclosure.

Security Advisory for Security Onion Elastic Alpha

Applicability
This security advisory only applies to Security Onion Elastic Alpha.  If you're running the stable version of Security Onion (ELSA instead of Elastic), this does not apply to you.  Since this advisory only applies to Security Onion Elastic Alpha, please be reminded of the usual warnings and disclaimers:

• Experimental Setup is ALPHA, BLEEDING EDGE, and TOTALLY UNSUPPORTED!
• If this breaks your system, you get to keep both pieces!
• This is a work in progress and is in constant flux.
• This is intended to build a quick prototype proof of concept so you can see what our ultimate Elastic configuration might look like. This configuration will change drastically over time leading up to the final release.
• Do NOT run this on a system that you care about!
• Do NOT run this on a system that has data that you care about!
• This should only be run on a TEST box with TEST data!
• Experimental Setup may result in nausea, vomiting, or a burning sensation.

Introduction
Security Onion Elastic Alpha runs the Elastic stack (Elasticsearch, Logstash, and Kibana).  UFW, the host-based firewall, is configured to only allow connections to port 22 by default.  Apache is configured as a proxy to authenticate users before accessing Kibana.  Therefore, the original intention of the design was that a user would run Setup and then run so-allow to allow their workstation IP to connect over the network to port 443 where Apache was proxying Kibana and requiring authentication.  However, due to incorrect Docker parameters, Kibana and Elasticsearch ports were being published directly to the network allowing users to bypass both the UFW firewall and the Apache proxy and access Kibana and Elasticsearch directly with no authentication.  This has been corrected in the lastest securityonion-elastic package (securityonion-elastic - 20171011-1ubuntu1securityonion1).

Resolution
If you're running the stable version of Security Onion (ELSA instead of Elastic), there is nothing to do.

If you're running Security Onion Elastic Alpha and you've already run Setup, please run the following:

sudo soup
sudo so-elastic-restart

If you haven't yet run Setup and are planning to choose the Experimental option to enable the Elastic stack, just make sure that you run "sudo soup" before running Setup.

Discussion
Previously, our so-elastic-start script would start containers using a --publish parameter like this (in the case of Kibana):

--publish 5601:5601

If you were to then examine the host-based firewall configuration, you would see that only port 22 is open by default:

However, if you were to port scan the box remotely, you would see more than port 22 open:

Now let's install the new securityonion-elastic package (securityonion-elastic - 20171011-1ubuntu1securityonion1):

sudo soup

This new package starts containers using a --publish parameter that only publishes to localhost like this (in the case of Kibana):

--publish 127.0.0.1:5601:5601

securityonion-elastic - 20171011-1ubuntu1securityonion1 makes the following changes:

• so-kibana publishes port 5601 to 127.0.0.1 only
• so-elasticsearch publishes ports 9200 and 9300 to 127.0.0.1 only
• so-logstash publishes ports 6050, 6051, 6052, and 6053 to 127.0.0.1 only
• so-freqserver no longer publishes port 10004
• so-domainstats no longer publishes port 20000

Now we need to restart the Docker containers:

sudo so-elastic-restart

Finally, we re-run the remote port scan to verify that only port 22 is open:

More Information
For more information, please see:
http://blog.viktorpetersson.com/post/101707677489/the-dangers-of-ufw-docker
https://github.com/moby/moby/issues/4737

Thanks
Special thanks to Todd Carlson for responsibly disclosing this security issue per our Security page:
https://securityonion.net/security

Timeline
All times below are in Eastern time.
10/10/2017 10:02 PM - Received initial notification from Todd Carlson.
10/11/2017 8:35 AM - Confirmed receipt of email, confirmed issue, and committed initial fix.
10/11/2017 9:52 AM - Built new securityonion-elastic package and asked Todd to test and confirm.
10/12/2017 8:18 PM - Received confirmation from Todd that the new package resolved the issue.
10/16/2017 7:20 AM - Pushed new securityonion-elastic package to stable repo.