Archive for the ‘Investigative Techniques’ Category

A forensic look at the installed IDrive backup service files

Thursday, August 16th, 2012

I didn’t intend on dissecting files when I started looking at IDrive. My intent was to look at its operation and determine a method of file acquisition as a “Cloud” service. That is still an ongoing project. What I found though is a little disturbing from a user point of view, and fantastic from a forensic point of view. I originally wrote this last year and never got it posted.  When I originally looked at IDrive I found some interesting information. I thought after a year they would have changed their methods of obscuring their client information on the local machine. Alas, no….Here is what I found.

IDrive Background

From their corporate information page IDrive identifies them as a “service” of Pro Softnet Corporation based in Calabasas, California. Pro Softnet has been around since 1995 providing Internet-based solutions. They have several other products including IBackup and RemotePC.

Disturbing Findings or not so disturbing for the Forensic examiner

I downloaded the “Free” version of IDrive’s software.  I wanted to test it and potentially include it in our training as a discussion item on cloud investigation issues. IDrive is unique among the “Online Backup” providers in that they offer “Free” storage of up to 5 GB of data. The other companies in this space seem to only offer a free trial period of their product. IDrive was unique enough that I thought I needed to try it.

This short blog entry is not a review of the entire installation of the software. I did not look in to the registry or examine ever file. I did however find a few things that are worth mentioning for the forensic examiner. I quickly and easily installed their software and easily uploaded some test data into their storage.  I then started to poke around on my machine to identify where IDrive put files.  I did not have to go far. IDrive’s files are found on the local system hard drive under the IDrive folder in the “Program Files” folder.

In the main IDrive folder is the 128 bit “rc4.key” encrypted key file I am sure that is used by the system to communicate with the IDrive server. RC4 is almost 25 years old as an encryption scheme. It however is still in common use today.  I did not examine further its implementation in the communication scheme of the product or try to crack it..

IDrive Temp Folder

In the IDrive “Temp” folder there were two folders with files similarly named. The file “DLLOutput1.txt” contained only an IP address of 206.221.210.66 (and what appears to be a port number of 11663) which belongs to IDrives parent company Pro-Softnet.

The file DLLIntput1.txt similarly contained a small amount of important information. The format was: 

8-16-2012 11-52-21 AM

 We will discuss the username and password translation below.

LDB Folder

In the LDB folder is a file titled “IDriveLDB.IDr”. The file is an SQlite database containing file paths of the data to be backed up.

Log Folder

Under the “Log” folder is another file containing a file named “Realtime Trace.txt”. This file is a log file with connection dates and times.   This file contained the backup up operation to IDrive, which included the IDrive User name, data files names and paths, the start and end time of the backup, the number of files backed up and any excluded files from the backup.

Folder with local computer name

In the folder with the local computers name was found a file titled “Backupfile.txt”. This file contained a list of the files backed up to the IDrive server. In this same folder was another file “BackupSet.txt” that appeared to contain the dates and times of the backups.

IDdrive\”Username”

In the IDrive user folder there is a file called “IDriveE.ini”. The contents are a little lengthier but it is revealing.  At first glance there is the same IP address identified above, the port and much more information. I looked at the lines in the file and realized that some encryption scheme was used. The question is what was it?  Thinking I would not easily find out what the scheme was that was implemented, I used a program to simply try various cyphers common in obfuscation. Without much effort I revealed my passwords and my user name from the text. The obfuscation used by IDrive was a simple 2 position Cesar Cypher.

Text in File Translation
user 2 position Cesar Cypher and is my login user name
User Password=xxxxxxx 2 position Cesar Cypher and is my login password
gpercuuyqtf=xxxxxxxx 2 position Cesar Cypher and is “encpassword=mypassword”
Enc password=xxxxxx 2 position Cesar Cypher and is my encrypted Idrive password but only the first 6 characters of my password
wugtgocknkf=vqffBxgtguqhvyctg0eqo useremailid;todd@veresoftware.com

(Real password has been removed for my security….)

