FBI Arrests Suspected LulzSec and Anonymous Hackers

Search warrants were also being executed in New Jersey, Minnesota and Montana. The FBI  arrested two alleged members of the hacking collectives LulzSec and Anonymous on Thursday morning in San Francisco and Phoenix, According to Fox news. The suspected hacker arrested in California is homeless and alleged to have been involved in the hacking of Santa Cruz County government websites.

The person arrested in Arizona is a student at a technical university and allegedly participated in the widely publicized hack against Sony. Both groups have been targeted by the FBI and international law enforcement agencies in recent months.

Meanwhile, the FBI arrested an alleged Anonymous member in San Francisco. The man, who is reported to be homeless, is said to have been involved in internet attacks against Santa Cruz County government websites.Just because a man is homeless, of course, doesn't mean that he can't get an internet connection. Coffee houses, cafes, libraries, etc can all offer cheap or free internet access - and because the computer being used can be a shared device, it may be harder to identify who might have been responsible for an attack compared to a PC at a home.

The arrests shouldn't surprise anyone. They made two errors:
Mistake #1: They brough too much attention to themselves.
It is said that John Gotti, the mafia boss, brought so much attention to himself that he became a natural, high profile target for law enforcement. As Amichai Shulman, our CTO, stated before, the Lulzsec, the hackers "were extremely unfocused in their goal and gained attention mainly due to the relative intensity of their activity and lack of other good media topics." They brought too much attention to themselves and you could expect law enforcement to find them. If you look at hacking historically, over the past 20 years many of the high-profile attacks or those that involve serious losses to governments or commercial companies have ended up with law enforcement finding the perpetrators eventually, such as Albert Gonzalez.

Mistake #2: They didn't cover up their tracks.
Let's review some of the Lulzsec chat logs from a few months ago. One snippet, in reference to discussions Lulzsec was having with the media, shows how the hackers themselves admit they gave away too much informaiton:
Topiary - Sabu and I got a bit carried away and gave LulzSec away a bit
As Imperva's Tal Be'ery said in this USA Today article, "When you're running this kind of operation for a long time, especially with not very concrete plans, you're bound to make mistakes." The mistakes Lulzsec and Anonymous made during their hacking spree left an electronic trail with enough foot prints to product today's arrests.

Vendor Security

I’d like to share our experiences with vendor security since I’m sure it’s something that impacts all of us. Like every company, Rapid7 relies on a number of technology vendors for a huge range of products and services to run the business. I’m sure no one will be surprised to hear that as a security company we have a policy specifying the security requirements that our vendors need to meet before we’ll do business with them. Our view is that their security directly impacts any of our internal or customer data that their systems hold, so we take it as seriously as our own infrastructure security. Most or all of you probably have the same approach, but one unique thing that we have at our disposal is a number of highly skilled security experts on staff which allows us to have a mandatory application security assessment as part of our policy.

The results of this policy over the last few years have been eye-opening.  The number of prospective vendors that pass our security bar is disappointingly low, across every category we used (marketing tools, sales tools, support tools, file transfer tools, IT infrastructure, etc). The most recent failure sparked this blog post, but it was the norm rather than the exception. More often than not they fail basic tests with numerous readily apparent and easily exploitable issues. If the vendor has a great product or service that we think is significantly better than the alternatives we evaluated, we’ll delay our deployment while we engage with them to address the issues we found, getting commitments to fix in a defined timeline. The results there have been equally dismal, with most of them missing their commitments and forcing us to end up going with an alternate months later. It’s clear that our security bar is far higher than their bar, but also that in many cases they don’t have either the desire or skills to significantly improve their security.

All of this ends up slowing our deployment of the various third party solutions, which is an acceptable tradeoff in our view. But what do we do when none of the vendors in the space pass the security bar? And more broadly, what can we do as a security community to raise awareness of the state of vendor security and create impetus for change?  Our individual efforts to push the vendors we’ve engaged with generally haven’t been enough to move the ball. If you have any suggestions on how we can tackle this as a community, please post them below.

