It has been a while since the last published article, and we are not going to try to make excuses.
But we are enticed to do a quick note of the developing story of STRATFOR. In summary, Strategic Forecasting (STRATFOR) servers got hacked by a group apparently affiliated with Anonymous. Anonymous have since denied any involvement in the hack.

The attack apparently resulted in more than 200 GB of data being stolen.

The story of the hackers is published on pastebin
http://pastebin.com/q5kXd7Fd

The STRATFOR site is currently offline



I can honestly say that I would not want to be in the shoes of the IT guys nor the CEO of STRATFOR.

This incident shows that even guys which do intelligence and security for a living can fail miserably at protecting their information assets.

But what is much more bizarre is the fact that STRATFOR decided to keep a large number of credit card numbers in their databases, thus creating a huge financial problem, which will greatly increase the profile of the incident.

Talkback and comments are most welcome

Related posts
Blogtipz Hacked
When Will Your Mobile Phone get Hacked?

More and more IT services are being outsourced. And as telco services are now easily integrated and transported over IP protocols, the outsourcing is being well established with telco.

But the issue with telco services is that quality in telco is very difficult to properly define. This is because there are parameters that are difficult to track – sound quality, response of system to tone-dial menu selection of an IVR, unexpected intermittent interruptions of voice communication, temporarily unavailable service.
And when part of the telco service is outsourced, it becomes even more difficult to manage the quality of such services.

Here are some elements that will affect the quality of outsourced telco services:

1. Oversubscription to outsourcing service – the service may be of a variable quality, with off and on periods when service is poor and then it’s great. This is usually connected to oversubscription of the outsourcing service, and when their services are overloaded, the customer facing service is of poor quality.
2. Availability of the oursourcing servers – simple and straightforward, power outages, server outages, cooling outages all create failures that interrupt service. Even if there are secondary servers, the switchover will fail all active connections
3. Connectivity to outsourcing service - most outsourcing services are far and away, most often in asia. So internet links will be the primary connectivity media to such outsourcing services. But the internet as a medium has a lot of possible issues and failures of connectivity paths are not that rare.

When the outsourcing service is part of your call management, things get very interesting. Services that are part of the call management process that are easily outsourced are ringback tone, voice mail, autoanswer etc.


How to solve this issue of quality when outsourcing? There is no magic bullet, but here are some experiences and pointers:

• Ofcourse, you will create the standard contract with availability, packet loss and jitter criteria. (see related posts)
  
• You can also include call disconnects or failure to connect.
• It would be very good to try to connect this to customer complaint number, but the outsourcing service will be very reluctant to accept a quality of service condition is connected to a very subjective criteria that cannot be measured and confirmed by both parties independently.
• Create a criteria of complaint to outsourcing service - for example, if the telco customer detects issues that are so large that they need to send a complaint to their outsourcing service more then 4 times every quarter, that would be a basis for a contract review. This clause is very wise to include especially in the first year of use of the outsourcing service, when you are still learning their weak points

Talkback and comments are most welcome

Related posts
Telco SLA - parameters and penalties
Is the Phone Working? - Alternative Telephony SLA
5 SLA Nonsense Examples - Always Read the Fine Print

We received the reply from the editor of BlogTipz.

From the info, it seems that the hack on BlogTipz is merely a target of opportunity.

The hack method is probably not related to error of WordPress, but the editor of BlogTipz does not reveal the actual attack method.

At any rate, blog masters everywhere need to maintain blog security high on their list of priorities

Here is the reply in full

Yes, I was going to possibly write a post on the blog, because I was not aware of it (it could have been up for 12+ hours). They simply changed the login name and password and injected in a new index (main) page, so it was rather simple to recover (within an hour).

I will be securing WordPress even more form this day forward to prevent it form happening on other sites. I was using a current version of WordPress. The attacker was called "North-Africa Security Team" and appears to be one of the most popular hackers in terms of results (~14 million).

If you need any further information, please inform me. I will be informing readers about this soon.

And, thanks for informing your readers about this.

Talkback and comments are most welcome

Related posts
Blogtipz Hacked

Today, blogtipz.com - a good internet blogging site got hacked. The attack is a simple defacement attack, and the signed culprits are Dr.0rYX|Cr3W-Dz.

Here is a screenshot of the hacked version of the blogtipz.com site


With the little information available, the most probable attack vector is a vulnerability in the implemented version of Wordpress. We are including two screenshots of the original (google cached and after the defacement was fixed)


We have submitted the following questions to the editor of Blogtipz

1. Did you get threatened by the hacker teams that hacked the page?
2. How much time did it take for you to recover from the hack?
3. Did you discover the attack vector, and would you share it?
4. Is your Wordpress now patched against such attacks?
5. Any message on your side for the readership?

As soon as response is back, we'll post the response.

Talkback and comments are most welcome

Analyzing an incident when the manufacturer claims that it's an operator error and the operator claims that it is an application error is one of the most daunting tasks of a security officer.
And this is a type of incident that the security officer will be called upon to investigate simply because the management needs an independent observer and has doubts both in the operator as well as the manufacturer. Here is what to do when thrown into the fire

