Daily Security Tips from Ed Skoudis - Week of September 16, 2002
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security Tip for Friday, September 20th, 2002
With the rapid spread of massively damaging worms and the rise of high numbers of script-kiddie attackers, your organization absolutely positively must have a defined, written process for learning about and deploying new security patches. This process must include specifically assigned roles and responsibilities. Your process should include the following elements:
Reading vendor and security mailing lists to determine when new vulnerabilities have been discovered
Obtaining copies of any vendor patches
Authenticating those patches to ensure they are legitimate
Testing them in a Quality Assurance environment
Moving them into production
Testing the production facilities to make sure functionality is preserved
Security Tip for Thursday, September 19th, 2002
Buffer overflow attacks are incredibly popular, and allow bad guys to take over a system or escalate their privileges. To stop many buffer overflow attacks from functioning on your machines, consider implementing non-executable system stacks on your machines. By preventing the system from executing code from the stack, such tools proactively defend against some buffer overflow attacks. Before rolling non-executable system stacks into production, make sure you test your applications thoroughly, as this configuration may break some legitimate but poorly written software. To implement non-executable system stacks on a Linux machine, download the Linux kernel patches available at www.openwall.com/linux. On Windows, you can use the commercial tool SecureStack from SecureWave (www.securewave.com). On a Solaris machine, the following lines should be added to /etc/system:
set noexec_user_stack=1 set noexec_user_stack_log=1
Security Tip for Wednesday, September 18th, 2002
On all of your critical servers, run a file integrity-checking tool, such as Tripwire (commercially available www.tripwire.com or for free at www.tripwire.org) or AIDE (located at http://www.cs.tut.fi/~rammer/aide.html). Such a tool should be run on a daily basis, or even more frequently, depending on available resources. These tools look for common alterations made by attackers when they install RootKits or other malicious software on your machines.
Security Tip for Tuesday, September 17th, 2002
Users can alter anything a web application sends to their web browsers unless the data is carefully protected. If a web application sends any variables to a browser, such as cookies, hidden form elements, or data in the URL itself, the user sitting at the browser can change their value, even across an SSL connection. If the user is malicious, he could change account information, alter prices, and possibly even usurp other users' accounts if these variables are not protected. Whenever data beyond the HTML displayed on the screen is sent to the browser, use a keyed hash algorithm (such as MD5 with a key) to cryptographically protect the integrity sent to the browser.
Security Tip for Monday, September 16th, 2002
To locate weak passwords in your environment before attackers do, periodically run a password cracking tool against your users' passwords. Make sure you have written permission from management before running this or any other security assessment tool. When you find weak passwords, ensure that you have a method for communicating securely with users who have easily cracked passwords. Don't just send them e-mail saying that their passwords are weak, because an attacker my intercept such an e-mail or spoof such messages to fool your users into resetting their passwords. Instead, physically visit users with weak passwords to ask them to change them. For an easy-to-use commercial password-cracker on Windows, consider LC4, available at http://www.atstake.com/research/lc. For a highly versatile free password cracker, look at John the Ripper (located at www.openwall.com/john).