An investigation into a security slip that left the identity information for over 170,000 users of a US federal government program publicly available online has led to accusations of hacking and legal threats.…
Iain Thomson
This 127-page report was just published by the UK Defence Academy. I have not read it yet, but it looks really interesting.
Executive Summary: This report presents a systematic way of thinking about cyberpower and its use by a variety of global players. The urgency of addressing cyberpower in this way is a consequence of the very high value of the Internet and the hazards of its current militarization.Cyberpower and cyber security are conceptualized as a 'Global Game ' with a novel 'Cyber Gameboard ' consisting of a nine-cell grid. The horizontal direction on the grid is divided into three columns representing aspects of information (i.e. cyber): connection, computation and cognition. The vertical direction on the grid is divided into three rows representing types of power: coercion, co-option, and cooperation. The nine cells of the grid represent all the possible combinations of power and information, that is, forms of cyberpower.
The Cyber Gameboard itself is also an abstract representation of the surface of cyberspace, or C-space as defined in this report. C-space is understood as a networked medium capable of conveying various combinations of power and information to produce effects in physical or 'flow space ,' referred to as F-space in this report. Game play is understood as the projection via C-space of a cyberpower capability existing in any one cell of the gameboard to produce an effect in F-space vis-a-vis another player in any other cell of the gameboard. By default, the Cyber Game is played either actively or passively by all those using network connected computers. The players include states, businesses, NGOs, individuals, non-state political groups, and organized crime, among others. Each player is seen as having a certain level of cyberpower when its capability in each cell is summed across the whole board. In general states have the most cyberpower.
The possible future path of the game is depicted by two scenarios, N-topia and N-crash. These are the stakes for which the Cyber Game is played. N-topia represents the upside potential of the game, in which the full value of a globally connected knowledge society is realized. N-crash represents the downside potential, in which militarization and fragmentation of the Internet cause its value to be substantially destroyed. Which scenario eventuates will be determined largely by the overall pattern of play of the Cyber Game.
States have a high level of responsibility for determining the outcome. The current pattern of play is beginning to resemble traditional state-on-state geopolitical conflict. This puts the civil Internet at risk, and civilian cyber players are already getting caught in the crossfire. As long as the civil Internet remains undefended and easily permeable to cyber attack it will be hard to achieve the N-topia scenario.
Defending the civil Internet in depth, and hardening it by re-architecting will allow its full social and economic value to be realized but will restrict the potential for espionage and surveillance by states. This trade-off is net positive and in accordance with the espoused values of Western-style democracies. It does however call for leadership based on enlightened self-interest by state players.
schneier
For a while now, I have been thinking about what civil disobedience looks like in the Internet Age. Certainly DDOS attacks, and politically motivated hacking in general, is a part of that. This is one of the reasons I found Molly Sauter's recent thesis, "Distributed Denial of Service Actions and the Challenge of Civil Disobedience on the Internet," so interesting:
Abstract: This thesis examines the history, development, theory, and practice of distributed denial of service actions as a tactic of political activism. DDOS actions have been used in online political activism since the early 1990s, though the tactic has recently attracted significant public attention with the actions of Anonymous and Operation Payback in December 2010. Guiding this work is the overarching question of how civil disobedience and disruptive activism can be practiced in the current online space. The internet acts as a vital arena of communication, self expression, and interpersonal organizing. When there is a message to convey, words to get out, people to organize, many will turn to the internet as the zone of that activity. Online, people sign petitions, investigate stories and rumors, amplify links and videos, donate money, and show their support for causes in a variety of ways. But as familiar and widely accepted activist tools -- petitions, fundraisers, mass letter-writing, call-in campaigns and others -- find equivalent practices in the online space, is there also room for the tactics of disruption and civil disobedience that are equally familiar from the realm of street marches, occupations, and sit-ins? This thesis grounds activist DDOS historically, focusing on early deployments of the tactic as well as modern instances to trace its development over time, both in theory and in practice. Through that examination, as well as tool design and development, participant identity, and state and corporate responses, this thesis presents an account of the development and current state of activist DDOS actions. It ends by presenting an analytical framework for the analysis of activist DDOS actions.One of the problems with the legal system is that it doesn't make any differentiation between civil disobedience and "normal" criminal activity on the Internet, though it does in the real world.
schneier
As part of the OWASP EU Tour 2013, there will be a special event in London next month, along the lines of the recent ones in Cambridge and Leicester.
The one day conference is being held in central London on Monday 3rd of June 2013 at the Lion Court Conference Centre, 25 Procter Street, Holborn, London, WC1V 6NY. The nearest tube station is Holborn. It is free to attend and is open to all, but registration is required as numbers are limited to 100.
The agenda is still being finalised, but OWASP Ireland chapter leader Fabio Cerullo is presenting PCIDSS for developers, OWASP Cambridge chapter leader Steven van der Baan will be talking about simple steps for secure coding, and OWASP London chapter leader Justin Clarke will be speaking about securing development with PMD, the popular Java code scanning tool. I will be introducing and demonstrating OWASP Cornucopia. A very developer-orientated agenda so far.
The EU Tour continues to OWASP chapters in Barcelona, Bucharest, Belgium, Denmark, Dublin, Lisbon, Netherlands and Rome. Other locations will be added in due course.
(author unknown)
Multiple vulnerabilities have been discovered in both File Lite and File Pro, two file management applications created by Perception Systems for iOS, currently available on Apple’s App Store.
Researchers at Vulnerability Laboratory found the bugs on the latest builds of File Lite and File Pro – released on May 17 and May 14 respectively.
Both apps afford attackers the ability to upload files to another user’s account without their permission, while two others allow code injection in the user’s browser while they view a file listing, according to AOL’s Apple blog TUAW, which wrote about the issues today.
Both of the vulnerabilities rely on the user browsing files on the device via its WiFi setting, so anyone who uses the apps may want avoid doing that until the company issues another fix.
Email requests for comment sent to Perception Systems were not immediately returned on Monday, yet the version update history for the applications in question are patched every several months.
Here’s an often held conversation between concerned website user and site owner:
User: “Hey mate, your website isn’t using SSL when I enter my password, what gives?!”
Owner: “Ah, but it posts to HTTPS so your password is secure! We take security seriously. Our measures are robust.” (and other random, unquantifiable claims)
Loading login forms over HTTP renders any downstream transport layer security almost entirely useless. Rather than just tell you what’s wrong with this, let me show precisely why this is with a site that implements this pattern:
How’s that for simple?! What people forget about SSL is that it’s not about encryption. Well that’s one feature of secure sockets, another really essential one is integrity insofar as it gives us confidence that the website content hasn’t been manipulated. Anything you load over an HTTP connection can be easily changed by a man in the middle which is why it’s absolutely essential to load those login forms over a secure connection. OWASP is very specific about this in part 9 of their Top 10 web application security risks and summarise it well in the transport layer protection cheat sheet:
The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location.
It’s not just Woolworths doing this, in fact it’s extremely common and you’ll see it on GoDaddy:
On Pandora:
And even on the Financial Times:
I’m calling out these simply because they’re high-profile sites yet they all load the login forms over HTTP and post to HTTPS. Why aren’t they implementing SSL correctly? Most likely convenience; customers can login direct from the homepage and they can have it delivered over HTTP. Mind you Pandora links off to a login page so why they couldn’t just serve that securely to begin with is a bit of a mystery.
So how should it be done? Load the login form over HTTPS, either by linking to a dedicated login page or popping it up in a separate window (although there’s a UX argument against this). Even better, just load the whole site over HTTPS! Yes, there are some barriers to HTTPS across the board (managing certs in web farms, dependencies on assets from third parties, impact on CDNs, etc) but it sure solves the login form issue. Check out Netflix’s approach – straight into HTTPS, job done!
The other issue with the examples above is that potential manipulation of the content aside, missing HTTPS on the login form leads to exactly the discussion this post opened with – users not believing their credentials are protected. All the messaging we’ve been delivering to website users since the early days of the web about checking for the padlock in the browser address bar goes down the drain because it’s simply not there! There’s no assurance that their credentials will be protected and it’s a real shame to dilute such an important security message.
As for how the exploit in the video works, it’s just a simple Fiddler script to inject the keylogger before the body tag closes off. The keylogger itself is over on Google Code, the only code I wrote to incorporate it was the script tags you saw at the end of the video and the “Hack Yourself” website which receives the logged keys. It really is that simple.
Whilst Fiddler is good for demonstration purposes, clearly an actual weaponised attack would work differently but the principle is the same: When unencrypted traffic passes through a node on the network – NIC, ethernet cable, router, proxy, ISP, etc. – it may be observed or manipulated by an attacker. This isn’t theoretical, there are many precedents such as the Tunisian government harvesting Facebook credentials en mass.
This is all a bit odd really, I mean these sites have gone to the effort of implementing some SSL but then blown it by loading those login forms over HTTP. As we saw with Woolworths, posting over a secure connection is completely useless if there’s no integrity in the login form itself, an attacker may already have the credentials by then if the connection is compromised which is the very risk they all implemented SSL to protect from in the first place!
Cornucopia Ecommerce Website Edition v1.00 was uploaded to the OWASP website in February and has now been upgraded to a full OWASP project.
Today, I have completed the new OWASP Cornucopia Project pages which include:
Please let me know if you think I can add anything of use to the project pages.
I am also working on some minor updates to the ecommerce website edition's documentation and deck. I will be presenting the project at an event in London shortly.
(author unknown)
The DOM is a mess. In an effort to support legacy quick short cuts such as “form.name” etc the browsers have created a Frankenstein monster. This is well known of course but I just wonder how far the rabbit hole goes. I’m gonna share what I discovered over the years.
HTML CollectionsFirst up is my favourite “HTML Collections”, when html elements are combined into groups they become a collection. You can actually force a collection by giving an element the same name. Such as:
<input id=x><input id=x><script>alert(x)</script>On IE “x” alerts “Object HTML Collection”. What’s interesting is there are two ways of doing this, via name and via id, because it’s an array like structure you can reference each element by the order they appear in the collection e.g. collection[0] is the first element. We can use this functionality to “clobber” variables into window to create some interesting stuff. An example of this:
<a href="invalid:1" id=x name=y>test</a> <a href="invalid:2" id=x name=y>test</a> <script>alert(x.y[0])</script>What is especially odd is that a collection constructed like this can refer to itself forever, for example:
<script> alert(x.y.x.y.x.y[0]); alert(x.x.x.x.x.x.x.x.x.y.x.y.x.y[0]); </script>When the elements become a collection this of course removes the normal properties/methods on the HTML element if it was being referenced by name.
<a href=1 name=x>test</a> <a href=1 name=x>test</a> <script> alert(x.removeChild)//undefined alert(x.parentNode)//undefined </script>You can see how that could cause problems
Variable assignments cause anchor href modificationsThis is a very old bug probably a few years old now, it was rediscovered by @gsnedders. On IE a global variable with the same name as an anchor element caused modification of that anchors href. For example
<a href="123" id=x>test</a> <script> x='javascript:alert(1)'//only in compat! ;</script>If you have an anchor named “x” and an assignment with the same name then even if it is fully encoded you can still inject XSS by modifying the anchor directly.
Framebusters bustedLastly on my trip down memory lane I have another interesting bug that was again found many moons ago. You might be familiar with code similar to this:
<script> if(top!=self){ top.location=self.location } </script>
It’s checking if the top most window is the same as the current window (usually to prevent a page being framed). If we can clobber a form before the check then we can fool the logic into thinking that self is a form and “self.location” is an attribute on that form like this:
<form name=self location="javascript:alert(1)"></form> <script> if(top!=self){ top.location=self.location } </script>Which fires the alert! But there’s more, since an attribute is decoded when it’s accessed we can encode the colon of course but because on IE when the assignment occurs it’s also decoded we can now double encode! Which means this is perfectly valid too:
<form name=self location="javascript&#58;alert(1)"></form> <script> if(top!=self){ top.location=self.location } </script>In conclusion the DOM is a mess.
More prescriptive regulation of the security posture in industry sectors like banking could have the paradoxical impact of reducing security, according to Andrew Dell, head of IT security services at the National Australia Bank.…
Richard Chirgwin
The risks in cloud deployments are generally differences of degree rather than different in kind. But there are some risks that are fundamentally new. We saw two examples recently. First was Bloomberg, not a 21st century Cloud for sure, more like 1990s era Cloud but the precedent is right there for anyone using a Cloud application:
In one instance, a Bloomberg reporter asked a Goldman executive if a partner at the bank had recently left the firm — noting casually that he hadn’t logged into his Bloomberg terminal in some time, sources added.
Goldman later learned that Bloomberg staffers could determine not only which of its employees had logged into Bloomberg’s proprietary terminals but how many times they had used particular functions, insiders said.
The matter raised serious concerns for the firm about how secure information exchanged through the terminals within the firm actually was — and if the privacy of their business strategy had been compromised.
“You can basically see how many times someone has looked up news stories or if they used their messaging functions,” said one Goldman insider.
And the second, the Google stalker case
former Google engineer, repeatedly took advantage of his position as a member of an elite technical group at the company to access users' accounts, violating the privacy of at least four minors during his employment, we've learned. Barksdale met the kids through a technology group in the Seattle area while working as a Site Reliability Engineer at Google's Kirkland, Wash. office.
Cloud apps have to deal with the normal IT risks, but in addition we have the above examples of new risks that are brought on in part by panopticon effects of Cloud apps.
Our good friend, Aaron Bedra, posted a fantastic piece at the Braintree Blog this morning about building a security culture. I thought the piece was so well done that I wanted to share it with you.
The best part of the article, for me, was the content about finding creative ways to say yes. IMHO, all too often, infosec folks get caught up in saying no. We are the nay sayers, the paranoid brethren and the net cops. But, it doesn’t have to be that way. It might take a little (or even a LOT) of extra work, but in many cases ~ a yes is possible ~ IF you can work on it and negotiate to a win/win point with the stakeholders.
Take a few minutes and think about that. Think about how you might be able to get creative with controls, dig deeper into detection, build better isolation for risky processes or even make entirely new architectures to contain risk ~ even as you enable business in new ways.
In the future, this had better be the way we think about working with and protecting businesses. If not, we could find ourselves on the sideline, well outside of the mainstream (if you aren’t there already in some orgs).
Great work Aaron and thanks for the insights.
The post Aaron Bedra on Building Security Culture appeared first on MSI :: State of Security.