In the meantime, I thought I’d share our own approach in case it’s useful to any of you. The overall approach we use is a coordinated process between procurement, legal, and IT security. Having a coordinated process between the business discussion and technical due diligence allows for not just improved decision making, but also more informed negotiation.

1. First, in addition to screening new vendors, if you haven’t already been doing this, start by pulling together a list of all your existing vendors (particularly SaaS vendors that have an exposed security surface). This will be eye-opening the first time you do it, since lots of groups will have been using tools without any IT involvement.
   • One useful tactic we use to find out what’s in use and catch new ad-hoc “deployments” that bypass your vetting process is a periodic review of corporate credit card statements, flagging expenses associated with known vendors & SaaS providers.
2. Use a security questionnaire to understand their security policies, processes, and sophistication.
3. Demand to see the results of their latest security audit, showing what was tested, the findings, and the remediation they’ve done since that time. (We do an audit ourselves because we can). Negotiate for rights to this on a periodic basis.
4. Pay close attention to audit logging functionality. Does the SaaS application track and report on login/logout, user actions within the application, and does it track source IP address? At the very least, you will want to conduct periodic reviews of the account logs to check for anomalies.
5. Scrutinize the identity management capabilities and set a policy for how they are used. Access management, particularly account management, is one of the weakest areas of SaaS security today. Multiple users are often tempted to share accounts because account limits are common to SaaS: this practice needs to be discouraged. Organizational password strength and password rotation policies are usually difficult to enforce when it comes to SaaS. Account provisioning and de-provisioning usually happens outside the IT group, and sometimes there are multiple users on a SaaS application with the ability to create accounts but no single user with clear ownership of, and responsibility for, the application. This creates a substantial risk that accounts will not be revoked in a timely fashion upon a change in employment status. Some approaches that can mitigate the issue:
   • Ensure that IT is solely responsible for account management in all SaaS applications.
   • Conduct periodic reviews of active SaaS accounts across all applications, matching to current employee rosters.
   • Work with your SaaS provider to enact IP-level restrictions to all logins, so that employees are required to be either physically present in the office or connected to the VPN to log in to the SaaS application. This will require the VPN to operate in “full tunnel” mode, where all traffic (including internet traffic) is driven over the VPN to egress from the corporate network.
6. Most SaaS applications allow you to grant different levels of permissions to different users. As much as possible, place reasonable limits on user access levels in SaaS applications. Restrict manager privileges to as few accounts as possible

As companies increasingly rely on SaaS solutions to do every day business, and security moves even further outside of your control, it becomes more and more important to proactively ensure the security and integrity of the solution you rely on. Employing a number of these suggestions, when considering your SaaS solutions, will help put you on the road to a higher level of security serving both your internal stakeholders and customers well.

Article from Rapid7 Blog:

https://community.rapid7.com/community/infosec/blog/2011/12/06/vendor-security

Toolkit cracks encrypted information on iOS 5 devices

ElcomSoft updated the iOS Forensic Toolkit with iOS 5 support for recovering keychain information in iOS 5 devices.

Providing near-instant forensic access to encrypted information stored in the latest iPhone and iPad devices, iOS Forensic Toolkit enables access to protected file system dumps extracted from supported Apple devices even if the original device passcode is unknown.

By performing a physical acquisition analysis of the device itself, the toolkit offers instant access to all protected information including SMS and email messages, call history, contacts and organizer data, Web browsing history, voicemail and email accounts and settings, stored logins and passwords, geolocation history and the original plain-text user passcode.

The tool can also perform logical acquisition of iOS devices, or provide forensic access to encrypted iOS file system dumps.

The toolkit can acquire a 16-Gb iPhone 4 in about 20 minutes, or a 32-Gb version in 40 minutes.

With the release of iOS 5, Apple made some minor tweaks and some major changes to data encryption. “There was no break-through in the iOS security model”, says Andrey Belenko, ElcomSoft leading developer. “The architectural changes are more of an evolution of the existing model. However, we highly welcome these changes, as they present better security to the end user. In particular, the number of keychain items that can be decrypted without the passkey is now less than it used to be. Device passcode is one of the hallmarks of Apple’s security model, and they are expanding the use of it to cover more data than ever before.”

