Thursday, May 17, 2007
May GRSec is Next Wednesday @ GRBC
Come hang out with infosectarians in West Michigan next Wednesday at GRBC. Stu Berman will be there and has assured me that he is bringing international guests. So it will definitely be a good time. See you there!
ArcSight 4.0 Released
As far back as a year ago there was working code that ArcSight was calling "four-point-oh." So there's no big news here other than the fact that this week ArcSight released installers and docs and all of that good stuff to their software site for general consumption. Add to that the fact that I can't find the announcement on their web site or in general press, and I figure that makes it blogworthy.
What's also blogworthy is the fact that if you're an existing customer and want to upgrade, you're stuck until August when ArcSight releases the upgrade-capable installers with SP1. Or, like with 3.5, you can pay their pro services team to do the upgrade for you before then. Anyway, I'm spoiling the feature list here:
What's also blogworthy is the fact that if you're an existing customer and want to upgrade, you're stuck until August when ArcSight releases the upgrade-capable installers with SP1. Or, like with 3.5, you can pay their pro services team to do the upgrade for you before then. Anyway, I'm spoiling the feature list here:
Key features of ArcSight ESM v4.0 include :
Identity Correlation ArcSight ESM v4.0 identity correlation can model the typical behavior of groups, machines, or individuals (as reflected in events) and provides a framework to access any other form of session data through mappings with dynamic variables. This information can be used or shown in rules, reports, active lists, active channels, and data monitors. Improved Asset Management & Scalability ArcSight ESM v4.0 introduces the ability to manage up to one million assets while maintaining performance, including maintaining memory usage in-line, processing, correlation, and ensuring sustained EPS (events per second). Trend Reporting & Report Generation Performance Trend Reporting enables the ready historical trending often required for regulatory compliance reporting. Trend reporting can track a trend over a specified period of time, and highlight changes in risks or threats during that period. Trend reporting improves report generation performance for regularly scheduled reports by tracking trends over a user-specified time and by keeping the data easily accessible. New Report and Template Designer ArcSight ESM v4.0 provides a new, more powerful and highly flexible reporting system. You can use this design capability to create well-defined reports for different scenarios or audiences. This feature offers options for unique queries and to define the overall look-and-feel for presenting information. These new features include the ability to report on several data queries simultaneously, using multiple charts and grids in one report. Report formats, layout, and overall look-and-feel can be customized to your needs. Historical Correlation ArcSight ESM v4.0 enhances the Verify Rules with Events capability (previously known as Replay with Rules) so you can define actions based on processing historical data through the correlation engine. ArcSight Packages ArcSight ESM v4.0 introduces a new feature called packages. A package is an ArcSight resource that acts as a portable container for group resources or content (e.g., rules, filters, data monitors, reports, etc). Resource Validation Enhancements ArcSight ESM v4.0 enhances resource validation beyond rule- and network-modeling, adding the ability to validate cross-resource dependencies automatically, and interactively, through the Console. This enables the ArcSight Manager to detect resource conflicts introduced during resource modification, creation, upgrading or importing. ArcSight ESM v4.0 64-bit The 64-bit JVM version of ArcSight ESM v4.0 will be made available as part of a controlled release. Customers who are interested in participating should contact Technical Support for additional information.
Thursday, May 10, 2007
Windows Logoff Events
Eric Fitzgerald at Microsoft posted a nice write-up on the subtleties of Windows logoff events. If you collect EventLog data in your SIM or if you have occasion to read EventLog files, I recommend reading Eric's post as well as the rest of mine.
To summarize (translate?), Eric's saying don't trust logoff events to indicate an actual logoff. It could be a timeout or a kerberos token expiring or being reclaimed by the server.
There's something of an exception to this, and you can probably find it in your EventLogs. EventID 538 - "User Logoff" - records a connection type with a decimal value. The value can be 2 or 3. Most of what you will see are type 3 connections, which can mean several different things. But type 2 logoffs indicate the end of an interactive (think RDP) session. That, again, doesn't guarantee that someone actually clicked Start -> Log Off, but it does indicate a definitive end to the session, whether it's a forced disconnect by the client or server, or a clean logoff.
The use case for logoff events is primarily forensic. "When was so-and-so using that system / at work?" "Who was logged on to server X between time A and time B?" And the fact that these events are soft and wonky is frustrating, but being aware of the squishiness of their meaning is important when using them in an investigation. This is where your SIM can really help, because sometimes the best indicator of a logoff/shutdown isn't a single event, but rather the end of activity. "I know Mr. Schmeaux stopped working at 3:30pm that day because there were no more events from his username or workstation IP address after that time."
To summarize (translate?), Eric's saying don't trust logoff events to indicate an actual logoff. It could be a timeout or a kerberos token expiring or being reclaimed by the server.
There's something of an exception to this, and you can probably find it in your EventLogs. EventID 538 - "User Logoff" - records a connection type with a decimal value. The value can be 2 or 3. Most of what you will see are type 3 connections, which can mean several different things. But type 2 logoffs indicate the end of an interactive (think RDP) session. That, again, doesn't guarantee that someone actually clicked Start -> Log Off, but it does indicate a definitive end to the session, whether it's a forced disconnect by the client or server, or a clean logoff.
The use case for logoff events is primarily forensic. "When was so-and-so using that system / at work?" "Who was logged on to server X between time A and time B?" And the fact that these events are soft and wonky is frustrating, but being aware of the squishiness of their meaning is important when using them in an investigation. This is where your SIM can really help, because sometimes the best indicator of a logoff/shutdown isn't a single event, but rather the end of activity. "I know Mr. Schmeaux stopped working at 3:30pm that day because there were no more events from his username or workstation IP address after that time."
Tuesday, May 8, 2007
One for the RSS aggregator: Chinese bot/sploit blogs
OK, so I can't read Chinese (or Japanese, or Korean, or...) characters to save my life. But in the course of my recent adventures in obfuscated JavaScript droppers, I stumbled across something interesting. I put the first piece of some obfuscated JavaScript in Google, and I got 2 hits!
I was really hoping to find a page on this particular type of encoding and where and how it's been used in the past. Instead, I found it posted to a pair of blogs in China, with no accompanying perl scripts for decoding the payload, so I can only assume the intent of the poster(s).
I was really hoping to find a page on this particular type of encoding and where and how it's been used in the past. Instead, I found it posted to a pair of blogs in China, with no accompanying perl scripts for decoding the payload, so I can only assume the intent of the poster(s).
Monday, May 7, 2007
Quick & Dirty JavaScript Sandbox
It seems like more and more browser attacks are using obfuscated JavaScript to make analysis harder. Some things are as simple as UTF encoding, others are far more inventive and confusing. Just like packed executables before, there are legit reasons for wanting to obscure JavaScript, like making it harder for people to steal your code.
So when your IPS alerts on suspicious JavaScript (which is almost never blocked in a default configuration), you can:
Today, however, I ran into a higher-than-usual volume of alerts, all of which were based on the presence of an unescape() call. In anticipation of having to do this again, and the VM being a poor solution to begin with, I built a Java sandbox, starting with a JavaScript interpreter.
Here's the recipe:
1. Cygwin (optional, but you know I love it, and it makes certain things easier)
2. Current Sun JRE for Win32
3. Rhino JavaScript engine
Create an unprivileged local user who's not even a member of 'Everybody'. You're never going to log in as this user anyway. Now unpack the JRE and Rhino to a directory where that user can view them. If you have Cygwin, build a home directory for your user, and then create a bash shell shortcut with that directory in the "Start In" line. Now use RunAs to launch your shell as the unprivileged user, and start Rhino:
Now you can dump JavaScript to the shell and watch it execute with relatively low risk of pwnage. Rhino also has a GUI debugger that's ideal for stepping through more advanced JavaScript trickery.
So when your IPS alerts on suspicious JavaScript (which is almost never blocked in a default configuration), you can:
- A) Investigate, get a sample of the offending page and potentially spend hours trying to work back through it by hand.
- B) Investigate, browse the page with your browser to see what happens, and potentially get pwned.
- C) Ignore it, and hope the local AV got it.
Today, however, I ran into a higher-than-usual volume of alerts, all of which were based on the presence of an unescape() call. In anticipation of having to do this again, and the VM being a poor solution to begin with, I built a Java sandbox, starting with a JavaScript interpreter.
Here's the recipe:
1. Cygwin (optional, but you know I love it, and it makes certain things easier)
2. Current Sun JRE for Win32
3. Rhino JavaScript engine
Create an unprivileged local user who's not even a member of 'Everybody'. You're never going to log in as this user anyway. Now unpack the JRE and Rhino to a directory where that user can view them. If you have Cygwin, build a home directory for your user, and then create a bash shell shortcut with that directory in the "Start In" line. Now use RunAs to launch your shell as the unprivileged user, and start Rhino:
Now you can dump JavaScript to the shell and watch it execute with relatively low risk of pwnage. Rhino also has a GUI debugger that's ideal for stepping through more advanced JavaScript trickery.
Thursday, May 3, 2007
Rothman Redux
Apparently nothing fires me up like Mike Rothman eulogizing SIM. Again.
"SIMs not dead, eh? - Then why is almost every SIM vendor announcing a dedicated log management appliance?"
Perhaps because Oracle or SQL tables are a lousy (and expensive) place to store your logs for years and years. Or perhaps because you don't want to shell out $10K/seat for a full featured console so your sysadmins can search your logs once a week while on a troubleshooting mission. Or, perhaps most likely of all, because infosec customers love appliances.
"How many more data points do we need about the evolving SIM space before we can finally start shoveling dirt on it?"
Let's not forget to also bury heuristic AV, behavioral IPS, deep packet inspection firewalls, and every other infosec product 'next' that has come to pass over the last decade. They all suck and nobody buys them.
Anyway, Mike's point is that since SIM vendors copy each other and are trying to sell log appliances because they discovered that agents don't scale as aggregation points, that SIM is over. Clearly.
"SIMs not dead, eh? - Then why is almost every SIM vendor announcing a dedicated log management appliance?"
Perhaps because Oracle or SQL tables are a lousy (and expensive) place to store your logs for years and years. Or perhaps because you don't want to shell out $10K/seat for a full featured console so your sysadmins can search your logs once a week while on a troubleshooting mission. Or, perhaps most likely of all, because infosec customers love appliances.
"How many more data points do we need about the evolving SIM space before we can finally start shoveling dirt on it?"
Let's not forget to also bury heuristic AV, behavioral IPS, deep packet inspection firewalls, and every other infosec product 'next' that has come to pass over the last decade. They all suck and nobody buys them.
Anyway, Mike's point is that since SIM vendors copy each other and are trying to sell log appliances because they discovered that agents don't scale as aggregation points, that SIM is over. Clearly.
Subscribe to:
Posts (Atom)