After the Facebook post last week, much of the backlash consisted of, "Who cares if someone has my IP address? That information is almost always out there." Well, here is a great example of what someone can do with an IP address. Here’s something to really think about.. I was able to obtain all of the information in this post for 16 cents and by just using an email and IP address from a piece of spam. Family members, ages, schools, anniversary dates, marriage lengths, hobbies, interests, phone numbers, addresses, property records, property taxes, pictures of their house, pictures of them, pictures of their children and grandchildren, deeds on their house, bankruptcies, employment history, previous addresses, previous creditors, and bits of social security numbers. I’m pretty sure I’d be able to fake my way through one of those password reset forms.. you know, where you set up a “secret question” asking what your dogs name was, or where you went to school? Beyond that, I’m fairly confident that at this point, if I were to call his bank and pretend to be him, I could easily pass when they asked me personal questions.
- 4cast (1)
- aboutus (1)
- apple (3)
- attacks (1)
- authors (1)
- backontrack (1)
- backtrack (2)
- blog (1)
- botnet (1)
- breach (1)
- cell phone (2)
- cell phone forensics (2)
- cellebrite (1)
- chain of custody (1)
- challenge (1)
- copyright (1)
- crime (1)
- crypto (1)
- cyber security (6)
- cyber stalking (2)
- cybercrime (4)
- cyberwar (1)
- data size (1)
- economy (1)
- encase (1)
- encryption (3)
- enticement (1)
- evidence (3)
- exploit (3)
- facebook (4)
- fail (1)
- forensics (16)
- free (1)
- free speech (2)
- ftk (1)
- ftw (3)
- funny (1)
- future (1)
- game systems (2)
- government (1)
- gps (1)
- guidance (1)
- harassment (1)
- imaging (1)
- interview (6)
- investigation (8)
- ip (1)
- ip address (1)
- iphone (2)
- law (3)
- links (22)
- mac (2)
- model (1)
- news (16)
- pentest (2)
- podcast (1)
- printers (1)
- privacy (12)
- products (1)
- ps3 (1)
- quickhit (1)
- registry (1)
- regripper (2)
- review (1)
- riaa (1)
- sim card (1)
- skype (1)
- social engineering (2)
- social networking (1)
- theft (1)
- threats (8)
- tools (2)
- triage (1)
- Twitter (1)
- video (2)
- vpn (1)
New Website
Check out MattChurchill.net. I have migrated most of the content over to this site and will mostly be using it from now on. Thanks.
Matt's Twitter
Other Blogs
This post was written by guest blogger Adam James. Please feel free to post any questions or comments for him on this blog.
-------------------------------------------------
Modifying RegRipper to automatically run against a selected mounted drive.
When using RegRipper I began running into user to computer interface problems. Namely, for some reason I would select a hive file to process, but forget to tell RegRipper what plugin file to use against it. After doing this several dozen times and having to rerun the reports after realizing I had done it, I started thinking about ways to modify RegRipper to alleviate my obvious “stupid” user issues. I figured since I can’t remember to select the plugin types I want, why can’t the program just throw all the available plugins against the hive and determine which ones should work against it. Then that got me thinking… for that matter why am “I” having to know where all these registry hives are at. I have to extract them from an image, remember where I took them from, and then run RegRipper against each one. That is way too much work. I wish RegRipper would just do that all for me so I can do what I really care about, look at the great output from the program.
To accomplish this task there were a couple of problems that needed to be solved. The rest of this post will be about how a proof of concept that I did solved these problems.
Problems:
1.RegRipper is intended to only run plugins against a single and specified type of registry hive. The plugins can be run against any single hive it is just not likely that any of the key value pairs will be successfully foundoHow if it is not of the correct type.
2.RegRipper expects the user to know the location of each registry hive that needs to be processed.
Potential Solutions:
1.Modify RegRipper to allow the user to select one or more registry hives. Have RegRipper attempt to determine each hive’s type and then run only the plugins that are intended for that hive against it.
This is pretty easy… right? All we need to do is (a)come up with some code to determine a hive file type, (b)programmatically determine what hive type a plugin is supposed to run against, (c)allow the user to select multiple hives, and then (d)iterate through all of the hives. That doesn’t seem too bad.
a.To determine the hive type, Harlan has already provided us with code in rip.pl that tries to guess the hive type, so that is done, we just need to add it to RegRipper. For my proof of concept I came up with a similar way, I just used different keys. (starts at line 563 of code)
b.To determine the hive each plugins should be run against the basic design of the RegRipper could be used. In each plugin the developer can specify what hive types the plugin should be run against. You could just pull the %config=>hive value from the plugin and use that. When reviewing the plugins I noticed that some could be potentially run against multiple hive types. I figured to keep closer to the current user experience it might be a better idea to still allow users to create their own plugin files, so I came up with my own format. Instead of putting just the plugin name in the plugin file, place the hive type you want to run it against in front of it. ie: “system:usbstor”. I had to modify the main RegRipper code to parse the new plugin file format, and also keep it backward compatible with the current plugin file format. (starts at line 434 of the code)
c.To allow the user to select multiple hive files an additional perl module is required. I used the FileOp::OpenDialog which allows the user to select multiple files. (line 251 of the code)
d.Since selecting multiple files with the OpenDialog returns an array of file names looping through them is easy to implement. (line 267 of the code)
So the first problem has been successfully solved and I no longer have to remember to change the plugin file type each time I run RegRipper against a new hive. As a side benefit I can run RegRipper against all of my exported hive files all at once if I want to also. Now on to the next problem.
2.Modify RegRipper to allow it to be run against a mounted drive. Have the program find all of the relevant hive files on the system and process them in a systematic manner.
Now this one looks a little more difficult… maybe? Ok, so we need to (a)allow the user to select a drive letter to run against, (b)grab the basic hive files from windows\system32\config, (c)parse the software hive for a list of profiles and grab the NTUSER.DAT file for each profile, (d)then iterate through all of the identified registry files. Shouldn’t be too tough, I guess.
a.To allow the user to specify running RegRipper against a mounted drive I added a checkbox to the GUI. When this box is checked the BrowseForFolder option from the FileOp perl module is used. (line 605 of the code)
b.Grabbing the basic hives from the mounted drive is a little more difficult than it first looks. Sure the standard location is C:\Windows\System32\config. I first tried this, but when running it on actual cases ran into some issues. Seems some of our corporate clients for some reason have created their own golden images that put the %systemroot% at somewhere other than C:\Windows such as C:\Win.
Now this creates a little bit of an issue, as it messes up what should have been an easy step. To resolve this on Windows XP the %systemroot% can be determined from the boot.ini file in a fairly straightforward manner. (starts at line 639 of the code) To resolve this issue in Vista and beyond is a little more difficult. The boot configurations are now stored in a registry hive called the BCD. So you have to parse the GUID and element key/value pairs to get the value that specifies the %systemroot%. (starts at line 614 of the code) If you want to replicate what is in the code I provided a link at the end of this post that should provide the relevant information about the BCD.
Lastly I tossed in some extra code just in case the boot.ini and BCD registry hives can’t be found to default to windows\system32\config. Cause it never hurts to try if nothing else was found.
c.To determine the profiles on the system Harlan has already provided the code in the profilelist plugin. I used a modification of that code to grab all of the NTUSER.DAT files. (starts at line 690 of the code).
d.The issue of iterating through multiple hive files was solved in the previous problem. For this I just had to make sure each hive file found was placed in an array to be processed. (line 267 of the code, again)
For me the proof of concept works. It is definitely a rough cut in my opinion, but the source is all there and this post explains the process if anyone wants to make improvements. I am not totally sure I really like the output file that this proof on concept results in, but it is a start. Drastically changing the output options of RegRipper is probably a more difficult undertaking than making it run against a mounted drive, so it may not be worth it.
Links
http://regripper.net/?page_id=150 (download the code)
The last post about Facebook including users' IP addresses in notification emails got a lot of traffic. We also sent quite a bit of traffic to myiptest.com through the link provided in the story. Adrian from myiptest.com contacted me about VPN access as he also helps run hideipvpn.com.
The benefits of using a VPN or proxy service is clear. Your personal IP address won't be seen by the sites you visit and it can help protect your privacy. If you were using a VPN/proxy service, you wouldn't have been affected by the Facebook notification email problem. If you need more info on VPNs, visit the Wikipedia articles for VPN and Proxy servers.
I have not used the services of hideipvpn.com yet and hadn't heard of them before, but I did check out their privacy policy and terms of service. Both seem to be standard and I didn't see anything concerning, but I always suggest checking them out for yourself. As with anything else, use at your own risk. You can also see some reviews of their service here and here.
Adrian was kind enough to set aside 25 free accounts for readers of this blog. For full disclosure, he also promised me use of a premium/paid account.
Since there is no reason to turn down a free account, go grab one from here. If you don't make it in time to get one of these accounts, check out the hideipvpn.com blog for future chances. You can also follow them on Twitter. Please let me know how things go and leave me a comment about what you think of their service.
Update: Be aware that during the sign-up process your passwords will be emailed to you in plain text. They also seem to be stored on the hideipvpn.com's servers in plain text. Use a unique password for this site and make sure you don't use it anywhere else.
It also looks like they never validate your Google Checkout or Paypal account since it will never be charged.
Update: It looks like Facebook fixed the default behavior of the sent emails. Your IP Address is no longer included in the notification emails. I will give Facebook credit that they solved this in less than 24 hours. Now, if they can just shore up some of the other issues...
Original Post:
Facebook has nice email notifications whenever a friend comments on your status, sends you a message, or a variety of other reasons. The emails have subjects similar to "John Doe commented on your wall post." The unfortunate thing is that this email also appears to contain John Doe's (or your other friend's) IP address.The email headers contain a line similar to:
X-Facebook: from zuckmail ([MTAuMzAuNDcuMjAw])
Copy this line out and feed it to this page:
You will get the IP address of your friend and clicking on it will get a geolocation-based map. This will also show you if your friend used their cell phone to post and who they use as their service provider.
This information is great when a fugitive is taunting law enforcement through their Facebook page, but not when a wife is trying to hide from an abusive husband and assumes Facebook is the best form of communication.
This isn't the end of the world compared to some of Facebook's other privacy problems, however, there is simply no need for Facebook to include these IP addresses and it should be quickly fixed.
Subscribe to:
Posts (Atom)