IMG_2718.JPGA year or so ago, I was having some success with the Raspberry Pi micro-controller and I was thinking of a cool robot project I could do with the kids.  Of course, I love aircraft so what better robot to build than one that could fly?  This began a year long project of building and learning to be a pilot.  Along the way, this project turned more into a hobby and has probably pushed beyond the interests of many security readers.  My work in this area is probably not appropriate for a security web site.  Also the community interested in building and fly these aircraft are likely not interested in security.

To better respect the attention and interests of both security and multi-rotor builders/pilots I am moving some of my multi-rotor articles and future updates to my new web site, 

Any articles related to the security of multi-rotor aircraft like radio protocols or flight control software will be covered on the security site.  All future builds, configuration, video, etc will be on

I generally don’t comment much on privacy these days.  Why?  I’m equipped to fight security but privacy, sigh, FB-Camera-Roll.pngthat’s an entirely different battle.  However, I’m making an exception since Facebook’s new feature is a hot mess from a personal privacy perspective.  The new mobile application feature presents your private camera roll photos to you for, I presume, easy publishing.  There are a number of points that concern me.

1) Unauthorized processing of mobile camera roll.  Let me explain, I did provide Facebook authorization to my camera roll but that was so I could select and upload the individual photos I choose for publishing.  Processing the entire camera roll and offering up private photos without end-user consent is begging for an accident.  The application could have a bug or the end-user could click the wrong button.  People take a lot of photos and there’s no good reason to assume they want recent photos published.

2) Mixing private photos with public photos.  Facebook provides a lock icon and notes only I can see my private photos.  This is terrible design!  Your private photos are a heartbeat from accidental publishing.  It’s already easy to publish photos from your camera role using Facebook’s mobile application.  Whatever the reason for the new feature, it provides Facebook an opportunity to data mine private offline camera rolls.  We need Apple to create better sandboxes for personal data and how applications can use personal data.  We also need all operating systems vendors to provide better controls to increase transparency into applications running on their operating systems and platforms.  The all or none approach to our personal data (e.g., camera roll, contacts, etc) is no longer good enough.  We need to design our application environments from the perspective that every application is hostile.

3) Increased potential for data leakage and exfiltration.  We have no idea how Facebook’s mobile application works.  It’s possible it could be holding images, reprocessed thumbnails, or similar in private caches.  Any vulnerabilities in the application (and every application has them) could lead to data leakage and exfiltration.  Without access to the closed source and testing we don’t know if a vulnerability exists.  All we know for sure is that the risk of data leakage and exfiltration is greater with more data within the applications tendrils.

4) Abused trust of Facebook’s end-user community.  Software vendors wield tremendous power.  In running their applications on our systems we place our sensitive personal information under their care.  Most assume mobile application vendors handle personal information with care and more or less in accordance with end-user expectations.  There is no basis of fact for this belief.  End-users have been lead to believe they must give up personal information for continued use of free software.  Perhaps end-users need to give up something but there should be much more transparency around how our information is used.  Free software is no justification for betraying public trust.

I don’t keep much in the way of private information on my mobile but it’s a matter of principle.  Facebook continually surprises me, and I’m betting others, around how it uses personal information.  I’m seriously considering deleting all my Facebook mobile applications until the privacy climate improves.  I will continue to use Facebook but, only through the web browser, and only where I can tightly control the diet of personal information I feed to the beast.

Warcraft movie trailer for those interested.  Movies, games, beer, and pizza, brain fuel for application security professionals.

Updated on June 21, 2016

On Friday September 18, 2015 both Symantec and Google announced an incident with digital certificates used to secure web sites in browsers.  In Chrome a secure connection is indicated by the green lock next to the URL in the browser.  Symantec noted in it’s official post that a “small number of test certificates were inappropriately issued” for three domains during testing.  No mention of the domain names were provided.  The company explains that the certificates were issued outside of company policy by employees for testing.  When the company learned about the policy violation, the employees were terminated, and the certificates were revoked.

