This past weekend I attended ShmooCon. Depending who you talk to, it is a white hat style conference. I suspect, as with any gathering of 1800 computer security people, you may end up with some black hats and some greys but generally speaking the sessions and discussions that I attended were white hat oriented. It was a good couple of days. For personal reasons I could only be there Friday and Saturday but even that short period of time generated lots of ideas.
Two ideas that stuck with me, even after thinking about them some more, are consumer oriented security thoughts. The first is the idea that not all Certificate Authorities (CAs) are created, or operated, equally. I think this is clearly evident in the issues we have seen with some over the last few years where we have had breaches of administrative accounts either due to the back end implementation or due to poor implementation/operations of user administrative accounts (aka Registration Authorities, RAs).
There are many CAs that are out the that are well operated and that are diligent with external audits and security reviews. These CAs implement policies that are at least as strong as the level of assurance that they deliver to their end customers and these policies are shown to be implemented properly through their external reviews. These CAs are listed in the same security store as other CAs that appear to not have the same level of policies, operations control or external review. In any browser, an Entrust or Verisign CA is treated the same as a DigiNotar, or at least they were before the DigiNotar breach. Is that beneficial to the consumer? There has to be a way to grade these CAs, outside of the EV versus standard certificate ideas. I am thinking something ala the FISMA grading mechanisms used in the US Federal government. In the FISMA grading system agencies are penalized for gaps, the bigger the gap in the operations versus policy, the bigger the hit. The grading then looks like the Green, Yellow, Red rating system. If this style of system was implemented in conjunction with Browser vendors the browser could allow a user to define a tolerance level - I will accept yellow and greens without warning, unless there is another issue, and I want to see warnings for red or block red all together. The variations between the levels could be worked through the CA Browser Forum and the determination of what triggers a downgrade or what is needed to bump a CA level back up.
The other thought is in a similar vein. Today when I authorize app access, whether on my phone or through some form of account connect, think Facebook Connect as an example, I see what the application is accessing and in some scenarios I have the option to be selective on if I want the application to have all the privileges it is asking for. For example - do I want the app to post on my Facebook Wall? Or, Do I want the app to have default access to my GPS location? This sort of flexibility may be lost on some but I do appreciate it as I often wonder why an app requires certain access. Now grant it, not all application platforms provide this flexibility but I see more and more doing this. What is interesting is when I access a website with Java code I do not get the same level of control. I can decide to only trust signed code but given the issue I described above is that enough? Do I want my code signed by a CA that I would not normally trust? Since Windows update dumps the full Root trust list to me and I have to manually go through and clean it there seems to be an opportunity here to do some better refinement. Again this would require browser cooperation but the end result could be powerful.
So the idea is two fold: "encourage" app developers to identify, in a standards way, likely in Metadata, the permissions that the app requires. With this definition lets give the user the option of choosing how to operate. Again the browser vendors could default settings but give the user the option of choosing whether he wants to see the data and how they want to react to the data. Settings to allow "application operations for JAVA" for example. If the code has permissions meta data then display that and let the user choose. If not then notify the user of the CA level (see above) that signed the data and make them aware of risk.
I am the first one to realize that the weakness in most of transactions is the end user but I believe that these types of implementations would increase awareness as they are already seeing elements of these in other areas. Of course this will require cooperation between developers and browser companies to implement and likely not a tomorrow thing but I believe something that should be thought about in a broader forum.
Monday, January 30, 2012
Tuesday, January 17, 2012
Sykipot Update
As I mentioned in my last post - one of my concerns was the possibility that a hacker could leverage the PIN access and the card update capability of the ActivClient to introduce malware on the card. After some investigation it appears that with the use of the Global Platform implementation it would be an extremely complex feat to execute. I do not believe it is impossible but the level of effort does not appear to have been taken and it would only be capable of happening during an actual card update which in most cases would be CMS initiated. There does not appear to be anything the data that has been released to indicate that there is a trigger for the action - so maybe one less concern.
Friday, January 13, 2012
Is this Sykipot something new?
Undoubtedly you have all seen the news of the alleged attack via Sykipot against US government smartcards. Of course the press has taken ahold of this with all of its usual gusto but is this really something new?
Well yes there are new elements to it - it appears to be the first Sykipot variant that appears to have specifically targeted a specific client and middleware to access smartcards for the purpose of utilizing the private keys for access to data. That being said the actually attack vector is not new and has been looked at for many years. This attack has the same sort of path as any man-in-the-browser style attack - deliver command and control elements to the target; install a key logger to capture and; once having determined that the target is viable then deliver the elements necessary to execute a complete attack. The major issue here is that fundamentally this was once again initiated through spear-phishing to deliver the required infrastructure to build the attack and possibly leverage it.
We are once again facing a massive push against a technology that fundamentally is not at fault here. If we look back at some of the attacks like this that occurred last year - it was not the technology but the implementation and the processes around the technology that are being leveraged to attack. It fundamentally did not matter what the underlying technology was. This Sykipot attack, ten years ago, would have been a key logger capturing userid and passwords, and just as likely could have been that today for many systems. However because it is smartcards it is now big news.
So is there really an issue - well quite possibly yes - and it could be big. Yes it is a problem that the card can be used when inserted without the user knowing it is being used - this is of course a major issue. There is however a potentially larger issue and the outcome of the investigations will determine if it is a real issue or not. The ActivClient does have a variant that is deployed to allow the local user to update their card. If in fact this Sykipot variant is hijacking the interaction with the ActivClient is it possible that the card can then be infected with malware? The threat of malware on the card is likely the worse case scenario. I know of no virus software that scans cards on insertion and it could be possible that this malware could be transmitted to devices via the contact and contact-less interface which would mean delivery to many platforms, possibly without knowledge. Of course right now this is speculation but hopefully one of the paths that is being investigated.
It will be interesting to see what comes out of the investigations and what gets publicized. For this interested in getting a base set of info on the attack check out the Alienvault article.
- Posted using BlogPress from my iPad
Well yes there are new elements to it - it appears to be the first Sykipot variant that appears to have specifically targeted a specific client and middleware to access smartcards for the purpose of utilizing the private keys for access to data. That being said the actually attack vector is not new and has been looked at for many years. This attack has the same sort of path as any man-in-the-browser style attack - deliver command and control elements to the target; install a key logger to capture and; once having determined that the target is viable then deliver the elements necessary to execute a complete attack. The major issue here is that fundamentally this was once again initiated through spear-phishing to deliver the required infrastructure to build the attack and possibly leverage it.
We are once again facing a massive push against a technology that fundamentally is not at fault here. If we look back at some of the attacks like this that occurred last year - it was not the technology but the implementation and the processes around the technology that are being leveraged to attack. It fundamentally did not matter what the underlying technology was. This Sykipot attack, ten years ago, would have been a key logger capturing userid and passwords, and just as likely could have been that today for many systems. However because it is smartcards it is now big news.
So is there really an issue - well quite possibly yes - and it could be big. Yes it is a problem that the card can be used when inserted without the user knowing it is being used - this is of course a major issue. There is however a potentially larger issue and the outcome of the investigations will determine if it is a real issue or not. The ActivClient does have a variant that is deployed to allow the local user to update their card. If in fact this Sykipot variant is hijacking the interaction with the ActivClient is it possible that the card can then be infected with malware? The threat of malware on the card is likely the worse case scenario. I know of no virus software that scans cards on insertion and it could be possible that this malware could be transmitted to devices via the contact and contact-less interface which would mean delivery to many platforms, possibly without knowledge. Of course right now this is speculation but hopefully one of the paths that is being investigated.
It will be interesting to see what comes out of the investigations and what gets publicized. For this interested in getting a base set of info on the attack check out the Alienvault article.
- Posted using BlogPress from my iPad
Wednesday, January 4, 2012
FINALLY!
I am not sure if anyone has noticed but the tag-line "Posted using BlogPress from my iPad" has been missing from posts for the last couple of months. In fact the reason for that is also part of the reason why there has been limited posting on tridentityideas over the last couple of months. The issue has been BlogPress on my iPad has not worked effectively (or at all) since upgrading to IOS 5 until an app upgrade today.
I am thankful that it is back but the next time I have to go months without access to an app will likely mean I will be changing my blog site. Hopefully that does not happen as mobile blogging is when I do most of my writing.
I guess the new update and renewed access mean that I can now officially kick off the new year with some more serious work on my blogs.
- Posted using BlogPress from my iPad
Subscribe to:
Posts (Atom)