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.
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.
Saturday, June 5. 2010
In my blog entry on random thoughts, I mentioned that Google plans to offer SSL for web searches (HTTPS instead of HTTP) and that SSL was a placebo. A couple of people asked for more information about my claim. The problem is, most criticisms about SSL don't cover everything. (And it would be egotistical for me to mention that all of these points are covered in my first book, Introduction to Network Security.)
Here's a quick summary of the problems with HTTP over SSL (aka HTTPS).
Strengths
Let me start by covering what SSL really does. Secure Socket Layer (SSL) is not a cryptographic algorithm. Instead, it is a framework. There are a wide variety of algorithms for data encryption (e.g., AES, DES, Triple-DES, Blowfish), encoding (8-bit, 256-bit, 64-byte), chaining (e.g., CBC), checksums (e.g., MD5 or SHA1), and key exchange systems (Diffie-Hellman, RSA, etc.).
These different algorithms can be combined. For example, ADH-AES256-SHA says to use an Anonymous Diffie-Hellman key exchange with 256-bit AES encryption and a SHA1 checksum. Since some combinations don't really make sense or are cryptographically weak, there are some pre-defined combinations. SSLv1 defines a set of combinations that work well, SSLv2, SSLv3, and TLS offer revisions to the "good enough" cipher sets. (And I'm not going down the weak SSL cipher options in this blog. Let the cipher punks argue the fine details.)
So what does SSL do? It provides a framework for an SSL client to negotiate ciphers with an SSL server. In effect, the client says "I support the following ciphers" and the server says "I'll choose this combination!" SSL also permits the client and server to renegotiate ciphers during the communications.
This is a huge strength for SSL; it allows clients and servers to negotiate algorithms and talk the same cryptographic language. However, like most tools, SSL can be applied incorrectly. And that's the problem with HTTP over SSL.
HTTPS
HTTPS uses certificates for authentication. Basically, there is a trusted third-party who can validate the certificate. The connection dialog looks like this:
- The web browser connects to the server using SSL.
- The server sends a server-side public certificate to the client.
- The client connects to the certificate authority and says "Yo! I got this server information. Is it valid and authentic?"
- The trusted third-party checks the data and sends back a yes or no.
If the challenge succeeds, then the rest of the SSL negotiation is performed (e.g., let's use RSA with AES256 and SHA1) and they start using the agreed ciphers for encoding the HTTP traffic. (The crypto is a little more significant, but this generalization gets the point across.)
There's a few problems with this system and they lead to the placebo effect.
SSL Hijacking and Client-Side Certs
After establishing the SSL connection, the network traffic is secure enough. You're not going to worry about someone taking over your session or seeing your data transfer.
However, the initial negotiation can be compromised. One example is the "man in the middle" attack (MitM). Your initial SSL connection is intercepted by a hostile system. (Rather than connecting to your bank, another server sees the request and responds before the bank can respond.) It issues the server challenge using a valid certificate. The third-party says "yes, its authentic" even though it is for a different server. Then, your browser is securely connected to the MitM and the MitM forwards all requests to the bank. In this attack, your traffic is encrypted... but the attacker is part of the encrypted path and can see everything!
Part of the server-side information is the name of the trusted third-party. Thus, the attacker can control both the server and the "trusted" party who does the authentication. Of course, why even need a third party? Some servers self-verify (I am the server AND you can trust me) -- that's bad because there is no "third-party" to trust.
Relying on the Human
The biggest problem with HTTPS comes from the web browser. Browsers don't just reject bad certificates. Instead, they prompt the user. (As if the user knows better...) Sample prompts include:
- Self-signed alert: The server is using a self-signed certificate. Accept? (Yes/No)
- Unknown certificate authority: The server has specified a trusted third-party server that the browser has never seen before. Accept? (Yes/No)
- Expired: The server's certificate has expired. Accept? (Yes/No)
- Failed: The server's certificate could not be validated. Accept anyway? (Yes/No)
With humans, we know what we want to do. You want to go to your bank. You want to visit that web site. You know that if you do not accept the bad/invalid/unauthenticated certificate, then your browser will block your access. So you accept it -- since that is the only way to continue. And by accepting, you are approving a no-security option.
For real security, the browser should reject the connection without prompting the user. I mean, seriously, if the server certificate is bad (invalid, unverifiable, or expired) then there is no way a human can safely say "use it anyway". An invalid certificate should generate an error, and the error should say that the server is not acceptable.
Little Locks
As if prompting the user was not bad enough, SSL connections are associated with a small picture of a lock (or key) in the web browser. This gives the impression that SSL is secure, when it really isn't. For example, one of the available ciphers is the "null" cipher -- it does not encrypt data. Even though the data is transmitted in plain text, you will still get the little lock... because the lock means "SSL" and not "secure".
There are also issues around when the lock appears. For example, "https://www.paypal.com/" links to a bunch of different servers (paypal.com, paypalobjects.com, ebaystatic.com, and paypal.112.2o7.net). However, clicking on Firefox's lock icon (bottom right corner) will only show you the details for the main web page's SSL connection and not for the connections to subsequent servers. Also, the little lock will only appear if the first/main URL uses https, even if the dependent links on the page use SSL.
Client-Side Certificates
The common HTTPS configuration only uses server-side certificates. This allows the client to authenticate the server (assuming you trust the third-party authentication server). However, this does not authenticate the client with the server.
The best security method uses server certificates to authenticate the server and server-assigned client-side certificates to authenticate the clients. Now, a MitM cannot intercept traffic because it cannot authenticate or validate the client-side certificate. This is a very secure method.
Unfortunately, (AFAIK) no online banks provide client-side certificates. This is probably because the browser's user interface makes client-side certificate installation difficult. Supporting these means a whole new level of Help Desk Hell.
Leaving the Tunnel
Assuming no MitM and a validated connection, SSL creates a secure tunnel for passing traffic between the web browser and server. This makes you safe, right? Well, yes... as long as the developers of the web site don't switch you from SSL to non-SSL. Unfortunately, this is very common. You may login to Yahoo! Mail using SSL, but pictures, ads, and text may still be sent to you from outside the SSL tunnel.
Here's a fun experiment for Firefox users: Connect to a site using SSL. View the page information (Tools -> Page Info). Does every URL used by this page begin with "https" and use the same server? Every instance of a non-SSL connection or a different server means that you could be passing information outside of the SSL tunnel.
Misunderstood Security
Between marketing, magazines, and bad online advice, regular users have learned to equate "SSL" with "Security". But seriously, where is the security in SSL? It's in the name: Secure Socket Layer. (Kind of like the confusion created by calling the web programming language "JavaScript" -- it isn't Java and isn't a script. Thank you marketing.) Remember: SSL is a framework for negotiating secure communications; it is not secure communications.
Unfortunately, regular users are under the impression that using SSL will stop their connections from being hijacked, safely transmit data, stop phishing, and prevent them from downloading viruses. The truth is, SSL without certificates can be easily hijacked, users may still transmit data in plain text, users may (and usually do) choose to bypass the available security, and SSL does nothing to block harmful sites. A server infected with a virus can easily pass the virus to browsers via HTTP or HTTPS -- but with HTTPS the virus will be transmitted more securely. (Yippee! Nobody hijacked your session that downloaded a virus!) Some phishing sites even use registered server-side certificates -- they can impersonate your bank and use SSL without a problem.
Why Bother?
These are not the only problems with SSL, but these are some of the big ones. With all of these issues, why do we even use SSL?
I refer to SSL as "better than nothing" security. It isn't ideal, does not mean you are safe, and does not stop malicious sites from sending you hostile information. (For servers, SSL also does not stop anyone from attacking your server.) However if you have no other option, then SSL is better than sending data in plain text. You may not know who received your data and may still be using a MitM, but at least other people won't be able to see your traffic. And frankly, until a better solution is developed and becomes widely adopted, SSL is the only realistic option right now.
Consider SSL to be on par with WEP security for wireless networks. WEP is easy to crack, uses a weak password, and is not the recommended solution. But, it is better than nothing.
Tuesday, May 25. 2010
There's a couple of random thoughts rumbling around my head... Rather than writing a blog entry on each, I decided to just mention them here.
Oiling The Machinery
Everyone is complaining about the oil gusher in the Gulf of Mexico. And everyone seems to have their own solutions. Use hair, use hay, construct a man-made barrier island, send down sludge, and more. British Petroleum has a couple of solutions lined up -- if one fails, then they will try the next. One of their solutions won't be ready until August! Some people think the government should take over the capping processes, but our government can't even pave roads without months of debate.
A few people are blaming Obama for this problem. (These are probably the same people who are upset that the Republicans lost the election and still watch Glenn Beck.) Frankly, we can't blame Obama for this one. Blame Bush? Sure -- he caused it by easing governmental regulatory oversight between 2006 and 2008. Obama only inherited this mess. And given other messes like Health Reform, Financial Reform, Immigration Reform, and Lobbying Reform... Regulatory Oversight Reform is just another item in the to-do list.
Anyway, I think I know the solution to quickly stopping the oil gusher. Congress should pass a resolution preventing BP from collecting any revenue until the gusher is capped and the cleanup is completed. Until both of those happen, any revenue received by BP should either go toward capping and cleanup, or be forfeited to the government and impacted states. If we cut off their revenue, then they will have an incentive for achieving a faster solution.
Google and SSL
Google recently released a beta of an SSL solution for their search engine. ( https://www.google.com) They claim that this will improve privacy:
This secured channel helps protect your search terms and your search results pages from being intercepted by a third party. This provides you with a more secure and private search experience.
There's a few problems here. First, SSL is a placebo. From a security perspective, it does not add very much security or privacy. To gain security and privacy, you really need SSL with client-side certificates -- but Google isn't offering that.
Second, I find it ironic that Google is offering a security and privacy solution. I mean, they store every search, associate searches with user accounts, and cache personal information. So for them to be concerned about search privacy is just... funny.
Summer's Here
Summer vacation has clearly started. The number of malware and attackers scanning my web site for vulnerabilities has increased 10x compared to last month. Looks like the k1dd13z are out of school.
The uptick includes a significant increase in scans for WordPress vulnerabilities. Sample initial scans look like this:
2010-05-03 11:10:10 | 72.46.136.130 | GET /wp-login.php
2010-05-09 17:43:28 | 188.40.73.239 | POST /wp-admin
2010-05-24 17:52:37 | 213.231.27.46 | GET /blog/wp-includes/js/tinymce/wp-mce-help.php
2010-05-24 17:52:40 | 213.231.27.46 | GET /blog/wp-admin/upgrade.php
2010-05-24 23:24:35 | 69.245.165.224 | GET /blog/wp-login.php
Of these scans, it is the tinymce one that bothers me the most. This is a WYSIWYG editor and it has a history of remote access vulnerabilities. If you don't need it, consider removing it or locking down your htaccess file and web pages.
Arizona State Lottery
Arizona recently passed Senate Bill 1070. The law basically says that people suspected of being illegal aliens will be asked to provide proof that they are permitted to be in the USA. Failure to provide proof can lead to incarceration and/or deportation.
I'm not going take a side on whether this law is racial profiling or justified. (Let's leave that debate to the pundits and citizens of Arizona.) Rather, I'm looking at this from the hacker point of view. The first US Citizen that is arrested and/or deported under this law will have a heck of a lawsuit. Most likely, the victim will receive an out-of-court settlement as an apology because the case won't have legs to stand on if a provable citizen goes to court. Anyway, this law should be called the Arizona State Lottery because you too can become a millionaire overnight!
Sunday, May 23. 2010
I'm always looking for security-oriented podcasts to listen to when I'm traveling. Some of the ones that I have found are pretty bad, while others are truly excellent.
2600
The 2600 radio show " Off The Hook" has been around since 1988. They have had episodes available for download as MP3 files since before "podcast" became a word. So one would think that, with over 20 years of experience, they would finally learn how to use the mixing board! For a technical forum, these jokers can barely make the phone lines work; every other podcast that I have heard has been cleaner and more professionally produced than this one.
Getting past the quality issues are the topics and advice. While they do discuss current topics related to security and privacy, they often take the viewpoint of someone intentionally doing something wrong. In some cases, they actively promote and advocate illegal activities. If you heed their advice and get caught, then you will probably end up in jail. (No wonder many of their letters to the editor published in 2600: The Hacker's Quarterly are from people in prison... and some of the hosts have felony convictions.)
I cannot recommend this show to anyone. It is an hour of your life that you will never get back. I give it two frownies: 
2600's Emmanuel Goldstein also has a show called " Off The Wall". It is basically a baseless rant and topic-less meander with really bad background music. Three frownies: . You'd be better off and more satisfied by spending an hour staring at a blank wall.
CyberSpeak
CyberSpeak is a semimonthly podcast hosted by Ovie Carroll (Director, Cybercrime Lab at U.S. Department of Justice Computer Crime and Intellectual Property Section) and Bret Padres (Director, Digital Forensics at Stroz Friedberg, LLC). One would think that, with their backgrounds in law enforcement, this would be a dry and boring podcast -- but one would be very wrong! The hosts are hysterical (they constantly crack each other up, and usually make me laugh out loud at least once per episode).
For topics, they cover recent issues in computer security, computer forensics, and privacy. Unlike 2600, Ovie and Bret never advocate illegal activities, but they do not always support laws and legal requirements. They are usually very critical in their evaluations of legal topics and usually see both sides of an issue.
This hour-long show contains discussions about current topics, reviews of new tools, lists of cool web sites, and interviews with people involved in the field. While they do evaluate tools and interview software developers, they don't actively push products.
This podcast is a must-follow for anyone interested in computer security, forensics, and privacy. I give this podcast my highest rating, three smilies: 
My only criticism: When he gets excited, Ovie shouts a lot. Be prepared to lose an eardrum if you wear headphones.
Crypto-Gram
Security guru Bruce Schneier has a monthly newsletter called the "Crypto-Gram". In it, he voices his opinion about various computer privacy related issues. The articles are actually a combination of his blog postings and mass media essays. While I don't always agree with him (I agree about 90% of the time), his arguments are well written and clearly presented. If you are looking for a speech and debate topic, he provides plenty of great starting points.
Unlike other podcasts, this one does not review technologies or dive into deep technical discussions. Instead, Schneier stays at the 1000-foot level, focusing on the forest and not the trees. You won't learn a new hack or how to apply a new program, but you will gain insight into the implications.
Shortly after his newsletter is published, the " Crypto-Gram Security Podcast" is updated. The podcast is someone other than Schneier reading the newsletter. The podcasts vary in length, but are usually 10-20 minutes long. If you only have a few minutes for something that will stimulate your brain, then this is a great choice.
Two smilies: 
Speaking of Security
RSA has a weekly podcast called " Speaking of Security". This podcast is short -- usually 10 minutes -- and includes sponsor advertisements. All of the interviews involve RSA partners and affiliates.
Having said that, the topics do give a good idea about available security oriented products and services. Of the product pushing podcasts, this is one of the better ones. One smiley:
PaulDotCom
There is a security podcast called " PaulDotCom Security Weekly". This podcast ranges from 45 minutes to 1.5 hours. But, it is almost all product placement, advertisements, and unrelated tangents. The banter between the hosts may be funny to them, but rarely even gets a smirk from me. Some episodes have over 10 minutes of nothing (ads, music, and tangents) before discussing anything security related.
In Episode 199, they mentioned not having any listener winners. Perhaps it is because they don't have any listeners... The technical coverage is mainly personal experience and comments like "and then I used the blah program to do blah" without details or context. One frownie:
This Week in Computer Hardware
The video podcast " This Week in Computer Hardware with Ryan Shrout" is not security focused. However, it discusses hardware and other issues that directly impact security, privacy, and forensics. The host is very knowledgeable, the discussions are focused and detailed, and the hour-long podcast is entertaining without the need for humorous tangents. Two smilies:
Other Podcasts
Computer security and forensics really require timely topics. Thus, I'm not reviewing podcasts like " The Security Roundtable" and " SploitCast" since they haven't released new episodes in years.
Are they other (free) security podcasts that are worth listening to? If you know of other security-related podcasts, let me know! I'll update this blog entry with the podcast name, your rating (from three frownies to three smilies) and your brief description of the podcast. Be sure to include a link to the podcast's feed!
Other Recommentations
David Garrard recommends the Australian podcast, " Risky Business". David didn't provide a description, so I just listened to two episodes. They cover technical topics with some depth (not enough to program by, but enough to get you started) and discuss current issues in security and privacy. It is like CyberSpeak, but without the funny banter and with an Australian accent. Three smilies:
Paul Wilkins, Keith, and King recommend " Security Now". Paul gave it two smileys , while Keith recommended two to three smilies. Keith included this excellent description:
I've not listened to any of the other podcasts you listed, so I can't compare to them. But I've found "Security Now" (http://twit.tv/sn, http://grc.com/sn, http://itunes.apple.com/us/podcast/security-now/id79016499) to be excellent. Each week, Steve Gibson and Leo Laporte review the week in security news, provide errata and updates to previous shows, and then spend alternate weeks either doing listener Q&A or covering some interesting topic (frequently not security related, but always interesting to geeks). I'd give it three smileys for what it is; some may give it two smileys because it's more consumer oriented and not NSA-level hard core. 1.5 - 2 hours, and always entertaining. Contains 2-3 product placement spots, but even those are entertaining, as Leo does them in his characteristic homey, Arthur Godfrey style.
King added:
Another vote for Security Now, it's a good overview of timely security information and chosen topics. Leo is a professional radio/tv guy from way back (as well as fairly techy) and Steve is deeply techy but can still talk to "regular" people. They make a good team, even when you already know the topic, they're entertaining.
I recently listened to the " Security Now" podcast and agree with Paul, Keith, and King. I give it a solid two smilies:
|
