Daily Archives: 12/06/2012

MySQL vulnerability allows attackers to bypass password verification

The vulnerability was addressed in MySQL 5.1.63 and 5.5.25, but many server administrators might not be aware of its impact.

Security researchers have released details about a vulnerability in the MySQL server that could allow potential attackers to access MySQL databases without inputting proper authentication credentials.

The vulnerability is identified as CVE-2012-2122 and was addressed in MySQL 5.1.63 and 5.5.25 in May. However, many server administrators might not be aware of its impact, because the changelog for those versions contained very little information about the security bug.

The vulnerability can only be exploited if MySQL was built on a system where the memcmp() function can return values outside the -128 to 127 range. This is the case for Linux systems that use an SSE-optimized glibc (GNU C library).

If MySQL was built on such a system, the code that compares the cryptographic hash of a user-inputted password to the hash stored in the database for a particular account will sometimes allow authentication even if the supplied password is incorrect.

The probability of triggering this bug successfully on systems that meet the prerequisite is about 1 in 256, said Sergei Golubchik, the security coordinator for MariaDB, in an email sent to the oss-sec mailing list on Saturday. “~300 attempts takes only a fraction of second, so basically account password protection is as good as nonexistent.”

MariaDB is a community-developed branch of MySQL that was also affected by this vulnerability. The flaw was patched in MariaDB versions 5.1.62, 5.2.12, 5.3.6 and 5.5.23 back in April.

A module for exploiting this vulnerability was added to the popular Metasploit penetration testing framework on Sunday. After exploiting the vulnerability, the module copies the MySQL server’s master user table, which contains all password hashes.

An attacker can crack the password hashes using dictionary attacks and maintain their unauthorized access on the server even if this authentication bypass vulnerability is later fixed. “If you are approaching this issue from the perspective of a penetration tester, this will be one of the most useful MySQL tricks for some time to come,” Metasploit chief architect HD Moore said in a blog post on Monday.

Moore also published a list of Linux distributions for which older MySQL builds were found to be vulnerable to this attack. These include 64-bit versions of Ubuntu 10.04, 10.10, 11.04, 11.10 and 12.04, the 64-bit version of OpenSuSE 12.1, the 64-bit version of the Debian unstable branch, the 64-bit version of Fedora 16 and an unspecified version of Arch Linux.

Most Linux vendors distribute pre-compiled MySQL builds through their own repositories and patched builds should already be available for the most popular distributions. Users are advised to upgrade to non-vulnerable builds as soon as possible, especially since the exploit code for this vulnerability is now public.

No official patch is available for MySQL 5.0.x, because that version of the database server is no longer supported by Oracle. However, some Linux vendors might backport the patch from MySQL 5.1 or 5.5.

Source:http://www.infoworld.com/d/security/mysql-vulnerability-allows-attackers-bypass-password-verification-195349

Did you like this? Share it:

Apple Releases Guide to iOS Security

For years, mobile app security was essentially an afterthought. This was not only true for consumers, but also for development shops. Recently, it’s become quite clear that something had to be done to combat the rising tide of mobile malware, viruses and other threats.

Last week, Apple took a major step in the right direction by releasing A Guide to iOS Security. This 20-page document takes a fairly in-depth look at the iOS system architecture, encryption & data protection, network security, devices access and other areas.

Testers and developers would be wise to read the entire document, but here is a good summary from the guide’s conclusion:

Each component of the iOS security platform, from hardware to encryption to device access, provides organizations with the resources they need to build enterprise-grade security solutions. The sum of these parts gives iOS its industry-leading security features, without making the device difficult or cumbersome to use.

Apple uses this security infrastructure throughout iOS and the iOS apps ecosystem. Hardware-based storage encryption provides instant remote wipe capabilities when a device is lost, and ensures that users can completely remove all corporate and personal information when a device is sold or transferred to another owner. For the collection of diagnostic information, unique identifiers are created to identify a device anonymously.

Safari offers safe browsing with its support for OCSP, EV certificates, and certificate verification warnings. Mail leverages certificates for authenticated and encrypted email by supporting S/MIME. iMessage and FaceTime provide client-to-client encryption as well.

The combination of required code signing, sandboxing, and entitlements in apps provides solid protection against viruses, malware, and other exploits that compromise the security of other platforms. The App Store submission process works to further protect users from these risks by reviewing every app before it’s made available for sale.

Businesses are encouraged to review their IT and security policies to ensure they are taking full advantage of the layers of security technology and features offered by the iOS platform.

Apple maintains a dedicated security team to support all Apple products. The team provides security auditing and testing for products under development as well as released products. The Apple team also provides security tools and training, and actively monitors for reports of new security issues and threats. Apple is a member of the Forum of Incident Response and Security Teams (FIRST). For information about reporting issues to Apple and subscribing to security notifications, go to apple.com/support/security.

Apple is committed to incorporating proven encryption methods and creating modern mobile-centric privacy and security technologies to ensure that iOS devices can be used with confidence in any personal or corporate environment.

Source:

http://www.mobileapptesting.com/apple-releases-guide-to-ios-security/2012/06/

Did you like this? Share it:

Cloud security testing strategies

Many companies are hesitant to move applications to the public cloud or use Software as a Service (SaaS) cloud applications, for fear of not being able to implement or test appropriately.

While much of that fear is based on the unknown, there are strategy changes companies should take to ensure their cloud application is properly security tested. In this expert response I will outline a few of those cloud security testing strategy changes.

Before you do anything, review the contract signed with your hosting company. Many hosting contracts require notification prior to security testing. Be clear with your company and your hosting company prior to performing any testing – outline the scope, tools involved, anticipated network load (if any), types of attacks you expect to perform, etc. If your company, or the hosting provider, has IDS or IPS technologies in place, you will need to agree on a window during which those tools will need different monitoring thresholds. Err on the side of over-communicating to avoid the element of surprise.

Remember: you don’t own the infrastructure. Your cloud solution, whether hosted at your company or at a cloud provider, will be hosted in an environment you may not be familiar with. As such, keep in mind that your testing coverage will change. Whereas internal application security testing often stopped at the application boundaries, your cloud application testing will need to probe around the edges of those boundaries. Testing for network, logical and even architectural security risks will be a very important strategy. In a way, it is a benefit to you that you can’t depend on the same networking infrastructure as your intranet. This forces you to think outside the box and test more thoroughly.

Another consideration is the need to decide between whitebox or blackbox testing. In blackbox testing, the penetration tester knows as little about the system as a real-world hacker would know. This is advantageous because, as you discover and exploit vulnerabilities, no one can challenge your report by claiming “an attacker wouldn’t know to do that.” On the other hand, whitebox testing is advantageous in that it is much faster. Not only is reconnaissance and server discovery accelerated, it’s easier to prioritize test efforts.

A big challenge to cloud security testing can be the lack of application logging to aid in focusing and enhancing your test efforts. Performing security testing in an isolated development environment means you will be able to tail logs and see evidence of your attacks’ outcomes. In a cloud environment, you will rarely be grated this level of access. Therefore, you will only be able to gauge attack success by the application’s behavior. Some tests are such that providing input into control A on screen Z will result in invalid data on page P. Be familiar with the data flow within your app and expect to have to poke all around the app to complete your testing.

In conclusion, security testing in the cloud does change things, but it’s not impossible. It’s important to plan ahead, to communicate the changes in your test strategy, and to set appropriate expectations with your management. Above all, it is critical to communicate before and during your testing—primarily with your cloud provider, but also with your IT and security organizations.

Source:

http://searchcloudapplications.techtarget.com/answer/Cloud-security-testing-strategies

Did you like this? Share it: