Cracking Acrobat 9 Password

Adobe admits Acrobat 9 passwords can be guessed more quickly.

Is this a True-Positive or True-Negative alert?

Adobe recently replied to the online discussion of Acrobat's vulnerability to brute-force attacks. Adobe claims that the specification for the 256-bit AES encryption in Acrobat 9 provides greater performance than the 128-bit implementation in previous versions. It is this improved performance that allows Acrobat 9 to open protected documents much more quickly.

Adobe has admitted that brute-force attacks and dictionary-based password cracks benefit from the program's extra speed, because "fewer processor cycles are required" to test each password guess than with AES 128-encrypted documents. Adobe does not say how much faster attacks can be carried out, but Elcomsoft, a manufacturer of password-recovery tools, claims that passwords can now be cracked 100 times faster.

To help mitigate dictionary attacks, Adobe advises customers to use long passwords or pass-phrases. Version 9 supports Unicode pass-phrases up to 127 characters in length. For even greater security, Adobe recommends using encryption based on the Public Key Infrastructure (PKI), although this requires the use of Adobe LiveCycle Rights Management.

See also:

• Manufacturer claims that passwords in Acrobat 9 are easier to crack than in version 8

Patching via Command Line

An interesting article about patching via command line. Below outlines the process and the command involves step-by-step.

• Create a list of server to be patched.

get-qadobject -sizelimit 0 -type computer | where {$_.osname -match "server"} | select name > c:\servers.txt

• Deploy the patch from a share folder.

psexec @serverlist.txt -c "\\File-Server\SecurityPatches$\MS08-067.exe /quiet /norestart /overwriteoem"

• Reboot the servers.

gc c:\servers.txt | ForEach-Object { gwmi win32_operatingsystem -ComputerName $_ | ForEach-Object { $_.reboot() }}

• Verify if any server failed the patching.

function Get-HotFix($server,$hotFixID) {
PROCESS{
$results = gwmi win32_quickfixengineering -computer $_ -filter "HotFixID='$hotFixID'"
if ($results) {
$results | select CSName,HotFixID,@{n="Installed";e={"Yes"}}
} else {
$results = "" | select CSName,HotFixID,Installed
$results.CSName=$_
$results.HotFixID=$hotFixID
$results.Installed="No"
$results
}
}
}
gc (Read-Host "Please provide path to server list file") | Get-HotFix -hotFixID (Read-Host "Hotfix ID") | ft -auto

>>>> See Poor Mans Patching with PSExec and PowerShell

USB 3.0 to Transfer 25GB in 70 Seconds

USB 3.0 will be unveiled soon, and so far the new specs for the protocol look incredible, promising 25GB transfers in a mere 70 seconds. To put that in perspective, the same transfer would take 13.9 minutes with the current USB 2.0 protocol and 9.3 hours on USB 1.0.

HITB Material Archive is Online

The presentation slides for Hack-in-The-Box security conference are online now.

• http://conference.hackinthebox.org/hitbsecconf2008kl/materials/

Security Event Correlation

This is an excellent post from TaoSecurity about SEM or SIEM.

Defining Security Event Correlation

This my final post discussing security event correlation (SEC) for now. (When I say SEC I do not mean the Simple Event Correlator [SEC] tool.)

Previously I looked at some history regarding SEC, showing that the ways people thought about SEC really lacked rigor. Before describing my definition of SEC, I'd like to state what I think SEC is not.

So, in my opinion -- you may disagree -- SEC is not:

1. Collection (of data sources): Simply putting all of your log sources in a central location is not correlation.
2. Normalization (of data sources): Converting your log sources into a common format, while perhaps necessary for correlation (according to some), is not correlation.
3. Prioritization (of events): Deciding what events you most care about is not correlation.
4. Suppression (via thresholding): Deciding not to see certain events is not correlation.
5. Accumulation (via simple incrementing counters: Some people consider a report that one has 100 messages of the same type to be correlation. If that is really correlation I think your standards are too low. Counting is not correlation.
6. Centralization (of policies): Applying a single policy to multiple messages, while useful, is not correlation itself.
7. Summarization (via reports): Generating a report -- again helpful -- by itself is not correlation. It's counting and sorting.
8. Administration (of software): Configuring systems is definitely not correlation.
9. Delegation (of tasks): Telling someone to take action based on the above data is not correlation.

So what is correlation? In my last post I cited Greg Shipley, who said if the engine sees A and also sees B or C, then it will go do X. That seems closer to what I consider security event correlation. SEC has a content component (what happened) and a temporal component (when did it happen). Using those two elements you can accomplish what Greg says.

I'd like to offer the following definition, while being open to other ideas:

Security event correlation is the process of applying criteria to data inputs, generally of a conditional ("if-then") nature, in order to generate actionable data outputs.

So what about the nine elements are listed? They all seem important. Sure, but they are not correlation. They are functions of a Security Information and Event Management (SIEM) program, with correlation as one component. So, add correlation as item 10, and I think those 10 elements encompass SIEM well. This point is crucial:

SIEM is an operation, not a tool.

You can buy a SIEM tool but you can't buy a SIEM operation. You have to build a SIEM operation, and you may (or may not) use a SIEM to assist you.

Wait, didn't Raffy say SIM is dead? I'll try to respond to that soon. For now let me say that the guiding principle for my own operation is the following:

Not just more data; the right data -- fast, flexible, and functional.