Continue reading »]]> So, first things first .. while I was researching information for this post I very quickly realised that safesearch is a requirement! Who would have thought that outside of the NSM world people would be posting about this whole “squert” thing (and not in a very savoury fashion either!)

With that said, let’s move on to my next topic!

We’ve spent a couple of posts now using Security Onion to do some basic web application attack detection where we looked at an attack & wrote a basic rule to detect it. We then looked at using sguil for categorising events manually, using the autocat.conf file for automatically categorising events and configuring the sguild.conf file to generate an email alert when certain alerts were generated. Today we are going to look at using squert for monitoring and reporting. The basic web interface reports generated by squert are great for non-technical management (they always love pretty colours, bar graphs, pie charts etc.), but as an analyst you can also use the interface to drill down into the alerts to get far greater detail. This post will focus more on the types of reports that could be shown to management, or included in monthly reports and so on, as an analyst I would suspect you would much rather work in sguil (well, I would).

Squert

After you have done the initial Security Onion install you will see an icon on the desktop that points to the squert webpage. In case you don’t it can be found at the following address

Squert web address – https://localhost/squert

Overview

“Squert is a web application that is used to query and view event data stored in a sguil database (typically IDS alert data). Squert is a visual tool that attempts to provide additional context to event through the use of metadata, time series representations and weighted and logically grouped result sets” (from www.squertproject.com). Squert is not a replacement for the sguil client, and is not intended to be a realtime (or near realtime) event console.

Squert has the following views to help in the interpretation of data

Overview Events/Traffic

Here you can see the total number of events in the sensors database, the total number of signatures detected, the total number of sources of traffic, and the total number of destination addresses. You will also see the various traffic counts on the sensor for the different agents that are running on it (e.g. snort, pads, ossec etc.). As this is in a lab environment the traffic counts are quite low.

Overview of Event Distribution/Classifications

In this screen shot, you can see where events have been categorised (either manually or automatically through the autocat.conf file). Once again you can see the number of signatures, source addresses, destination addresses and number of events triggered per category (and what that category is).

Overview of Top Detected Signatures

This screen shot shows the top detected signatures.

Percentages of Detected Signatures

Here you can see we have an awesome management pie chart of the top detected signatures. If you include this in a monthly report you can almost guarantee yourself a promotion J

Overview of Top IPs and Ports

Here we have a few bar graphs top IP’s and ports. These reports will be good to monitor as time goes on for different trends, who knows, you might be one of the lucky kids on the block to notice traffic on a certain port when a cool new exploit comes out!!

Query View of all Detected Traffic

And finally we have a query view of traffic. This is one of the views that an analyst can drill down on to get a lot more detailed information about an event or alert.

So there you have it. A quick and dirty look at the basics of squert! There is a lot more to the squert interface, but this should give you a little insight into what it’s about.

Continue reading »]]> So, we have already had a quick look at some basics with SecurityOnion for detecting a file execution attack and how to write a rule up to detect it. The next thing we might want to do as an analyst is to have events that show up in sguil categorised (both manually and automatically) and then to get an alert when particular events are triggered.

Categorising Alerts

Both sguil and squert have ability to classify events into categories, as you can see in the following images (figure 1 & figure 2). These categories can be used to group similar events together to help an analyst review the alerts that have been triggered on their network. For example, any form of ping sweep or port scan could possibly be classified as Category 6 – Reconnaissance/Probes/Scans. All of the category 6 alerts can then be removed from the main console windows allowing the analyst to concentrate other important alerts without having to review all of the other noisy traffic. The classification of events can be done manually through sguil, or automated with the use of the autocat.conf file (this will then classify the events in sguil, squert and other consoles).

Figure 1 – Sguil Categories

Figure 2 – Squert Categories

SGUIL Categorisation

To manually classify an event in the console, the analyst would highlight the alert and press the appropriate function key associated with the event classification, or right click on the event and choose the appropriate event status. Similarly, if an analyst determines while reviewing the alerts in the console that some of them can be classified as normal traffic, they can easily highlight them and press the F8 key to indicate that no further action is necessary and they will be cleared from the console screen.

Sguil uses the following categories with associated function keys to classify events in the console.

F1: Category I: Unauthorized Root/Admin Access
F2: Category II: Unauthorized User Access
F3: Category III: Attempted Unauthorized Access
F4: Category IV: Successful Denial-of-Service Attack
F5: Category V: Poor Security Practice or Policy Violation
F6: Category VI: Reconnaissance/Probes/Scans
F7: Category VII: Virus Infection
F8: No action necessary
F9: Escalate