Prerequisites

1. Do not let the manufacturer's expert be the one that leads the investigation. If he insists to be involved, make it clear that this is your investigation and that he has to ask permission for and explain any action he wants done on the database and application during the investigation.
2. Know a bit of SQL or bring someone that you trust that knows SQL.
   

Tools of the trade

• Toad for Oracle and Query Analyzer
• MS SQL Server Management Studio for SQL Server
• Event viewer for Windows and
• Syslog and text log files for Unix/Linux
• Notepad, hi-res camera or screenshots for everything.
  

Incident Investigation Process

1. Gather as much information as possible - even gossip!
• Talk to the witnesses of the incident.
• Establish who else worked with the application during the incident discovery
• Document the events that lead to the discovery of the problem and their timeline
• Document any data involved in the process - account numbers, exact names, values, currencies - anything that can be found in the database. Do this for both the clean and and corrupt data
• Gather screenshots of the application of the events that lead to the discovery of the problem
2. Establish a time interval of the incident
• Choose a database backup closest to the time the incident has been identified and Request that a database restore be done and the users to verify that the restored database is in good condition.
• If the database is 'good' then the incident occurred between that backup and now.
• If the database is 'bad' repeat with an earlier backup
• Repeat until you find the closest 'good' and 'bad' backups - the incident has occurred sometime in that interval
3. If possible, try to reproduce the conditions of the incident
• Starting from the known 'good' state - a non-corrupt database ask the users to repeat their activities
• Observe/Film the user while performing the activities in the application
• Run a profiler/logger type of tool while the users are working to capture all backend activities on the database
• Follow through until the application is closed and all sessions are torn down - there can be a closing script that is a problem
4. Identify key data repositories
• Consult the documentation and captured queries if available to identify the tables that the corrupt data is kept in.
• If there is no usable source, use trial and error: The tables are usually named in a logical manner related to their purpose - so match them to the statement of events to find which tables are relevant.
• In order to confirm that the right tables are identified, find at least some of the documented data involved in the incident in these tables. Don't be disappointed if you miss at first - they MUST be somewhere!
5. Look through the audit and/or the logs of the database to identify which updates or changes were made in the database.
• This is a very problematic step - some applications and databases will not have any audit, or a small amount of audit.
• But almost all applications have a form of application trail - a table or set of tables that logs the action to be or was done, mostly because a lot of application actions are dependent on each other so they need to create a unique identifier (key) in one table to be referenced further.
6. Match the described timeline with the database logged actions as closely as possible.
• Consult the witnesses of the incident during this process - tell them that you notice certain type of event at certain time - this reminder triggers memory - they'll remember more detailed actions of their work!Add log details and timestamps at each step of the timeline
7. Discuss Observable Trail With Manufacturer and Users
• If you find a proof of a bug or human error you're in luck. Write a report and recommend corrective and preventive measures.
• Most likely, you'll find a gap in the events right where the incident occurred (interval of minutes) but the trail of events will indicate what was the next step: whether the program malfunctioned or the user made a flagrant error. Then you need to confront the manufacturer and users with the problem. Ask for a recreation of the actions with both parties present and with full logging. The log will give the actual event.
  

NOTE: Non reproducible errors are possible - If the error cannot be reproduced, then that is a report also. But then you need to increase the logging level to maximal possible level until the problem resurfaces.

Related Posts
Tutorial - Mail Header Analysis for Spoof Protection
Tutorial - Computer Forensics Process for Beginners
Tutorial - Computer Forensics Evidence Collection
The SLA Lesson: software bug blues

Talkback and comments are most welcome

Computer forensics is currently a very popular term, and a lot of conferences are organized and books written on the subject. This, together with the popularity of the CSI series, brings an aura of certain very special, even magical steps that forensics teams use. In reality, the computer forensics job is a standard process, and every one of us does parts of the process when we debug our computers. So, here is a simple tutorial on what is involved in computer forensics:

Computer forensics process


Below is a diagram of the forensics process. It is a generic process, but applies in computer forensics.

In order to properly apply the forensic process to computers, let's expand the generic diagram into the following:

As you can see, in computer forensics, a lot of evidence can be collected while the computer is running. That is a one-shot chance, and you'll never have it again when you turn off the computer.

Your Forensic Toolkit

Every trade needs it's tools. For the beginner investigator, here is my recommended toolkit:

1. Helix forensic CD - your basic tool for the investigation
2. Digital camera - capturing physical state of the suspect computer
3. Evidence USB - 4 GB Capacity - for removing smaller evidence files from the evidence computer
4. Evidence USB hard drive (500 GB will be enough for most purposes) - for making an evidence copy of the disk drive
5. Analysis computer - probably a laptop, but sparkling clean - no viruses, Trojans, cookies or similar wildlife on it, since they can corrupt the evidence. Even if the evidence isn't corrupted, it may be considered as contaminated and become inadmissible in a formal case.
6. VDK driver, for the analysis computer (if using windows) - this driver will enable you to mount a DD image created during the evidence collection
7. Antivirus/Antispyware/Rootkit detector software for the analysis computer

