Windows pen testing - access tokens

I'm a bit late on this subject, but I think it's worth a post. For those who usually do pentesting and usually get some access to Windows boxes, but are looking for a specific credential (like a domain admin), impersonating access tokens available can be a very useful approach. The details about how to do it and tools available can be found in this paper from Luke Jennings.By the way, Jennings also published some good stuff about MQ Series and general mainframe security stuff. You can find it (and more) at MWR Labs.

Simple but dreadful, part 3 - Workstation local administrator

The logic behind risk management makes almost all companies to focus on protecting their servers instead of spending time on the workstations. Although it seems to make sense, it is important to note that people access, generate and input information on sensitive applications and servers mostly through their workstations. Owning the workstations of an organization can be as bad as owning its servers.One of the easiest ways to do that is to identify how the organization deals with the local administrator account of the workstations. Setting a password for the local admin account seems to be a easy thing to do, bu when you have thousands of workstations it can really become a nightmare. Some companies try to set a single strong password for all workstations, but that means if this password is compromised the keys to the whole kingdom are lost. You may think that using a very strong password can avoid problems from offline cracking (together with disabling LanMan password, etc - I assume you know the basics about Windows passwords), but remember that if a single guy from IT support (the guys who know that password) is fired or discloses the password to someone out of the entitled circle, you will have to change it on ALL workstations. Now, if you can do that (yes, there are lots of companies that are not even prepared to do that), it would be a good idea to start thinking about using a different password for each workstation. You may think I'm crazy, but there are tools that allow you to do that in a pretty decent (and secure) way, from a central location and with a lot of controls over who access those passwords.Also remember that if you properly manage permissions on those workstations you will most likely never use that password. You will have a group of the administrators as part of the "local admin" group for each box, meaning that they won't need the admin account to do anything there, giving you the bonus of better accountability.Some things to avoid when defining your strategy to manage workstations local admin passwords:

• Logon scripts with clear text passwords (noooo!!!!!!!!!!)


• Scripts from SMS or other central management tool with clear text passwords (believe me, the users will found that!)


• That-same-very-secret-password-that-only-those-ten-guys-know-about-for-all-boxes mistake (yes, I mentioned that before. Just in case)


• Different passwords generate by a "security by obscurity" algorithm that uses the name of the workstation as input. Hey, if it's a bad idea on encryption why would it be a good idea for passwords?

After all, how infosec is related to SOX??

Yes, a lot of security professionals went to the bill's text and were not able to find anything related to information security, even when directed to sections 302 and 404. I was very happy to find this post from the eIQnetworks blog today, as it is written in the same exact way that I use to explain this issue to those who ask me. So, to save some words, you can go directly to their post.

I've never seen my previous CSO role so well explained

I've stumbled upon this blog from Shrdlu (that just entered into my blogroll) and found a very good piece on why a CSO ends up working more (ok, as much as) than his/her employees.Also a very good post from him on incident response.

Mogull on adaptative Auth and AuthZ

Richard Mogull mentions on his blog today the concepts of adaptative Authentication and Authorization. In short, from his post:

• "User: This is an area I intend to talk about in much greater depth later on. Basically, right now we rely on static authentication (a single set of credentials to provide access) and I think we need to move more towards adaptive authentication (where we provide an authentication rating based on how strongly we trust that user at that time in that situation, and can thus then adjust the kinds of allowed transactions). This actually exists today- for example, my bank uses a username/password to let me in, but then requires an additional credential for transactions vs. basic access.


• Transaction: As with user, this is an area we’ve underexplored in traditional applications, but I think will be incredibly valuable in cloud services. We build something called adaptive authorization into our applications and enforce more controls around approving transactions. For example, if a user with a low authentication rating tries to transfer a large sum out of their bank account, a text message with a code will be send to their cell phone with a code. If they have a higher authentication rating, the value amount before that back channel is required goes up. We build policies on a transaction basis, linking in environmental, user, and situational measurements to approve or deny transactions. This is program logic, not something you can add on."