These were not the only lines that used the 2 position Cesar Cypher. In going through the entire file, the lines not in plaintext all used this same cypher to encode their data.

IDriveEUsername_Folder

In reviewing a file named “SerTraceFile.txt” I found a log file with more interesting information about the service and what it collects about my system. The file contained many pieces of information about the IDrive service and the local machine including the local PC name and the NIC card’s MAC address.

Conclusion

WOW….So in looking at IDrive, the “Encrypted” backup service, I found from a forensic point of view, some substantially important failings on the local machine. Well not failings from an investigative point of view, this is actually some great information.  I made no attempt at the writing of this blog entry to use the file information to login from a separate machine. Until Prosoft changes the IDrive local machine files Digital Forensic examiners will have access to some useful information from the IDrive files.

Post script

I am sure this will be changed in a follow-on version by Pro-Soft (at least I hope so), but for the record what I found is limited to my examination of these specific versions on a Windows 7 machine. The IDrive versions I used in this testing were 3.3.4 and3.4.1.

Cell phones, the Internet and common evidence issues

Wednesday, July 6th, 2011

Our free webinar last week was on cell phones and the common apps used to connect them with the Internet. Mike Harrington of Teel Technologies talked about some of the items of evidence which those apps leave, both on the phones and on the Internet sites the apps lead to.

Todd has been talking for some time about how the normal crime scene has been changing over time and that investigators, both civil and criminal, need to be thinking of where there evidence is outside of the physical location they are at. The Internet, and the ability of most modern cell phones to connect to it, have greatly expanded our possible locations for evidence to be found – far beyond the physical crime scene. With this increase means of course more work. But with the additional locations for evidence, investigators can obtain a clearer picture of what occurred.

This means that evidence will be located at a minimum in the following places:

  1. The cell phone itself (forensic data extraction)
  2. The social media site (accessed from the web and properly documented). Depending on the number of apps on the phone this could be numerous sites.

Because we don’t generally let the cell phone access the web during data extraction (to prevent syncing and therefore data change), what is on the cell phone will undoubtedly be different then what is on the social media site.

This is particularly true if the user accesses the sites from places other than his cell phone, or his friends make posts to his wall (as themselves or even posing as him). So, to corroborate what they find on the phone, investigators should also plan to collect additional items through legal service (civil or criminal subpoena or search warrant):

  1. Cell phone/tower records from the provider
  2. Social media site records from the social media site. Again, depending on the number of apps on the phone, this could be numerous sites.

Each of these records contains a piece of the puzzle. Compiling all of them can give the investigator a more accurate picture of what occurred and when, but it all needs to be documented properly.

The investigator must also be prepared to investigate further when the two are inconsistent, and if necessary, explain the inconsistencies in court. For example, if phone artifacts have date/time stamps and content that are different from those found on social networking sites, investigators must question why. Likewise when a cell service provider’s records differ from phone or Internet evidence.

In short: none of this evidence – data on the cell phone, the social networking site, or in the cell or Internet service provider’s records – should be considered “nice to have.” With courts paying more attention to the authenticity and verifiability of digital evidence, gathering as much information as possible from as many sources as possible is a requirement to ensuring that victims and suspects alike get the due process they deserve.

Smartphones and the Internet: Finding evidence in 2 different places

Wednesday, June 22nd, 2011
How do Internet and mobile phone evidence support each other?

How do Internet and mobile phone evidence support each other?

On Thursday, June 30, we’ll be offering another webinar that is new to our series: Smartphones and the Internet, a discussion about how smart phones are changing the world of online investigations. Instructor Michael Harrington, Director of Training at Teel Technologies and a longtime expert in mobile device forensics, will cover the various apps and tools that tie smart phones to the Internet and the potential for evidence collection on both the phone and the websites tied to the apps.

We asked Mike for some more detail on what he’ll be talking about:

VS: What are the major apps and platforms you’ll be covering in your webinar, and why are they especially relevant?