The Toolkit currently supports the following iOS devices:

• iPhone 3G
• iPhone 3GS
• iPhone 4 (GSM and CDMA models)
• iPod Touch (3rd and 4th generations)
• iPad (1st generation only).

Read Full Article 
https://www.net-security.org/secworld.php?id=11867

Information about toolkit 
http://www.elcomsoft.com/eift.html.

Honeynet Project: Android Reverse Engineering (A.R.E.) Virtual Machine released

This VirtualBox-ready VM includes the latest Android malware analysis tools as follows:

• Androguard
• Android sdk/ndk
• APKInspector
• Apktool
• Axmlprinter
• Ded
• Dex2jar
• DroidBox
• Jad
• Smali/Baksmali

A.R.E. is freely available from http://redmine.honeynet.org/projects/are/wiki

Cybercrime investigation center beefed up

The prosecution has decided to bolster its cybercrime investigation center to better cope with hacking and other illegalities on the Internet.

It will assign an additional 25 investigators to its cybercrime squad which is currently comprised of eight officers, the Seoul Central District Prosecutors' Office said Sunday.

The cybercrime investigation center tracks down hackers, electronic commerce fraud, the leak of private information, and other crimes that are committed on the Internet.

“We expect this enforcement of investigations will provide a great leverage for the cybercrime investigation center to crack down on all kinds of crimes on the Internet,” a prosecution official said.

Its move comes as the number of cybercrimes jumped to 164,536 cases in 2009 from 136,819 in 2008. 

Article from: The Korea Times

FBI Investigating Gawker Media Hack

The FBI confirmed to PC World that it is investigating the recent intrusion by a group of hackers into Gawker Media's servers last weekend. The hack exposed more than 200,000 reader e-mail addresses and passwords, and the data is now circulating online as a peer-to-peer torrent file. An FBI representative declined to comment further about the ongoing investigation; however, Gawker Media founder and CEO Nick Denton was scheduled to meet with federal authorities on Monday, according to The New York Post .

On Sunday, an online hacker collective calling itself Gnosis broke into the servers of Gawker Media, which owns a variety of popular online blogs including Deadspin, Fleshbot, Gawker, Gizmodo, Jezebel, io9, Jalopnik, Kotaku and Lifehacker. The hackers obtained the e-mail addresses and passwords for the company's employees, and the source code for Gawker Media's content management system. Gnosis hackers also obtained the login credentials for readers who were registered to leave comments on Gawker Media websites.

Gawker Media said most user login information was encrypted, but Gnosis managed to crack the credentials for more than 200,000 accounts. The exposed login information is now part of a data dump contained in a torrent file available on peer-to-peer file sharing networks.

It's not entirely clear what inspired the attack against Gawker, but a person claiming to represent Gnosis recently told the blog Mediaite that the hacker group broke into the company's servers because of Gawker's "outright arrogance." Previously, it was suggested the Gawker hack was related to the company's ongoing feud with members of 4chan, an online message board. The Gnosis representative said there was no connection between the hacker group and 4chan.

Despite the potentially criminal acts perpetrated by Gnosis hackers, more high-minded hackers (among software engineers the term hacker refers to someone who is a programming expert) were coming to the defense of Gawker Media users. Readers of Y Combinator's Hacker News -- a news aggregator and discussion thread for technology start-up entrepreneurs and software engineers -- banded together to create an automated e-mail program to alert the 200,000 people whose e-mails and passwords were exposed by Gnosis.

If arrested, it's not yet clear what charges those responsible for breaking into Gawker's servers would face.

This article is taken from NetworkWorld.

Xplico 0.5.7: VoIP tapping and phone numbers

The goal of Xplico is extract from an internet traffic capture the applications data contained. For example, from a pcap file Xplico extracts each email (POP, IMAP, and SMTP protocols), all HTTP contents, each VoIP call (SIP), and so on. 

This release introduces improvements in the SIP and RTP dissectors. In this version was also added the RTCP dissector, with this dissector Xplico is able to obtain the phone numbers of the caller and called party (obviously only if present in the RTCP packets). DEFT 5.1 Live distribution contains this version.
You can download source code and Ubuntu 10.04 package here.