I'll keep out from this post the ideas about cloud computing, layers and the real meat of his post, but I want to stress how nice the adaptative authentication and authorization concepts are. Richard is right when he says that banks are already doing that, I remember including the concept in the online banking of a Bank I worked for almost 4 years ago. The thing, however, would be trying to bring that to other authentication and authorization actions that exist inside (and outside, in the cloud, whatever) the organization. It could be used to further protection on privileged IDs, to enforce higher controls over remote access from potentially malicious networks, specific time ranges, and a lot of other things that could be used to indicate a higher threat level. In fact, it could even be deployed by transparent proxies in front of the applications without a need to change code or hard to deploy integrations.Definitely, something that should be better explored by security vendors.

TCG IF-MAP

I was very excited to read about TCG IF-MAP on Chris Hoff's blog last week. Chris found that interesting as something that could bring some light to the "cloud nightmare" and to virtualization issues.I like IF-MAP, however, because it raises the security intelligence level on the network. Today most of SIEM installations are working mostly with information from network devices and concentration points, like firewalls and IPSes. There are a lot of things happening in the endpoint world, behind those enforcement points, that is not usually detected and feed into correlation systems. IF-MAP seems to be a nice way to leverage security information along security tools, including SIEMs, to allow better correlation. Look at this example from the IF-MAP FAQ:"Q. What can people do with IF-MAP?A. The IF-MAP 1.0 specification supports many use cases. The following are two examples:• An intrusion detection system with an IF-MAP client publishes an alert to an IF-MAP server ( “IP address 10.10.100.24 is sending anomalous traffic” ); A firewall that subscribes to information involving 10.10.100.24 receives a notification from the IF-MAP server, triggering an automatic response• A Security Event Manager (SEM) system queries an IF-MAP server to find the aggregate associations between the IP address and MAC published by the DHCP server, the user name published by the RADIUS server, and the hostname published by the DNS server.Since IF-MAP is extensible, more use cases may be supported in the future."I always believed that effective correlation on security should be able to deal with information from different layers, like MAC, IP, Port, user name, information context, physical location, among others. Sometimes two events don't show any correlation when looking at the network level, but when you look at them on higher layers you can see they are referring to similar things. With this perspective you can not only figure out that the exploit from IP X being detected by the IDS and blocked at the firewall are the same event (ok, it has its value, but not that much), but you also can start to identify colusion between different internal users to bypass segregation of duties controls, privilege abuse and stolen credentials in use. That should be the play field for security intelligence, and IF-MAP can help vendors to produce tools that can do that.

Sarbanes Oxley, good to hear people questioning

John Pescatore is right when he says that talking about less regulation at this time seems to be not aligned with the current crysis, but the article he is pointing to is very precise on saying that the costs from SOX are pretty high and, as we could see, it wasn't able to prevent cases like Bear Sterns, Lehman Bros., AIG and Merrill Lynch. Accountants are as creative as lawyers, they will always look for breaches in the controls (laws) to do their magic.

SOX brought a lot of money to Information Security, but it also brought some directed focus on some controls that are not always the most required for all organizations. It would be nice to see a review of the law, verifying its results and actual costs.

The WPA sky is not falling

A lot of noise about a new research that "cracked" WPA was made this week. Well, there are more details about it today, and they clearly show that the WPA sky is not falling.

There is a very good abstract of what is happening on the article above:

"To describe the attack succinctly, it's a method of decrypting and arbitrarily and successfully re-encrypting and re-injecting short packets on networks that have devices using TKIP. That's a very critical distinction; this is a serious attack, and the first real flaw in TKIP that's been found and exploited. But it's still a subset of a true key crack."

So, it's not the final attack against WPA protected networks, but it is a very important building block for more elaborate attacks. I can see that in a near future we will see more serious stuff being done using this as a starting point. Keep your ears open.