Information Security News
by Sean Gallagher
On the heels of the Syrian Electronic Army compromising a number of high-profile accounts—including those of the Associated Press, The Guardian, and The Onion—Twitter has introduced a two-factor authentication feature that should make such attacks more difficult. In a blog post today, Jim O'Leary of Twitter's security team announced the release of "login verification," an optional security measure that requires a verified phone number and e-mail address.
Twitter is a bit late to the two-factor authentication party. Word first spread that Twitter was working on a two-factor authentication scheme in February when the company advertised job openings for security engineers to develop "user-facing security features, such as multi-factor authentication and fraudulent login detection." Google has offered two-factor authentication since February of 2011, and Facebook introduced two-step login approval in May of 2011.
Like Google's two-factor authentication, Twitter's login verification sends a code via SMS to be entered to confirm login. But unlike Google's system, the code will be sent every time users sign into Twitter through its website. This is the case even if it's from a computer or device that they've logged in from before. The phone has to be enrolled through Twitter's existing SMS service first—you have to text a code to Twitter to verify the phone first, which may not work with some phone carriers. The relationship between phones and accounts is also strictly one-to-one: if you have a shared business account, you're going to need to share a phone number too. If you have multiple accounts and only one phone number, then you can only secure a single account.
by Jon Brodkin
A Congressional survey of utility companies has revealed that the country's electric grid faces constant assault from hackers, with one power company reporting a whopping 10,000 attempted cyberattacks per month.
US Reps. Edward Markey (D-MA) and Henry Waxman (D-CA) sent 15 questions to more than 150 utilities and received replies from 112 of them. Only 53 of those actually answered all the questions—the others provided incomplete responses or only "a few paragraphs containing non-specific information" without answering any of the questions.
Results from those who did answer show utilities are under continuous assault:
In my day job I spend about 90% of my time on the red team, performing vulnerability assessment and penetration testing. The rest is spent on threat research, incident response, and digital forensics. Interacting with clients as a consultant I often hear what I term 'interesting' responses. When a penetration tester calls something interesting you should probably pay attention :)
The IDS only listens external to the firewall? SharePoint is directly exposed to the Internet? The WAF protects against attacks therefore we don't have to fix the application? The VMs are all physically on the same host? The DMZ and the internal VLAN are physically on the same switch? You don't bother with privilege escalation patches? All quite interesting.
One of the responses I have heard multiple times is that privilege escalation vulnerabilities are a low priority because they require the attacker have local access. Meaning that that would be very difficult to pull off, therefore we don't have to worry about it. This also assumes that every single account holder is 100% gruntled all of the time, and that nobody ever makes a mistake. Meaning that we can trust everyone who accesses our networks and applications. Which I also find to be 'interesting' :)
There are multiple types of privilege attacks. The first is privilege escalation, where someone who has valid credentials or means to access a network or application can raise their level of access to a more privileged level. Like getting root on a Unix system for example, or becoming Domain admin before lunch on day 1, or assuming a higher role within an application. Impersonation attacks are similar however they entail becoming a different user, often with the same level of privilege, but with way more money in their account :) which soon finds its way to a non-extradition treaty country.
If the major difference between a remote exploit and a local one is that a network connection is required for the former, and not for the latter, does this mean that local priv escalation attacks cannot be performed across the network? Actually no. If an attacker can gain access to a system through a client side exploit, they may then effectively become the local user, and escalate to local system. Local system priv on a Windows computer is just a hop, skip, and jump away from being Domain administrator.
In a recent discussion about the priority to be assigned to patch one comment was "It's only a privilege escalation!". Yes, you are correct, and that is an interesting statement was my response.
Adrien de Beaupré
My SANS Teaching Schedule