More about Xplico:
http://sourceforge.net/projects/xplico/files/
http://www.xplico.org/

Suricata – Open Source Next Generation Intrusion Detection and Prevention Engine

The Suricata Engine is an Open Source Next Generation Intrusion Detection and Prevention Engine. This engine is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field.

Basically it’s a is a multi-threaded intrusion detection/prevention engine engine available from the Open Information Security Foundation. OISF is part of and funded by the Department of Homeland Security’s Directorate for Science and Technology HOST program (Homeland Open Security Technology), by the the Navy’s Space and Naval Warfare Systems Command (SPAWAR), as well as through the very generous support of the members of the OISF Consortium. More information about the Consortium is available, as well as a list of our current Consortium Members.The Suricata Engine and the HTP Library are available to use under the GPLv2.

The HTP Library is an HTTP normalizer and parser written by Ivan Ristic of Mod Security fame for the OISF. This integrates and provides very advanced processing of HTTP streams for Suricata. The HTP library is required by the engine, but may also be used independently in a range of applications and tools.
You can download Suricata v0.9 here:
http://www.openinfosecfoundation.org/download/suricata-0.9.0.tar.gz

For more details, please refer here:
http://www.openinfosecfoundation.org/

CRITICAL LOG REVIEW CHECKLIST FOR SECURITY INCIDENTS

This cheat sheet presents a checklist for reviewing critical logs when responding to a security incident. It can also be used for routine log review. To download it, click here:
http://www.securitywarriorconsulting.com/security-incident-log-review-checklist.pdf


General Approach

• Identify which log sources and automated tools you can use during the analysis.
• Copy log records to a single location where you will be able to review them.
• Minimize “noise” by removing routine, repetitive log entries from view after confirming that they are benign.
• Determine whether you can rely on logs’ time stamps; consider time zone differences.
• Focus on recent changes, failures, errors, status changes, access and administration events, and other events unusual for your environment.
• Go backwards in time from now to reconstruct actions after and before the incident.
• Correlate activities across different logs to get a comprehensive picture.
• Develop theories about what occurred; explore logs to confirm or disprove them.

Typical Log Locations

• Linux OS and core applications: /var/log
• Windows OS and core applications: Windows Event Log (Security, System, Application)
• Network devices: usually logged via Syslog; some use proprietary locations and formats.

What to Look for on Linux

• Successful user login- “Accepted password”, “Accepted publickey”, "session opened”
• Failed user login- “authentication failure”, “failed password”
• User log-off- “session closed”
• User account change or deletion- “password changed”, “new user”, “delete user”
• Sudo actions- “sudo: … COMMAND=…”, “FAILED su”
• Service failure- “failed” or “failure”

What to Look for on Windows
Event IDs are listed below for Windows 2000/XP. For Vista/7 security event ID, add 4096 to the event ID.Most of the events below are in the Security log; many are only logged on the domain controller.

• User logon/logoff events -Successful logon 528, 540; failed logon 529-537, 539; logoff 538, 551, etc
• User account changes- Created 624; enabled 626; changed 642; disabled 629; deleted 630
• Password changes- To self: 628; to others: 627
• Service started or stopped- 7035, 7036, etc.
• Object access denied (if auditing enabled)- 560, 567, etc

What to Look for on Network Devices
Look at both inbound and outbound activities. Examples below show log excerpts from Cisco ASA logs; other devices have similar functionality.

• Traffic allowed on firewall- “Built … connection”, “access-list … permitted”
• Traffic blocked on firewall- “access-list … denied”, “deny inbound”; “Deny … by”
• Bytes transferred (large files?)- “Teardown TCP connection … duration … bytes …”
• Bandwidth and protocol usage- “limit … exceeded”, “CPU utilization”
• Detected attack activity- “attack from”
• User account changes- “user added”, “user deleted”, “User priv level changed”
• Administrator access- “AAA user …”, “User … locked out”, “login failed”

What to Look for on Web Servers

