Nearly two weeks ago Admiral Mike McConnell, the former U.S. Director of National Intelligence (DNI), testified about the preparedness of the U.S. in the event of a cyberware at a meeting of the U.S. Senate Commerce, Transportation and Technology Committee. He said that if the U.S. were to be attacked in a cyber war, the U.S. would lose. Admiral McConnell’s testimony created shock waves among members of this committee, who reportedly did not have a clue that the U.S. was so dismally prepared for cyberwarfare. Jim Lewis, who heads the government’s Commission on Cybersecurity, followed Admiral McConnell by saying that most of the U.S.’s critical computing infrastructure is within the commercial sector, but this sector is not doing enough to safeguard computing assets. According to Lewis, no improvements in cybersecurity practices within private industry are likely to occur unless regulations require these improvements.
I find it incredulous that members of the U.S. Senate were so naïve and uninformed about the U.S.’s current state of unpreparedness for cyberwarfare. Perhaps this is due to denial, the same kind of denial that caused U.S. government and military personnel in 1941 to dismiss the notion that Pearl Harbor was about to be attacked. Or perhaps those within the U.S. government who need to understand cyberwarfare-related risks the most are not devoting the time and effort needed to genuinely and thoroughly understand these risks, very possibly because of the need to fight other major brushfires (e.g, the economy and healthcare reform). Whatever the cause of the Senators’ ignorance, one thing is for sure—the U.S. is not very likely to achieve any advances in the information warfare arena unless those who lead our nation wake up to the problem and do something about it.
Sadly, almost immediately after his testimony was finished, Admiral McConnell fell under heavy criticism for his statements. Critics accused him of being a highly paid “fatcat” now that he has left the government and that he was in essence doing nothing more than grandstanding when he gave his Congressional testimony. How can his critics be correct when epoch incidents such as Titan Rain and Aurora, in both of which the U.S. had its proverbial cyberclock cleaned by state-sponsored cyberattackers, have occurred repeatedly and are highly likely to occur again in the future? Sadly, these attacks are likely to continue to be highly successful because of ineptitude and indifference both within the U.S. government and the U.S. private sector. Consider the following quote from:
“The attacks have also hit government and military institutions in the United States, where analysts said that the West had no effective response and that EU systems were especially vulnerable because most cyber security efforts were left to member states.” (See http://www.einnews.com/article.php?oid=bhzfsFHn34hHjQ&v=38375EnDmRv3c_YtUQQrSNBTWrjUdDQmU )

This article goes on to say that the number of cyberattacks against the U.S. Congress and other government agencies had risen dramatically to somewhere around 1.6 billion monthly, with China being one of the most prevalent sources of the attacks. According to the author of the article, the risk of unauthorized access to intelligence data has also grown to the point where the distribution of such data has been restricted substantially.
If you still don’t believe that the U.S. is poorly prepared to defend itself against and respond to cyberattacks, check out:

http://transcripts.cnn.com/TRANSCRIPTS/1002/20/se.01.html

In short, U.S. government agencies stumbled their way badly through a recent cyberattack simulation exercise, once again demonstrating the government’s lack of ability to fend against and respond to massive cyberattacks.
My main point here is that although Admiral McConnell was correct in pointing out the U.S.’s unpreparedness in the event of a cyberwar, he was also dreadfully wrong in another major way—he treated the subject of information warfare as if it were something that could happen in the future. No, Admiral, a major international cyberwar has been occurring for years. The U.S. is not likely to lose—it is losing badly now! And even if the U.S. government and the commercial sector were to wake up to this fact and start making changes accordingly, it would take many years to reverse the long established trend of one defeat after another in the information warfare arena. Still, late would be so much better than never…

Earlier this week I once again went to the RSA Conference in San Francisco. I could have gone to some of the presentations and panels, but once again I chose to not do so. Why? I have found that many times one can learn more from meeting and talking to people at this conference rather than attending sessions, and once again I found this to be mostly true.

I went to the RSA Conference last year and noted in a blog entry shortly afterwards that attendance had dropped considerably from 2008. An unfortunate outcome was my having to deal with the conference’s PR firm, which objected to my mentioning the then downward turn in attendance. Good news—this firm should have no objection whatsoever to my saying without any reservation that the attendance for RSA 2010 was dramatically higher than last year. My main metric, good or bad as it might be, is how easy it is to get from point A to point B within the Moscone Convention Center. This year I had to constantly dodge people in the main upstairs areas and down below in the exposition hall. Seating areas were crowded. There is no doubt that attendance was at least back to its 2008 levels, or very possibly even higher.

Some of the most valuable time I spent at this conference was the time I spent with a very seasoned information security professional who works for the U.S. government. He was the first to inform me several years ago about the major shift in attack strategies from targeting servers to attacks targeting browsers on small systems running Office, Adobe Acrobat Reader, Adobe Flash Player, and other widely used applications. He had previously told me how spear phishing went hand-in-hand with such attacks, but a few days ago he told me that the most recent round of attacks also exploits social networks. If an attack against a particular person who works for a U.S. government agency or another organization succeeds, the attackers will next attempt to determine with whom the victim frequently sends email and IM, and also to whom that person is connected on social networking sites. The goal is to determine the next round of targets. Once the attackers have successfully attacked the computers of individuals within the original victim’s circle of contacts, the attackers can obtain a wider range of information related to subjects of interest so that this information can be aggregated for intelligence purposes. My friend concluded that the Internet is used for a very broad range of purposes, one of the main ones of which is social purposes. The fact that social purposes mix with other, more sensitive purposes such as on-the-job communications with others creates major vulnerabilities for perpetrators to exploit.

I also had lunch with a person who had attended a conference session that I now very much wish that I had attended. This session covered the processes involved in planning and preparing for perpetrating identity theft. Pictures that this person had taken with her iPhone told much of the story. One picture showed a device that made phony credit cards. Another showed the products—a container full of bogus credit cards.  Still another showed an “ID theft store” for use by identity thieves.  One showed a storyboard with the picture of the targeted victim and information needed to carry out the identity theft attempt. A final one showed a display showing information being used in an identity theft attempt. Seeing these pictures nearly sent chills down my spine. Think of the value this information and these pictures would have in information security awareness efforts!

By all appearances RSA 2010 appeared to be a huge success. If I didn’t see you there this time, I’ll hopefully see you there next year!

In a SANS NewsBites editorial a little over a week ago I lamented the fact that to date software companies have for the most part not been held responsible in legal cases for damages resulting from bugs in their code. I described this situation as “the single greatest enabler of bug-infested coding on the part of vendors.” A mentor and also friend of mine, the legendary Bill Murray, sent me a message with a plethora of excellent comments concerning the issue of liability related to software bugs. His commentary on this issue is so outstanding that I decided to (with his advance consent) publish it as a blog posting. Here goes:
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -
Murray’s first rule of computer security is “Be careful what you ask for….” Couple the current computing environment with “strict liability” and many, not to say most, software vendors would be a coin toss or a jury decision from bankruptcy. We want to be sure that in getting to where we want to go, we do not break something that we did not create and cannot repair, destroy something we cannot replace.

Key in your statement is “due to.” Rarely do damages have a single demonstrable cause. Moreover, most of the code errors do not result in damages. On the other hand, juries love to find someone with deep pockets to blame.
That said, having spent my early years developing in an environment where the computing environment was hidden from end users by purpose-built applications, I have always been skeptical of highly generalized and flexible environments with gratuitous features and functions. While these have created market numbers upon which developers could make money, they have also contributed to products whose use the developer could not make predictive statements and could not make statements about safe use, much less warranties.

To the best of my knowledge, the MVS Integrity Statement (user cannot increase his privileges) is the most successful software warranty ever. Of course, if the remedy had not been limited to fixing the code, IBM would never have offered it. Somewhere between the present remedy and liability for “consequential damages,” I think that IBM could have crafted a remedy stronger than the promise to fix the code.

One can contrast Word, Acrobat, Excel, sendmail, and Apache running on Windows and Unix, to 140K purpose built applications running on the iPhone. (Note that it takes a very large number of iPhones for developers to make money on applications with limited function and appeal.) The more specific the application, the easier it would be to define safe use and warrant the program. While not getting to strict liability, one might get to merchantability. Moreover, by providing a very limited UI, even Apple might be able to make warrantable statements about the iPhone operating system. For example, Apple might be able to say that process-to-process isolation is such that programs could not interfere with one another and data cannot leak from one program to another. One might even find enough competitive advantage over competitors, think Windows Mobile or RIMM, to encourage Apple to offer such a warranty.

My friend and colleague Donn Parker, security consultant and researcher par excellence, gives an RSA session entitled “Alternatives to Security Risk Management” (RSA P2P 204A Weds at 1pm Burgundy 222) in which he attempts once more to debunk the myth that “risk can be managed” in information security.  Donn has been on the forefront of thinking about information security since the 1970s and he is used to being ignored by all types of people who either don’t get it or haven’t figured out a way to exploit an idea for profit yet.  Sometimes his rants can seem quixotic but almost always look prescient after-the-fact.  Here is an example.  Donn is not saying that “risk doesn’t matter” (although read below for more on this notion), but he is saying that the idea that an organization can use quantitative techniques analyzing detailed risk profiles around data and controls to make decisions about information security is pure bunkum.  I agree…mostly.

Controls can be managed.  And we should continuously develop our ability to manage controls so that – at minimum – we keep pace with the rapidly changing threat landscape and the less-rapidly evolving state of controls and best practices.  On this Donn and I agree.  However, I believe that CISOs and organizations should be able to address a big risk (that is: (threat*likelihood of attack-success)*impact)) before they address a small risk which implies a crude quantitative analysis.  You could define “risk management” as “managing the controllable portion of risk facing the organization” and be done with the controversy.  Unfortunately, CEOs and CFOs will expect the implied definition — that when you implement your brand new control, overall risk to the organization will have been reduced by the amount you promised.  Donn’s point is that is folly and potentially career limiting if something bad does indeed happen anyway.