MH: I’ll mostly be concentrating on iOS and Android and focusing attention on GPS, browser, cloud and social networking applications such as Facebook and Twitter. iOS and especially Android account for the vast majority of the consumer market. Android growth is particularly strong in emerging markets, and has arguably the number one market position.

I’ll be concentrating on social networking applications because research has shown that the vast majority of access to services such as Facebook and Twitter are done on mobile. Facebook in particular is relevant because of the recent controversies of underage access and of course its role in the Arab Spring. Twitter has also made the news with Weinergate, and controversy over ill-thought tweets by such people as Roger Ebert.

The ability to access cloud based services from smart phones (Evernote, logmein and the like) as well as the smartphones capturing of location information not just overtly through GPS applications makes discussion of the platforms relevant.

VS: How do online evidence and mobile evidence work in conjunction? What if one doesn’t match the other?

Online evidence and mobile evidence should be used to validate each other. They should match each other regarding similar data such as IP address. In some instances online evidence may contain more information and vice versa. If they don’t match further investigation and explanation is needed to account for differences.

VS: How deep should investigators dive when collecting evidence from the Internet and from a mobile device? How can they make the decision about how far to go?

I think these questions are tied together inextricably. The decision on how far to dive depends on the severity of the crime. In most instances a simple download of the logical data on the phone will be sufficient to corroborate online evidence or to gather additional evidence to support that gathered online. In some instances it may be necessary to try to recover deleted data off a mobile — this may require specialist equipment and certainly more time and training.

VS: Not all mobile examiners will collect online evidence, and not all online investigators will collect mobile evidence. What’s the best way for them to come together to work out case building?

Since most people on the planet carry mobile phones and the usage of smart phones to access more services is expected to rise by 55% in 2011 it is absolute folly not to look for evidence on mobile devices. I would recommend that a [standard operating procedure] be worked out that if mobile devices are seized, and the particular type of case being worked suggests that a device may be used to access online services where evidence could be collected — or the like is found on mobile devices — that [all] those leads are chased down.

Investigators have to aware of all ways in which criminals and victims access the online world. More and more it’s through their mobile devices.

VS: Anything else webinar attendees should know in advance?

Maybe some stats on the smartphone market. Here is an excerpt from the first chapter of the Android book (Apress, expected pub date December 2011) I’m working on:

The growth of the global smart phone market has been nothing short of explosive. According to the International Data Corporation (IDC), a leader in market research, the world wide smartphone market is expected to grow 55% in 2011, fueled by consumers eager to exchange their feature mobile phones for advanced devices with more features, and most importantly, apps.

The sheer number of devices being shipped is staggering. Again according to the IDC’s Worldwide Quarterly Mobile Phone Tracker there will be a total of 472 million smart phones shipped in 2011 up from 305 in 2010. Furthermore, this is expected to almost double to an unbelievable 982 million by the end of 2015.

The growth rate is over four times the rate of the overall mobile phone market due to the accessibility of devices to a wide range of users, and helped by falling prices, functionality and low cost data plans.

The growth is most pronounced in markets that are emerging and where the adoption of these devices is still in early days – the IDC predicts that the most stunning growth will be in the Asia/Pacific region and in Latin America.

Join us on Thursday, June 30 from 11am-12pm Pacific, and bring any questions you have for Mike!

Image: Johann Larsson via Flickr

Dissecting a MySpace cookie

Wednesday, May 18th, 2011

myspace_logoI previously looked at the MySpace source code and as an aside, I decided to look at the MySpace cookie placed on my computer through Internet Explorer. I need to spend some more time with it, but I found one tidbit of interest. Here are the contents of that cookie:

MSCulture
IP=76.232.69.187&IPCulture=en-US&PreferredCulture=en-US&Country=VVM%3D&ForcedExpiration=0&timeZone=-7&USRLOC=QXJlYUNvZGU9Nzc1JkNpdHk9UmVubyZDb3VudHJ5Q29kZT1VUyZDb3
VudHJ5TmFtZT1Vbml0ZWQgU3RhdGVzJkRtYUNvZGU9ODExJkxhdGl0dWRlPTM
5LjU1NDUmTG9uZ2l0dWRlPS0xMTkuODA2MiZQb3N0YWxDb2RlPSZSZWdpb25
OYW1lPU5WJkxvY2F0aW9uSWQ9MA