• Excessive access attempts to non-existent files
• Code (SQL, HTML) seen as part of the URL
• Access to extensions you have not implemented
• Web service stopped/started/failed messages
• Access to “risky” pages that accept user input
• Look at logs on all servers in the load balancer pool
• Error code 200 on files that are not yours
• Failed user authentication- Error code 401, 403
• Invalid request- Error code 400
• Internal server error- Error code 500 

Other Resources

• Windows event ID lookup: www.eventid.net
• A listing of many Windows Security Log events: http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx
• Log analysis references: www.loganalysis.org
• A list of open-source log analysis tools: securitywarriorconsulting.com/logtools
• Anton Chuvakin’s log management blog: securitywarriorconsulting.com/logmanagementblog
• Other security incident response-related cheat sheets: zeltser.com/cheat-sheets

How to choose your Information Security Training

Article taken from: http://www.offensive-security.com/blog/offsec/questions-information-security-training-provider/

In the past couple of years, the economy has struck hard on organizations seeking to educate their employees. Training budgets have been cut down, and choosing the right course that will give you real Return on Investment is not an easy job. This is especially true in the offensive InfoSec arena, where training standards and qualifications are weakly defined. So how can you make sure your getting your money’s worth ?

Welcome to our “10 questions you should be asking your InfoSec Training Provider“.

1. What are the objectives of the training ?

What will the training do for you ? Anyone promising you that you will be a “hardcore penetration tester” or a “security expert” after their 5 day class has never run a pentest, or otherwise has no clue what they are talking about. Learning *any* profession in 5 days is unrealistic, let alone one as complex as IT Security, or penetration testing. This is one of the first questions I ask before attending a training… its allows me to set my goals for the course and gives me a baseline for my expectations.

2. What topics does the course cover ?

Always read the syllabus of the course you want to attend, before you attend it.  Try finding other people who have taken the class, (if possible) and get their opinion. Try to see if the syllabus follows a reasonable methodology, or if it’s just a collection of topics. If you see a list of 1500 tools on the syllabus – expect to spend around 0.6 minutes per tool. 

3. Who is your trainer ?

Are they well known in their field ? Do they have training experience ? Are they involved in the security community ? Do they practice what they preach? Although these are 4 separate questions, they all relate to one thing – the ability of the trainer to provide the goods you paid so dearly for. Finding a GOOD InfoSec trainer is NOT easy. Most computer genii are usually lacking in their social skills – something a good trainer must have.

4. What previous reviews does the class have ?

Running a few internet searches for the name of your class, or the name of the trainer is a must. Find out what people have to say about their experiences – during and after the class. Although you can’t believe *everything* on the internet, taking an average of all the reviews will usually give you a solid idea of what you are getting into.

5. What is the ratio of students to trainers ?

How many students will there be in the class ? Some training providers cram more than 30 students in one class – often with a single instructor. During a 5 day period, a trainer can’t give personal attention to 30 people, no matter what. In general, smaller classes mean a more intimate environment, more attention from the trainer, and a more productive and engaging experience.

6. What is the ratio between theory and hands-on exercises ?

Remember the famous saying “In theory, there is no difference between theory and practice – But in practice, there is”. If you don’t exercise what you learn, you are less likely to retain or understand it as nothing replaces practical experience. Ask for a rough ratio estimate for “theory VS exercise” for your class – anything above 40% class-time spent on exercises is a good sign. Of course, this greatly depends on the quality of the exercises too.

7. How often is the course updated ? Is the material relevant to modern day situations ?

Learning methods and techniques on antiquated systems will bring you little benefit in the real world. Hacking a Windows 2000 SP4 machine with RCP DCOM doesn’t cut it any more. On the other hand, don’t expect to learn “Bypassing Windows 7 Stack Protection” in an introductory buffer overflows course. You need to gauge the balance between these two elements carefully.

8. What are the pre-requisites for the class ?

How should you prepare yourself for the class? Do you need to refresh your knowledge on certain topics? Nothing is more frustrating than coming to a class, and then lagging behind because you are not up to par with the class requirements. Not good for your learning experience, and not good for your self esteem – on the other hand “no pre-requisites required” might indicate lack of depth. If the pre-requisites were defined well by the training provider, it’s definitely a good resource to use to evaluate the relevancy of the course to you.