But hold on a moment.  Maybe it’s not career limiting after all to maintain a façade of risk management.  Take a look at two recent exhibits for the prosecution: (1) the housing-credit-crisis and the resultant recession, and (2) the TJX data breach.  I really want to write about (1) but I’m throwing in (2) for those of you who might say, “Well, that was a special case – an outlier and not something we should use to guide us.”  The housing-credit crisis was the direct result of a willful failure of risk management.  Executives at a small number of very large and powerful financial institutions, aided by regulators who were predictably transfixed by the beauty of their own financial models, took huge and – in hindsight anyway – unjustifiable risks in order to score big playing the financial markets.  OK, what they did was bad, right?  But look who lost their jobs.  Thousands of employees at Bear, Lehman, WAMU and Wachovia (and others).  But how many of the executives that actually made the bad bets?  Not many.  FNMA said house prices would decline by at most 5%.  Goldman’s WOW (“worst of the worst” cases) model said 30%.  The rating agencies, who hawked AAA ratings like papal indulgences in the fifteenth century, said 15% to 20%.  There you have “risk management” at its finest.  Smart economists have told us that you cannot spot a market bubble until after it has burst and unfortunately most investors tend to get in right before the bubble collapses.

Take a look at TJX, if you think the current recession is an outlier.  The accompanying chart shows that the March 28, 2007 announcement of a massive data breach at TJX had little or no discernible effect on the stock price of the company.  TJX recently announced record profits and – just a year after hundreds of billions of bailouts were doled out — Wall Street bonuses were up 17% over 2008.  Conclusion: there is no longer a penalty for taking untoward risk.

So what is the purpose of information security risk management?  Go to Donn Parker’s RSA session and find out for sure.  But my guess is it is – at best — a very fancy fig leaf.

This is the last of a seven-part series on smartphone forensics. The topic is what do with the information that has been copied from smartphones and other mobile devices such as iPods. We’ll assume that the forensics data have been copied to a special handheld device for mobile device forensics (such as one that Guidance Software makes), a PC (ideally one on which a forensics tool is running), or a secure USB drive. (The best forensics procedure is actually to make two copies, one a best evidence copy to be stored in a forensics vault, and the other a working copy for forensics analysis.) One of the risks in making forensics dumps is the possibility that information obtained in this manner might be altered on the computer or device to which it has been copied. The copied data must thus be accessible in read-only mode so that nothing can be changed. Additionally, a hash value (preferably using one of the SHA family of hash algorithms) of the data should be computed and, if possible, compared to the hash value of the data on the original device. Forensics tools make performing all these procedures much easier and more error proof, but experienced forensics investigators can do just about anything without such tools if necessary. For example, it is possible to set a Registry value in Windows XP to prevent the ability to write. To prevent ability to write to the USB drive, use regedt32 or another Registry editor to go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies

Insert the following value:

“WriteProtect”=dword:00000001

The next steps are to determine what kind of information has been collected, document that it has been collected, and to identify evidence that is relevant to the case at hand. Again, forensics tools can help considerably, but you can instead use built-in commands such as grep, egrep and fgrep in connection with pipes as well as tools such as Splunk to locate specific words, word combinations, files with certain extensions, and so on. In conventional computing systems perpetrators hide information in a variety of ways—using slack space, marking sectors in which certain information is written as bad, using steganography, and more. To the best of my knowledge, perpetrators are not currently using these information hiding methods in smartphones, although they could hide information in Word and HTML documents if they desired.

Some of the data stored on a smartphone is likely to have been deleted. You may nevertheless be able to recover these data. The trick is using the restore function, which is built into many smartphones. This function will bring back deleted data if they have been backed up.

Some of the types of information on smartphones that may prove of interest to an investigation include:

