Thursday, August 19. 2010
Over the last week, a bunch of friends have forwarded to me stories about the risks of GPS information embedded in pictures. For example, MythBuster Adam Savage apparently took a picture of his car at his home and forgot to disable the GPS information. Rabid fans quickly identified where Adam lived. Granted, I doubt most celebrities have secret homes, but the fact is: pictures tell much more about you than just the photo's content.
The GPS data in JPEGs is nothing new. It was part of JPEG's EXIF 2.1 Standard back in 1998. (And that may not be the earliest version...) However, it wasn't until the last few years that cameras, cell phones, and other portable devices began to incorporate GPS technologies. Today, it is hard to find a cell phone without a camera, and many of them include GPS as a feature.
While GPS information embedded in a picture may tell people where you were, Facebook has decided to use your GPS for telling people where you are. Called Facebook Places, they will broadcast your GPS location to all of your Facebook friends. While they do have options for limiting distribution, Facebook is well-known for abruptly changing policies.
iPhone, iPad, iTouch, iMac, iSpy
Today's ever-smarter portable devices are not designed for privacy-oriented people. While the embedding and publishing of GPS information may be an overt example, there are many other cases of your device leaking information about you.
I've been collecting photos from various hand-held devices. I use them to populate a photo ballistics database. My friend, Bum, recently purchased an iPad. He sent me a screenshot from the device. (His iPad doesn't have a camera.) While the picture's ballistics wasn't very interesting, the email header was!
From: Bum <b...@...com>
To: Neal Krawetz <n...@...com>
Content-Type: multipart/mixed; boundary=Apple-Mail-1-186804698
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPad Mail 7B405)
Subject: You wanted a photo?
Date: Sun, 8 Aug 2010 10:39:58 -0700
X-Mailer: iPad Mail (7B405)
The first thing to notice is the X-Mailer header. It identifies the device (iPad), application (Mail), and version (7B405). This isn't too exciting since most MUAs (mail user agents) include this type of information. However, it was the content boundary that got my attention: Apple-Mail-1-186804698.
I dug through my email archives and found a bunch of other examples:
Apple-Mail-11-1034880980
Apple-Mail-2--961132422
Apple-Mail-1--77112522
Apple-Mail-1-186804698
Apple-Mail-4--29131759
Apple-Mail-5--10882313
Apple-Mail-15-908210705
Apple-Mail-4-1054791469
With a little help from the DC3, I finally understand what these non-random numbers describe. The big number is actually the most uninteresting value. It is the time in milliseconds stored in a signed 32-bit register. (Negative numbers have the double hyphens.) Since it is a 32-bit register, the value rolls over about every 24.86 days. However, the zero date isn't the Unix epoch (00:00:00 on 1970-01-01). Instead, if you assume the timestamp represents today's date (from the email Date header) and repeatedly subtract 2 31 microseconds until you reach the Unix epoch, then you'll notice that it is off... The value closest to the epoch (without going under) is 128397792ms, or Jan 2 11:39:57 1970. (You might see it vary by a second, 11:39:58, if the clock happened to roll over between generating the Date and content boundary.) I'm not sure why Apple chose this date, but it is consistent. The Mail program on the iPhone, iPad, iTouch, and Mac OS X all use the same date.
From a forensics viewpoint, this is useful. This is a quick way to identify forged emails that claim to be from Macs. (I actually had a use for this last week!)
The more interesting number is the smaller value. It took me a while to identify the purpose. That is the number of attachments sent by the mailer (Apple Mail) since the program was started. If you see "-1-" then it means that you received the first attachment that they sent since they started the program. The "-15-" means that person had started Apple Mail and sent 14 attachments before sending one to me. ( Winn Schwartau sent me an email that had "-245-"!)
This is very useful, particularly if you receive multiple emails from the person over a short duration. For example, Bum always sends me with "-1-". This means he closes the Mail program frequently. (Make sense for an iPad that can't multitask.) I also received emails from a friend, M., who clearly loves attachments -- in 30 minutes he went from "--12--" to "--28--".
From a forensics viewpoint, this is awesome. Let's say the person has a couple of different Apple computers. I should be about to look over his computer and see how many attachments he sent on each system and match the count to the emails. Even if you delete a specific email, I can still determine how many attachments were included in the deletion.
Android Spies
The information leakage is not limited to Apple products. At Defcon, my friend Factor sent me a sample picture from his Android phone. The problem is, it crashed my analysis tool!
The problem was a poorly formed JPEG. Specifically, every JPEG should begin with 0xffd8, contain a stream that starts with 0xffda, and end with 0xffd9. Between the 0xffd8 and 0xffda are various other settings, including APP records (0xffe0 to 0xffef for APP0 to APP15). In his case, his Android was storing additional APP records after the end of stream (0xffd9).
I added a check for this situation (so my code no longer crashes). However, these APP5 records (0xffe5) turned out to be really interesting. They only appear in one type of Android phone: the Motorola Android. I have observed these fields from photos taken with:
- Motorola, Droid, 2.0.1
- Motorola, Droid, 2.1-update1
- Motorola, Droid, 2.2
- Motorola, DROIDX, 2.1-update1
- Motorola, DROID2, 2.2
- Motorola, Milestone, 2.1-update1
They probably appear in other phones as well. However, I have not seen them with any other type of Android phone.
These extra APP fields like:
tag='0xffe5' length='32' field='APP5' value='HPQ-MetaData'
tag='0xffe5' length='168' field='APP5' value='HPQ-HostIntf'
tag='0xffe5' length='2400' field='APP5' value='HPQ-AutoExpo'
tag='0xffe5' length='1856' field='APP5' value='HPQ-LensInfo'
tag='0xffe5' length='4112' field='APP5' value='HPQ-AutoFoS1'
tag='0xffe5' length='4104' field='APP5' value='HPQ-AutoFoLV'
tag='0xffe5' length='6140' field='APP5' value='HPQ-WhiteBal'
tag='0xffe5' length='1660' field='APP5' value='HPQ-PPR'
tag='0xffe5' length='1164' field='APP5' value='HPQ-Capture'
tag='0xffe5' length='142' field='APP5' value='HPQ-Pipe2Mdd'
tag='0xffe5' length='1692' field='APP5' value='HPQ-Flicker_'
tag='0xffe5' length='44' field='APP5' value='HPQ-SensorMD'
tag='0xffe5' length='22' field='APP5' value='HPQ-ImgGener'
tag='0xffe5' length='20' field='APP5' value='HPQ-DigiZoom'
tag='0xffe5' length='84' field='APP5' value='HPQ-MotionMd'
tag='0xffe5' length='32' field='APP5' value='HPQ-CalsMfg '
tag='0xffe5' length='65016' field='APP5' value='HPQ-CalsSec1'
tag='0xffe5' length='10016' field='APP5' value='HPQ-CalsSec2'
tag='0xffe5' length='8568' field='APP5' value='HPQ-LRGEBUFF'
tag='0xffe5' length='24' field='APP5' value='HPQ-MetaHint'
tag='0xffe5' length='12' field='APP5' length='12' value='pad pad pad '
That's right, every picture has over 95K of additional APP5 data after the picture! That is as much as 8% of the file size!
So far, I can only decode one of the fields: HPQ-Capture. This has 3-5 records (depending on the version) and the records identify your phone. Here's an example from a decoded block from a Motorola, Droid, 2.2:
field='Build Version' value='4719:5353'
field='Build Date' value='2010-06-14 15:15:45'
field='Builder Email' value='kraigp@itlbuild.fc.hp.com'
field='Build Name' value='SholesMR2_RC9'
field='Kernel Release' value='2.6.32.9-g103d848'
field='Kernel Version' value='#1 PREEMPT Wed May 26 18:02:03 PDT 2010'
The kernel information is the same as running "uname -r" and "uname -v" from a command prompt. The Build Version looks like a SVN string, but it could be some other source code revision system.
I sent an email to "kraigp" asking for more information about these undocumented fields, but got a bounced email:
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients was aborted after 34 second(s):
* kraigp@itlbuild.fc.hp.com
Different Android versions include different information. For example, the Motorola DROIDX 2.1-update1 says:
field='Build Version' value='5476'
field='Build Date' value='2010-06-24 16:02:09'
field='Builder Email' value='tanvir@tanvir-lnxdev'
field='Build Name' value='Shadow_RC7'
field='Kernel Release' value='2.6.29'
field='Kernel Version' value='#1 PREEMPT Thu Jul 1 18:18:04 CDT 2010'
All of these HPQ fields appear to be part of the HPAndroidHAL driver. Since only Motorola seems to use this driver, only Motorola photos get tagged. (If I'm wrong here, I hope someone will tell me. I'll be sure to make corrections.) It kind of makes sense that Hewlett-Packard would embed their stock symbol (HPQ) in the APP field...
Most of the HPQ records have fixed lengths. Some values don't change regardless of camera version. Some change between versions but not between cameras, some change with each photo (e.g., White balance and focus), and some seem to change between specific cameras. It is these last fields that seem interesting. Not only can I tell what camera took the picture, but I can tell you if two photos were taken by the exact same camera. Unfortunately, I don't know the meaning of these fields since the "changes between cameras" could be coincidental based on my minimal sample size.
The only variable-sized field seems to be the HPQ-LRGEBUFF record. It looks like some kind of fractional memory dump. (I really suspect debugging code that was not disabled before release.)
If you have an Android phone and want to know if your pictures have the HPQ tags, then try this:
- Take a photo. (Let's call it photo.jpg.)
- strings photo.jpg | grep HPQ-
If you don't see anything, then your pictures are clean. If you see HPQ strings, then your photos are tagged. Use 'hexedit photo.jpg' and search for "HPQ-". This will show you all of the HPQ records.
In any case, until we learn what "HPQ" is embedding in each photo taken by a Motorola Android, I'm going to stay on the paranoid side. If you happen to know how to decode the other fields, please let me know!
The End?
Smarter devices do not mean smarter users or smarter programmers. Unless you know how to disable every undesirable feature (and remember to disable it), you are probably going to leak information. While online anonymity isn't dead, it is getting harder and harder to protect our privacy.
Tuesday, July 13. 2010
You know that feeling you get when someone gives you advice that you don't care about at the time but turns out to be prophetic? I just had that experience...
Boxes
Even though my background includes a significant amount of experience with artificial intelligence algorithms, I rarely use AI systems in my day-to-day work. The reason has to do with repeatability and provability. The various types of neural networks are relatively easy to construct and train, but act as black-box systems. You know the input, you see the output, but you don't know how the system generated the output from the input. Moreover, if you train a neural network with different initial weights or a different order through the training set, then it will result in a different learned configuration.
While black-box AI systems may generate accurate results, the training process is NP-complete -- you don't know ahead of time how much training it will take or whether it can actually learn. Moreover, these systems can be very good at memorizing training sets. Don't over-train your black box unless you want it to memorize the training set and completely screw up on the testing set.
In contrast to neural networks, fuzzy logic and genetic algorithms are gray box systems. You kinda know how they work. Given the input, it generates output and you can see how it came up with the output decision. However, barring very simple fuzzy logic systems, you cannot really tell what the output will be until you run the input though the system. You can see how it made the decision, but not before running it.
Finally, there are white-box AI systems like Bayesian networks. You know the input, the output, and how it will make the decision. The only real problem here is configuring the system. Since you need to know the probabilities, you really only have two choices. You could compute the probabilities before hand, but this requires you to have enough data to statistically compute the probabilities and be able to characterize the various statistical factors. The other choice is to use a gray-box or black-box system to learn the probabilities, in which case the probabilities may not be provable or optimal.
Dusting Off
I recently had a need for "a solution", where "provable" and "deterministic" are not requirements. This is a perfect situation for using AI. I wrote my own AI library many years ago. Basically, I didn't like any of the existing systems (not flexible enough for my own needs) and it was easier to build my own than adapt around existing systems. However, it has been years since I used it and I only vaguely remember the configuration options.
A couple of things really surprised me. First, my AI library was written in 1990 and last maintained in 1996. (Last bug fix was in 1994.) I didn't even know if it would compile with the latest GCC. My first surprise was that it compiled cleanly with "gcc -Wall". It even passed its benchmark and regression tests.
As I gawked at the output, I thought, "This is great! I wish I remembered how it worked!" Then I looked at the source code... There are huge paragraphs that describe how every function works and how to use it. Completely documented. Even the variables have reasonable names: no "int i,j" or "float q[12]" or "double phi,theta". Instead the variables have names like 'CutoffThreshold' and 'float *weights; /* network weight matrix */'. The comments even cite books and pages as references.
Way Back When...
I had a professor back in college who drilled "style" into all of us. He had three basic rules that, if broken, would result in a zero on your homework.
- Always comment your code. If the code is more complex than a simple loop, then describe what it does.
- C permits 64-character variable names (well, it did back then). Variable names should be descriptive and not generic. Single letter variables (i, j, x, y) are only permitted for very short loops. Greek letters should never be used for variable names unless you are programming in Greece.
- Don't use features specific to a compiler or operating system. Stick with portable standards. If you must use something specific, encapsulate it so a replacement won't impact the rest of the code.
We obeyed because we wanted to pass the class. However, the lesson was never lost on me. I still "over-comment" my code.
I looked up my notes and found a great quote from the professor (from notes I took in 1988): "Always comment your code because you never know when you will refer to something you wrote 20 years earlier." Wow -- he even nailed the duration.
Saturday, July 10. 2010
Over the last few months I have had friends and associates contact me about hacked web sites. In each case, someone (or something) planted hostile URLs on their web pages. These URLs would redirect visitors to porn sites or serve up viruses. Worse: these URLs would be embedded everywhere -- in HTML, in PHP, and in back-end databases.
The question they always ask me: What should I do?
It is easy to tell people that they should have a disaster recovery plan in place. However, few people have one. Other pre-attack advice, like hardening servers, changing defaults, and installing filters is great advice, but is usually ignored. In my experience, the sites that have taken simple steps and have plans in place are not the ones usually compromised. The common compromises are directed at non-technical users who installed default software and ignored even basic maintenance.
Post-Compromise
So let's say you have a default WordPress or Wiki or Blogger installation. It isn't a question on whether your site will be compromised or infected. The only question is when. And like most people, you haven't maintained your software (applying patches, upgrading as needed), don't have backups (your ISP does that, uh, right?), and haven't removed default files or hardened the system. What should you do after a compromise?
There are plenty of good checklists out there. Some examples include:
While each of these sites gives good advice, there is no single consensus regarding appropriate steps. My own checklist is a little more detailed and extreme.
Neal's Post-Compromise Checklist
Nobody wants to have their site compromised. However, like auto accidents, bad things happen. If you were not paying attention (like texting while driving or not applying system patches) then bad things are more likely to happen to you.
Here are the steps that I usually recommend to people with compromised web sites:
- Stay calm. Only the WordPress checklist included this advice, but it is very valuable. Now is not the time to panic, place blame, or get angry. Compromises and exploits go hand in hand with technology. Don't panic, deal with it.
- Check your own systems for malware. There is no point in fixing the server if your own workstation is infected. It is actually very common for a home computer to be infected and used to gain access to your public blog or web server.
- Take the site offline. Most e-commerce companies really don't like this idea. However, which is more important? Making a sale, or compromising your customer's credit card and tarnishing your reputation because your site was hijacked? Shut it down. Put up a temporary "We're upgrading, back in 48 hours" message.
After you take your site offline, check to make sure it really is offline. Some attacks actually hijack your domain name (DNS entry) and not the server itself. If your site still looks online, has the DNS server been compromised? Your DNS registrar and/or domain hosting provider can usually help you in this situation.
- Make a full backup. This includes all files, scripts, and database records. Yes, it is infected. But if you don't have backups then this is your only option.
- Grab your logs. You will need these to identify how the attack was done, when it happened, and who else might have been infected. This includes system logs, web logs, and any other kind of log file. Grab it first and see if you need it later.
- Evaluate the compromise. What kind of attack was it? Were they after "a site" or "your site"? Was the attacker looking for low hanging fruit or was it personal? Most malware, like the kind that inserts links, are automated. They scan for known vulnerabilities and infect anyone they find. If you were compromised this way, then it is likely because you have a default configuration with a known vulnerability (known to the attacker).
Defacements may be automated or semi-automated. They scan for sites with known vulnerabilities and then they either automatically or manually deface the site.
E-Commerce theft is usually associated with an initial automated vulnerability scan. The scan is followed by a manual compromise that is customized for the site. However, if you use a very common e-commerce package, then the compromise may be semi or fully automated.
Personal attacks are always manual compromises.
It is important to recognize that automated attacks are almost never against custom code. They look for known vulnerabilities in default installations. If you change the defaults, move default files, or otherwise filter and harden the site, then automated attacks are very unlikely to succeed.
- Look for similar attacks. Are other people running the same software getting attacked? Perhaps you need a patch. Is it everyone on the same server or in the same hosting environment? Maybe someone should maintain the system. Is it all of your accounts? Perhaps your computer has a virus.
- Change passwords. Between taking the server offline and changing passwords, attackers will be kept out while you repair the system. (Hopefully.)
- Wipe the system. There is only one thing people hate more than being told to turn off an e-commerce site, and that's being told to wipe the system and reinstall from scratch. But seriously, the inserted URLs and malware may only be the part that you notice -- much more may have been done to the system. There could be backdoor software, trojans, or embedded viruses that cannot be removed by a simple system restore. By wiping and reinstalling, you ensure that all malware is gone.
- Patch. Bring the system up to the current state of the art. While you're at it, harden the system and change all system defaults.
- Restore. You do have backups from before the compromise, right? If not, then install basic software (like blogs and wikis) and harden them first. Then place custom software on the system. Finally, restore content. Be sure to validate that the content is not infected. You can do this by reviewing the content before uploading it. (What? Review your 10,000 blog entries? Yes. There is no point in removing the malware from the server if you're just going to upload it again.)
- Change passwords again. Passwords before the patch and restore could have been compromised.
- Watch. Now you can turn the system back on. If the attackers come back, then you didn't patch or restore something. (And now you have experience to recover much faster!) Watch your logs and IDS and try to determine how they exploited your site. If the logs show nothing, then you know which parts of your site were not responsible for the attack.
- Blame. This is everyone's favorite part. If you don't have logs, don't regularly patch or update, and don't maintain the system, then you cannot blame anyone except yourself. Security is a moving target -- software that was secure yesterday may not be secure today. Unless an administrator did something completely stupid, such as posting login credentials in a public forum or actively assisting the attacker, then there probably is nobody else to blame. Blame the management.
Too many times I have seen management blame developers or software for compromises. For example, if your old version of WordPress was the source of the compromise, then they will blame WordPress even when newer versions are available. (Let's blame the software instead of ourselves for failing to maintain and harden the systems.)
Having your site compromised isn't fun, but it isn't the end of the world either. Stay calm and address the problem. Treat it as you would any other learning experience.
Tuesday, June 15. 2010
Last week was entertaining. I had the opportunity to assist in an interesting project -- part development, part forensics, and part penetration testing. Fortunately for me, I had a couple of Firefox plugins that really made the work easier. All of these plugins can be found by using the Tools -> Add-Ons menu under the Firefox web browser, or by going to https://addons.mozilla.org/en-US/firefox/.
NoScript
The NoScript plugin is an absolute must-have. As far as I am concerned, it should be part of the default Firefox installation. This plugin stops all JavaScript, Flash, and other objects from automatically starting. You can also block access to some web servers, or if you really like a site, then you can add it to a white-list of permitted, trusted sites. If there happens to be something you want to run, you can permit it on a case-by-case basis.
From a user's viewpoint, this is awesome. You don't have to worry about an unknown site sending malware to your browser. In my case, I didn't want to download videos, Java, and other stuff that would waste my CPU cycles and bandwidth.
Httpfox
When evaluating any kind of web-based service, either as a developer or as an auditor, you need to know what is being transmitted across the network. Usually I use Wireshark or Snort. The problem is, these only work well if you use HTTP and not HTTPS. With HTTPS, you cannot see the traffic inside the tunnel (without compromising the tunnel).
Fortunately, I had Httpfox. This plugin is like having Wireshark in the browser! It shows you all data that the browser sends and receives -- the URLs, request and response headers, cookies, post data, and query parameters.
This plugin is great for auditing, but does have a few minor limitations. Specifically, if any of the values are longer than the visible fields, you don't get scroll bars. You can work around this by copying values to the clipboard, but that isn't an ideal solution.
Firebug
While Httpfox shows the network traffic, Firebug shows the HTML content. And this isn't just the HTML that was sent to your browser... it is the HTML that is displayed. If the web page includes JavaScript or active CSS content that alters the web page, then Firebug will show you the rendered values.
Besides viewing the page, you can also edit the currently-displayed web page. If you are testing parameters, playing with web forms, or trying out different style sheet settings, then this is a must-have.
Finally, you can click on the little arrow icon and it enables an inspector. As you hover the mouse over various elements on the web page, Firebug displays the active HTML elements (both HTML code and style sheet values). As a web developer, you've probably had times where you wondered "Where do I define that border?" Well, the inspector quickly answers this.
Add N Edit Cookies
This plugin is an oldie but goodie. Httpfox shows you queries, but does not allow you to edit. Firebug allows you to change the active HTML, so you can edit query parameters and URLs, but you cannot alter cookies. The "Add N Edit Cookies" plugin completes the set by allowing you to view and edit cookie values. (There are two versions of it. One is for older browsers and the other is for newer browsers.)
There are a couple of other plugins for editing cookies. However, I like this one because it is simple to use.
All Together
With these four plugins, we were able to easily access our web services, debug the network traffic, view and test dynamic web content, and even validate cookie settings. With NoScript, we were able to restrict the content that the server sent to the browser and control exactly when different calls were made.
In the old days, we would need to hack the SSL tunnel and use custom scripts to manage queries. Today, we can evaluate and modify the system in real-time and with just a few plugins.
Tuesday, May 11. 2010
No operating system is perfect. In my latest book, Ubuntu: Powerful Hacks and Customizations, I provide tips and tricks to enhance an already awesome operating system. (However not all hacks, like this one, made it into the book.) Some of these modifications add functionality to make the system better, while others are workarounds for common problems.
Watch Your Language
One such common problem is the built-in spell checker. With Dapper Drake (6.06 LTS) and Hardy Heron (8.04 LTS), the spell checker uses the default system language. If you installed using Australian English then it will use Australian English.
However, this isn't the case with later Ubuntu releases. If you are in the United States and use gedit, then you've probably noticed that the spell checker uses British English instead of American English. (For example, it thinks "color" is spelled "colour".) While you can change this using the Set Language option under the gedit Tools menu, changes are not retained when you open a new document.
This problem is actually much larger. Debian users have had this issue since at least 2004, but Ubuntu didn't incorporate this problem until 2008. Intrepid Ibex (8.10), Jaunty Jackalope (9.04), Karmic Koala (9.10), and the newest release -- Lucid Lynx (10.04) -- all have this spell checker problem.
He Who Spelt It...
The core problem actually isn't gedit. This simple notepad uses an open-source package called " enchant" for dictionary support. Enchant is a wrapper around a variety of back-end spell checker systems. The search list is found in /usr/share/enchant/enchant.ordering. The contents should look something like:
*:myspell,aspell,ispell
fi:voikko,ispell,myspell,aspell
fi_FI:voikko,ispell,myspell,aspell
he:hspell,myspell
he_IL:hspell,myspell
yi:uspell
This says that the Finnish language (fi) should use voikko as the primary spell checker first, then ispell, myspell, and aspell. If no specific language definition line is available, then it will default to the "*" entry: myspell then aspell then ispell.
And that's the problem. Myspell does not use the system-wide dictionary (see the man page section "Directories Important To Enchant"), so it ignores the default system language. In contrast, aspell does used the system-wide setting and it is installed by default on Ubuntu. Changing the enchant default to use aspell before myspell fixes the problem:
*:aspell,myspell,ispell
Alternately, you can leave the default and specify an alternate order for English:
*:myspell,aspell,ispell
en:aspell,myspell,ispell
en_US:aspell,myspell,ispell
Word Up
Finally, make sure that the language dialect is enabled on the system. For American English (en_US), use:
sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8
You might need to logout and login in order to refresh the language settings in your various running shells and applications. The locale-gen program can take a specific dialect (en_US or en_US.UTF8), base language (en for generating all English dialects), or no options to use the default base language. The set of installed languages is found under /usr/share/locale/.
This trick also works for other languages and dialects, including Canadian English (en_CA), Hong Kong English (en_HK), Korean (ko_KR.eucKR), Lithuanian (lt_LT.ISO-8859-13), and any other language on the system.
|
