Tuesday, December 21, 2010
Tuesday, December 7, 2010
Saturday, December 4, 2010
Wednesday, December 1, 2010
Improving security vulnerabilities in open source Web applications
By Dustin Larmeir, Contributor
29 Nov 2010
Some would argue that online security has changed for the worse. As open source Web applications become popular within businesses, they have also become appealing to hackers.
As more company websites run on open source applications like Drupal and with corporate blogs powered by WordPress, more victims may suffer from hacks and costly exploits. Both 960 Grid System (960.gs) and Learning jQuery learned this lesson the hard way. Before these companies took a serious look at hardening open source platforms, embarrassing and costly attacks wrought havoc. Other companies that haven’t taken proper precautions to insulate themselves against such threats could face the same fate.
A look at real-world exploits of Linux security vulnerabilities
We’ll highlight some security issues that open source Web applications pose and propose solutions if you’ve considered making open source applications part of your business.
Common vulnerabilities in open source Web applications
Like you, hackers love that open source Web applications are free and provide easy access given their “open” source code. If, for example, a hacker can deploy a script to steal information or take control of a Web application on a single piece of hardware, he can easily reproduce these devastating results to affect multiple users or multiple websites that share the same code base. Here’s why:
•Many open source applications depend on older versions of scripting languages that remain subject to exploitation.
•Modules plugged into open source applications must be maintained separately from the parent project. Left unpatched, these modules can create problems for the entire application.
•Smaller open source projects often go unpatched for long periods of time. This extended window puts your files at high risk for exploitation.
•Hackers create bots that specifically target application vulnerabilities. When a tireless army of “workers” tries to penetrate code around the clock, exploits are easy to achieve.
•Locking down administrative privileges is a common oversight that enables cyber-thieves to easily compromise code.
•Procedure calls such as XML-RPC are frequently exploited, and cross-site scripting hacks and SQL injections commonly cause trouble for open source platforms.
Locking down open source Web applications
Knowing is half the battle, and there are many tactics to lock down open source Web applications. To succeed in your online business and gain the trust of end users, proper protection is paramount.
Let’s use the two company examples as a backdrop for discussing common breaches to open source and what can be done to achieve better protection for the rest of us.
960.gs experienced a hack that compromised the operating system while running Textpattern CMS. The breach gave full server and FTP access to the bad guys, and once inside, hackers uploaded malicious, embarrassing images to the site with the aim of inducing a negative search engine optimization benefit. This type of hack was difficult to detect because, for public visitors, the site appeared to run smoothly and correctly. A number of techniques could have prevented 960.gs from falling victim to these problems while running an open source Web application:
•Application hardening (includes OS and databases). Operating system and database installations should be completed carefully. Avoid default settings and maintain strict permissions controls. Rewrite file extensions to mask the application type, and remove all unnecessary functions and features to close as many virtual “holes” as possible. Additionally, patch, patch, patch. Particularly in an open source environment, updates go far in preventing compromises. The same rules also apply to scripting languages that may be used on your server.
•Server hardening. Remove information (such as response headers) that could help a bot or hacker identify the version and type of application running on a server. Patch and perform frequent manual checks of server logs to help identify unusual occurrences.
•Strong passwords and access control. Implement passwords containing alphanumeric, uppercase, lowercase and special characters, and never use dictionary terms. Additionally, reset them regularly. Control access to administrative passwords and grant database credentials only on an as-needed basis. Never use an SA or root account for the database user, block all public and port access to site administrator areas, and refrain from opening up a server to any ports, except 80/443 -- these are required to transmit web pages over HTTP/HTTPS, respectively.
•System log monitoring. Watch your system logs closely and ensure that no unauthorized login attempts are successful. Run vulnerability audits and scans on your application regularly (quarterly at minimum) to help identify threats, breaches and suspect activity quickly.
Learning jQuery, a customer of FireHost, experienced a completely different type of attack: a SQL injection that exploited an open security vulnerability in the database layer of WordPress. WordPress and other content management system (CMS) providers work hard to stay ahead of SQL injection vulnerabilities by addressing them proactively via patches. Unfortunately, Learning jQuery’s site was an early victim of this particular problem.
Cyclically, hackers innovate and adapt while CMS providers just try to keep up. Web application firewalls (WAFs) help bridge the gap between hackers’ innovation and CMS providers’ patching. WAFs inspect Web traffic before it can reach the code and block suspect visitors from reaching your services. The ability to block an attack increases exponentially when WAFs team up with intrusion prevention and intrusion detection systems, and other network-level barriers. Had this type of network-layer protection been in place, Learning jQuery’s site might have never experienced an onslaught of malicious attacks.
Keeping open source Web application breaches at bay
The growth and popularity of open source content management systems have changed the security landscape and made traversing it more perilous. But with the help of a developer or technical engineer experienced in securing Web applications (and their hosting environment), you can implement these methods and keep cyber-thieves at bay. With proper precautions, attention to detail and commitment to maintaining your open source websites, companies that use (or plan to use) open source Web applications can have a successful and fruitful run.
Dustin Larmeir is a Linux security specialist at FireHost. He has an extensive background in system administration and Web hosting working with Linux and open source technologies.
29 Nov 2010
.
29 Nov 2010
Some would argue that online security has changed for the worse. As open source Web applications become popular within businesses, they have also become appealing to hackers.
As more company websites run on open source applications like Drupal and with corporate blogs powered by WordPress, more victims may suffer from hacks and costly exploits. Both 960 Grid System (960.gs) and Learning jQuery learned this lesson the hard way. Before these companies took a serious look at hardening open source platforms, embarrassing and costly attacks wrought havoc. Other companies that haven’t taken proper precautions to insulate themselves against such threats could face the same fate.
A look at real-world exploits of Linux security vulnerabilities
We’ll highlight some security issues that open source Web applications pose and propose solutions if you’ve considered making open source applications part of your business.
Common vulnerabilities in open source Web applications
Like you, hackers love that open source Web applications are free and provide easy access given their “open” source code. If, for example, a hacker can deploy a script to steal information or take control of a Web application on a single piece of hardware, he can easily reproduce these devastating results to affect multiple users or multiple websites that share the same code base. Here’s why:
•Many open source applications depend on older versions of scripting languages that remain subject to exploitation.
•Modules plugged into open source applications must be maintained separately from the parent project. Left unpatched, these modules can create problems for the entire application.
•Smaller open source projects often go unpatched for long periods of time. This extended window puts your files at high risk for exploitation.
•Hackers create bots that specifically target application vulnerabilities. When a tireless army of “workers” tries to penetrate code around the clock, exploits are easy to achieve.
•Locking down administrative privileges is a common oversight that enables cyber-thieves to easily compromise code.
•Procedure calls such as XML-RPC are frequently exploited, and cross-site scripting hacks and SQL injections commonly cause trouble for open source platforms.
Locking down open source Web applications
Knowing is half the battle, and there are many tactics to lock down open source Web applications. To succeed in your online business and gain the trust of end users, proper protection is paramount.
Let’s use the two company examples as a backdrop for discussing common breaches to open source and what can be done to achieve better protection for the rest of us.
960.gs experienced a hack that compromised the operating system while running Textpattern CMS. The breach gave full server and FTP access to the bad guys, and once inside, hackers uploaded malicious, embarrassing images to the site with the aim of inducing a negative search engine optimization benefit. This type of hack was difficult to detect because, for public visitors, the site appeared to run smoothly and correctly. A number of techniques could have prevented 960.gs from falling victim to these problems while running an open source Web application:
•Application hardening (includes OS and databases). Operating system and database installations should be completed carefully. Avoid default settings and maintain strict permissions controls. Rewrite file extensions to mask the application type, and remove all unnecessary functions and features to close as many virtual “holes” as possible. Additionally, patch, patch, patch. Particularly in an open source environment, updates go far in preventing compromises. The same rules also apply to scripting languages that may be used on your server.
•Server hardening. Remove information (such as response headers) that could help a bot or hacker identify the version and type of application running on a server. Patch and perform frequent manual checks of server logs to help identify unusual occurrences.
•Strong passwords and access control. Implement passwords containing alphanumeric, uppercase, lowercase and special characters, and never use dictionary terms. Additionally, reset them regularly. Control access to administrative passwords and grant database credentials only on an as-needed basis. Never use an SA or root account for the database user, block all public and port access to site administrator areas, and refrain from opening up a server to any ports, except 80/443 -- these are required to transmit web pages over HTTP/HTTPS, respectively.
•System log monitoring. Watch your system logs closely and ensure that no unauthorized login attempts are successful. Run vulnerability audits and scans on your application regularly (quarterly at minimum) to help identify threats, breaches and suspect activity quickly.
Learning jQuery, a customer of FireHost, experienced a completely different type of attack: a SQL injection that exploited an open security vulnerability in the database layer of WordPress. WordPress and other content management system (CMS) providers work hard to stay ahead of SQL injection vulnerabilities by addressing them proactively via patches. Unfortunately, Learning jQuery’s site was an early victim of this particular problem.
Cyclically, hackers innovate and adapt while CMS providers just try to keep up. Web application firewalls (WAFs) help bridge the gap between hackers’ innovation and CMS providers’ patching. WAFs inspect Web traffic before it can reach the code and block suspect visitors from reaching your services. The ability to block an attack increases exponentially when WAFs team up with intrusion prevention and intrusion detection systems, and other network-level barriers. Had this type of network-layer protection been in place, Learning jQuery’s site might have never experienced an onslaught of malicious attacks.
Keeping open source Web application breaches at bay
The growth and popularity of open source content management systems have changed the security landscape and made traversing it more perilous. But with the help of a developer or technical engineer experienced in securing Web applications (and their hosting environment), you can implement these methods and keep cyber-thieves at bay. With proper precautions, attention to detail and commitment to maintaining your open source websites, companies that use (or plan to use) open source Web applications can have a successful and fruitful run.
Dustin Larmeir is a Linux security specialist at FireHost. He has an extensive background in system administration and Web hosting working with Linux and open source technologies.
29 Nov 2010
.
Subscribe to:
Posts (Atom)