9. Is there a certification involved ? What is it’s value ?

The “value” of a certification can be measured in the real world using two main indicators:

• The “market value” of the certification – how popular is this certification in the workforce ? Is the certificate recognized and appreciated by the industry ? And of course, will it help you get a (better) job ?

• The “practical value” of the certification – or as Eddie Murphy would say “WHAT HAVE YOU DONE FOR ME LATELY?”.  What real world skills does the certificate prove? If it proves you can memorize 100 questions, you might not be up to the job when confronted with a real world scenario.

10. What post training benefits are provided?

What ongoing benefits will you get from the training provider, if any ? Is there a continuation path for the training ? Will the trainers be available for future questions or issues that may arise ? Is there a student community you can join, to discuss the course with other student ? Or in other words, what kind of “post customer service” can you expect ?

These 10 questions should cover all the important elements you should verify before committing your valuable time and limited training budget to any service provider. The average person only gets a limited number of training opportunities per year, therefore you should always maximize the return you receive.

apache.org incident report for 04/09/2010

apache.org incident report for 04/09/2010

Apache.org services recently suffered a direct, targeted attack against our infrastructure, specifically the server hosting our issue-tracking software.

The Apache Software Foundation uses a donated instance of Atlassian JIRA as an issue tracker for our projects. Among other projects, the ASF Infrastructure Team uses it to track issues and requests. Our JIRA instance was hosted on brutus.apache.org, a machine running Ubuntu Linux 8.04 LTS.
Password Security

If you are a user of the Apache hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised.

JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords.

Bugzilla uses a SHA-256, including a random salt. The risk for most users is low to moderate, since pre-built password dictionaries are not effective, but we recommend users should still remove these passwords from use.

In addition, if you logged into the Apache JIRA instance between April 6th and April 9th, you should consider the password as compromised, because the attackers changed the login form to log them.
What Happened?

On April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:

ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured]

Tinyurl is a URL redirection and shortening tool. This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

At the same time as the XSS attack, the attackers started a brute force attack against the JIRA login.jsp, attempting hundreds of thousands of password combinations.

On April 6th, one of these methods was successful. Having gained administrator privileges on a JIRA account, the attackers used this account to disable notifications for a project, and to change the path used to upload attachments. The path they chose was configured to run JSP files, and was writable by the JIRA user. They then created several new issues and uploaded attachments to them. One of these attachments was a JSP file that was used to browse and copy the filesystem. The attackers used this access to create copies of many users' home directories and various files. They also uploaded other JSP files that gave them backdoor access to the system using the account that JIRA runs under.

By the morning of April 9th, the attackers had installed a JAR file that would collect all passwords on login and save them. They then sent password reset mails from JIRA to members of the Apache Infrastructure team. These team members, thinking that JIRA had encountered an innocent bug, logged in using the temporary password sent in the mail, then changed the passwords on their accounts back to their usual passwords.

One of these passwords happened to be the same as the password to a local user account on brutus.apache.org, and this local user account had full sudo access. The attackers were thereby able to login to brutus.apache.org, and gain full root access to the machine. This machine hosted the Apache installs of JIRA, Confluence, and Bugzilla.

Once they had root on brutus.apache.org, the attackers found that several users had cached Subversion authentication credentials, and used these passwords to log in to minotaur.apache.org (aka people.apache.org), our main shell server. On minotaur, they were unable to escalate privileges with the compromised accounts.

About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services. We notified Atlassian of the previously unreported XSS attack in JIRA and contacted SliceHost. Atlassian was responsive. Unfortunately, SliceHost did nothing and 2 days later, the very same virtual host (slice) attacked Atlassian directly.

We started moving services to a different machine, thor.apache.org. The attackers had root access on brutus.apache.org for several hours, and we could no longer trust the operating system on the original machine.

By April 10th, JIRA and Bugzilla were back online.