myspace.com/
1600
1450779520
30110255
767532288
30108847*
SessionDDF2
WecgMpqrHOI4tePW304hLLYkIoD8e+hqZQakpBfhu0bf+3YNd9a3gLJAKgrhd57+klMP1U9u
DlEKYfXnDvXE8w==
myspace.com/
1536
2677308160
31578165
1536619600
30108650
*__utma
102911388.576917061.1287093264.1287098574.1287177795.3
myspace.com/
1600
522347392
30255698
765392288
30108847
*
__utmz
102911388.1287093264.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
myspace.com/
1600
428951552
30145363
1564109600
30108650
*__utmb
102911388.0.10.1287177795
myspace.com/
1600
1584863104
30108851
765392288
30108847
*
__unam
7639673-12bb1c67c3e-6a4aaea5-1
myspace.com/
1600
3491813376
30163644
781442288
30108847
*

Here is an interesting part in Base64:

QXJlYUNvZGU9Nzc1JkNpdHk9UmVubyZDb3VudHJ5Q29kZT1VUyZDb3VudHJ5
TmFtZT1Vbml0ZWQgU3RhdGVzJkRtYUNvZGU9ODExJkxhdGl0dWRlPTM5LjU1NDUmT
G9uZ2l0dWRlPS0xMTkuODA2MiZQb3N0YWxDb2RlPSZSZWdpb25OYW1lPU5W
JkxvY2F0aW9uSWQ9MA

Here is the Base 64 Translation:

USRLOC=AreaCode=775&City=Reno&CountryCode=US&CountryName=United States&DmaCode=811&Latitude=39.5545&Longitude=-119.8062&PostalCode=&RegionName=NV&LocationId=0

The investigator should be aware that the latitude and longitude is generally based on the IP address geolocation. Again this is something you are revealing to the website when you visit it. The website automatically geolocates the IP address for general marketing purposes. As an investigator you need to be aware that you are exposing this information to the websites you surf. I’ll comment more on geolocation in another post.

Not that we all did not know that companies use tracking codes to identify us, but here is the type of information that might be on a suspect’s system if you go looking for it in his cookies. It also shows how much MySpace is tracking about you during an investigation and collecting about you when you go to a suspect’s MySpace page. I found a nice article at http://helpful.knobs-dials.com/index.php/Utma,_utmb,_utmz_cookies describing some of the cookie’s contents of the cookie.

The cookies named __utma through __utmz are part of Google Analytics, originally by the urchin tracking module, also by the newer ga.js. These cookies track usage on sites that use Google Analytics.”

The article goes on to describe the various pieces of the cookie.

__utma tracks each user’s amount of visits, first, last visit.
__utmz tracks where a visitor came from (search engine, search keyword, link)
__utmb and __utmc are used to track when a visit starts and approximately ends (c expires quickly).
__utmv is used for user-custom variables in Analytics
__utmk – digest hashes of utm values
__utmx is used by Website Optimizer, when it is being used