A screen shot of the console can be seen in figure 3 (below)

Figure 3 – Classifying an event in sguil

If an analyst can’t determine how to classify the event, they can escalate the alert by pressing F9. This will then move the event into the “Escalated Events” tab in sguil for further analysis (see figure 4 below).

Figure 4 – Escalated alerts

In the below scenario (figure 6), you can see that the analyst has classified package management events as a Category 5 alert (Poor Security Practice or Policy Violation). The analyst has then run a query for category 5 events by selecting “Query” -> “Query by Category” -> “Cat V” from the sguil console (figure 5).

Figure 5 – Event classification in sguil

Figure 6 – Even classification query

AUTOCAT.CONF

To automate the classification of some events, an analyst can use the /etc/nsm/securityonion/autocat.conf file. Automated classification of events should be reserved for special cases and not used to try and classify all the events in the analysts console. The format of an autocat.conf rule is as follows (from the autocat.conf file) :

<erase time>||<sensorName>||<src_ip>||<src_port>||<dst_ip>||<dst_port>||<proto>||<sig msg>||<cat value>

- <erase time> is the time the filter will be removed in # YYYY-MM-DD TT:TT:TT format. Use ‘none’ if you wish to make # the rule permanant.

- Sensor name is the name of the sensor to filter on. Can by ‘any’ # # – The value of ‘any’ can be used for any of the ip, port, and sig msg fields.

- proto can be ‘any’ or the int value for the proto (6 == TCP, 17 == UDP, 1 == ICMP)

- The <cat value> is the value for that category in the DB.

    Cat I – VII == 11 – 17 : NA == 1

- The src_ip and dest_ip can be networks in CIDR notation (eg: 10.0.0.0/24)

- sig msg can use TCL regexp format. To make a sig msg a regexp begin the rule with %%REGEXP%%

    Do not use / / syntax. Matching is case sensitive unless the string is preceded by a (?i). Use ^ to match the beginning of the line and $ for the end.

Examples:

- ‘%%REGEXP%%Testing’ would match ’123Testing123′ but not ’123testing123′

- ‘%%REGEXP%%(?i)testing’ would match both ’123Testing123′ and ’123testing123′

- ‘%%REGEXP%%^Testing’ would match ‘Testing’ but not ’123Testing’ and not ‘testing’

- ‘%%REGEXP%%(?i)^testing would match ‘Testing’ and ‘testing’ but not ’123testing’

- if you don’t use %%REGEXP%% the string you type in the sig must EXACTLY match the rule.

For the event in sguil as shown in figure 7, we could write the following basic example rule:

Figure 7 – sguil event

none||ANY||ANY||ANY||ANY||ANY||ANY||%%REGEXP%%GPL SHELLCODE||13

This rule uses the following options :

erase time – none (the rule is permanent)

sensor name – any of the sensors

source IP – any source IP

source port – any source port

destination IP – any destination IP

destination port – any destination port

protocol – any protocol

sig message – a regular expression for any event with “GPL SHELLCODE” in the signature

category value – Category 3 Attempted Unauthorized Access

Once the sensor has been restarted, the categories will start to populate with the alerts that are configured in the autocat.conf file. Figure 8 displays how a Cross Site Scripting alert gets automatically classified as a category 2 event.

Figure 8 – Auto categorised events

Email Alerting with Sguil

Another functionality sguil provides the analyst is the ability to send email alerts on particular SIDs or Classes when they have been triggered. To configure this utility the analyst must do the following :-

1. edit /etc/nsm/securityonion/sguild.email
   
   1. set Email_Events 1 <- this enables email alerts
      
   2. set SMTP_SERVER mail.domain.com <- this is your SMTP mail server
      
   3. set EMAIL_RCPT_TO “analyst@company.com” <- this is who you want to send the email to
      
   4. set EMAIL_FROM “snort_sensor@company.com” <- this is who the email is from
      
   5. set EMAIL_CLASSES “successful-admin trojan-activity attempted-admin attempted-user” <- these are the classes of events you want email alerts triggered for
      
   6. set EMAIL_ENABLE_SIDS “2009714″ <- this is for any specific SID’s that you would like an email alert generated for
      
2. restart sguil with – “sudo nsm_server_ps-restart”
   
3. check that your email configuration with the following command – “head -20 /var/log/nsm/securityonion/sguild.log”
   

Below is an example output of a configured sguild.email configuration