On April 13th, Atlassian provided a patch for JIRA to prevent the XSS attack. See JRA-20994 and JRA-20995 for details.

Our Confluence wiki remains offline at this time. We are working to restore it.
What worked?

• Limited use passwords, especially one-time passwords, were a real lifesaver. If JIRA passwords had been shared with other services/hosts, the attackers could have caused widespread damage to the ASF's infrastructure. Fortunately, in this case, the damage was limited to rooting a single host.
• Service isolation worked with mixed results. The attackers must be presumed to have copies of our Confluence and Bugzilla databases, as well as our JIRA database, at this point. These databases include hashes of all passwords used on those systems. However, other services and hosts, including LDAP, were largely unaffected.

What didn't work?

• The primary problem with our JIRA install is that the JIRA daemon runs as the user who installed JIRA. In this case, it runs as a jira role-account. There are historical reasons for this decision, but with 20/20 hindsight, and in light of the security issues at stake, we expect to revisit the decision!
• The same password should not have been used for a JIRA account as was used for sudo access on the host machine.
• Inconsistent application of one time passwords; We required them on other machines, but not on brutus. PAM was configured to allow optional use of OPIE, but not all of our sudoers had switched to it.SSH passwords should not have been enabled for login over the Internet. Although the Infrastructure Team had attempted to configure the sshd daemon to disable password-based logins, having UsePAM yes set meant that password-based logins were still possible.
• We use Fail2Ban for many services, but we did not have it configured to track JIRA login failures.

To see full article, please read the link below:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Digital Forensics Case Leads: New Gear, New PDFs Abuse, and Defeating TrueCrypt

Logicube releases new forensics gear, Didier Stevens discovers a new way to do interesting things with a PDF and a cooperative user, and Passware provides a means to defeat TrueCrypt.

Logicube has released two devices which look interesting. The MPFS or Massive Portable Forensic Storage provides up to 8TB of storage capacity for acquiring multiple images. The device may be attached to a forensic analyst’s workstation via firewire, USB, or eSATA. The unit is compatible with Logicube’s Dossier imager and Logicube’s second new device, the NETConnect which as the name suggests, allows network access to forensic images. Based on the description, NETConnect is essentially a file server which enables multiple investigators to access forensic images as soon as they are acquired. The device supports Windows, Mac, and Linux and includes support for CIFS and NFS. (I’ve not had the opportunity to test either device but if Logicube or anyone else wants to send me a set, I will be happy to do a write up.)

If you’ve ever analyzed a PDF, you’ve probably used a tool created by Didier Stevens. Didier has figured out a way to make certain PDF readers execute embedded binaries. Check out his explanation in Good Reads.

Disk encryption in various forms is becoming more common when it comes to incident response and forensics. In response to its customer’s requests, Passware has updated their flagship product to handle TrueCrypt. Their product also has support for BitLocker.

To read more:
http://blogs.sans.org/computer-forensics/2010/04/01/digital-forensics-case-leads-gear-pdfs-abuse-defeating-truecrypt/

FTK 3.0 Forensic Toolkit

FTK 3.0 delivers on a number of advanced capabilities, including greatly enhanced analytics, remote device acquisition and expanded reporting options. GUI speeds and processing time have also been dramatically improved.

Reengineered for Improved Performance:
* UI Performance: The FTK GUI is 10 times more responsive across the board, even on machines with only 4GB of RAM.
* Indexing: Indexes quickly and search results populate fast, even with large result sets.
* Distributed Processing: Every copy of FTK 3 comes with 4 workers, allowing you to leverage CPU resources from up to 4 computers (3 distributed workers and 1 worker on the main FTK examiner system).

Compelling New Capabilities:
* RAM Analysis: Enumerate all running processes from 32-bit machines, search memory strings, and process RAM captures for passwords, html pages, lnk files and MS Office documents.
* Mac Analysis: Many new capabilities, such as processing B-Trees attributes for metadata, decrypting Sparse Images or Sparse Bundles, PLIST support, SQLite support and more.
* Pornographic Image Identification: Enables the automated detection and identification of pornographic images by analyzing visual features in the image to assess its actual visual content.