Greetings Autosnort Users,
It's been some time since I've posted here. I haven't been idle this whole time however, I've been focusing on other things.
Last fall I came across a guide on Ars Technica on how to build your own secure webserver with NGINX. Curious, I decided to read it. I was never one for being a "web admin" or "webmaster", since I've never been in those roles in my life, I decided I would live up to my reputation and learn how set up a webserver on NGINX along with several web applications.
Sure I have some experience with Apache and setting up/configuring web interfaces for snort, but NGINX was an entirely different beast to me. So I decided to dive in. Only I decided to modify the Ars Technica guide ever so slightly. They decided to use Ubuntu server for their guide, and that's fine, but I'm an individual that likes a good amount of challenge to my projects. I decided that following the exact same cookie cutter recipe wasn't what I wanted to do, so I settled on CentOS. In spite of RHEL-based operating systems being the preference in the corporate world of Linux, no one really has any guides for doing a damn thing in RHEL-based operating systems. I decided that wasn't fair or cool and dove in.
For the most part, it was pretty smooth sailing, but there were a couple of rough spots I had to be aware of and resolve myself, SELinux and how it wants the system to interact with UNIX domain sockets was one such example.
So, why was I spending time on all this? I'm moving away from blogspot and want to host things internally. So, I'm proud to introduce BlindSeeker, My new self-hosted website. The URL will read:
haxthruhere.dyndns-server.com
I'm using dynamicdns for DNS, since I have a dynamic IP, and while I could have chosen a better dyndns hostname, I think it fits, so it stays for now.
My site hosts 4 services:
A wordpress blog that I will be using to post product updates, etc. This will be acting as the new Autosnort blog. Update your bookmarks, and watch for news here.
A forum that can be used for discussing whatever you'd like, including questions related to Autosnort, etc.
A wiki that I'll be updating this heavily as I go along. I plan on releasing all core Autosnort guidance and documentation on this wiki, along with screenshots, etc. I'll also be hosting my guide on how I built BlindSeeker on CentOS here eventually and perhaps even more things down the line.
An etherpad instance -- Etherpad is essentially a multi-user instance of notepad with some chat capabilities built in, etc. It's very nice for collaboration/troubleshooting. Think of it as a no-hassle version of google docs. That can be used for collab.
Just to re-iterate the above, BlindSeeker, the server in my basement will be acting as the replacement for the Autosnort blog. I feel that I need to manage my own web applications and be responsible for securing my own stuff to grow as a security professional.
Things to be aware of:
1) The certificate for the site IS self-signed. Sorry, I don't believe in giving free money to CAs, not when they can be infiltrated and have wildcard certificates generated before anyone notices and investigates.
The certificate is issued by Triptych Security Inc for BlindSeeker.com (which doesn't match my dyndns hostname... I know, I know...) just so you know what to look for, If you are the (rightly so) paraniod type who needs to verify the details of the certificate, before you blindly accept self-signed certs. I may fix the details of the cert eventually, but it will always be self-signed.
2) Registration for the forums and to be a contributor on the wiki are both a manual process right now. You'll have to register for the forum or wiki (whichever you are interested in) and send me an e-mail with the username you registered in order for me to give you rights to do anything. Sorry, but that's just the way it is. It's more secure, prevents spam, and aside from initial access overhead is more tenable security-wise.
Also e-mail is required to register on the forums, but since I don't have a mail-relay set up, you won't get e-mail from my forums for anything. Same goes for registering to the wiki -- don't bother with your e-mail address there. I may fix this at some point, but not right now :\
3) I've established a Regular maintenance schedule. Saturday at 3:30am the system has updates applied and is rebooted. Sunday at 3am, all current etherpads are wiped from the server to maintain your privacy, and limit my liability for things copied to them. If you have anything important you want to preserve on your Etherpad instance(s) Save it before the Sunday weekly wipe.
Join me and become a BlindSeeker today.
Cheers,
DA_667
Sunday, January 5, 2014
Monday, October 21, 2013
By the gods, he lives! (Part 2: Secret weapons that never were)
So,
Last post I had talked about MDC3, and my role along with the rest of the unallocated team in making it to the finals. Sadly, we didn't win, but even worse, we never got to utilize the secret weapons we were planning on bringing with us. Once again, I had my involvement on the secret weapons front.
Most of our weapons weren't exactly that secret -- we had plans to bring massive password cracking wordlists with us from freely available sources, and essentially bring a package of updated tools with us.
My job was to re-spin Kali with the most up-to-date tools available for use, as well as provide us with some (not-so) secret weapons that are tailored towards CTF usage. Unfortunately, they outlawed use of your own special software or tools for the competition (in my opinion, that didn't keep others from downloading their tools and using them, but we played by the rules, regretfully)
So I worked at this shell script only to find out we couldn't use it for our CTF event. Well, our loss is now your gain. I present to you, updater.sh
What does updater.sh do?
Updater is a script specifically for Kali Linux that performs the following tasks:
.5: checks to see if you're root. If you're running on Kali, you should be, but still.
1. Generates new ssh host keys for your Kali installation, starts the ssh daemon and makes it start on boot -- this was something that was somewhat of an annoyance to me. Kali has every other service and capability known to man on it, but doesn't have sshd started by default. Well, I fixed that.
2. Adds the Kali Linux bleeding edge repository -- There isn't that much to say that hasn't already been said here. Basically there are certain tools that update frequently that were included by default with Kali. The bleeding edge repo was Kali's answer to those tools. Right now, the bleeding repo only has a small subset of tools, but dammit I want the latest and greatest, so I added the bleeding repo to Kali's /etc/apt/sources.lst
3. The almighty apt-get update and apt-get -y upgrade (dist-upgrade) -- What would an update script be without apt-get update and upgrade? I know, this is braindead simple stuff, but I wanted to automate it regardless. Just to give you fair warning: make sure you have ample time when running this script. This is the longest portion of the script. Why? Default Kali install pulls 400+ packages of varying size (some over 100+mb), then has to install all that.
You might wonder, why the hell would I choose to use dist-upgrade as opposed to just upgrade? I noticed when I ran the updates initially there was a number of packages that were "held back". Doing my homework, held back packages can be force updated via dist-upgrade when updating packages. I don't see a reason to hold back security tool packages, so I opted for the simplest way to fix it.
4. Msfupdate -- So you've updated your OS installations core tools and bleeding edge tools, what next? Kali's heart is metasploit. So msfupdate seemed logical to me. Takes a moment or two, but not nearly as drawn out as the apt-get package pull and the benefits are definitely noticable if you have any tasks where you'll be using or relying on the framework.
5. If you have the flash installer package for linux (.tar.gz) and/or the Nessus .deb package (with a home or professional feed provided to the script), they are automatically installed -- drop the adobe flash play for linux package in the root ("/") directory and/or the nessus installer package and provide the shell script with a home or professional feed key, and the script will auto install both.
Some of the more security conscious saw flash player and probably did one of these , but flash is required for a wide variety of web consoles (nessus included), so I included the option of installing it if the script detects you downloaded it and have it in the right place. If you don't want it installed, just don't download flash. That simple.
6. Couple of minor customizations -- As a part of the updater, some packages that I found to be missing on a deafault Kali install I configured apt-get to install:
armitage -- The popular graphical front-end to the metasploit framework by Raphael Mudge of Strategic Cyber. Also installs the teamserver (armitage collaboration) program. Was very surprised this was not installed by default.
mimikatz -- a popular program for dumping plaintext passwords -- basically if a user is logged in, lsass stores a plaintext copy of that user's password within lsass' memory space in memory. mimikatz can dump it and reveal the passwords stored.
terminator - a terminal emulator program that supports tabbed terminal sessions and also has a unique feature that allows you to split your terminal screen vertically and horizontally as many times as you want. For those with an OSX background, think of this as the Linux version of iterm/iterm2
unicornscan - a leightweight asynchronous network scanner. Doesn't have all the fancy bells and whistles of nmap, but sometimes all you want is a list of open ports. unicornscan does this fast and it does it well.
zenmap - the graphical front-end to the ever popular nmap scanner. Was also very surprised that this was not installed by default as well.
7. A collection of scripts and tools from other CTF veterans and pentesters alike who were willing to share their armaments, including:
1. The github collection of Cortana .cna scripts for automated red-teaming and post-exploitation. Cortana is touted as a "Red team force multiplier". Translated from cyber-ese, Cortana is a bot platform for armitage. Basically you provide scripts to Cortana and they can do things ranging from updating functionality in Armitage and allowing you to do new things to, automated scanning, to automatically throwing exploits at new targets seen on the network that have certain points open and/or listening services to post-exploitation modules to maintain persistence to hard-won hosts. If you're familiar with the sleep language, (The strange perl dialect that much of Armitage is written in along with java) then you can write your own, or simply modify the pre-existing scripts to suite your needs.
2. Unsploitable tools: Unsploitable is a collection of tools/scripts that when you feed them the results of a nessus scan will tell you what exact patch will fix the vulnerabilities listed. Good for situations where you have to perform triage quickly.
3. Defense Tools for the Blind (DTFTB): a set of scripts for unix systems that sort of allow you to ghetto rig security for unix systems and kinda triage the system/provide emergency defensive countermeasures for when you don't have the time or resources to fully patch out your vulnerabilities. For example, one script is a while true that scans ps output for /bin/sh or nc or netcat and kills the associated processes, killing post-exploit shells and simple backdoors.
4.New custom build of smbexec by Brav0hax. Basically this is a copy of the smbexec functionality found in metasploit re-written to get around some security products catching metasploit smbexec and flagging it as a non-legitimate service installation.
That's it. Lot of simple things, that make Kali that much more awesome and makes it that much easier for you to gear up for the CTF or pentest.
As with the autosnort scripts, the script tells you what it's doing and gives you success or failure indicators. If there's a failure the script bails.
The script logs the entirety of output for each of the installation steps to a dedicated log file in /var/log named kali_updater.log
If you're looking for a challenge, troll through it, figure out what failed, fix it, contact me, tell me my script is broken and how you fixed it. If you're lazy or not looking for a challenge, tell me my script is broken and ship me a copy of the updater log.
As usual, along side any post where I announce a new tool or script, it's available via github
My final installation in the 'what the hell have you been doing series: BSIDES DC!
Last post I had talked about MDC3, and my role along with the rest of the unallocated team in making it to the finals. Sadly, we didn't win, but even worse, we never got to utilize the secret weapons we were planning on bringing with us. Once again, I had my involvement on the secret weapons front.
Most of our weapons weren't exactly that secret -- we had plans to bring massive password cracking wordlists with us from freely available sources, and essentially bring a package of updated tools with us.
My job was to re-spin Kali with the most up-to-date tools available for use, as well as provide us with some (not-so) secret weapons that are tailored towards CTF usage. Unfortunately, they outlawed use of your own special software or tools for the competition (in my opinion, that didn't keep others from downloading their tools and using them, but we played by the rules, regretfully)
So I worked at this shell script only to find out we couldn't use it for our CTF event. Well, our loss is now your gain. I present to you, updater.sh
What does updater.sh do?
Updater is a script specifically for Kali Linux that performs the following tasks:
.5: checks to see if you're root. If you're running on Kali, you should be, but still.
1. Generates new ssh host keys for your Kali installation, starts the ssh daemon and makes it start on boot -- this was something that was somewhat of an annoyance to me. Kali has every other service and capability known to man on it, but doesn't have sshd started by default. Well, I fixed that.
2. Adds the Kali Linux bleeding edge repository -- There isn't that much to say that hasn't already been said here. Basically there are certain tools that update frequently that were included by default with Kali. The bleeding edge repo was Kali's answer to those tools. Right now, the bleeding repo only has a small subset of tools, but dammit I want the latest and greatest, so I added the bleeding repo to Kali's /etc/apt/sources.lst
3. The almighty apt-get update and apt-get -y upgrade (dist-upgrade) -- What would an update script be without apt-get update and upgrade? I know, this is braindead simple stuff, but I wanted to automate it regardless. Just to give you fair warning: make sure you have ample time when running this script. This is the longest portion of the script. Why? Default Kali install pulls 400+ packages of varying size (some over 100+mb), then has to install all that.
You might wonder, why the hell would I choose to use dist-upgrade as opposed to just upgrade? I noticed when I ran the updates initially there was a number of packages that were "held back". Doing my homework, held back packages can be force updated via dist-upgrade when updating packages. I don't see a reason to hold back security tool packages, so I opted for the simplest way to fix it.
4. Msfupdate -- So you've updated your OS installations core tools and bleeding edge tools, what next? Kali's heart is metasploit. So msfupdate seemed logical to me. Takes a moment or two, but not nearly as drawn out as the apt-get package pull and the benefits are definitely noticable if you have any tasks where you'll be using or relying on the framework.
5. If you have the flash installer package for linux (.tar.gz) and/or the Nessus .deb package (with a home or professional feed provided to the script), they are automatically installed -- drop the adobe flash play for linux package in the root ("/") directory and/or the nessus installer package and provide the shell script with a home or professional feed key, and the script will auto install both.
Some of the more security conscious saw flash player and probably did one of these , but flash is required for a wide variety of web consoles (nessus included), so I included the option of installing it if the script detects you downloaded it and have it in the right place. If you don't want it installed, just don't download flash. That simple.
6. Couple of minor customizations -- As a part of the updater, some packages that I found to be missing on a deafault Kali install I configured apt-get to install:
armitage -- The popular graphical front-end to the metasploit framework by Raphael Mudge of Strategic Cyber. Also installs the teamserver (armitage collaboration) program. Was very surprised this was not installed by default.
mimikatz -- a popular program for dumping plaintext passwords -- basically if a user is logged in, lsass stores a plaintext copy of that user's password within lsass' memory space in memory. mimikatz can dump it and reveal the passwords stored.
terminator - a terminal emulator program that supports tabbed terminal sessions and also has a unique feature that allows you to split your terminal screen vertically and horizontally as many times as you want. For those with an OSX background, think of this as the Linux version of iterm/iterm2
unicornscan - a leightweight asynchronous network scanner. Doesn't have all the fancy bells and whistles of nmap, but sometimes all you want is a list of open ports. unicornscan does this fast and it does it well.
zenmap - the graphical front-end to the ever popular nmap scanner. Was also very surprised that this was not installed by default as well.
7. A collection of scripts and tools from other CTF veterans and pentesters alike who were willing to share their armaments, including:
1. The github collection of Cortana .cna scripts for automated red-teaming and post-exploitation. Cortana is touted as a "Red team force multiplier". Translated from cyber-ese, Cortana is a bot platform for armitage. Basically you provide scripts to Cortana and they can do things ranging from updating functionality in Armitage and allowing you to do new things to, automated scanning, to automatically throwing exploits at new targets seen on the network that have certain points open and/or listening services to post-exploitation modules to maintain persistence to hard-won hosts. If you're familiar with the sleep language, (The strange perl dialect that much of Armitage is written in along with java) then you can write your own, or simply modify the pre-existing scripts to suite your needs.
2. Unsploitable tools: Unsploitable is a collection of tools/scripts that when you feed them the results of a nessus scan will tell you what exact patch will fix the vulnerabilities listed. Good for situations where you have to perform triage quickly.
3. Defense Tools for the Blind (DTFTB): a set of scripts for unix systems that sort of allow you to ghetto rig security for unix systems and kinda triage the system/provide emergency defensive countermeasures for when you don't have the time or resources to fully patch out your vulnerabilities. For example, one script is a while true that scans ps output for /bin/sh or nc or netcat and kills the associated processes, killing post-exploit shells and simple backdoors.
4.New custom build of smbexec by Brav0hax. Basically this is a copy of the smbexec functionality found in metasploit re-written to get around some security products catching metasploit smbexec and flagging it as a non-legitimate service installation.
That's it. Lot of simple things, that make Kali that much more awesome and makes it that much easier for you to gear up for the CTF or pentest.
As with the autosnort scripts, the script tells you what it's doing and gives you success or failure indicators. If there's a failure the script bails.
The script logs the entirety of output for each of the installation steps to a dedicated log file in /var/log named kali_updater.log
If you're looking for a challenge, troll through it, figure out what failed, fix it, contact me, tell me my script is broken and how you fixed it. If you're lazy or not looking for a challenge, tell me my script is broken and ship me a copy of the updater log.
As usual, along side any post where I announce a new tool or script, it's available via github
My final installation in the 'what the hell have you been doing series: BSIDES DC!
Sunday, October 20, 2013
By the gods, he lives! (Part 1, MDC3)
Hello again,
It's been quite a long time since I've posted anything here or posted any updates on github for autosnort OR H1N1 for that matter. well, let me tell you what I've been up to lately, this'll probably be over multiple posts, so I hope you're ready to be shotgunned with updates >:) so let's start with MDC3.
For those who don't know about MDC3, what it is and why I'm interested in it, it's a yearly event sponsored by SAIC among other organizations. It's mainly a "suitcon", where managers in industry meet up, and a bunch of security vendors come on down to the Baltimore convention center with whitepapers and statistics and other things as to why you want to buy their wares.
In addition to that, MDC3 hosts a yearly cyber challenge event that I use as a sort of whet stone for keeping myself sharp. There are 5 rounds in total. The first 4 rounds are done online/offline with friends at a place of your choosing, with the final round at the "suitcon" live.
Out of the four online/offline rounds, the first two are practice rounds while the next two rounds are qualifier rounds for the finals. The practice and qualifier rounds are very similar -- either you're given VM images to examine, or you are given forensic and crypto challenges to perform. -- things ranging from "Here's a VM with an operating system of some sort running on it. It's owned in various ways and has several security holes. Close the holes." to "Here's a PCAP, answer these questions", where the questions range from "What was the admin on this box doing while the system was being compromised?" to "The attacker used FTP to exfil data off the system. Give us the name and an md5sum of the files downloaded."
We skipped the practice rounds this year, though in retrospect, I kinda wish we had gotten the files so I could practice more. So for the first qualifier round, we ended getting a windows server VM that was owned in various ways. The server was running IIS and had simple TCP services enabled. In addition to that, no patches, no security countermeasures, no firewalls, several netcat backdoors, user applications (firefox and chrome installed -- plus firefox was backdoored with another netcat listener), etc.
The round was scored out of 20 points or 20 vulnerabilities to remediate. Our team ended up getting 19 out of 20 and passing the round. Essentially all we did was more or less manually revert the host back to a clean,default install with DISA STIG recommendations applied, full patches, all services disabled, user account passwords changed and other common sense things you would do to a system that was compromised. We had no requirements to keep IIS running or core services on the VM that were required to be running, so we just uninstalled everything.
Some of you may be running, how would SAIC know what was going on with the VM and whether or not you remediated something? They had a really crappy java client called cybernexs installed on the VM with a special account running a service that would start on boot, that you would register to a scoring server. This service would phone home and say what you had fixed.
Theoretically, you could reverse engineer the client and make it pretend to call back stating everything was fixed, but we never got around to doing that. I know I'm not skilled enough to do that, but there were some on our team that probably could have done it.
Back to the competition. So overall I'll call round 1 a success, however it's disappointing: In a real-live production environment, your server is responsible for providing a service (at minimum 1 service, sometimes many), the fact that we were given free reign to uninstall all services and applications installed on the server flies in the face of reality.
So the second round this year was network forensics and crypto. We were given a packet capture to analyze and the following questions:
10. Repair the zip file and answer the challenges within.
I managed to do most of these questions easily. The only tools I used this were Wireshark, Network Miner, md5sum and DiskInternals zip repair utility. Managed to answer all the questions except question 8.... a portion of the pcap showed the attack managed to get a copy of /etc/shadow. Even after throwing JohnTheRipper at it for 24 hours straight, I never cracked the password or got any hint in the pcap as to what root's password was. Bummer.
Question 10 was a multi-parter. Part of the forensic challenge indicates there were files transferred during the attack. One of the files was a zip file. It was in plaintext and was easy to single out with wireshark and tcp stream separation. After exporting the bytes of the TCP stream, I was able to reconstruct it as a zip file. The problem was that the zip file was broken. Another one of our team members who knew more about forensics than me was able to manually fix it. There was some sort of discrepency between the zip file's size and the zip file record's reported size that needed to be repaired. I ended up using diskinternal's zip file repair utility and that fixed it for me. That was as far as I got there, I relied on other team members to resolve the crypto challenges since I'm absolutely terrible at crypto and cipher schemes.
We did well enough as a team to make it to the finals. The format of the final round is completely different from the previous rounds. It's essentially a king of the hill style CTF challenge. There are several systems (with more being added over the duration of the event) that are vulnerable and very exploitable. The goal is to get on the system, and plant your flag (a flag.txt file with a hash that represents your team in a specific directory on the host) and keep it there. You can lose shell access to a system, but as long as your flag is there, the system is still yours.
Well, I was in charge of exploiting windows systems, and here was my run-down: Most of the Windows 2000, w2k3 and XP systems were vulnerable to some fort of MS08-067 (If you don't know what this is, it's essentially a 4+ year old SMB exploit for windows versions ranging from windows NT to Server 2003 as well as several service pack revisions, it's pretty old, but is still used as a point of reference for many security conferences and classes because it's very reliable and a shining example of Remote Code Execution exploitation) MS03-026 (this exploit is mainly focused around windows 2000, early versions of XP and early versions of server 2003. It's an RPC DCOM exploit that is also another popular remote code execution exploit used as an example in lots of training courses.), etc.
The most unique windows box I had to throw against in the network, another team member found was vulnerable to file upload via webdav, and handed off to me to finish owning. There's a metasploit module that exploits the file upload and uploads an ASP script which then gives you a meterpreter shell as an unpriveleged user. At that point, you could plant the flag as an unpriv'd user, or you could be like me, rummage through armitage and metasploit's post-exploit modules and find a privilege escalation that would give you SYSTEM access...As an attacker, why would I want system access? Well, there are a number of reasons, we'll get into that in a moment. after several unsuccessful tries, I managed to get system through ms11-080. I wish I was smart enough understand how it worked, but the gist of it is that it's a driver that executes in ring 0 (kernel space, SYSTEM space) and through some voodoo magic or another, you load shellcode into memory and tell this driver to refer to your shellcode, and BAM you have a system shell (smarter hackers will skewer me... but I did what I could with what I know.)
So, what was the point of gaining system access the windows boxes? system access enables you to utilize a post-exploitation module known as hashdump. hashdump allows you to dump the contents of the SAM (Security Accounts Manager) database. This contains hashes for all the users on the system, from the lowliest of users to all system administrators.
What good are hashes without having the cracked, you may ask. Well, in windows, you don't necessary need to crack the hashes in order to be able to utilize them. A common exploit for windows is a technique called "Pass the Hash". PTH exploits a weakness in windows filesharing that allows you to authenticate to a remote windows system by simply giving the remote system a copy of that user's hash as opposed to the actual password and having the remote system do hash checking. Pass the hash can be used to do anything that user can do -- map drives, execute commands, upload and execute metasploit payloads, etc.
So, when you exploit a windows system, the first thing you want to do is esclate privs and get system access as soon as you can. After you have system access, you want to dump hashes and get hashes for admin users, since it's extremely easy to gain system access as an admin user. Once you have hashes for admin users, this allows you to use psexec/pass the hash to maintain access to an exploited host, or easily regain access to the host if you've somehow lost your initial access.
So, in spite of getting hashes for multiple systems and repeatedly managing to get back on as SYSTEM, we didn't get very far in terms of placement, because others would simply beat us to our targets and had better methods of planting their flag and keeping it there. I didn't know enough about acls and cacls to figure out how to fix file permissions to undo what they did to their flag file to leave it on the host, then drop our file and lock it to where other teams couldn't modify it. It was really frustrating. Also, in addition to that, I would repeatedly lose my meterpreter shells in spite of doing things the right way (e.g. migrate processes and load meterpreter into a system process that an adversary would not want to kill, etc.)
While I was thrashing windows boxes, others were doing everything they could in linux and unix hosts. And once again, we would get access (managed to plant our flag briefly on one), and lose it, then the hole would be closed, locking us out of that host.
So, in spite of all things, and not having won the competition, I was satisfied because of the fact that I did manage to pop some windows boxes and be a massive annoyance to other teams. I was annoyed because either the network was incredibly unstable, or the hosts we were attacking were incredibly unstable. I'm guessing a combination of the two, but the systems we attacked and got on to would get REALLY bogged down after a little while. I was also disappointed. SAIC didn't give us much swag this year for making it to the finals. Last year, we got challenge coins for making it to the finals, this year, we got a craptastic backpack. registration for the event was something like 300 dollars per team in the professional level. What gives? Sigh. Oh well.
So, that's a run-down of my MDC3 adventures.
Part 2: the secret weapons that never were. Look forward to a script release...
It's been quite a long time since I've posted anything here or posted any updates on github for autosnort OR H1N1 for that matter. well, let me tell you what I've been up to lately, this'll probably be over multiple posts, so I hope you're ready to be shotgunned with updates >:) so let's start with MDC3.
For those who don't know about MDC3, what it is and why I'm interested in it, it's a yearly event sponsored by SAIC among other organizations. It's mainly a "suitcon", where managers in industry meet up, and a bunch of security vendors come on down to the Baltimore convention center with whitepapers and statistics and other things as to why you want to buy their wares.
In addition to that, MDC3 hosts a yearly cyber challenge event that I use as a sort of whet stone for keeping myself sharp. There are 5 rounds in total. The first 4 rounds are done online/offline with friends at a place of your choosing, with the final round at the "suitcon" live.
Out of the four online/offline rounds, the first two are practice rounds while the next two rounds are qualifier rounds for the finals. The practice and qualifier rounds are very similar -- either you're given VM images to examine, or you are given forensic and crypto challenges to perform. -- things ranging from "Here's a VM with an operating system of some sort running on it. It's owned in various ways and has several security holes. Close the holes." to "Here's a PCAP, answer these questions", where the questions range from "What was the admin on this box doing while the system was being compromised?" to "The attacker used FTP to exfil data off the system. Give us the name and an md5sum of the files downloaded."
We skipped the practice rounds this year, though in retrospect, I kinda wish we had gotten the files so I could practice more. So for the first qualifier round, we ended getting a windows server VM that was owned in various ways. The server was running IIS and had simple TCP services enabled. In addition to that, no patches, no security countermeasures, no firewalls, several netcat backdoors, user applications (firefox and chrome installed -- plus firefox was backdoored with another netcat listener), etc.
The round was scored out of 20 points or 20 vulnerabilities to remediate. Our team ended up getting 19 out of 20 and passing the round. Essentially all we did was more or less manually revert the host back to a clean,default install with DISA STIG recommendations applied, full patches, all services disabled, user account passwords changed and other common sense things you would do to a system that was compromised. We had no requirements to keep IIS running or core services on the VM that were required to be running, so we just uninstalled everything.
Some of you may be running, how would SAIC know what was going on with the VM and whether or not you remediated something? They had a really crappy java client called cybernexs installed on the VM with a special account running a service that would start on boot, that you would register to a scoring server. This service would phone home and say what you had fixed.
Theoretically, you could reverse engineer the client and make it pretend to call back stating everything was fixed, but we never got around to doing that. I know I'm not skilled enough to do that, but there were some on our team that probably could have done it.
Back to the competition. So overall I'll call round 1 a success, however it's disappointing: In a real-live production environment, your server is responsible for providing a service (at minimum 1 service, sometimes many), the fact that we were given free reign to uninstall all services and applications installed on the server flies in the face of reality.
So the second round this year was network forensics and crypto. We were given a packet capture to analyze and the following questions:
1. What files were transferred from the victim?
2. What directory were files initially copied to?
3. What is MD5 hash of files transferred to the attacker? (Use lowercase letters)
4. What port is the backdoor listening on?
5. What was the admin doing during attack?
6. What is the name of the backdoor user?
7. What is the password of the backdoor user?
8. What is root's password?
9. What software on the victim allowed the attack?
I managed to do most of these questions easily. The only tools I used this were Wireshark, Network Miner, md5sum and DiskInternals zip repair utility. Managed to answer all the questions except question 8.... a portion of the pcap showed the attack managed to get a copy of /etc/shadow. Even after throwing JohnTheRipper at it for 24 hours straight, I never cracked the password or got any hint in the pcap as to what root's password was. Bummer.
Question 10 was a multi-parter. Part of the forensic challenge indicates there were files transferred during the attack. One of the files was a zip file. It was in plaintext and was easy to single out with wireshark and tcp stream separation. After exporting the bytes of the TCP stream, I was able to reconstruct it as a zip file. The problem was that the zip file was broken. Another one of our team members who knew more about forensics than me was able to manually fix it. There was some sort of discrepency between the zip file's size and the zip file record's reported size that needed to be repaired. I ended up using diskinternal's zip file repair utility and that fixed it for me. That was as far as I got there, I relied on other team members to resolve the crypto challenges since I'm absolutely terrible at crypto and cipher schemes.
We did well enough as a team to make it to the finals. The format of the final round is completely different from the previous rounds. It's essentially a king of the hill style CTF challenge. There are several systems (with more being added over the duration of the event) that are vulnerable and very exploitable. The goal is to get on the system, and plant your flag (a flag.txt file with a hash that represents your team in a specific directory on the host) and keep it there. You can lose shell access to a system, but as long as your flag is there, the system is still yours.
Well, I was in charge of exploiting windows systems, and here was my run-down: Most of the Windows 2000, w2k3 and XP systems were vulnerable to some fort of MS08-067 (If you don't know what this is, it's essentially a 4+ year old SMB exploit for windows versions ranging from windows NT to Server 2003 as well as several service pack revisions, it's pretty old, but is still used as a point of reference for many security conferences and classes because it's very reliable and a shining example of Remote Code Execution exploitation) MS03-026 (this exploit is mainly focused around windows 2000, early versions of XP and early versions of server 2003. It's an RPC DCOM exploit that is also another popular remote code execution exploit used as an example in lots of training courses.), etc.
The most unique windows box I had to throw against in the network, another team member found was vulnerable to file upload via webdav, and handed off to me to finish owning. There's a metasploit module that exploits the file upload and uploads an ASP script which then gives you a meterpreter shell as an unpriveleged user. At that point, you could plant the flag as an unpriv'd user, or you could be like me, rummage through armitage and metasploit's post-exploit modules and find a privilege escalation that would give you SYSTEM access...As an attacker, why would I want system access? Well, there are a number of reasons, we'll get into that in a moment. after several unsuccessful tries, I managed to get system through ms11-080. I wish I was smart enough understand how it worked, but the gist of it is that it's a driver that executes in ring 0 (kernel space, SYSTEM space) and through some voodoo magic or another, you load shellcode into memory and tell this driver to refer to your shellcode, and BAM you have a system shell (smarter hackers will skewer me... but I did what I could with what I know.)
So, what was the point of gaining system access the windows boxes? system access enables you to utilize a post-exploitation module known as hashdump. hashdump allows you to dump the contents of the SAM (Security Accounts Manager) database. This contains hashes for all the users on the system, from the lowliest of users to all system administrators.
What good are hashes without having the cracked, you may ask. Well, in windows, you don't necessary need to crack the hashes in order to be able to utilize them. A common exploit for windows is a technique called "Pass the Hash". PTH exploits a weakness in windows filesharing that allows you to authenticate to a remote windows system by simply giving the remote system a copy of that user's hash as opposed to the actual password and having the remote system do hash checking. Pass the hash can be used to do anything that user can do -- map drives, execute commands, upload and execute metasploit payloads, etc.
So, when you exploit a windows system, the first thing you want to do is esclate privs and get system access as soon as you can. After you have system access, you want to dump hashes and get hashes for admin users, since it's extremely easy to gain system access as an admin user. Once you have hashes for admin users, this allows you to use psexec/pass the hash to maintain access to an exploited host, or easily regain access to the host if you've somehow lost your initial access.
So, in spite of getting hashes for multiple systems and repeatedly managing to get back on as SYSTEM, we didn't get very far in terms of placement, because others would simply beat us to our targets and had better methods of planting their flag and keeping it there. I didn't know enough about acls and cacls to figure out how to fix file permissions to undo what they did to their flag file to leave it on the host, then drop our file and lock it to where other teams couldn't modify it. It was really frustrating. Also, in addition to that, I would repeatedly lose my meterpreter shells in spite of doing things the right way (e.g. migrate processes and load meterpreter into a system process that an adversary would not want to kill, etc.)
While I was thrashing windows boxes, others were doing everything they could in linux and unix hosts. And once again, we would get access (managed to plant our flag briefly on one), and lose it, then the hole would be closed, locking us out of that host.
So, in spite of all things, and not having won the competition, I was satisfied because of the fact that I did manage to pop some windows boxes and be a massive annoyance to other teams. I was annoyed because either the network was incredibly unstable, or the hosts we were attacking were incredibly unstable. I'm guessing a combination of the two, but the systems we attacked and got on to would get REALLY bogged down after a little while. I was also disappointed. SAIC didn't give us much swag this year for making it to the finals. Last year, we got challenge coins for making it to the finals, this year, we got a craptastic backpack. registration for the event was something like 300 dollars per team in the professional level. What gives? Sigh. Oh well.
So, that's a run-down of my MDC3 adventures.
Part 2: the secret weapons that never were. Look forward to a script release...
Monday, August 26, 2013
Project H1N1: An introduction.
Hello Autosnort viewers, today I'm going for a change of pace and going to introduce a bold, new project that could have a monstrous impact on the IDS and Network Intelligence realm. I'd like to introduce groundbreaking for the new Unallocated Space collaboration project, H1N1:
----------
H1N1 – Abstract:
H1N1 is a project that is meant to integrate the PRADS Passive Operating System Detection with Snort, the popular Intrusion Detection System package. The end goal is a system where Passive OS fingerprinting and IDS both work off one another to present a bigger picture:
- Snort benefits would benefit from Passive OS fingerprinting by having the Passive OS fingerprinting software inform it as to what operating systems are in its HOME_NET, and use that information to build Preprocessor policies, specifically frag3 and stream5 reassembly policies, that control how snort handles reassembling traffic for those hosts. Eventually this gathered information could be used to make snort rule recommendations based on hosts, client service banners observed in the HOME_NET as well.
- PRADS would (eventually…) benefit from snort, by existing as a preprocessor in the “stack”, benefitting from snort’s native ability to reassemble fragmented packets and reassemble TCP streams for both Operating System identification and Client/Server banner grabbing from the wire.
- Users would be able to review information for assets in their HOME_NET detected off the wire, alone with their intrusion events, offering greater network intelligence and a bigger picture.
The problem is, I’m a complete derp when it comes to anything programming or development. I know shell scripting, I’ve done some introductory python, but beyond that, I’m pretty much helpless. The key to completing this project lies in the Unallocated space motto: Teach, Learn, Build -- We'll teach one another something, We will learn in order to fill in the gaps of knowledge we may lack in making this project a reality, and the end goal will be to Build something awesome.
So that's the general abstract and overall goal of this project. Yesterday afternoon, I did a presentation about the project at my local hackerspace, Unallocated Space The goal was to find others in my area who would want to collaborate and be interested in making the project a reality. Below is an overview of the discussion and the powerpoint slides I brought with me:
----------
H1N1 – Day 1: Introductions, Teach, Learn, Build
The first day was primarily an introduction to the technology behind the project. Unallocated motto was integrated into today’s talk, in introducing H1N1:
- Teach:
o I introduced the audience the open-source IDS/IPS software snort, if they weren’t already familiar, as well as how it worked. After that I explained the difference between Active and Passive OS fingerprinting, then delved deeper into the various techniques used to passively fingerprint operating systems that have been researched and well-established by minds much greater than my own; such as TCP SYN flag options, Client/Server banners, ICMP fingerprints, etc. I discussed the weaknesses of Passive OS fingerprinting – network devices modifying traffic between the source and destination, duplicate fragments/segments, etc.
o I then set the stage for H1N1 – why hasn’t there been a project that integrates these two technologies together and have them work together? Most of the more well known solutions are commercial, while some of the Open-Source solutions aren’t quite there yet, in terms of usability .
- Learn:
o I want to make this project a reality. But I next to 0 programming knowledge. I know how to “hello world” in three separate languages, but unless I have an active challenge, or a reason to extend my knowledge beyond that, I tend to lose interest and my knowledge drops off nearly immediately. H1N1 is going to be a challenge, A challenge that I don’t know where to even begin to tackle.
o This is where Learning comes into play. I want to learn how to develop in different programming languages. I’m more than willing to learn from anyone willing to teach. If you know how to do it, show me. If you don’t have the time, tell me to “Go learn about X concept in Y language then come back to me.” Once I understand it, I’ll teach others. We all benefit and gain knowledge in this way. Knowledge is power, and we all deserve to wield it.
- Build: The project is ambitious, but I want to start with baby steps. Let’s start with the basics.
o What passive OS identification software do we want to use?
o Where are we going to host the code, and eventually the alpha builds?
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET
----------
Finally, We ended the conversation with a review of the slides, Q + A and what direction to take the project -- a review of the Build portion of my slides where I wanted to establish project milestones for H1N1:
----------
H1N1 Q + A:
o What passive OS identification software do we want to use?
Answer: We all primarily agreed that PRADS has the most features out of the options presented, and it made the most sense to build off it.
o Where are we going to host the code, and eventually the alpha builds?
Answer: For the time being, we all have infrastructure in our own homes that we can build snort and prads on, Forgotten offered to create an unallocated space github account for hosting the project code there. Eventually, when we have a workable alpha release, or beta release, or SOMETHING, we can talk to hunter and UAS Keyholders to either get a physical box or virtual machine to demo things.
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
Answer: This should be very easy for us to do. compile/build a snort sensor (snort, barnyard2, a web interface of choice), then compile PRADS. Set them both to run on startup (either via rc init script, or via rc.local), throw traffic at it. If it doesn't explode in a fit of rage, I'm going to call it a victory.
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?
Answer: There's a general fear and loathing of perl that's understandable, along with a love of python. Additionally there's been talk at our first session that it would be trivial to write a parser to drop this information into a database. Any volunteers for reviewing the prads2db.pl script as well as the prads2snort.pl script, and prads.sql data and determining whether or not porting it all to python would be feasible?
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.
Answer: Ruby on rails has been suggested. I don't know enough about web application technology to make this happen, but I'm not opposed to trying this. Another technology that I've been curious about is node.js.. A lot of new up and coming infosec projects have used node.js, and it's supposed to be incredibly fast. I wanna learn more.
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?
Answer: It was suggested that we turn this into a rolling time window sort of thing that's user configurable. Instead of taking the first fingerprint we see and associating it to an IP address, we can keep fingerprints associated to an IP address seen over a period of time, and based on results over X time period, Have Y% confidentiality that this IP address is this type of operating system. This is likely something that will have to come much further down the line, as it seems to be something that will require considerable effort to code.
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET
Answer: This should be fairly straightforward to do: Basically read the database, and generate a host_attributes.xml the same way the current perl scripts read the prads log and generate output.
----------
That just about sums up the discussion about this project. This project is still very much in its infancy. No hard timelines for ANY of the milestones established have been set. The reason for that is that I want this to be a project that anyone can come into with any level of programming knowledge, say "this part of the project interests me", take charge of it, learn the concepts necessary to complete it, come back to the group, teach what they learned, and implement in a way that helps meet the overarching goal of the project -- Teach, Learn, Build. To make this happen, setting hard timelines isn't feasible since everyone learns at different rates.
I hope to drum up support for this project as far and as widely as I possibly can. I'm not looking for anyone to do the code and solve the problems for me, or folks wanted to collaborate on this project. Even if your contribution to this project is "This task would be best suited to this programming language. Go learn about this concept in this language and come back to me."
A good friend of mine, Forgotten has started a collaboration github account on github, by the namesake of this project:
https://github.com/Unallocated/H1N1
Currently there isn't much there other than the readme; I'm hoping to change that if not on my own, then with your help, slowly but surely.
Hope to see you on the list of contributors,
DA_667
----------
H1N1 – Abstract:
H1N1 is a project that is meant to integrate the PRADS Passive Operating System Detection with Snort, the popular Intrusion Detection System package. The end goal is a system where Passive OS fingerprinting and IDS both work off one another to present a bigger picture:
- Snort benefits would benefit from Passive OS fingerprinting by having the Passive OS fingerprinting software inform it as to what operating systems are in its HOME_NET, and use that information to build Preprocessor policies, specifically frag3 and stream5 reassembly policies, that control how snort handles reassembling traffic for those hosts. Eventually this gathered information could be used to make snort rule recommendations based on hosts, client service banners observed in the HOME_NET as well.
- PRADS would (eventually…) benefit from snort, by existing as a preprocessor in the “stack”, benefitting from snort’s native ability to reassemble fragmented packets and reassemble TCP streams for both Operating System identification and Client/Server banner grabbing from the wire.
- Users would be able to review information for assets in their HOME_NET detected off the wire, alone with their intrusion events, offering greater network intelligence and a bigger picture.
The problem is, I’m a complete derp when it comes to anything programming or development. I know shell scripting, I’ve done some introductory python, but beyond that, I’m pretty much helpless. The key to completing this project lies in the Unallocated space motto: Teach, Learn, Build -- We'll teach one another something, We will learn in order to fill in the gaps of knowledge we may lack in making this project a reality, and the end goal will be to Build something awesome.
So that's the general abstract and overall goal of this project. Yesterday afternoon, I did a presentation about the project at my local hackerspace, Unallocated Space The goal was to find others in my area who would want to collaborate and be interested in making the project a reality. Below is an overview of the discussion and the powerpoint slides I brought with me:
----------
H1N1 – Day 1: Introductions, Teach, Learn, Build
The first day was primarily an introduction to the technology behind the project. Unallocated motto was integrated into today’s talk, in introducing H1N1:
- Teach:
o I introduced the audience the open-source IDS/IPS software snort, if they weren’t already familiar, as well as how it worked. After that I explained the difference between Active and Passive OS fingerprinting, then delved deeper into the various techniques used to passively fingerprint operating systems that have been researched and well-established by minds much greater than my own; such as TCP SYN flag options, Client/Server banners, ICMP fingerprints, etc. I discussed the weaknesses of Passive OS fingerprinting – network devices modifying traffic between the source and destination, duplicate fragments/segments, etc.
o I then set the stage for H1N1 – why hasn’t there been a project that integrates these two technologies together and have them work together? Most of the more well known solutions are commercial, while some of the Open-Source solutions aren’t quite there yet, in terms of usability .
- Learn:
o I want to make this project a reality. But I next to 0 programming knowledge. I know how to “hello world” in three separate languages, but unless I have an active challenge, or a reason to extend my knowledge beyond that, I tend to lose interest and my knowledge drops off nearly immediately. H1N1 is going to be a challenge, A challenge that I don’t know where to even begin to tackle.
o This is where Learning comes into play. I want to learn how to develop in different programming languages. I’m more than willing to learn from anyone willing to teach. If you know how to do it, show me. If you don’t have the time, tell me to “Go learn about X concept in Y language then come back to me.” Once I understand it, I’ll teach others. We all benefit and gain knowledge in this way. Knowledge is power, and we all deserve to wield it.
- Build: The project is ambitious, but I want to start with baby steps. Let’s start with the basics.
o What passive OS identification software do we want to use?
o Where are we going to host the code, and eventually the alpha builds?
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET
----------
Finally, We ended the conversation with a review of the slides, Q + A and what direction to take the project -- a review of the Build portion of my slides where I wanted to establish project milestones for H1N1:
----------
H1N1 Q + A:
o What passive OS identification software do we want to use?
Answer: We all primarily agreed that PRADS has the most features out of the options presented, and it made the most sense to build off it.
o Where are we going to host the code, and eventually the alpha builds?
Answer: For the time being, we all have infrastructure in our own homes that we can build snort and prads on, Forgotten offered to create an unallocated space github account for hosting the project code there. Eventually, when we have a workable alpha release, or beta release, or SOMETHING, we can talk to hunter and UAS Keyholders to either get a physical box or virtual machine to demo things.
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
Answer: This should be very easy for us to do. compile/build a snort sensor (snort, barnyard2, a web interface of choice), then compile PRADS. Set them both to run on startup (either via rc init script, or via rc.local), throw traffic at it. If it doesn't explode in a fit of rage, I'm going to call it a victory.
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?
Answer: There's a general fear and loathing of perl that's understandable, along with a love of python. Additionally there's been talk at our first session that it would be trivial to write a parser to drop this information into a database. Any volunteers for reviewing the prads2db.pl script as well as the prads2snort.pl script, and prads.sql data and determining whether or not porting it all to python would be feasible?
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.
Answer: Ruby on rails has been suggested. I don't know enough about web application technology to make this happen, but I'm not opposed to trying this. Another technology that I've been curious about is node.js.. A lot of new up and coming infosec projects have used node.js, and it's supposed to be incredibly fast. I wanna learn more.
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?
Answer: It was suggested that we turn this into a rolling time window sort of thing that's user configurable. Instead of taking the first fingerprint we see and associating it to an IP address, we can keep fingerprints associated to an IP address seen over a period of time, and based on results over X time period, Have Y% confidentiality that this IP address is this type of operating system. This is likely something that will have to come much further down the line, as it seems to be something that will require considerable effort to code.
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET
Answer: This should be fairly straightforward to do: Basically read the database, and generate a host_attributes.xml the same way the current perl scripts read the prads log and generate output.
----------
That just about sums up the discussion about this project. This project is still very much in its infancy. No hard timelines for ANY of the milestones established have been set. The reason for that is that I want this to be a project that anyone can come into with any level of programming knowledge, say "this part of the project interests me", take charge of it, learn the concepts necessary to complete it, come back to the group, teach what they learned, and implement in a way that helps meet the overarching goal of the project -- Teach, Learn, Build. To make this happen, setting hard timelines isn't feasible since everyone learns at different rates.
I hope to drum up support for this project as far and as widely as I possibly can. I'm not looking for anyone to do the code and solve the problems for me, or folks wanted to collaborate on this project. Even if your contribution to this project is "This task would be best suited to this programming language. Go learn about this concept in this language and come back to me."
A good friend of mine, Forgotten has started a collaboration github account on github, by the namesake of this project:
https://github.com/Unallocated/H1N1
Currently there isn't much there other than the readme; I'm hoping to change that if not on my own, then with your help, slowly but surely.
Hope to see you on the list of contributors,
DA_667
Friday, August 23, 2013
autosnort: compatible with Linux Mint
This is a really quick post. I've installed Linux mint on my person desktop at home, and out of curiousity, decided to try to run autosnort on mint to verify whether or not any of my build scripts were compatible. Well, the ubuntu autosnort script is 100% compatible with mint.
I'm aware that mint is primarily a desktop operating system, but if you're interested in running it on a Mint desktop as a sort of personal single workstation IDS, here's what to do:
1. Get a root shell: sudo /bin/bash
2. wget http://www.github.com/da667/Autosnort/Archive/master.zip
3. unzip master.zip
4. copy the autosnort-ubuntu-[date].sh script and an interface installation script to /root
5. run "bash autosnort-ubuntu-[date].sh"
6. run through the prompts as normal.
7. At the very end, when the script asks you whether or not you want to reboot, choose NO.
8. sudo vi or sudo gedit /etc/rc.local and modify the ifconfig eth0 line.
It initially reads: ifconfig eth0 up -arp -multicast promisc
make it read: ifconfig eth0 up promisc
9. save the file.
10. either reboot, or run "sudo bash /etc/rc.local"
11. Open firefox, or the web browser of your choice. type "localhost" in the address bar. You should be greeted by the web UI of your choosing.
12. ps -ef | grep snort will confirm whether or not snort and/or barnyard2 are running.
Yes, I know I've said in the past that managing your IDS on the same interface you're sniffing on, or having your sniffing interface be addressable isn't a good thing, but those are for DEDICATED IDS installations, this little "hack" is meant for users who want to drop snort on their personal workstation as an added layer of security.
Cheers,
DA_667
I'm aware that mint is primarily a desktop operating system, but if you're interested in running it on a Mint desktop as a sort of personal single workstation IDS, here's what to do:
1. Get a root shell: sudo /bin/bash
2. wget http://www.github.com/da667/Autosnort/Archive/master.zip
3. unzip master.zip
4. copy the autosnort-ubuntu-[date].sh script and an interface installation script to /root
5. run "bash autosnort-ubuntu-[date].sh"
6. run through the prompts as normal.
7. At the very end, when the script asks you whether or not you want to reboot, choose NO.
8. sudo vi or sudo gedit /etc/rc.local and modify the ifconfig eth0 line.
It initially reads: ifconfig eth0 up -arp -multicast promisc
make it read: ifconfig eth0 up promisc
9. save the file.
10. either reboot, or run "sudo bash /etc/rc.local"
11. Open firefox, or the web browser of your choice. type "localhost" in the address bar. You should be greeted by the web UI of your choosing.
12. ps -ef | grep snort will confirm whether or not snort and/or barnyard2 are running.
Yes, I know I've said in the past that managing your IDS on the same interface you're sniffing on, or having your sniffing interface be addressable isn't a good thing, but those are for DEDICATED IDS installations, this little "hack" is meant for users who want to drop snort on their personal workstation as an added layer of security.
Cheers,
DA_667
Sunday, August 18, 2013
Changing of the seasons; RHEL/CentOS code push/update; Autosnort milestones posted.
So here we are, at the end of August. Defcon has came and went, summer vacation is coming to close, and labor day is right around the corner. I don't consider summer officially over until Labor Day has come and passed, but why postpone it?
On that note, I've been busy in the lab, and have a whole host of updates that I'm dropping tonight for Autosnort. 99% of these updates are specific to the RHEL/CentOS release, that has been long neglected -- much longer neglected than the other distro scripts. The last update you all saw for RHEL/CentOS was sometime in April. The last major blog post you saw was in regards to the 9 layers of hell I traversed to make Snorby work on CentOS with SELinux enabled, then I disappeared for summer break. So, without further adieu, here's what's happening:
RHEL/CentOS:
- Updated the entire look and feel of the main autosnort installation script. CentOS/RHEL users now have the metasploit like prompts just like the Debian and Ubuntu users. Only things the user should be aware of are printed to the screen now:
- Status updates are in blue (e.g. [*] this indicates what autosnort is doing currently)
- Notifications are in yellow (e.g. [*] this indicates something the user needs to pay attention to (such as a prompt, or something they may want to note somehow))
- Successful modifications are in green (e.g. [*] this indicates whatever autosnort was doing was successful)
- Unsuccessful modifcations/installations are in red (e.g. [*] something bad happened. You'll probably want to get a hold of me and give me the log files for your installation, so it can be resolved)
- Speaking of logging, the installations scripts no longer spew output all over your screen buffer. Thanks to neat trick I picked up from stack exchange, the output of every major command is saved in two separate log files in /var/log:
-/var/log/autosnort_install.log -- contains output from all the major commands ran from the main autosnort installation script
-/var/log/[interfacename]_install.log -- contains output from all the major commands ran from the interface installation script for the interface you chose to install.
- The main autosnort installation script and all the web interface installation scripts have been updated with the new metasploit-like prompts and the background logging. This includes:
-autosnort-CentOS-[date].sh
-snortreport-CentOS.sh
-base-CentOS.sh
-aanval-CentOS.sh
-syslog_full-CentOS.sh
-snorby-CentOS.sh
- All web interface installation scripts for RHEL derivatives have had their DocumentRoot and Directory directives reconfigured to serve out the web interface of your choice. This means all you have to do is point your web browser to the ip address of your sensor's management interface, and provided you reconfigured ip tables to allow port 80 inbound, your web interface will pop up automatically.
- All web interface installation scripts for RHEL-based distros are 100% compatible with SELinux
- All web interface installation scripts for RHEL-based distros have had the ownership of DocumentRoot changed to the apache user and group
-Fixed minor grammatical and syntactical errors littered throughout the script.
Ubuntu/Debian:
- Apparently at some point between now and june, the passenger output directory for the mod_passenger.so binary changed the name of the directory from "libout" to "buildout". sigh. consistency is awesome, don't you agree? I only discovered this during testing passenger during the CentOS testing process.
- In an effort to make the mysql installs uniform between all autosnort builds and promote better security, I've made the mysql-server installation for Ubuntu and Debian silent, but now, just like with the CentOS script, the /usr/bin/mysql_secure_installation script is ran as a part of autosnort. huzzah for better secured databases.
- Same as the CentOS script, found minor grammatical and syntactical errors littered all over the script. Found and fixed what I could.
Code push should be happening tonight before init 1 for the night. As usual, the scripts are open source and are available on the autosnort github:
https://github.com/da667/Autosnort
While we're on the topic of github, I've posted some milestones that officially lay out where I want to take autosnort next -- things I want to accomplish with it. Have a look, see if I'm missing something:
https://github.com/da667/Autosnort/issues/milestones?with_issues=no
And last, but not least... The new project ideas I spoke of in my last blog post? I'm holding a meeting at our local hackerspace about one of them in particular, the passive OS fingerprinting project, trying to get some helping hands with it and make it more of a success. If you're in the Maryland/DC/VA area, come to unallocated space on the 25th so we can get a project outline hashed out.
Cheers,
DA_667
On that note, I've been busy in the lab, and have a whole host of updates that I'm dropping tonight for Autosnort. 99% of these updates are specific to the RHEL/CentOS release, that has been long neglected -- much longer neglected than the other distro scripts. The last update you all saw for RHEL/CentOS was sometime in April. The last major blog post you saw was in regards to the 9 layers of hell I traversed to make Snorby work on CentOS with SELinux enabled, then I disappeared for summer break. So, without further adieu, here's what's happening:
RHEL/CentOS:
- Updated the entire look and feel of the main autosnort installation script. CentOS/RHEL users now have the metasploit like prompts just like the Debian and Ubuntu users. Only things the user should be aware of are printed to the screen now:
- Status updates are in blue (e.g. [*] this indicates what autosnort is doing currently)
- Notifications are in yellow (e.g. [*] this indicates something the user needs to pay attention to (such as a prompt, or something they may want to note somehow))
- Successful modifications are in green (e.g. [*] this indicates whatever autosnort was doing was successful)
- Unsuccessful modifcations/installations are in red (e.g. [*] something bad happened. You'll probably want to get a hold of me and give me the log files for your installation, so it can be resolved)
- Speaking of logging, the installations scripts no longer spew output all over your screen buffer. Thanks to neat trick I picked up from stack exchange, the output of every major command is saved in two separate log files in /var/log:
-/var/log/autosnort_install.log -- contains output from all the major commands ran from the main autosnort installation script
-/var/log/[interfacename]_install.log -- contains output from all the major commands ran from the interface installation script for the interface you chose to install.
- The main autosnort installation script and all the web interface installation scripts have been updated with the new metasploit-like prompts and the background logging. This includes:
-autosnort-CentOS-[date].sh
-snortreport-CentOS.sh
-base-CentOS.sh
-aanval-CentOS.sh
-syslog_full-CentOS.sh
-snorby-CentOS.sh
- All web interface installation scripts for RHEL derivatives have had their DocumentRoot and Directory directives reconfigured to serve out the web interface of your choice. This means all you have to do is point your web browser to the ip address of your sensor's management interface, and provided you reconfigured ip tables to allow port 80 inbound, your web interface will pop up automatically.
- All web interface installation scripts for RHEL-based distros are 100% compatible with SELinux
- All web interface installation scripts for RHEL-based distros have had the ownership of DocumentRoot changed to the apache user and group
-Fixed minor grammatical and syntactical errors littered throughout the script.
Ubuntu/Debian:
- Apparently at some point between now and june, the passenger output directory for the mod_passenger.so binary changed the name of the directory from "libout" to "buildout". sigh. consistency is awesome, don't you agree? I only discovered this during testing passenger during the CentOS testing process.
- In an effort to make the mysql installs uniform between all autosnort builds and promote better security, I've made the mysql-server installation for Ubuntu and Debian silent, but now, just like with the CentOS script, the /usr/bin/mysql_secure_installation script is ran as a part of autosnort. huzzah for better secured databases.
- Same as the CentOS script, found minor grammatical and syntactical errors littered all over the script. Found and fixed what I could.
Code push should be happening tonight before init 1 for the night. As usual, the scripts are open source and are available on the autosnort github:
https://github.com/da667/Autosnort
While we're on the topic of github, I've posted some milestones that officially lay out where I want to take autosnort next -- things I want to accomplish with it. Have a look, see if I'm missing something:
https://github.com/da667/Autosnort/issues/milestones?with_issues=no
And last, but not least... The new project ideas I spoke of in my last blog post? I'm holding a meeting at our local hackerspace about one of them in particular, the passive OS fingerprinting project, trying to get some helping hands with it and make it more of a success. If you're in the Maryland/DC/VA area, come to unallocated space on the 25th so we can get a project outline hashed out.
Cheers,
DA_667
Monday, August 5, 2013
End of my Summer vacation; new projects to consider -- want feedback!
Dear autosnort users,
I just got back from Defcon. Summer is almost over. You're probably wondering if this lazy louse is going to get off his ass and start scripted again. Well, yes, but, I have some details to announce.
1. I will definitely be continuing the Autosnort project. I never really had the intention of taking the summer off, but now I'm kinda realizing that it makes sense to do this. Summer is practically the only time I get to spend with other hackers locally and at Defcon, and one of the few times a year that I get to see family back home.
First on my order of things to do is to finish testing on CentOS for pulled pork. I released the selinux module I painstaking build through a couple of weekings of gnashing teeth and cursing, but I want to have the selinux module generated by the snorby install script for centOS instead of having use have to bring another item with them for the installation. Right now, I have the script echoing out the source of the module that I got to work and building that generated file. It looks kludgy in the code, but it works wonderfully.
2. I have an ambitious project that I really want to get some help doing. I was a former Sourcefire employee. That being said, I'm familiar with RNA or what they call firesight right now. The general gist of this technology is to gain insight as to what operating systems are running in your network, and make one's snort ruleset more efficient based on that -- You're not going to care about X11 exploit rules if you're not running Linux boxes with publically listening X servers, the same as you wouldn't care about seeing alerts about SMB/windows malware attacks if you have your HOME_NET defined as a network that is solely a groupe of freeBSD servers not running samba.
p0f -- passive OS fingerprinting has been around for years, at least a few decades. I was present at shmoocon. The project had been idling for a while up until a group of folks decided to request access to oversee the project and continue on with it. This was a talk at shmoocon over a year ago. The project is alive and kicking.
What I want to be able to do: take p0f signatures, have them monitor a defined network, and develop a measure of confidence as to what is running in your home network.
take this intelligence and use it modify pulledpork -- enable/disable sids based on p0f results, set ip defragmentation and tcp stream reassembly policy by majority of X hosts in your HOME_NET, etc.
the thing is, I'm not quite sure where to start. If anyone wants to help me with this in any way... I want to make this happen.
3. Malware analysis wiki. this inspired by my friend @forgottensec. Forgotten ended up providing the Capture the Flag community the CTF wiki. Well, I want to provide a resource for the information security community as well:
There seems to be information scattered to the seven corners of the internetz. I want to gather as much information as I possibly can into one way for malware analysis techniques. For example, I don't the first thing about using debuggers to debug malware, but I know lots of interesting things to look for, when it comes to dynamic malware analysis. Why not put it some place publically accessible and easily contributed to?
Let me know what your thoughts are on these new developments I'm thinking about, until then... I'm gonna enjoy the end of my summer before I have to get my lazy ass back to work
I just got back from Defcon. Summer is almost over. You're probably wondering if this lazy louse is going to get off his ass and start scripted again. Well, yes, but, I have some details to announce.
1. I will definitely be continuing the Autosnort project. I never really had the intention of taking the summer off, but now I'm kinda realizing that it makes sense to do this. Summer is practically the only time I get to spend with other hackers locally and at Defcon, and one of the few times a year that I get to see family back home.
First on my order of things to do is to finish testing on CentOS for pulled pork. I released the selinux module I painstaking build through a couple of weekings of gnashing teeth and cursing, but I want to have the selinux module generated by the snorby install script for centOS instead of having use have to bring another item with them for the installation. Right now, I have the script echoing out the source of the module that I got to work and building that generated file. It looks kludgy in the code, but it works wonderfully.
2. I have an ambitious project that I really want to get some help doing. I was a former Sourcefire employee. That being said, I'm familiar with RNA or what they call firesight right now. The general gist of this technology is to gain insight as to what operating systems are running in your network, and make one's snort ruleset more efficient based on that -- You're not going to care about X11 exploit rules if you're not running Linux boxes with publically listening X servers, the same as you wouldn't care about seeing alerts about SMB/windows malware attacks if you have your HOME_NET defined as a network that is solely a groupe of freeBSD servers not running samba.
p0f -- passive OS fingerprinting has been around for years, at least a few decades. I was present at shmoocon. The project had been idling for a while up until a group of folks decided to request access to oversee the project and continue on with it. This was a talk at shmoocon over a year ago. The project is alive and kicking.
What I want to be able to do: take p0f signatures, have them monitor a defined network, and develop a measure of confidence as to what is running in your home network.
take this intelligence and use it modify pulledpork -- enable/disable sids based on p0f results, set ip defragmentation and tcp stream reassembly policy by majority of X hosts in your HOME_NET, etc.
the thing is, I'm not quite sure where to start. If anyone wants to help me with this in any way... I want to make this happen.
3. Malware analysis wiki. this inspired by my friend @forgottensec. Forgotten ended up providing the Capture the Flag community the CTF wiki. Well, I want to provide a resource for the information security community as well:
There seems to be information scattered to the seven corners of the internetz. I want to gather as much information as I possibly can into one way for malware analysis techniques. For example, I don't the first thing about using debuggers to debug malware, but I know lots of interesting things to look for, when it comes to dynamic malware analysis. Why not put it some place publically accessible and easily contributed to?
Let me know what your thoughts are on these new developments I'm thinking about, until then... I'm gonna enjoy the end of my summer before I have to get my lazy ass back to work
Subscribe to:
Posts (Atom)