• Call history—to discover with whom the smartphone owner has talked, when, how long, and so on
• Contacts in the address book
• Information stored in files
• email, IM and SMS message content
• Camera and multimedia images
• Calendar information
• Music (and in some investigations, especially music that might be illegally copied.

It should once again be evident that although many similarities in the processes and procedures for forensics investigations in conventional computing systems and in mobile devices exist, many critical differences also exist. For reasons stated in the first blog entry in this series, the need for forensics in mobile computing devices is going to grow dramatically over time. It is thus imperative that information security professionals learn all they can about this area and prepare well in advance for the inevitable onslaught of cases in which forensics investigations involving these devices is required. At a minimum, you need to create and test mobile device-specific forensics procedures and acquire the necessary hardware and software well in advance of situations in which they will have to be used.

The first posting in this series provided an introduction to smartphone forensics. Parts two, three, four and five covered forensics in iPhones, BlackBerrys, Motorola smartphones, and iPods, respectively. So far we’ve gone over how to use forensics procedures to capture data from each type of cell phone as well as some of the challenges involved, but we haven’t really gone farther in the forensics process. This sixth posting in this series covers some of the other extremely important procedural considerations, These include how to gain access to data on smartphones, ensuring that all relevant data are captured, protecting the integrity of data, dealing with differences in operating systems and file systems, and being careful to avoid errors that can easily invalidate a forensics investigation.

• Gaining access to data on smartphones. Some smartphones do not require authentication—they allow access to the phone and its contents without any security whatsoever. In contrast, some require entry of a password or PIN. In this latter case, the forensics investigator must guess the password or PIN, somehow find it, ask the owner of the smartphone for it, or exploit a vulnerability that enables the investigator to bypass authentication altogether. Guessing a password or PIN is likely to be easier with smartphones than conventional computers because smartphone passwords and PINs are likely to be shorter in length than passwords and PINs for conventional systems. Why? Many smartphones do not have password policies that require, among other things, a minimum password length. Remember, too, that some smartphones have default passwords that users almost never bother to change. Consider also that a smartphone may be seized while it is being used, something that precludes having to know or guess the password or PIN to gain access to the data stored therein.

• Ensuring that all relevant data are captured. Smartphones almost without exception have less RAM than do conventional computing devices. If users want to increase the RAM, they often add memory devices such as MMC (Multi Media Card) and SD (Secure Digital Memory Card) cards. Be sure, therefore, to inspect the device you are forensically investigating for the presence of extra memory devices, and if they exist, to dump the data from them, too. It is easy to overlook these sources of potentially very important data in a forensics investigation with smartphones. Additionally, as mentioned in a previous posting in this series, you have the option of capturing only certain regions of memory or partitions on hard drives. All things considered, it is better to err on the side of capturing too much, even though some types of data may not seem pertinent to an investigation.

• Protecting data integrity. Some smartphones have hard drives; others do not. In smartphones that do not have hard drives, e.g., Windows smartphones, data are stored in volatile memory. If these phones are powered off, data in volatile memory are very likely to be lost. Data lost in this manner may or may not be recoverable. Complicating things is the fact that in many smartphones forensics data capture is not possible if the phones are turned off. And even if a smartphone is ostensibly in the off state, it in reality is probably not completely off. In most major types of smartphones, background processes that can change data run continuously even though users have turned the phones off. Worse yet, it is easy to start the forensics data capture process without realizing that a smartphone may still have an active wireless connection through which someone could still obtain remote access to change or erase data. Additionally, the presence of malware on a smartphone can change data integrity. Furthermore, hardware keys can be maliciously altered to start functions that modify or delete data. In sum, there are many ways that data on smartphones may be changed from the time that a smartphone comes into your possession to the time that your forensics dump is finished—think of the negative implications for court cases. About the best thing you can do is to ensure that the device you are forensically analyzing is disconnected from all wireless networks. Then record the state (on or off) of the device when you begin forensically investigating the device and use MD5 and/or SHA1 to compute a hash value for the phone’s data at that point in time. When you are finished, again record the state of the phone and compute another hash value using the same hashing algorithm. Any changes between the two points in time spell trouble in the forensics process.

• Dealing with differences in operating systems and file systems. The range of operating systems in today’s generation of smartphones is surprisingly large. Different versions of each operating system also typically exist. Forensics tools that work in connection with one operating system and version may not work in connection with others, often necessitating buying a number of different forensics tools. The existence of different file systems on smartphones presents yet another complication. Dumping data from a smartphone’s file system to another file system (e.g., the NTFS-5 file system on Windows computers) is extremely likely to result in loss or modification of some of the data on the original file system.

• Avoiding major errors. It is incredibly easy to make a mistake that results in loss or modification of forensics data. Resetting the device accidentally while conducting an investigation is one of the most common errors—one that typically results in loss of data. A hard reset will delete the contents of RAM. If a battery runs out during an investigation, a hard reset will occur, so it is wise to ensure that there is a continuous source of electrical power independently of the battery during a forensics investigation with smartphones. Finally, an accidental or intentional soft reset should also be avoided because it reinitializes dynamic memory; to-be-deleted data are deleted if this happens.

It should once again be evident that although some similarities in the processes and procedures for forensics investigations in conventional computing systems and in mobile devices exist, many critical differences exist. Also, although mistakes can occur at any point in any forensics investigation, mistakes in smartphone forensics investigations can be particularly detrimental, and must thus be avoided at all costs. Learning about the special “care and feeding” that is required in forensics investigations with smartphones and incorporating them into special forensics procedures (at a minimum, one for each type of smartphone) is imperative if forensics investigations involving smartphones are to be performed properly.

So far this series has covered forensics for the iPhone, Blackberry, and Motorola smartphones. I was just about ready to wrap-up this series when I suddenly realized that iPods and similar devices are now also increasingly the focus of forensics investigations. Accordingly, this posting covers forensics for iPods.

One of the most important initial considerations regarding forensics investigations with iPods is that these devices are often physically connected to computers. Whenever so, the iPod becomes a mounted device on the computer. You can determine whether or not an iPod is mounted on another computer by looking at the iPod’s screen. If “Do Not Disconnect” is displayed, the iPod is mounted, and it thus has to be unmounted before it is physically disconnected from the computer. To do this on Macintosh computers, drag the iPod icon to the trash bin on the Mac desktop. To do this on Windows computers, click the “Unplug or eject hardware” icon that is displayed in the task bar in the lower right hand part of the display. If the iPod is not unmounted before being physically disconnected from a computer, the iPod’s hard drive can be damaged.

Before an investigator starts umounting the iPod being analyzed, it is important to record the name of the iPod, which should appear on the desktop of the computer system on which the iPod is mounted. Knowing this name will guide the investigator to the choice of the right tool(s) to use when the forensics dump and subsequent forensics analysis are being done.

Another thing that a forensics investigator must do when dealing with an iPod is to find out if the device is formatted for the Macintosh file system (HFS+) or the Windows file system (NTFS-5). On the iPod go to Settings -> About > and then scroll down to Format: Windows. Now look at the bottom of the display. If the iPod is formatted for Windows, a short message to that effect will be displayed. If there is no such message, the iPod is almost certainly HFS+ formatted.

One thing that is nice about working with iPods in forensics investigations is that it does not matter whether the iPod is off or on. Regardless of the state of the iPod, you will be able to make a forensics dump of the data, although turning this device off minimizes the likelihood of data being modified during the data transfer process. You will have several options in making this dump:

• You can turn the iPod off and take the iPod apart, detaching the hard drive for the purpose of analysis. Forensics purists will almost certainly prefer this option, because all things considered, connecting to a detached hard drive is least likely to result in data modification and/or incomplete data capture. You can now physically connect the iPod to the machine on which a forensics tool has been installed and then use the tool to do a data dump. Alternatively, you can use the dd command on a Unix or Linux system or a Windows system on which cygwin has been installed.

• You can leave the iPod physically attached to the computer that has mounted the iPod. You can then run a forensics tool or use the dd command to dump the iPod’s data to that computer.

• You can physically connect the computer to which the iPod is physically attached to another computer to dump the iPod’s data to the other computer. Access to the data is this case is through the mounted volume on the computer to which the iPod is attached. Alternatively, you can set up an ssh or other secure remote connection between the computer to which the iPod is attached and the other computer.

Finally, iPods have a Restore function that Apple claims overwrites old data when this function is run. A paper, “iPod Forensics” by Christopher Marsico and Marcus Rogers in the fall 2005 issue of the International Journal of Digital Evidence, reports empirical tests that show Apple’s claim to be incorrect. Marsico and Rogers were able to forensically recover iPod data that were supposedly erased as the result of a Restore. Assuming that Marsico and Rogers are correct (and they very much appear to be), forensics investigators thus need to be aware that potential ways of recovering iPod data that appear to be deleted exist.

In many ways, forensics analysis for iPods is simpler than with other mobile devices. This news should come as welcome relief, especially if you have read my previous postings in this series.

Although both iPhones and BlackBerrys command a disproportionate share of the smartphone market, many smartphone users have other types of smartphones that may also need to be forensically analyzed. Motorola phones are good examples. Motorola has manufactured a wide variety of smartphones that are similar in look and feel, but that may also differ from each other in a number of ways. Suppose that law enforcement suspects that evidence concerning a crime that has been committed exists on a Motorola p2k or p2k05 phone. On most of these phones it is first necessary to go to the Menu and then to the Flash&Backup function to start the processes of obtaining a copy of information stored on this device. A menu consisting of six backup selections will appear. These functions include:

• CG1 (Firmware)
• CG2 (Flex)
• CG3 (Langpack)
• CG15 (DRM graphics)
• CG18 (Digital signature)

CG1 contains the operating system, which is coded into firmware. CG2 is the memory region that contains both user data and applications; it thus is the most important portion of the phone’s memory to back up. CG3 contains firmware for digital signal processing that supports phone conversations. CG4 contains fonts used in the smartphone’s displays. CG15 contains graphics, such as the graphics for the various icons that are displayed on this smartphone. CG18 contains a unique digital signature for the phone that is being analyzed.

Of all the memory regions, CG2 is the most important in forensics investigations because user files potentially containing data of interest to investigations reside here. CG18 is likely to also be important in some forensics investigations because the digital signature in this region of memory provides a conclusive link between the phone itself and its memory contents. The contents of the other memory regions are in contrast seldom of interest in forensics investigations because although different memory regions contain particular types of information, there is likely to be no difference in content of one memory region (e.g., the DRM graphics region) on one phone to the same region on another. Still, it might be desirable to back up each of the ‘’less important’’ memory regions so that a forensics investigator can assert that the data capture process was exhaustive—that it included all memory regions. This could conceivably be important in a court case or investigation.

If you click on ‘’Select All,’’ all memory regions will be dumped. Once the desired memory region(s) have been selected, uncheck ‘’Cut empty bytes at the end of code groups;’’ otherwise, you will not obtain all the information from each memory region. Next select either SBF (for ‘’single binary file’’) or SMG (for multiple binary files). If you choose the former, all memory region data will be dumped to a single file. If you choose the latter, the contents of each memory region will be dumped to a separate, dedicated file. If you are dumping all the memory regions, choose SMG to know exactly what is dumped where; each output file will contain a particular region of memory. The alternative is writing all data to a single file. But if you are backing up only a single portion of memory e.g., the Flex region), having a single file for the output is appropriate. Finally, click on “Read Data.”

Download and install the USB driver from:

http://direct.motorola.com/hellomoto/nss/driversNplugins.asp

Next download and install a copy of P2k Commander, a file manager application for Motorola p2k phones, on the PC to which the data will be transferred. Visit:

http://handheld.softpedia.com/progDownload/P2kCommander-Download-38120.html

Physically connect the PC on which P2k Commander has been installed to the phone. Start P2k Commander on the PC and then launch HyperTerminal there by going Start -> All Programs -> Accessories -> Communications -> HyperTerminal. Next select COM3 in the ‘’Connect To’’ dialog box. Select the following settings in the ‘’COM3 Properties’’ dialog box that will appear:

Bits per second: 115200
Data bits: 8
Parity: None
Stop bits: 4
Flow control: Hardware

Now put the phone in P2k mode by entering the following AT command in the command input area that will appear:

AT+MODE=8

Data transfer will now begin.

Once more it should be apparent that making smartphone forensics dumps using procedures such as the ones described in this paper is not exactly the easiest thing in the world to do. Fortunately, commercial tools generally make the whole process somewhat easier, but there is plenty of room for mistakes even with the best of tools. The bottom line is that forensics in smartphones is not something to be taken lightly. If you are going to enter this arena, you need to make every effort to get up to speed quickly.

In part two of this series I discussed some of the difficulties involved with conducting forensics investigations on iPhones. Are these investigations easier when mobile devices other than iPhones are the targets of investigation? The answer is that it depends.

Let’s begin with BlackBerry forensics. A simple way to conduct a forensics investigation on a BlackBerry is to use the BlackBerry Desktop Manager to make a backup of the databases on this device. To do this, click on the Backup/Restore icon. The Backup/Restore dialog box will appear. Click on Backup (for a full backup) or Advanced (for special backup options). The backup file will by default be named:

Backup-(current date,time and year)-.ipd

All backup files are by default created in the BlackBerry’s My Documents folder for the current user, but you can easily change the default to any folder owned by any user by clicking the Options button in the Backup/Restore dialog box. Each file produced by the backup process has the following format:

<Line feed> – 1 byte – value 0A
<Version> – 1 byte – value 02
<Number of databases in file> – 2 bytes
<Database name separator> – 1 byte
<Database name block#1>
<Database name block#2>
<Database name block#n>
<Database data block#1>
<Database data block#2>
<Database data block#n>

Note that information such as the number of databases contained in the backup file and the name of each database precedes the data blocks. Each data block has the following format:

<Database ID>2 bytes
<Record length>4 bytes
<Database version>1 byte
<DatabaseRecordHandle>2 bytes
<Record unique ID>4 bytes
<Field length #1>2 bytes
<Field type #1>1 byte
<Field data #1>As long as the field length
<Field length #m>2 bytes
<Field type #m>1 byte
<Field data #m>As long as the field length

The field data content is formatted in a manner that resembles the format of the data a tool such as TcpDump that sniffs network data dumps. Three columns of data are displayed:

1. The first column displays the offset from byte 0 in hexadecimal numbers starting with zero and incrementing by 10 for each displace row. The first column in the first row thus has an entry of 0, the first column in the second row has an entry of 10, the first column in the third row has an entry of 20, and so on.
2. The second column displays hexadecimal data nibble-by-nibble, with each nibble separated from the neighboring ones by a space. Exactly 10 bytes of data are displayed in each row.
3. The third column displays the data in ASCII, again 10 bytes per row. Here you can readily read and analyze the content of each database.

The following is an example of how field data are displayed:

0 | 49 6E 74 65 72 40 63 74 69 76 65 20 50 61 67 65 | Inter@ctive Page
10 | 72 20 42 61 63 6B 75 70 2F 52 65 73 74 6F 72 65 | r Backup/Restore

Curiously, “Inter@ctive Pager Backup/Restore” is always the first part of every field data dump.

Once you have completed the procedures described up to this point, you’ll want to transfer the backed up data to another device such as a PC. One way to do this is to use a free Research in Motion (RIM) tool called the “Simulator.” You can download this tool by going to the following URL:

https://www.blackberry.com/Downloads/entry.do?code=060AD92489947D410D897474079C1477

Unfortunately, different versions of the Simulator are available for different versions of BlackBerry devices. You’ll thus need to find and download the Simulator that is appropriate for the particular BlackBerry device that is targeted in your forensics investigation. Install and run the Simulator and then click on the Backup/Restore icon. After ensuring that the USB cable connects the BlackBerry and the device to which the forensics dump is to be written, click the Restore option for the ipd file you want to transfer.

The major limitation of using BlackBerry’s built-in backup program is that it produces a file-by-file, not a bit-by-bit backup. For some purposes this type of backup might be acceptable, but widely accepted forensics procedures dictate that a bit-by-bit backup be made. To obtain this type of backup, you’ll need to use a third-party forensics tool that works on BlackBerrys.

One major advantage of the BlackBerry in forensics investigations is that you don’t have to do anything like “jailbreaking” (discussed in my previous blog entry) to run a forensics tool on BlackBerry devices. Still, conducting forensics investigations on these devices involves more procedural steps than might meet the eye and thus is just about as difficult as conducting such investigations on iPhones. The bottom line is that there are no instant and easy solutions for forensics on smartphones.

The iPhone is widely used today. Numerous survey results not surprisingly indicate that the IPhone has now grown to 50 percent of the smartphone market. Market leading technology spawns supporting technology, and the iPhone is no exception. While doing research for writing this blog entry I found that over ten forensics tools for the iPhone exist. However, despite the availability of numerous iPhone forensics tools (some of which are free), I cannot honestly say which one I would use if I had to perform a forensics analysis of an iPhone at this minute, because all of these tools have at least some significant limitations.

The essence of conducting forensics investigations in computing systems is making bit-by-bit copies of original data without changing anything in the to-be-analyzed system, including any data that reside on the hard drive and in memory. In conventional computing systems, the technology and procedures for accomplishing these goals are well-established; the same is not true for iPhones or any other type of smartphones, however. In conventional systems (but not smartphones) hard drives can easily be physically detached from the rest of the computer hardware, helping ensure that other parts of a system such as memory are not changed. The only exceptions in iPhones and other smartphones is removable SIM cards and memory cards. Furthermore, in conventional systems it is usually possible to boot into a special read-only mode that allows forensics analysis to occur without the risk of changing anything. But because iPhones and other smartphones do not have complete operating systems, they almost always lack this ability. Additionally, integrity checking through obtaining and comparing hash values before and after copying data for forensics purposes is another major hurdle in iPhones and smartphones, but not in conventional computing systems. Again, the lack of a complete operating system in these phones is the problem.

Another very significant obstacle to forensics analysis applies only to iPhones, not other types of smartphones. To install some applications on an iPhone it is necessary to “jailbreak” the phone. When an iPhone is installed, it stays in a “factory state” that is intended to be changed only as the result of Apple upgrades. Jailbreaking means overwriting the phone’s firmware to install application bundles and/or unlock baseband firmware that keeps the iPhone from doing things such as connecting to another service provider’s 3G network. Jailbreaking may not sound like such a big deal, but it is in at least three respects, namely that it:

1. Voids the iPhone service warranty.
2. Produces numerous changes in the iPhone that may cause the best of iPhone forensics efforts to be thrown out in a court of law.
3. Can expose the iPhone to a wider range of attacks.

Andrew Hoog wrote a very nice white paper (see viaforensics.com/wpinstall/wp-content/…/03/iPhone-Forensics-2009.pdf) in which he as objectively as possible compared major iPhone forensics tools on a number of differentially weighted criteria, including:

1. Installation (which covered the installation, activation and update process)
2. Data acquisition
3. Reporting
4. Accuracy and completeness of data that were obtained. Data include call logs, SMS messages, contacts, email messages, calendar information, notes, pictures, songs, Web history, bookmarks, cookies, applications, Google maps, voicemail, passwords, configuration files, phone information, video, podcasts, details, VPN configuration, Bluetooth information, GPS information, file hashes, HTML files, and Office documents.

Perhaps not surprisingly, no tool obtained anywhere near a perfect score. What I found eye opening, however, was the types of data that iPhone forensics tools failed to capture—in some cases, forensics tools missed five or more types of data. It is thus difficult to think that forensics investigations using most of these tools would be very complete.

The tool that scored the highest was not a single tool, but was instead a method called the “Zdziarski method,” one that utilizes several tools and methods, as follows:

1. Use the Pwnage Tool to build a custom firmware package that must be modified later and to pave the way for the boot ROM to accept special unsigned images.
2. Use the xpwntool to build a Stage 1 custom firmware package to update the NOR (kernel cache) while not erasing any live user data.
3. Use the xpwntool to build a Stage 2 custom firmware package to install a special forensic recovery toolkit that creates a forensics image using the dd command and computes an MD5 hash value for the contents of the user partition.
4. Run iTunes and install the Stage 1 firmware package, then the Stage 2 firmware package by putting the iPhone in DFU (Device Firmware Update) mode.

Some of the many advantages of using the Zdziarski method include:

1. This method creates a bit-by-bit copy of the content of the user partition.
2. Data integrity can be verified through computing MD5 hashes.
3. No “jailbreaking” or any other similar method that can compromise the integrity of the iPhone itself with the exception of a few changes in the system partition is used. The data in the user partition, which are of major interest in most forensics investigations, are unchanged.
4. All of the types of data (call logs, SMS messages, and so on) used as criteria in Hoog’s comparison of the different forensics tools is captured.

Is the Zdziarski method too good to be true? The answer, unfortunately, is no. The major downside associated with this method is that it is very difficult to use, and even the most technically knowledgeable person can easily make a tiny mistake that forces him/her to become stuck or to start over.

The good news is that iPhone forensics tools are just in their infancy. The iPhone itself is, after all, not all that old. These tools will become better and better in time. Until this happens, it is imperative to do what Hoog did by testing available tools to determine which is most suitable from the standpoint of both forensics proficiency and usability.

If you look a little ways back in the archive of Emagined blogs, you’ll see a three part series that I wrote on mobile computing security several years ago when I was still at High Tower Software. In that series I enumerated and described some of the major security risks involved in mobile computing and predicted that these risks will only become bigger over time. And then more recently I wrote about vulnerabilities in the iPhone, something that I really badly want to purchase for myself, but something about which I am also too nervous (because of all the vulnerabilities in this product) to motivate me to do so.

Given the plethora of risks associated with smartphones, paying attention to and fixing smartphone vulnerabilities is imperative. There is also another side of smartphones, however. It involves some of the methods and techniques that information security professionals often use—forensics methods. Forensics in smartphones has been mostly overlooked in the past, but the almost ubiquitous use of smartphones nowadays has brought this area to the forefront of interest both within and outside of the law enforcement community. Smartphones are now routinely used in the commission of crimes, for example, such as when a drug dealer uses a smartphone to call another to confirm a drug dropoff time and location. Although phone call logs are available from telecom providers, information on individual cell phones themselves is not—thus the need for forensics analysis of smartphones.

Methodology for conducting forensics investigations with conventional computing systems such as PCs is widely agreed upon and used in real-life settings. Forensics investigators record information about the setting in which evidence is being gathered, make image copies of hard drives, label, attest, seal, and hand over to an evidence custodian any evidence that has been gathered, and (usually) use a forensics tool to methodically analyze working copies of hard drives and other evidence (e.g., physical evidence). Hardware tools that quickly image hard drives are widely available. If such tools are not available, a forensics investigator can always use forensics software to duplicate the information on hard drives, even though doing so is much slower. And just about every forensics investigator understands where system binaries and configuration files are located on a conventional computing system as well as where and how perpetrators hide information on the hard drives of these systems, e.g., using slack space to hide pornographic pictures.