root@SecOnionSnort:/etc/nsm/securityonion# head -20 /var/log/nsm/securityonion/sguild.log
Executing: sguild -c /etc/nsm/securityonion/sguild.conf -a /etc/nsm/securityonion/autocat.conf -g /etc/nsm/securityonion/sguild.queries -A /etc/nsm/securityonion/sguild.access -C /etc/nsm/securityonion/certs
2012-04-28 06:58:03 pid(5248) Loading access list: /etc/nsm/securityonion/sguild.access
2012-04-28 06:58:03 pid(5248) Sensor access list set to ALLOW ANY.
2012-04-28 06:58:03 pid(5248) Client access list set to ALLOW ANY.
2012-04-28 06:58:03 pid(5248) Adding AutoCat Rule: ||ANY||ANY||ANY||ANY||ANY||ANY||%%REGEXP%%^URL||1
2012-04-28 06:58:03 pid(5248) Adding AutoCat Rule: ||ANY||ANY||ANY||ANY||ANY||ANY||ET WEB_SERVER Script tag in URI, Possible Cross Site Scripting Attempt||12
2012-04-28 06:58:03 pid(5248) Email Configuration:
2012-04-28 06:58:03 pid(5248) Config file: /etc/sguild/sguild.email
2012-04-28 06:58:03 pid(5248) Enabled: Yes
2012-04-28 06:58:03 pid(5248) Server: mail.domain.com
2012-04-28 06:58:03 pid(5248) Rcpt To: analyst@company.com
2012-04-28 06:58:03 pid(5248) From: snort_sensor@company.com
2012-04-28 06:58:03 pid(5248) Classes: successful-admin trojan-activity attempted-admin attempted-user
2012-04-28 06:58:03 pid(5248) Priorities: 0
2012-04-28 06:58:03 pid(5248) Disabled Sig IDs: 0
2012-04-28 06:58:03 pid(5248) Enabled Sig IDs: 2009714
2012-04-28 06:58:03 pid(5248) Connecting to localhost on 3306 as sguil
2012-04-28 06:58:03 pid(5248) MySQL Version: version 5.1.41-3ubuntu12.10
2012-04-28 06:58:03 pid(5248) SguilDB Version: 0.13
2012-04-28 06:58:03 pid(5248) Creating event MERGE table.

Once a SID or class is triggered, sguil will send an email alert to the configured recipients. An example email is shown in figure 9

Figure 9 – Email alert

Continue reading »]]> OK .. we have an application that is vulnerable to command execution (we are using the damn vulnerable web application, or DVWA distro for this)

It’s a simple application to ping a machine on the network, internet, or perhaps space! It’s a basic little thing that lets you enter an IP address and it will run the ping command and return the result.

It seems though, through a little bit of basic command line knowledge that you can also chain commands together and get them to run besides just the programmed ping command

So at its simplest form you can see we now are not bound by just the programmed intention of this little script. The question then is, “So what else can we do with this then?”. First of all, we can pull a copy of netcat over and kick it off so that we can connect to a shell. I won’t get into details on how to do this .. but you can easily accomplish this with the use of Backtrack. So on our vulnerable website we would issue the following command

And if we have everything set up correctly, we should see the following screen

We now have a shell on our vulnerable web server. I will say right now however, this is greatly simplified by having a known vulnerable web application (a part of the DVWA distro).

From here we can either try and elevate our privileges to own the box, or we could pivot off of it to another machine or network.

Here you will see that out of the box, both snort and suricata both detect the transmission of the windows netcat binary over tftp.

So say we just wanted to detect that netcat was run and was offering up a shell (this is denoted in netcat with the “-e cmd” switch). We could easily knock out a quick snort/suricata rule to detect (in it’s most simplest form) the “-e cmd” switch. To do this we first need to know what we are looking for to generate a rule. Lets take a wireshark sample of the traffic when the web application is getting exploited. The TCP stream that carries the http post request looks like below. Take note of the actual post command! (A quick side note here – we could have also used burp or some other intercepting proxy to manipulate the data when it is sent back to the web server from the clients browser instead of just putting it into the provided web application field)

The actual transfer of traffic looks like below. Take note of the source & destination addresses, and the ports used for the communication (52888 & 80).

So using the information we have we can craft a rule that looks something like the following (this is very ugly and a rule at the most basic level and will possibly cause a few false positives – it does work however but you would be better off writing a nice clean rule)

We then will see the following alert in sguil

We can of course really define our rule a lot better than what we have here, but that’s not really the point of this post for me

Another line of defense would be to use a Web Application Firewall (WAF) in front of our web application .. or if you want to get totally crazy you could always code your application securely .. but hey thats just me.

Continue reading »]]> Well, it looks like we have a new GCFA in town .. thats me!