Another good description of the Google Analytic cookies and their contents can be found at MoreVisibility (A marketing website). There are many other sites that collect similar information such as NetcraftAlexa, and WMtips (each of these can be accessed from our free Internet Investigators Toolbar.

The __utma cookie appears to be a string with six fields, delimited by a “.”. The last field is a single integer which records the number of sessions during the cookie lifetime

Here are the various pieces of the cookie with the date and times translated:

Cookie Code Section Date and Time Translation*
myspace.com/
1600
1450779520
30110255
767532288
30108847
1450779520,30110255
Fri, 22 October 2010 13:23:15 -0800
767532288,30108847
Fri, 15 October 2010 13:23:15 -0800
SessionDDF2
WecgMpqrHOI4tePW304hLLYkIo
D8e+hqZQakpBfhu0bf+3YNd9a3g
LJAKgrhd57+klMP1U9uDlEKYfXn
DvXE8w==
myspace.com/
1536
2677308160
31578165
1536619600
30108650
2677308160,31578165
Mon, 14 October 2030 13:54:22 -0800
153661960,30108650
Thu, 14 October 2010 13:52:03 -0800
__utma
102911388.576917061.1287093264.
1287098574.1287177795.3
myspace.com/
1600
522347392
30255698
765392288
30108847
522347392,30255698
Sun, 14 October 2012 13:23:15 -0800
765392288,30108847
Fri, 15 October 2010 13:23:15 -0800
__utmz
102911388.1287093264.1.1.utmcsr=
(direct)|utmccn=(direct)|utmcmd=(none)
myspace.com/
1600
428951552
30145363
1564109600
30108650
428951552,30145363
Fri, 15 April 2011 01:54:24 -0800
1564109600,30108650
Thu, 14 October 2010 13:54:24 -0800
__utmb
102911388.0.10.1287177795
myspace.com/
1600
1584863104
30108851
765392288
30108847
1584863104,30108851
Fri, 15 October 2010 13:53:15 -0800
765392288,30108847
Fri, 15 October 2010 13:23:15 -0800
__unam
7639673-12bb1c67c3e-6a4aaea5-1
myspace.com/
1600
3491813376
30163644
781442288
30108847
3491813376,30163644
Thu, 14 July 2011 23:00:00 -0800
781442288,30108847
Fri, 15 October 2010 13:23:16 -0800

*Decoding of the dates and times are thanks to the free “Dcode” tool by Digital Detective.

Todd Shipley is Vere Software’s president and CEO.

Dissecting a MySpace page

Tuesday, May 17th, 2011

myspace-300x81Having not seen this done anywhere else, I decided to look at some basic MySpace pages at random and determine if I could find anything in the source code that might be of any investigative interest.

In general, the source code of a MySpace page has lots of HTML code, but much of it is of no use to the investigator because it does not identify the user or provide investigative leads. There are, however, a couple of interesting things to be found if you look for them.

The actual server location of an image file

Images on a MySpace main page are not embedded in the page. They are linked to a separate web address at www.msplinks.com. Here is a real example randomly gathered from a MySpace page of an image that was on the page:

href=”http://www.msplinks.com/MDFodHRwOi8vdmlld21vcmVwaWNzLm15c3BhY2
UuY29tL2luZGV4LmNmbT9mdXNlYWN0aW9uPXZpZXdJbWFnZSZmcmllbmRJRD0y
ODYzNDc4JmFsYnVtSUQ9MjExNDE2NSZpbWFnZUlEPTQ0OTU4MTY2″>

This highlighted portion of the code which is obfuscated and is actually encoded in Base64:

MDFodHRwOi8vdmlld21vcmVwaWNzLm15c3BhY2UuY29tL2luZGV4LmNmbT9mdXNl
YWN0aW9uPXZpZXdJbWFnZSZmcmllbmRJRD0yODYzNDc4JmFsYnVtSUQ9MjExNDE
2NSZpbWFnZUlEPTQ0OTU4MTY2

The Base64 translation of this portion of the code is:

01http://viewmorepics.myspace.com/index.cfm?fuseaction=viewImage&friendID=2863478&albumID=2114165&imageID=44958166

The Base64 translated link contains the friendID of the page it is from and what appears to be a uniquely assigned imageID.

The www.msplinks.com address is just a white page when you go there. However, when you look at the source code for this page you see some “old school letters” spelling out myspace.com:

myspace

Embedded video files and their original location

If you right click on an embedded video and select “copy embedded HTML” and paste that into a separate document, you can review the code and find the video location.

Actual example of an embedded video from a random MySpace page:

<imgsrc=”<object width=”640″ height=”390″><param name=”movie” value=”http://www.youtube.com/v/Xz2MWedTbP0&hl=en_US&feature=
player_embedded&version=3″></param><param name=”allowFullScreen” value=”true”></param><param name=”allowScriptAccess” value=”always”></param><embed src=”http://www.youtube.com/v/Xz2MWedTbP0&hl=en_US&feature=
player_embedded&version=3″ type=”application/x-shockwave-flash” allowfullscreen=”true” allowScriptAccess=”always” width=”640″ height=”390″></embed></object>

The actual page location on YouTube of the embedded video from above example:

http://www.youtube.com/v/Xz2MWedTbP0

Finding the FriendID

I also found the MySpace FriendID in several different locations in the pages source code. A simple search for “FriendID” will find the numerical Friend ID used by MySpace.

Here is a random example of a FriendID found in MySpace source code:

var MySpaceClientContext = {”UserId”:-1,”DisplayFriendId”:281346014,”IsLoggedIn”:false,”FunctionalContext”:
“UserViewProfile”,”UserType”:1};

This is the Myspace ID # that corresponds with the MySpace user name:

DisplayFriendId”:281346014

Add the Friend ID to the MySpace URL and it will take you to that friend’s page.

http://www.myspace.com/281346014

Tracking Code

I also found something of interest to the investigator and a good reason not to use your agency/company computer network to look at a MySpace page. Without much effort I found the code for MixMap. MixMap is tracking code that can be used to identify the IP addresses of anyone viewing a MySpace page. You can register at www.mixmap.com for access to your account and to prepare unique code for insertion on your MySpace page.

In a real example I found the following tracking code located in the MySpace page’s source code:

<a href=”http://www.msplinks.com/MDFodHRwOi8vd3d3Lm1peG1hcC5jb20v”
target=”_new” title=”MySpace Tracker”>
<img src=”http://www.mixmap.com/661165/no_image_tracker_strict.jpg” border=”0″ height=”1″ width=”1″ style=”visibility:hidden;” alt=”MySpace Tracker” /></a></style></span>

<a href=”http://www.msplinks.com/MDFodHRwOi8vd3d3Lm1peG1hcC5jb20v” target=”_new” title=”MySpace Tracker”><img src=”http://www.mixmap.com/661165/no_image_tracker_strict.jpg” border=”0″ height=”1″ width=”1″ style=”visibility:hidden;” alt=”MySpace Tracker” /></a></style></span>

This portion of the code is actually encoded in Base64:

MDFodHRwOi8vd3d3Lm1peG1hcC5jb20v

The Base64 translation of this portion of the code is:

01http://www.mixmap.com/

MySpace beacon data

Another thing I found a little disturbing about MySpace was what it is collecting on its pages. I located the following code labeled MySpace.BeaconData, which indicates that MySpace appears to be tracking persons viewing MySpace pages. Not that this is unusual from a marketing point of view. But the investigator should be aware that s/he is being tracked.

In the abbreviated random example below, you can see in the bolded portions the city, state and country I am coming from, as well as my computer’s operating system and the version of Internet Explorer I was using.

MySpace.BeaconData={”dsid”:”2″,”dsv”:”1″,”rd”:”browseusers.myspace.com”,”rqs”:”",”refpg”:
“/Browse/Browse.aspx”,”rpf”:”Browse”,”d”:”www.myspace.com”,”qs”:
“friendID=2863478″,”pf”:”UserViewProfile”,”fa”:”",”pgnm”:
“/Modules/Profiles/Pages/Display/Profile.aspx”,”cip”:”1290290619″,”pc”:”en-US”,”pid”:”405384887825081977″,”pidf”:”0″,”ABtd”:”0″,”t”:
“1287086098069″,”ct”:”1287086098069″,”ci”:”Reno“,”st”:”NV“,”co”:”US“,
“dmac”:”811″,”uff”:”0″,”uatv”:”br=MSIE 8.0&os=Windows NT 6.1“,”sip”:”170659174″,”uid”:”-2″,”pggd”:
“e327762c-2571-4e8f-b47f-d5fb46a670e5″,”prid”:”2863478″,”ili”:”0″,”at”:”1″,”cfv”:”0:0:0″,”cef”:
“0″,”sliu”:”0″,”pref”:”0″,”kvp”:”bt=0

In the following abbreviated random example I used the Tor network to hide myself, and you can still see (in the bolded portions) the city, state and country the Tor exit node was located:

MySpace.BeaconData={”dsid”:”2″,”dsv”:”1″,”rd”:”",”rqs”:”",”refpg”:”",”rpf”:”",”d”:”www.myspace.com”,
“qs”:”friendID=542455573″,”pf”:”UserViewProfile”,”fa”:”",”pgnm”:
“/Modules/Profiles/Pages/Display/Profile.aspx”,”cip”:”3493170727″,”pc”:”en-US”,”pid”:”405384887825081977″,”pidf”:”0″,”ABtd”:”0″,”t”:”1287100961997″,”ct”:
“1287100961997″,”ci”:”Woodstock“,”st”:”IL“,”co”:”US“,”dmac”:”602″,”uff”:
“0″,”uatv”:”br=MSIE 8.0&os=Windows NT
6.1
“,”sip”:”170663537″,”uid”:”281346014″,”pggd”:”c1834a83-d897-44a8-adfe-
93e8f959c60e”,”prid”:
“542455573″,”ili”:”0″,”at”:”2″,”cfv”:”0:0:0″,”cef”:”0″,”sliu”:”0″,”pref”:”0″,”

In this example the Tor exit node just happened to be in Illinois. From an investigative standpoint, the investigator should know what s/he is exposing to the target website.

I’ll continue to review pages and comment as I find anything interesting. If anyone else has any good tidbits about MySpace or any other social networking sites let me know in comments.

Todd Shipley is Vere Software’s president and CEO.

Tracing IP Addresses: Q&A

Friday, February 18th, 2011

We were very pleased to welcome back Dr. Gary Kessler to our “Online Investigations Basics” webinar series this week. Once again Dr. Kessler discussed some of the background and tools relevant to tracing IP addresses. Below is his companion presentation:

During the session, we took several questions from some of our listeners. One person asked whether tracing IP addresses overseas was any different from tracing them domestically. Answer: not technically; the overall process remains the same, but whether American investigators can secure foreign cooperation is a different question. The best bet is for investigators to contact legal representatives in American embassies for help dealing with law enforcement in another country.

Another participant asked whether TCP/IP packets would provide information on what kind of device accessed the Internet; in a related question, someone else asked if MAC addresses from two devices could show that they had been communicating with one another.

By themselves, packets contain no information on the type of device communicating. A device or router is needed to show where an IP address was assigned; the same is true for tracing IP addresses past a private network. And as for MAC addresses, they have only local relevance, not end-to-end applicability.

We wished we could have gotten into more detail about this question: the biggest challenges with tracing IP addresses in the cloud. As the load of traffic increases, and IPv4 addresses diminish (before IPv6 takes hold), more ISPs will begin to allow shared IP addresses. On the flip side, multiple IP addresses will be resolved to single devices.

Again, we’re grateful to Dr. Kessler for taking the time to help educate the community on a complex issue. Have questions? Please contact us. And we’d love to see you at our future “Online Investigations Basics” webinars. In another few weeks, Cynthia Navarro will be talking about online sources of information. We hope you’ll join us!

Our Online Investigations Basics webinar series is back!

Thursday, February 3rd, 2011

We’re excited to announce the return of our popular, free “Online Investigations Basics” webinar series! Designed to help investigators maximize their online evidence collection skills, the monthly webinars will feature investigative techniques and issues such as:

  • Tracing IP Addresses
  • Online Sources of Information
  • Online Identity Theft Investigations
  • Internet Relay Chat (IRC) Investigations
  • Investigating Social Media

The webinar series builds on the original series, offered in the fall of 2009, by offering both new courses and updated content from some returning instructors as well as new voices. Established experts in their fields, the Online Investigation Basics instructors will take questions from, and interact with, webinar attendees during a structured Q&A period within each 60-minute presentation. The webinars are meant for investigators from all sectors — law enforcement, corporate and independent.

In addition, we’ll continue to provide our monthly WebCase webinars, which allow investigators to get to know our software when they can’t attend our on-site training.

The first Online Investigation Basics webinar is Thursday, February 17. Dr. Gary Kessler of Gary Kessler & Associates will present “Tracing IP Addresses,” in which he will introduce concepts about the TCP/IP suite, the Internet, IP addressing and domain names, and the administration of Internet names and numbers. He will also demonstrate tools to support IP tracing.

Want to know more? Sign up today!

Simplifying the webmail collection process

Thursday, January 13th, 2011

A recent ComputerWorld article discussed the security problems posed by webmail within organizations. In short, because webmail comes across HTTP rather than SMTP protocols, the organization does not protect against data leakage as it does from its own email system.

The reasons for this are many. In 2008, ComputerWorld ran an article that discussed ways webmail could breach even organizations with strong security. As always, the human factor can be a challenge. Well-meaning employees may use webmail to segregate business from personal email, when they are required not to conduct personal business on company accounts; employees may also use webmail to bypass overly complicated email security procedures.

At that point, even if employees’ personal webmail accounts aren’t being archived per the law, their email may become discoverable in the event of litigation. How to document the emails’ content?

In an October 2009 article for EDEN: The Electronic Data Extraction Network, Jonathan Yeh discussed various ways in which webmail could be captured for archival purposes. Among them:

  • Download the email locally using an email client with a POP or IMAP protocol. It can then be searched just like other digital evidence.
  • If these protocols cannot be used, screenshots, web page capture, or even printing.
  • Obtain data via browser artifacts.

Each of these methods is, however, complicated. Yeh goes into these issues in some detail, ending with the need to document each step of the collection process. While true that the courts accept expert testimony together with downloaded or screenshot data, there is still nothing about these collection methods to prove that the content was not manipulated in any way.

In addition, the procedures Yeh describes, along with some of the issues that the investigator must take into account, are time-consuming. Under such conditions, the margin for human error is greater, and as Yeh concludes, “The reliability of evidence can often only be gauged by the reliability of the methods used to collect it, and proper documentation can be the difference between admissibility and inadmissibility in court.”

Simplifying the “screenshots and web page captures” process, and in doing so addressing the reliability issue that Yeh brings up, is WebCase. That it is currently the only tool to do so should not be lost on e-discovery experts or other investigators.

Want more information? Schedule your free demo today!

Fingerprinting a Web server from an investigative point of view

Wednesday, May 19th, 2010

Fingerprinting web servers is not a startling new revelation in web development. For several years now technology to identify web servers has been used by black and white hackers to identify weaknesses in web servers. Companies have used these “fingerprinting” techniques to identify incoming information about IP addresses and the servers they come from to prevent Identity Theft and credit card fraud. These techniques are also commonly used by penetration testers to help identify a system prior to attempting to review the system. Hackers have used the techniques to ascertain weakness in a web servers implementation to attack the system.

Most often the technique of “fingerprinting” is implemented as a server side technique to view the incoming traffic. The implementation of client side application is what would be of interest to the online investigator. There have been numerous discussions about its use and technical development but not from the law enforcement investigative capacity. Identify the information about a server can be advantageous for an investigation being conducted on the internet. “Fingerprinting” the web server can identifying certain aspect about the server, including the operating system and version.  This identification can potentially provide law enforcement investigators with additional useful information as to the nature and origin of the website.

Using browser responses to identify what the system is running can aid the investigators preliminary examination of a website. The initial review of the website can determine the website’s ownership and validity. A commonly used tool that has been a hacking/penetration tester staple for years is Nmap. Nmap is short for Network Mapper, an open source utility for exploring networks and doing security audits. Other tools have been developed specifically for the purpose of identifying web servers through the server’s response to a browsers request. Some of those tools include hmap, Nikto, httprint and XProbe.

More in depth identification of web server “fingerprinting” needs to be accomplished to identify its complete benefit as an investigative tool. Based on its current use in the field, as a reliable penetration tester’s tool, the prospect appears great that this methodology could be beneficial to law enforcement.