This is the first of a two part series. In part two I’ll be demonstrating how to use Bro as well as use cases.
This installation was done on Debian. Use the appropriate package manager for your Linux distribution to install the following packages.
sudo apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev
sudo apt-get install libgeoip-dev
sudo mv /home/<username>/GeoLiteCity.dat /usr/share/GeoIP/GeoIPCity.dat
tar zxvf bro-2.4.1.tar.gz
sudo ./configure –prefix=/opt/bro2
- In /opt/bro2/etc/node.cfg, set the right interface to monitor.
- In /opt/bro2/etc/networks.cfg, comment out the default settings and add the networks that Bro will consider local to the monitored environment.
- In /opt/bro2/etc/broctl.cfg, change the MailTo email address to a desired recipient and the LogRotationInterval to a desired log archival frequency.
bro -C -r pcap.pcap
Stay tuned for more Bro goodness!
In my spare time I like to sharpen my skills by pentesting vulnerable virtual machines, usually from vulnhub.com. This is my review of “Seattle”. This wasn’t a thorough pentest of the web application, it was what I was able to knock out in a couple of hours one afternoon for fun.
I found an LFI at the URL “/details.php?prod=1&type=1&lang=USD”.
The “My Account” page is vulnerable to SQL injection. The email address must be a valid email address. It wouldn’t accept email@example.com.
On the Blog page, I clicked on “Admin” and arrived at this page which includes admin’s email address.
Back on the “My Account” page, I logged in with firstname.lastname@example.org and a password of “‘ or 1=1 — “.
After multiple tests, I was able to exploit stored XSS on the site with “<a onmouseover=alert(document.cookie)>xxs link</a>”. Any requests containing SCRIPT were filtered on the blog form. OWASP has an excellent cheat sheet on XSS filter evasion at https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet.
I was able to use sqlmap to exploit SQL injection with any of the product pages, using URL “/details.php?prod=1” for example. This was a blind SQL injection vulnerability, meaning that my usual methods of manually pulling info from the database to be displayed on the page didn’t work, so I let sqlmap do the heavy lifting as blind SQL injection can be very difficult to exploit.
I pasted the hash into crackstation.net and found the root password. Had it not been found on crackstation I would have run it through oclhashcat which uses the GPU to run through very large password lists in a few minutes.
This wasn’t the most difficult web app that I’ve worked through. It did provide a couple of hours of fun on an afternoon off from work.
Do you have Linux hosts with non privileged users allowed to run tcpdump by placing tcpdump in the sudoers file? There’s a tcpdump –z flag that allow you to specify a post-rotate command to run. The user can create a text file in /tmp with commands that will be executed as root.
Although this isn’t a newly discovered hack, it bears repeating because of the fact that this is still seen in production environments.
$ sudo -l
[sudo] password for john:
User john may run the following commands on this host:
Used in conjunction with the -C or -G options, this will make tcpdumprun ” postrotate-command file ” where file is the savefile being closed after each rotation. For example, specifying -z gzipor -z bzip2 will compress each savefile using gzip or bzip2.
A way to test this is to create a file… /tmp/.test and place the “id” command in it then run the command: “sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/.test -Z root”
It will output:
uid=0(root) gid=0(root) groups=0(root)
The way to fix this:
With the following commands we can run Tcpdump as a normal user instead of a root user.
setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump