(ISC)2 Board candidate

Wednesday I went to the TASK meeting and learned about Seth Hardy, who is trying to get his name included in the (ISC)2 Board ellection ballot. I really don't know Seth, but I don't like the 1% rule from (ISC)2, where a member who wants to be a candidate for the Board must gather signatures of 1% of the members to be able have his name included in the ballot. I also like what TASK does, as they really seem to be like what the Brazilian ISSA chapter used to be when I was there. By that alone I think he deserves credit to be at least included in the ballot.So, if you are a CISSP, please visit http://sethforisc2board.org and sign his petition!

Simple but dreadful, part 1 - Logon Scripts

Now that I'm back to pen testing I'm having the chance to see the mistakes that admins are going into nowadays. There is something very interesting that Windows domain administrators sometimes forget and needs to be addressed as it brings serious security implications: login script files permissions.Login scripts are those little batch scripts that run when the user is logging in. They're usually stored in a share at the domain controllers called NETLOGON. The risk here is quite obvious; if I can modify your login script, I can run commands under your user account when you are logging on. This is usually not possible as the NETLOGON permissions are usually set accordingly, being writable only by domain admins.The problem is that login scripts are one of those complexity beasts that grow together with the organization and its network. Big organizations usually have lots of servers, file servers, domains and other stuff. The admins struggle to keep user lives a little easier by automatically mapping network drives, cleaning temporary file transfer areas and other stuff, and the login scripts are a good tool to do that. When doing that they sometimes need include some different command line utilities, as the regular Windows shell doesn't have all the features needed by those very creative admins. When doing that, they usually place those executables on network folders accessible by all users (of course, as they need those files during the login process :-)). What happens is that when doing that they often give too many rights for the users on those folders. Remember, when you create a folder and then share it on a Windows Server without changing any permissions there is a big chance that it will be a "Everybody - Full Control".

If you are a domain admin in a organization that extensively uses login scripts, check them for external executable references. Tampering with login scripts is a easy way for a insider to steal credentials and information from other users without being detected.

Portknocking, SPA and SOA

I already mentioned how I like stuff like port knocking. It can't be used as replacement for other security measures, but it's a nice way to keep important stuff out of radar. Imagine if you had some SSH daemons remotely accessible when that OpenSSL PRNG crisis started. I saw lots of admins running to replace flawed keys for servers because of that. If those daemons were hidden behind some portknocking stuff, it wouldn't be necessary to rush.Today I read some interesting stuff about SPA, or Single Packet Authentication, to protect SOA resources published on the web. I must say that it's a nice way to avoid too much attention on them. It would be nice to see this being integrated into frameworks.

The future of mass card theft (and PCI)

The indictment of 11 people on a mass card theft is all over the news this week. I've seen reports about software developed to steal cards, war driving and other stuff that I really don't know if it's just bad press or actual facts. There are some good info here and here.Of course PCI will be brought into the middle of the discussion about the methods used by the group. It seems that the attacks happened a long time ago (2003), but it's interesting to look into the story with the eyes of the standard. Like, why was so easy to these guys to go into the card data environment (CDE)? PCI has very specific rules about wireless networks, what I'm almost sure that those companies were not following. Besides that, it seems that all that information was being transmitted without proper encryption.An interesting aspect of the attacks is that they used tools developed specifically to steal card data. In the same way that there are tools being designed to identify sensitive data in order to protect it (DLP tools, e-discovery stuff), tools designed to steal that data will also be developed. I was reading on Hay's blog today about the Coreflood Trojan. Criminals developed a trojan and deployed that in a clever way to avoid being detected. They used a strategy that we have been using on "penetration tests" for years, to leverage access to a workstation and wait for an domain administrator to log in there to steal his passwords (and the keys to the kingdom). The results? According to Joe Stewart from SecureWorks, "463,582 user names and passwords to more than 35,000 domains. Nearly 8,500 passwords were for banks and credit unions in the United States and overseas. "So, we can see that criminals have leveraged the ability to go into large corporate networks with high privileged access rights. They also know what information they need to get, and the technology to look for that is improving everyday. It's not hard to play the oracle and say that in a near future we will witness some huge scams performed by very organized criminal groups. Welcome to the future.