Wednesday, September 30, 2015

Iron-Clad Java Book Blooper

About a year ago I helped some friends on a security book project, Iron-Clad Java: Building Security Web Applications (Amazon).  As we were winding down the project we received some early printed copies of the book from the publisher.  I remembered the feeling of seeing the project in printed form.  However, when I began flipping through the pages I noticed the Foreword was missing.  A missing foreword is not a big deal.  Still security is a really tough job for many of us.  I thought the foreword helped to call out some of the industry challenges while still keeping an encouraging message.  Following is the missing book foreword and our blooper.

***

The greatest challenge in product security today is the fact that security quality is difficult for consumers to evaluate.  A product with little security design consideration and a weak security posture discloses few, if any, outward signs of being insecure.  Software security, like performance and scalability, cannot be effectively evaluated visually and requires specialized tools and training.  In a vacuum, consumers often mistakenly assume strong positive product safety unless news surfaces to shake that confidence.  As a result, with ever increasing pressure on business leaders to be more competitive, deliver more value to customers, security is frequently marginalized in favor of delivering more direct features with tangible business value.  There’s little incentive to pursue security excellence when consumers assume it already exists.  All too often, businesses roll the dice and short product security, explaining away incidents when they occur with excuses like: “hackers are becoming more sophisticated”, “security is too difficult a problem to solve”, or “everyone has bugs”.  As the number and severity of security incidents increases, the public’s patience for excuses grows weary.   Consumers are demanding more secure information systems and more accountability from business leaders and governments.  Product security claims are no longer accepted at face value.  As we transition from an era of plausible deniability to accountability, leaders are increasingly motivated to deepen their security investments.  In the end, strong security is a choice, and it always has been.  Security excellence is no accident.  It’s purposeful, requires dedication, and role appropriate education is essential to success.

In this book, Jim Manico and August Detlefsen tackle security education from a technical perspective and bring their wealth of industry knowledge and experience to application designers.  A significant amount of thought was given to include the most useful and relevant security content for designers to defend their applications.  This is not a book about security theories, it’s the hard lessons learned from those who have been exploited, turned into actionable items for application designers, and condensed into print.

One of the best things I enjoy about the field of security is that it’s small and still possible to reach out and touch your heroes.  Jim and August are my heroes and it’s an honor and privilege to be their technical editor on this project.  The hallmarks of true experts and expert teams are: confident but soft-spoken, good listeners, secure in their abilities and not afraid to explore the ideas of others.   Teams imbuing such qualities produce results like no other and working in this environment is educational for everyone.  Working on this project with Jim and August was a tremendous privilege.  It’s my sincerest hope you enjoy this book as much as we enjoyed bringing it to you. 

Milton Smith

***

I happened to think of posting the book blooper since I noticed the Kindle Edition of the book includes the foreword and it's the books one year anniversary - Happy Birthday!  Congratulations Jim, August, Kevin, and crew.

HTTPS Party at Blogspot

Today Google announced[1] limited HTTPS support for Blogspot.  HTTPS support is critical for banking and other areas where online trust is required.  HTTPS is also important for viewing web site content to ensure it's authentic and free from tampering.  Without HTTPS support, web site content is easily modified in transit.  Google explains their decision to offer HTTPS support is based on their HTTPS Everywhere[video] strategy.  HTTPS is not enabled by default but can be enabled via configuration by the site Administrator.   Custom domains like securitycurmudgeon.com are not supported via HTTPS on Blogspot.  Google notes, "blogs with custom domains are not supported in this first version" and implies Blogspot will offer HTTPS support for custom domains sometime in the future.  More than likely Blogspot users will be able to load a custom certificate generated popular Certificate Authority's in the future.  This small improvement is a really big deal for many bloggers!  +1 Google security team!

[1] HTTPS support coming to Blogspot

* Image: Blogger configuration settings.  New HTTPS Settings option.

Tuesday, September 22, 2015

The Case of the Symantec's Mysterious Digital Certificates

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 google.com and www.google.com.  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, https://openclipart.org/detail/213115/blindfolded-woman-arrows

Saturday, September 19, 2015

Livermore Flying Electrons RC Swap Meet

I 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.

Friday, September 18, 2015

LinkedIn API's Hold Members Hostage

I think it's great that LinkedIn prompts members using LinkedIn API enabled applications about the type of information requested.  This is the minimum amount of transparency all cloud applications should present to their users but what information is included in a connection?  Sure, "1st and 2nd degree connections"  but what does that mean?  Only a members relationship to another member?  Or the connection relationship along with other profile information?  Asking a LinkedIn member to share profile information for another is like asking my Mom if it's ok for me to come out and play.  It should be each members choice what they want to share about their profile.  I'm open with my information but some are very private and connect only to their closest colleagues.  An easy area of future improvement is to clean up the connection sharing description to users.  A future suggestion, if the type of information can't be clearly communicated to members don't do it.

Another area of improvement in this message dialog is provide members some options about the type of information they are willing to share.  Today the choice is all or nothing.  Members can choose to "Allow access" or not use the application.  Essentially many applications hold you hostage on this screen.  You either hand over all your member data or you don't get access the application.  My concern is that often applications request much more information than the application requires.  I'm not against software developers asking but the user should have some choices.  If LinkedIn is concerned about their members privacy they should provide a checkbox next to each type of information requested.  This allows members to turn off information they don't want to share (like personal connections) while sharing other types of information.


Wednesday, September 16, 2015

Creepy World of Radio Numbers Stations


Radio Numbers Stations are clandestine radio stations operating over shortwave radio by government agencies.  The mysteriousness is due to the cryptic and unintelligible messages transmitted, a stream of numbers, and the lack of information around the intended destination.  Sometimes a man or woman may speak the numbers, sometimes the speech is synthesized, and sometimes there's data but always the destination and message is unknown.  With the advent of the Internet these stations may seem a throwback to a more primitive era; however, there are distinct benefits to this old technology.  First, shortwave signals carry a great distance.  





This makes the transmitters difficult to locate without use of radio signal direction finding(DF) gear.  A more important point is that the intended recipient of the message is untraceable since it can be anyone within the radius of the transmission - usually thousands of square miles/kilometers.  Anonymity in the age of the Internet is next to impossible so numbers stations protecting identities of intelligence agents in the field is important.  And last, the messages are encrypted or rendered otherwise unintelligible.  To listen to some real numbers stations check out the priyom.org web site.  Also check out The Numbers Station Movie Trailer.  I doubt numbers stations are so action packed in real-life but the movie is entertaining.



Thursday, September 10, 2015

ZMR250 Quad Racing Drone Build Log


Updated on January 13, 2016

THIS ARTICLE HAS MOVED...
Now being maintained on a dedicated site.

Thursday, September 3, 2015

OWASP Board Candidate Interviews Live!

Listen as Mark Miller (Twitter: @TSWAlliance) interviews me and other OWASP board candidates.  Now live! [AUDIO]

For more information about OWASP Global Board of Directors and the OWASP and the election process.
OWASP Board Candidate Interview on August 25, 2015
OWASP 2015 Global Board of Directors Candidate
2015 Global Board of Directors Election

Share It!