In a separate blog post by Google on the same day, we learn the domains in question were and  There is no mention of the third domain.  We also learn the certificates were Extended Validation(EV) type digital certificates.  EV certificates are special since they convey the highest level of trust in a users web browsing experience.  Google notes that the certificates were, “…recorded in both Google-operated and DigiCert-operated [certificate transparency] logs” on Monday September 14, 2015 at 19:20 GMT.  Symantec maintains, “…certificates and keys were always within our control…”  It’s difficult to know what Symantec means by control.  Clearly Symantec’s information systems did not provide adequate security controls to enforce it’s own corporate policies when issuing EV digital certificates.  Symantec reassures the public this time they will, “…place additional processes and technical controls to eliminate the possibility of human error.”  Symantec provides no details about processes and controls leading to the incident or how their new improvements will address security concerns moving forward.  No dumps of the certificates were provided, no digital fingerprints, etc.  Readers cannot verify or check any revocation information to ensure certificates have been properly black listed.  The article provides no verifiable facts for the public.

Symantec refers to the Google digital certificates as “test” certificates.  Google, calls the same certificates, “pre-certificate was neither requested nor authorized by Google.”  In other words, these are EV digital certificates generated on behalf of Google by Symantec, for domains owned by Google, without Google’s permission and used for unauthorized testing.  Isn’t a certificate that’s not requested or authorized by the subject for a domain owned by the subject also known as a – forged certificate?  So what is the difference between a “test” certificate, a “pre-certificate”, and a forged certificate?  I’m not sure.  Certainly the message to the public is softened.  The best course of action for such a serious breach of confidence is a complete disclosure of the event.  Symantec should provide a narrative, a timeline, and complete set of facts so the public verify all statements made independently.  Unfortunately there is no public evidence to support any statements made by Symantec about how they used Google’s certificates.  Trust but verify is one of the basic tenants of security.  In this case we can only trust Symantec but not verify.

The weakness with digital certificates is that the system is predicated largely based upon trust.  CA’s are free to issue certificates for any domain.  For example, if Google normally works with Thawte (a Symantec brand) for issuing certificates for their domains, Verisign or any other CA, can issue a certificate for Google as well.  Nothing prevents other CA’s with roots within Chrome from issuing a certificate for a Google domain or any other domain.  Google notes they developed a Certificate Transparency(CT) measure to address these concerns.  The CT extensions and log servers are new to me so I need to read up on them.  I don’t see a lot of good tools to dump out CT logs.  I need to investigate CT, CT logs, and related tools further.  Maybe I should consider adding CT support to my DeepViolet pet project.  CT has the potential to spot problems during certificate issuance whereas Chrome Certificate Pinning can spot certificate problems at runtime, both CT and pinning work together.  The good news, in spite of the weaknesses, forged certificates are fairly rare in the public.

Additional Resources
No root for you!  Google slams door on Symantec certs
Fuming Google tears Symantec a new one over rogue SSL certs
Proactive measures in digital certificate security

Image: Open Clipart,

IMG_2593.JPGI have been experimenting with building racing drones and (First Person View)FPV gear.  Today I was at the swap meet of the Livermore Flying Electrons RC club with my brother-in-law.  I found a huge deal.  I bought a 90mm Taft Hobby Viper EDF jet and desktop LiPo charger for really low price.  I’m more into multi-rotors but it was too good of a deal to turn away.

Viper Jet in action (VIDEO).   Note, not me flying.

I was thinking a fixed wing aircraft for FPV would be a cool addition.  Although before I fly this jet I’m going to spend some time on a low-cost trainer.  Flying fixed wings are totally different than flying multi-rotors.  One of the great points about fixed wing is that they stay up in the air a long time compared to multi-rotor.  You can really do some long distance FPV on a fixed wing.  Switch to a ground station for your video feed and upgrade your transmitter to UHF and you ready fly missions out to about 50mi (80km).  My new jet is probably not the best FPV platform but it will get me wherever I want to go fast.

By the way, if anyone has resources on security research related to RC please send my way.  I have been looking at different flight controllers, transmitters, ESC’s, and the all the open source software available.  I could also use any information related to radio transmission protocols for popular transmitters.