The same is not true of smartphones, however. As I have previously said, smartphones have operating systems that more closely resemble “normal” operating systems in mainstream computing systems with every new generation of these products. So, for example, the iPhone’s operating system has become increasingly (but not completely) identical to the Macintosh operating system, DarwinOS. But the hard drive of an iPhone is quite different from a Macintosh hard drive. The first part of the former consists of a 300 MB read-only partition. The second part, the user data partition, is the rest of the storage space—the part of the hard drive in which pictures, email, and other files are stored. Conventional forensics tools do not in general interface with smartphone hard drives, something that usually necessitates buying special software that is often available from vendors who make forensics tools for conventional computing systems. Additionally, making a physical connection between a smartphone and a computer running specialized forensics software requires obtaining a specialized cable, e.g., one that provides an interface between physical ports on the smartphone and a conventional computing system.

In the next of this series of postings we’ll look at forensics for iPhones. Then afterwards we’ll look at forensics for BlackBerry devices and other types of smartphones. Stay tuned.

About two months ago I purchased a laptop running Windows 7 Home Premium. Like so many others, I never bought Windows Vista, and my only experience with Vista was in trying to help Vista users who had a question or experienced a problem that they could not solve. I never liked Vista. As I look back on my experiences with the operating system, I think that the combination of the 3D desktop, performance problems, and dialog boxes popping up everywhere and just about all the time pretty much precluded my chances of feeling favorable towards this operating system. Ads that portrayed Windows 7 as much more user friendly and favorable reports from early Windows 7 users convinced me that I needed to try this operating system.

I’ve owned my Windows 7 laptop for a little over two months now. In general, I like this operating system (although I very much miss some of the features of my Mac, so much that I sometimes go back to using it, especially for multi-media functions). I’m glad that the 3D desktop has disappeared, and the I cannot for one second complain about the performance, which certainly is due in large part to my running the 64-bit version of this operating system. I also like the fact that I by default login as an unprivileged user, something that greatly reduces risks such as visiting malicious Web sites or opening email messages that contain a malicious attachment. As in Vista, the Windows User Access Control (UAC) feature pops up a dialog box whenever I am about to engage in a potentially risky action from a system stability and/or security standpoint. I must admit that after being annoyed by having been presented with hundreds of such dialog boxes, I have tuned them out. I now barely skim the text within each such dialog box before clicking “Yes,” but I now think I would rather have UAC than to not have it.

Windows 7 also has some more annoying features. Until my boss showed me a setting to change the default cursor/pointer behavior, I found that the pointer sometimes ended up in strange places, normally in an extreme corner of the screen, when I had no intention of making it move in such a manner. Additionally, windows used to re-size themselves seemingly out of nowhere and the Windows 7 “snap” feature in which two windows on a display suddenly butt up to each other, each taking half of the screen, is something that some users may appreciate, but I am not one of those users. I like the way the cursor/pointer and window sizing worked in Windows XP and other previous versions of this operating system—why change something that has worked so well?

Already a number of vulnerabilities in Windows 7 have been identified. One of the most serious is a vulnerability in the Server Message Block (SMB), the protocol used for file and printer sharing, which if exploited can cause denial of service. This vulnerability also exists in Windows Server 2008. Another is in UAC, which works just fine with applications that involve interaction with users, but not when a third-party application invokes code by proxy via a built-in Windows application. In this case UAC does not prompt users concerning whether or not they want to continue when something potentially risky (e.g., when invoked code may be malicious) is about to happen. Worse yet, any malware that is invoked runs with full Administrator privileges.

One of the most troublesome vulnerabilities in Windows 7, however, is in connection with the Virtual DOS Machine (VDM), something that was first built into Windows NT when it was first released in 1993 so that 16-bit applications could run in 32-bit computing environments on 386 and higher architectures. The problem is with BIOS calls in the Virtual-8086 mode monitor code. An unprivileged malicious user running a 16-bit application on the VDM can issue calls that escalate privileges and ultimately gain complete control of the system. This flaw exists in all Microsoft operating systems with a VDM, meaning that this vulnerability has existed in Microsoft operating systems for a long time.
Microsoft has not yet released a patch for this serious vulnerability, but several workarounds can be used. One possible workaround is for someone with Administrative privileges on Windows 2003 and up to modify a Group Policy setting that prevents 16-bit applications from running. One has to invoke the Group Policy Editor, then go to Computer Configuration -> Administrative Templates -> Windows Components -> Application Compatibility and set this option to “True.” This will prevent any access to the VDM.
No operating system is perfectly safe from a security point of view. I’ll take Windows 7 security over Windows NT or Windows 2000 security any day. And it is nice that Windows 7 is more user friendly than Windows Vista. But the presence of legacy vulnerabilities in this newest release of the Windows operating system genuinely troubles me. It is well time for Microsoft to take a cue from OpenBSD, in which new code is written to replace patched code in each subsequent release of this operating system. Copying this practice will not solve all the legacy vulnerability problems in Windows operating systems, but it would at least be a good start.