Steps of the forensic process process
1. Evidence collection

1.1. While the suspect computer is running

• Make an image of the RAM Memory, and store it on the evidence hard drive/USB. Make MD5/SHA1 hash of the image and save it and write it down in a notebook.
• Make an inventory of all processes, network connections, installed software, hardware, everything you can about the computer. Save this in a file on the evidence hard drive/USB. Make MD5/SHA1 hash of the file and save it and write it down in a notebook

1.2. When the suspect computer is off

• Make an image of the hard disk drive and store it on the evidence hard drive/USB. Make MD5/SHA1 hash of the image and save it and write it down in a notebook
• Photograph the suspect computer from all sides. Save the pictures on on the evidence hard drive/USB. Make MD5/SHA1 hashes of the photographs and save them and write them down in a notebook.
• If any immediate physical tampering is apparent, photograph it specifically, and possibly expand the investigation with a forensic expert who will look for evidence regarding the tampering method (fingerprints, tool markings)
• Open the computer and photograph the interior under good lighting. Save the pictures on on the evidence hard drive/USB. Make MD5/SHA1 hashes of the photographs and save them and write them down in a notebook.

2. Evidence analysis

• Load copies of the evidence images into your analysis computer. Confirm that the copies have the same MD5/SHA1 hashes as the original noted ones.
• Search the raw images of the ram memory and the disk drive for strings, and save them for future reference

All following steps need to be used in the context of the investigation, so there is no specific exact step to use

• Review the strings dump for specific keywords
• If there are specific keywords related to your investigation ('payroll', 'salary', 'password', someones user name or e-mail address), search for those strings in the raw images. Save the results for future reference.
• Mount the disk drive image as a read-only drive. Scan the drive for viruses, rootkits and spyware. Save the results as screenshot or log file
• Analyze the event log of the suspect computer for any anomalies. Log anomalies with times of occurrence
• Analyze the running processes log of the suspect computer for any suspicious processes. If found, refer back to the memory dump to investigate the process (memory content, using a hex editor and string search)
• Find pics/movies/docs/web-mail and log positions for review. Alternatively, review them immediately for specific issues
• If applicable, use steganography detection software to detect hidden data in images and music.
• Analyze browser cookies for connection to specific sites or Internet activity
• Analyse e-mail records for connection to specific sites or Internet activity
• Investigate files in slack space (deleted from the File Allocation Tables but not physically from the disk)

3. All incriminating evidence (context dependent) are to be logged with original timestamps and with appropriate presentation (screenshots, text dumps, audio recording)

This is by no means a definitive and final tutorial. Shortinfosec will follow-up with excersises and a demo dump for the readers to dissect in the comfort of their own home.

Talkback and comments are most welcome

I have been hugely busy in the past weeks with several projects, so the blogging got stuck... I Will try to avoid this in the future. Now back to my latest experience

Part of every Information Security Management System is the incident management process. It is as process in which the company identifies a problem which is occurring or has ocurred, and performs steps to contain it, minimize the impact, identify the root cause and take measures to prevent the incident from recurring.

The incident in question is a dreaded application blocking - a company of 1000 employees uses a custom made fully integrated CRM/ERP system, which exibited complete or partial non-responsiveness of several minutes for a period of nearly two hours. This situation was identified at several departments, while the rest of the company is functioning as usual.

As soon as the call came in, the incident response team was formed and the problem was analyzed. After 15 minutes, the problem was identified. Accounting has started a program which should run once a week and affects the billing information of most Key Customers. This program was started at it's usual time, with usual parameters. The problem was rectified by stopping the processing and postponing it for after business-hours

Upon further investigation of the incident it was identified that the problem has occured before, at regular intervals, but was never reported as an incident. The situation has been handled by the IT department, who communicated the problem to the software company which created the software as a bug.

When i requested a status update from IT on this bug report, i received a shocking information: The software company has closed the bug report with a status of DENIED

So I called the release manager at the software company, and i got an even bigger shock: He explained that the software company decided to deny this bug report due to overwhelming change requests and bug reports from our company. In his words, this bug was a mere nuisance since it blocked part of the software for about an hour once a week - just run it during lunch!

At this point, the incident was no longer just an incident, it became a support contract issue, so i reported the situation to management and recommended an intervention from their side.

This incident is a very good lesson in the different priorities and focus of the parties involved:

For a user of the system any problem can be a show stopper.

For the manufacturer of the system, the same problem can be played down to an importance of an itch. There can be many reasons for such a difference in opinion, but here are a few:

1. There are insufficient human resources to address the issue
2. There are profitable change requests or projects to to address, so this element is merely postponed since the software company will not see a profit from engaging their resources into correcting this problem.
3. The problem is caused by a design flaw in the system, that is either very difficult or impossible to rectify in a reasonable time and within reasonable budget

The only way to increase the value of the users' incident to the manufacturer is through applying proper controls and penalties in the support contract. That is why security incidents history and results should also be used as a very valid input into the preparation and negotiation of the SLA