I’ll be honest .. forensics really isn’t my thing. My mind doesn’t work the right way for it .. it just doesn’t click like other lethal forensicators.

I did however, tackle FOR508 with Rob Lee last year in Vegas after my GSE exam (why didn’t I pick something simple to give my head a rest) and I really enjoyed it! I hadn’t completed FOR408 so I really felt like I missed out on some of the basic foundation information that was required, and I felt that during my exam.

I put a fair bit of hard work and effort into passing the GCFA and its a cert i’m definitely proud of. Its not that simple or straight forward, and I now have the ability to go through a stack of old and broken hard drives at home and possibly get a bunch of old lost photos off of them now

I guess really the highlight to my whole exam was seeing Chris Mohan and his lovely hair .. that really got me through at the end of the day – Thanks Chris!

For now though, its back to this stinking Gold Paper .. I want to get the GSE and have a break!

Oh yeah .. im doing SEC660 in July hahahahahah

Continue reading »]]>  

The dominance of exploit kits like Blackhole, Incognito and others, continues to be seen in the wild. Attackers continue to use these exploit kits to generate malicious webpages and host them on various domains. These exploit kits usually targets browser and browser plugin vulnerabilities.

To increase the likelihood of a successful attack, exploit kits are commonly used to infect legitimate sites that already have significant traffic. Attackers achieve this by crafting scripts designed to identify sites with injection vulnerabilities, which allow for hidden iFrames to be written, which then point to the exploit kit URL. When users visit the infected sites and are redirected to the browser exploit kits, a known browser or plugin vulnerability is typically used to download and execute malicious content without user knowledge. You can visit this related blog for more information about iFrame injection in detail.

Recently, I’ve seen a spike in such compromised sites, which lead to exploit kit URLs.In most cases, the JavaScript code containing the hidden iFrame is heavily obfuscated. Different exploit kits have their own techniques to obfuscate malicious code. Let’s take look at a couple of examples and their respective de-obfuscated code.

Read the full article on Zscaler Research

Continue reading »]]>

While unpatched systems are often the first stepping stone of a breach, it’s often weak or shared credentials that help attackers intrude deeper into the network and breach sensitive data. Common problems are:

• Weak passwords that lack length or complexity
• Passwords contained in dictionaries
• Passwords that are easily guessed based on information about the infrastructure
• Vendor default passwords
• Replaying cached credentials
• Re-use of passwords across trust zones
• Development test credentials in a production environment
• Active accounts of previous employees

Services You Can Audit With Metasploit

These are all issues you can scan for with Metasploit. Unlike other password auditors that only test Windows login credentials, Metasploit Pro can brute force passwords to audit passwords across a wide range of operating systems and services, including:

• SMB/Windows/CIFS server
• PostgreSQL database
• IBM DB2 database
• MySQL database
• Microsoft SQL Server database Oracle
• Oracle RDBMS Server
• HTTP server (basic authentication)
• HTTPS server (basic authentication)
• Secure Shell server
• Telnet server
• File Transfer Protocol server
• Post Office Protocol v3 server
• BSD Remote Execution server
• BSD Remote Login server
• BSD Remote Shell server
• VNC/RFB server
• Simple Network Management Protocol

Where You Can Learn More

HD Moore, the Metasploit Chief Architect, is showing some of the tips and tricks of how to audit passwords with Metasploit in next week’s webinar. Register now and save the date on your calendar!

Read the full article from Rapid7 Community : Blog List – Metasploit

Continue reading »]]>

From Oracle:

This Critical Patch Update Pre-Release Announcement provides advance information about the Oracle Critical Patch Update for January 2012, which will be released on Tuesday, January 17, 2012. While this Pre-Release Announcement is as accurate as possible at the time of publication, the information it contains may change before publication of the Critical Patch Update Advisory.

A Critical Patch Update is a collection of patches for multiple security vulnerabilities. This Critical Patch Update contains 78 new security vulnerability fixes across hundreds of Oracle products. Some of the vulnerabilities addressed in this Critical Patch Update affect multiple products. Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply Critical Patch Update fixes as soon as possible.

78 security patches. I’ll say that again. 78 oracle security patches. While I’m glad that they’re fixing their stuff it is just a little amazing that there are that many. And DBA’s being who they are will vacillate and come up with all kinds of reasons why they can’t apply patches as they still haven’t done the ones from 2010. In other words…job security for the rest of us.

Oh, and if that wasn’t enough there will also be 27 MySQL patches released at the same time.

Source: Article Link

from Liquidmatrix Security Digest