Critical Control 1 - Inventory of Authorized and Unauthorized Devices
How many servers are in your DMZ?
How many Servers do you have in total?
How many workstations are connected to the network?
How many printers?
Switches/switches/routers/firewalls/Access Points?
If you can answer all the questions above for your organisation accurately, well done. Unfortunately the reality is that many people will not be able to answer them at all.
Knowing what you have in your environment is critical to the security of the environment. We know that many attackers use automated processes to identify and attack machines on the internet. If you are not aware of what internet facing systems you have, or they are not controlled, then it is likely that they will be discovered and compromised quickly. So it is quite important to know what is actually there.
How can you achieve that? you need to be able to control what is plugged in. Failing that, you will need to know when something has been plugged in. 802.1x controls or other forms of Network Access Control will help you achieve the first, but this may not be suitable for all areas of your environment, or you may not get around to implementing it for a while.
Detecting what is plugged in can be achieved in a number of ways. Tools like arpwatch will detect when something is plugged in. You could scan the network segment on a regular basis using something like nmap and use ndiff to compare the results. This will let you know when something is connected to your network. You my be able to watch DHCP allocations and detect or prevent unauthorised allocations. In order for it to be effective you will need some sort of inventory, if you don't know what you have, then you will not know what should or should not be there. Document the operating systems in use, the types of hardware used, switch types, printer types etc.
There are of course other tools that will help in this scenario. Many management tools will have inventory capabilities, some patching tools have the capability and some of the AV solutions will now detect "unknown" devices on the network.
What do you do to identify and control what is on your network?
Mark - Shearwater
Beauty and the BEAST
(This is a bit longer diary – if you are just interested in conclusion and recommendations, skip below to the “Is SSL broken?” section. I recommend that you read the whole diary – and let us know if you have any comments).
Unless you’ve been hiding on a deserted island, you heard about the latest attack on SSL, named BEAST. We wrote several diaries (first, second, third) on this topic. I got interested into the attack a lot and finally had some time to go through all the details.
So, first of all – big props to Duong and Rizzo for implementing this in practice. While the idea itself is really cool (a bit more about it below), the implementation is what really impressed me, and all the effort they invested into the research here.
Some basics about the attack
As has been already written on million places, the BEAST attack attacks SSL 3.0 and TLS 1.0, in particular their implementation of the Cipher-block chaining (CBC) block encryption algorithms.
This is probably the most widely used mode for block encryption algorithms today, so it is obvious that any attack on this (and SSL/TLS overall) can have huge impact.
In a nutshell, BEAST very cleverly uses predictable IV (initialization vector) values in order to set up particular input vales for SSL. By very carefully modifying these input values, the attacker can exploit BEAST to guess what value 1 byte in an encrypted block had. Block encryption algorithms fragment input messages into blocks, usually 8 or 16 bytes long.
The IV is initially a random number and then every next block uses the previous cipher text as the IV. The IV is XORed with the input plain text – this produces input for the encryption algorithm. So normally, in a block encryption algorithm, encrypted block C4 = encryption ( C3 XOR P4), where C is an encrypted block and P is a plain text block.
According to this, the last blocks (CN) IV will be CN-1: CN = encryption (CN-1 XOR PN). Doung and Rizzo cleverly used this so they leave the channel open and add the next block (N+1) whose content will be of one of the previous blocks. Imagine that we supply P4 (with only 1 byte modified), XORed with CN and it’s original C3:
CN+1 = encryption ( CN XOR ( CN XOR C3 XOR P4 ))
This results in:
CN+1 = encryption ( C3 XOR P4)
For which we know the result as it is C4! Now, if we can influence P4 to give us the opportunity of guessing one byte (by supplying, for example, 7 known bytes) we can try to guess what the last byte was: if CN+1 is equal C4, we guessed the byte, otherwise we didn’t.
This is just a brief overview – for more information read the leaked paper – it is written very well.
Guessing HTTP values
As you’ve seen above, the attacker can now guess byte by byte. With HTTP creating this boundary is actually simple since we know what each HTTP request will look like:
GET /AAAAA HTTP/1.1<cr><lf>
header
If we want to guess the first character of Header, we can make the previous line 23 bytes long (if blocks are 8 bytes each):
GET /AAAAAAA HTTP/1.1<cr><lf>H
Notice how only H will make it into the 3rd block. The attacker now knows the content of the first two blocks and can try to guess the first character by using the attack described above.
Attack prerequisites and implementation
As if the attack itself was not impressive enough, Doung and Rizzo managed to actually do all this in the browser. Let us revisit what they have to do for this attack:
- They need to pull a MITM attack on the victim. This is needed for two things: first, they need to monitor the network traffic in order to guess bytes. Second, they need to somehow influence the browser to make it issue requests such as the one shown above that will let them do the guessing. For the demo they used a Java applet, but there are other ways of exploiting this (more below).
- Once they injected the Java applet into the victim’s browser, they wait for the victim to log in to the target site. Now the Java applet will open an SSL connection to the target site and send a specially crafted request as above (i.e. GET /AAAAAAA …). The SSL connection must stay opened so they can feed new blocks in real time, as they monitor network traffic. This will allow them to guess content of bytes encrypted by the browser. So, their Oracle in this case is the browser itself – the web server that they are attacking is irrelevant, it is the victim’s browser that let’s them guess encrypted content.
As you can see from 2), the crucial requirement is that the SSL connection is open (so they are able to append the data and use the last block as the IV). This proved to be very difficult to do (and is one of the things in Doung’s and Rizzo’s research that impressed me the most).
There are many ways that can be used in a browser to open a new connection. The easiest way is to use JavaScript’s XmlHttpRequest (XHR). There are some limitations here though. First, Internet Explorer does not support XmlHttpRequest level 2 (which is needed in order to send cookies) and instead has an XDomainRequest object. XDomainRequest will never send cookies so, in theory, Internet Explorer users are more protected than Mozilla Firefox or Chrome users (is this a first or what!?!).
Firefox and Chrome support XHR level 2. It is worth pointing out here that the attacker is not able to read the request response through active scripting due to the fact that the server will not set the correct Access-Control-Allow-Origin header, but the attacker does not care about that since he just wants to be able to use the browser as an Oracle for guessing encrypted stuff. Similarly, settings such as Secure or HttpOnly will not help with this attack (but will with other).
The biggest problem with this is, it appears, that XHR cannot be used to create streaming requests, which are needed to perform the guessing (the attacker needs to be able to append those pre-calculated blocks to a request). Many other possible exploitation vectors, such as plain IFRAMEs, Websockets or Silverlight have similar issues that prevented Doung and Rizzo from using them – keep in mind that this does not mean these are “safe” against BEAST, just that current attempts to use them failed.
Is SSL broken?
Simple question, simple answer – NO. As you can see above, there are many prerequisites that the attacker needs to do in order to conduct the BEAST attack.
While the attack is inherent to block encryption algorithms, it requires the attacker to be able to append these specially crafted input blocks into an active session. In other words, it is very difficult, or impossible to exploit BEAST on other protocols that use SSL, such as POP3s, IMAPs and similar. Doung and Rizzo did it with browsers because there are many scripting (extending) possibilities with browsers and the HTTP protocol.
Couple of things I would suggest doing:
- Be careful about switching to TLS 1.1 or TLS 1.2 because you might break things for many clients. While this definitely fixes the vulnerability, be very careful.
- Move to RC4 over CBC. RC4 has also its own issues but just the fact that Google prefers RC4 says something too – you can use the nice sslscan utility to see what ciphers are supported by a server, here are the results for mail.google.com:
# sslscan --no-failed mail.google.com:443
_
___ ___| |___ ___ __ _ _ __
/ __/ __| / __|/ __/ _` | '_ \
\__ \__ \ \__ \ (_| (_| | | | |
|___/___/_|___/\___\__,_|_| |_|
Version 1.8.2
http://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009
Testing SSL server mail.google.com on port 443
Supported Server Cipher(s):
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
Prefered Server Cipher(s):
SSLv3 128 bits RC4-SHA
TLSv1 128 bits RC4-SHA
- Do not accept any unsigned Java applets and allow them to run. You should always do this, not only in this case. Same goes for any other active technology.
- When accessing sensitive sites, close all browser windows (not tabs, all windows) and open a fresh new one and use it only to access the sensitive site. After you’re done, close it again and reopen it for further surfing. This should make exploitation a bit difficult, but keep in mind that as of Java 6 Update 10 an attacker can potentially trick a victim into dragging applets out of browser windows so they continue running after the browser is closed (I’m not sure if this can be used to help BEAST).
- If you are a sensitive server owner – keep an eye on errors on your server. The BEAST attack needs to issue quite a bit of requests (generally each byte has a 1/256 chance of being guessed, so in average 128 blocks need to be appended to a single request). One request is needed for a byte so if you see a lot of 404 requests with similar patterns (/AAAAA) that should raise some flags. Of course, you should always monitor and correlate your logs, not only now :)
At the end, I must again admit I like the attack a lot - the idea is really cool, amazing how they came up with everything. That being said, as you can see above, there are a lot of prerequisites for successful exploitation so I don't think that the resulting risk is very high at the moment.
(small update): There have been some comments about recommending RC4. While there have been plenty of bad/broken/failed implementations of RC4 (take a look at WEP), I definitely do not consider RC4 to be broken, especially not the OpenSSL implementation that is widely used.
Besides me ;-), US CERT is also recommending that RC4 is prioritized in their advisory available at http://www.kb.cert.org/vuls/id/864643.
--
Bojan
INFIGO IS
@bojanz on Twitter
Security 101 : Security Basics in 140 Characters Or Less
It was one of THOSE gigs: an internal penetration test against a client that, considering the amount of personal information they held on their customers, should have been well prepared. And yet, we went from "you-can-plug-your-laptop-in-over-there" to "Domain Admin" in... well, let's just say a "shockingly small" number of hours. And it just went downhill from there...
For me, writing up the resulting report, triggered what I could only describe as a "crisis of faith." While, as a security community, I don't fool myself that we have it all "figured out," I had – up until now – strongly believed that we were making progress. And yet, I had just spent a week immersed in a corporate culture that seemed to have focused itself on so many higher-level security issues that the basics – the "Security 101" stuff – was just plain overlooked.
The more I thought about it, the more it bothered me. It wasn't some fancy-schmancy 'leet h@x0r 0-day that let us take down this organization from the inside: it was stupid-simple low-hanging fruit. I spent a bit of time chatting over Twitter with the ever-insightful Brian Honan (@BrianHonan) and came to the conclusion that the security community may have reached an awkward age at which we're grown up enough to be focusing on the golly-gee/whiz-bang/cool stuff (vis-à-vis the "APTification" of all that passes for security discussion) and, as a result, we're neglecting the basic, "Security 101" stuff that raised the bar in the first place.
Think about it: Over the past year, how many high-profile hacks have been the result of awesome cutting edge skillz? How many have happened because someone just flat-out did something dumb? Take a quick gander at back issues of SANS NewsBites and I think you'll be convinced as well: We truly are neglecting the basics.
Since October is "Security Awareness Month," a few weeks back, I sent out a call on Twitter for folks to submit pithy, 140 character-long, chunks of Security 101 wisdom. Below, I've compiled together the resulting list, along with the Twitter name of the submitter.
If you're feeling a little shaky on your security knowledge, then heeding this advice might just save your behind. Even if you're confident that you "know it all," a quick review might have you discovering stuff you've inadvertently overlooked. Either way, I heartily recommend that you read (and heed) this advice. Also, if something particularly strikes your fancy, you might consider following the author on Twitter... you never know – you might learn even more.
One last "housekeeping" note: I lightly edited these to remove some of the more blatant "Twitterisms" used to stuff big thoughts into limited character lengths. If anything got messed up, I'll take the blame.
| @ChrisJohnRiley | If you can guess where PHPmyAdmin is installed, then so can attackers. |
| @DavidJBianco | You are already pwn3d. The question is, "What will you do about it?" |
| @Keldr1n | Don't leave default passwords on the administrative interfaces of your 3rd party web applications. |
| @Keldr1n | Know your network - and all devices in it - well enough to spot unusual activity. |
| @Keldr1n | Users are almost always the weakest link. Make it a priority to educate them. Do most of yours even know what phishing is? |
| @averagesecguy | Security 101: If you don't need it, turn it off. |
| @bowlesmatt | Passphrases are the new passwords. Make a sentence that is long, hard to guess, and easy to remember. ihatepasswordsseewhatididthere? |
| @bowlesmatt | Patch your systems and disable any unused services to reduce attack surface. |
| @bradshoop | Never trust a host you can't trust. |
| @bradshoop | Computers remember a lot. Even more if you contact security personnel before you reboot. |
| @bradshoop | Dedicate personnel to prevention AND detection. Preferably the same personnel in rotation to breed familiarity and contempt. |
| @connellyuni | It's more important to know what you don't know than it is to know what you do know. |
| @cutaway | Try to avoid saying "We are investigating... why equipment that we have a destruction certificate for was... sold online" to the media. |
| @cutaway | Assets using secure authentication are directly and adversely impacted by your assets using plain text authentication. |
| @cutaway | Complacency: 1) Self-satisfaction especially when accompanied by unawareness of actual dangers or deficiencies. 2) You will be hacked. |
| @cutaway | Default SSL Certs for internal management interfaces should be replaced with valid certificates associated with the organization. |
| @cutaway | Don't be afraid of your incident response plan. Conducting investigations will give your team experience and eventually reduce costs. |
| @cutaway | How do you "Find Evil" in your organization? Seriously, go "Find Evil" and report back to me. |
| @cutaway | IT environments are complex systems. They require a System Development Life Cycle to effectively manage AND secure. |
| @cutaway | If your product allows remote connections somebody WILL write a python/perl/ruby script to connect to it and send whatever THEY want. |
| @cutaway | Monitor and alert to new accounts and accounts being added to Domain Administrator, SUDO, or root groups. |
| @cutaway | Product certification does not mean it has been deployed correctly. Review placement, logging, access, input validation, etc... |
| @cutaway | Service accounts should adhere to corporate password policies and be monitored for modifications including lockout. |
| @eternalsecurity | Make sure you're protecting the right thing. A belt AND suspenders doesn't help if you're not wearing pants. |
| @hal_pomeranz | "A backup is not a backup until you do a restore." #sysadminkoan |
| @hy2jinx | Attack vectors and regulatory requirements change. "That's how we've always done it" is a poor and lazy excuse. |
| @hy2jinx | Scanner "infos" can turn up bigger issues than you'd guess. Look at overall results, not just singles. |
| @hy2jinx | Five missing patches across 100 devices does not equal "five vulnerabilities." |
| @hy2jinx | It's cheaper to consult a security professional from conception than mere days before "go live." |
| @hy2jinx | Security professionals should be empowered to point the business towards good decisions and reserve the power of "No" for a last resort. |
| @itinsecurity | In your encryption system, your key is the weakest link. If it isn't, you're doing it wrong. |
| @itinsecurity | Security is not a box you buy or an app you write. It's an emergent property, a sum greater than its parts. |
| @jarocki | "Dear User: Millions of $$ of software won't keep you from clicking that link. Only YOU can prevent link clicking." |
| @jarocki | When it comes to security controls, Trust But Verify... nah, forget the Trust... just Verify. |
| @jimmyzatl | If you don't log "accepts" in your FW logs for admin protocols you will have no way of knowing when those accounts are abused. |
| @jimmyzatl | An encryption algorithm that has to be hid from the public is by definition a weak algorithm... |
| @ken5m1th | That successful PCI DSS Report On Compliance will not save you from Zombies. |
| @kentonsmith | When setting up any new system, Step 1: Change default admin password. |
| @kill9core | Security through obscurity, or the practice of hiding flaws hoping they won't be found, has proven time and time again not to work. |
| @mattdoterasmus | Just because your security teams work from 9-5, doesn't mean attackers aren't looking the rest of the time. |
| @omegadefence | The attitude that "it won't or can't happen to us" because "we're too small/big/have nothing to offer" is dangerous. |
| @omegadefence | The attitude that "I can't do anything about it so I won't even bother with security or reporting" is also dangerous. |
| @omegadefence | Analyse your logs in detail, it is those with their heads buried in your logs that hold the key to prevent, detect and recover. |
| @omegadefence | Give only the permissions required to do the normal daily duties, nothing more. Special logons for special occasions. |
| @omegadefence | Best: using high-speed trend analysis with custom searches as well as automated reporting AND followup. |
| @rob_bainbridge | Security teams that work in isolation and without transparency will fail. Collaborate with other risk mgmt - audit, ops risk, etc... |
| @tccroninv | Those that store passwords in plain-text invite catastrophe. |
| @tliston | "We can't implement strong passwords/two-factor authentication. Our users aren't capable," says more about your competence than theirs. |
| @tliston | Developers: Never roll your own encryption, authentication or session management schemes. You're not that smart. Trust me. |
| @tliston | If you don't have written authorization to perform security-type testing in your organization, don't. You're too pretty for prison. |
| @tliston | If you're not putting as much thought into your outbound firewall rules as you are for your inbound rules, you're doing it wrong. |
| @tliston | If you're not supporting a legacy Windows OS, for the love of all that is Holy, turn off LANMAN hashes. |
| @tliston | If you've never tested restoring from your backups, then you don't have backups - you have a crapload of data and hope. |
| @tliston | If your internal security posture is based on,"our employees wouldn't know how to do that," then you're likely already 0wned. |
| @tliston | Remember: As an attacker, I exploit misplaced trust. There's nothing mystical or magical about it. |
| @tliston | Run scans against your network. It's the only way to really know what's out there. I've yet to see a fully accurate network diagram. |
| @tliston | Sanity check security spending. A $500 lock on a cheap wood door doesn't buy security. It just gives a thief something to laugh at. |
| @tliston | Security isn't just about preventing compromise. It's about maintaining confidentiality, integrity & availability despite compromise. |
| @tliston | Security-through-obscurity doesn't work against anything with intelligence, but there's lots of dumb sh*t out on the 'net. |
| @tliston | Taking nude photos of yourself? Don't store them on an always-connected device with little-to-no security. #forscarlett |
| @tliston | Teach your users not to click on unknown links. DON'T send links to your users in email. More info: http://t.co/bdNTRI3O |
| @tliston | Web developers: Give the exact same answer whether you're given a bogus username or password on logins. EXACT. SAME. ANSWER. |
| @tliston | WebApp Devs: Just because you have a <SELECT> with A, B, C, & D as options doesn't mean you'll only ever get A, B, C, or D back. |
| @tliston | Webhosting Companies: Web servers shouldn't be making many *outbound* connections. TCPDump is your friend. |
| @tliston | Your organization's AUP should explicitly prohibit Copyright abuse. You do HAVE an Acceptable Use Policy, right? |
| @tliston | Centralize your logging - you have no idea how helpful it will be. |
| @tliston | Companies who use the same Windows Local Admin password on large numbers of machines are ripe for picking by malicious insiders |
| @tliston | Developers: Input, even data you think you control, can never be trusted. Consider all input a threat and process accordingly. |
| @tliston | Diligent change management practices have saved more asses than a Beverly Hills plastic surgeon. |
| @tliston | Ensure that user accounts are disabled as part of your termination process. Audit all accounts at least semi-annually for "misses." |
| @tliston | High privilege level accounts should be used only for administrative functions, not for day-to-day activities. |
| @tliston | High privilege level accounts should have kick-ass passwords or two factor authentication. Or both. |
| @tliston | If at all possible, disable password authentication for SSH. SSH is a huge brute force target. Keys are your friend. |
| @tliston | If it plugs into your network, know why. The last thing you ever want to hear an admin say is, "That thing has a web interface?!?" |
| @tliston | Learn how to manipulate text files. Learn how to use sed, cut, wc, and grep as a minimum. Text is your friend. |
| @tliston | Logging authentication failures is NOT enough. Log successes and failures. |
| @tliston | Mr. CxO: Your employees are not a "family." Some are untrustworthy. FYI: Some of the people in your real family are pretty sketchy too. |
| @tliston | Never rely on the fact that you "own" anything: data, a communication path, etc... If you do - I 0wn it, I 0wn you. Trust nothing. |
| @tliston | Nothing is more important to the long-term survivability of your organization than a fully functional backup process. |
| @tliston | Packets to or from RFC-1918 addresses should not be allowed to traverse your border firewall in either direction. |
| @tliston | Passwords are no longer security measures. They are merely speed-bumps. Treat them accordingly. |
| @tliston | Physical access trumps most security measures. |
| @tliston | Remember to always think in terms of "defense in depth." A belt AND suspenders is always better than a belt OR suspenders. |
| @tliston | Shared accounts are never a good idea. |
| @tliston | Telnet, FTP, and any other clear-text protocol developed in simpler, more naive times has no business on a modern network. |
| @tliston | There is no excuse - NONE - not to use full disk encryption on laptops. Data breaches due to lost/stolen laptops are inexcusable. |
| @tliston | Unencrypted WiFi is never secure. WEP = Unencrypted WiFi. Trust me. Stop using it. Now. Really. |
| @tliston | Web Developers: Remove comments from your production website code. They serve NO purpose and can give away too much info. |
| @vaudajordan | Total loss of Sony Breach $171M, I wonder how many salaries, code reviews, software, hardware that could have bought. |
| @zanis1 | Assign only those privileges that are required to do the job. |
Also, I want to extend a great big "thank you" to all of the people who submitted these tweets using the #sec101 hash tag. I tried really hard to grab them all... If I missed anyone, I apologize.
Tom Liston
Senior Security Consultant, InGuardians, Inc.
Handler: SANS ISC
Note: Matt (@0xznb) has kindly made a fortune-mod zip file available here of the #sec101 wisdom.
What are the 20 Critical Controls?
[the following is a guest diary contributed by Dr. Eric Cole]
One of the questions I often receive is what are the twenty critical controls. Details can be found at www.sans.org/cag but the general approach of the controls is to begin the process of establishing the prioritized baseline of information security measures and controls that will lead to effective security. The consensus effort that has produced the controls have identified 20 specific technical security controls that are viewed as effective at defending against the most common methods of attack. Fifteen of these controls can be monitored, at least in part, automatically and continuously. The consensus effort has also identified a second set of five controls that are essential but that are more difficult to be monitored continuously or automatically with current technology and practices; however they are critical to achieving an optimal level of security. Each of the 20 control areas includes multiple individual sub-controls, each specifying actions an organization can take to help improve its defenses.
Additionally, the controls are designed to support agencies and organizations that currently have different levels of information security capabilities. To help organizations focus on achieving a sound baseline of security and then improve beyond that baseline, certain subcontrols have been categorized as follows:
- Quick Wins: These fundamental aspects of information security can help an organization rapidly improve its security stance generally without major procedural, architectural, or technical changes to its environment. It should be noted, however, that a Quick Win does not necessarily mean that these subcontrols provide comprehensive protection against the most critical attacks. If they did provide such protection, there would be no need for any other type of subcontrol. The intent of identifying Quick Win areas is to highlight where security can be improved rapidly.
- Improved Visibility and Attribution: These subcontrols focus on improving the process, architecture, and technical capabilities of organizations so that the organization can monitor their networks and computer systems, gaining better visibility into their IT operations. Attribution is associated with determining which computer systems, and potentially which users, are generating specific events. Such improved visibility and attribution support organizations in detecting attack attempts, locating the points of entry for successful attacks, identifying already-compromised machines, interrupting infiltrated attackers' activities, and gaining information about the sources of an attack. In other words, these controls help to increase an organization’s situational awareness of their environment.
For additional details on the controls, please go to www.sans.org/cag. Portions of the above are taken from version 2.0 of The Twenty Critical Controls.
----------------
Dr. Eric Cole
twitter: drericcole
école .at. secure-anchor.com
Comments