Nmap project released Nmap 7 after three years and half development. The new version of Nmap had more 100 contributors and 3,200 code commits since Nmap 6. The new version has 171 Nmap Scripting Engine (NSE) and supports fully IPv6 from host discovery to port scanning to OS detection. [Read more…]
(LiveHacking.Com) – Apple has released a massive set of security fixes to address vulnerabilities in OS X, iOS, Safari, and Apple TV. The update for OS X is largest of all the patches and addresses 80 unique vulnerabilities. The OS X Yosemite v10.10.3 update is available for OS X Yosemite v10.10 to v10.10.2, while Security Update 2015-004 is available for OS X Mountain Lion v10.8.5 and OS X Mavericks v10.9.5.
Of particular interest is a fix to several CVEs raised by Ian Beer of Google Project Zero. Multiple input validation issues existed in fontd, and as a result a local user may be able to execute arbitrary code with system privileges.
Apple also fixed a use-after-free issue that existed in CoreAnimation, an input validation issue that existed within OS X’s URL processing, and a memory corruption issue that existed in WebKit. Because of these, visiting a maliciously crafted website could have led to arbitrary code execution.
Other “arbitrary code execution” vulnerabilities fixed by Apple include:
- Multiple memory corruption issues that existed in the processing of font files (CVE-2015-1093 : Marc Schoenefeld).
- A memory corruption issue that existed in the handling of .sgi files.
- A memory corruption issue that existed in an IOHIDFamily API (CVE-2015-1095 : Andrew Church).
- A memory corruption issue that existed in the handling of iWork files (CVE-2015-1098 : Christopher Hickstein).
- A heap buffer overflow existed in SceneKit’s handling of Collada files (CVE-2014-8830 : Jose Duart of Google Security Team).
Apple also update the bundled version of Apache in OS X. Multiple vulnerabilities existed in Apache versions prior to 2.4.10 and 2.2.29, including one that may allow a remote attacker to execute arbitrary code. These issues were addressed by updating Apache to versions 2.4.10 and 2.2.29.
Likewise it also updated the bundled version of PHP. Multiple vulnerabilities existed in PHP versions prior to 5.3.29, 5.4.38, and 5.5.20, including one which may have led to arbitrary code execution. This update addresses the issues by updating PHP to versions 5.3.29, 5.4.38, and 5.5.20.
The update for iOS addresses 58 separate CVE entries, while Apple TV 7.2 fixes 38 unique CVEs. The fixes for Safari updates the browser to Safari 8.0.5, Safari 7.1.5, and Safari 6.2.5 respectively. In total the Safari update addresses 10 different CVEs.
You can get more information on these updates on Apple’s Security Updates web site: https://support.apple.com/kb/
(LiveHacking.Com) – The OpenSSL Project announced on March 16th that it would make a new release of its OpenSSL suite to fix a number security defects. As promised the project published three new versions today, OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. The highest severity defect fixed by these releases is classified as High.
Before looking at the defects which have been fixed, it is worth noting that the project has reclassified its advisory about the FREAK vulnerability from Low to High. It was previously classified as Low severity because it was originally thought that server RSA export ciphersuite support was rare: a client was only vulnerable to a MITM attack against a server which supports an RSA export ciphersuite. Recent studies have shown that RSA export ciphersuites support is far more common.
The new security advisory lists only one High severity fix, for CVE-2015-0291 – ClientHello sigalgs DoS. If a client connects to an OpenSSL 1.0.2 server and renegotiates with an invalid signature algorithms extension a NULL pointer dereference will occur. This can be exploited in a DoS attack against the server. This issue affects OpenSSL version 1.0.2.
The rest of the bug fixes are rated as Moderate or Low:
- Multiblock corrupted pointer (CVE-2015-0290) – Severity: Moderate – OpenSSL 1.0.2 introduced the “multiblock” performance improvement. This feature only applies on 64 bit x86 architecture platforms that support AES NI instructions. A defect in the implementation of “multiblock” can cause OpenSSL’s internal write buffer to become incorrectly set to NULL when using non-blocking IO. Typically, when the user application is using a socket BIO for writing, this will only result in a failed connection. However if some other BIO is used then it is likely that a segmentation fault will be triggered, thus enabling a potential DoS attack.
- Segmentation fault in DTLSv1_listen (CVE-2015-0207) – Severity: Moderate – The DTLSv1_listen function is intended to be stateless and processes the initial ClientHello from many peers. It is common for user code to loop over the call to DTLSv1_listen until a valid ClientHello is received with an associated cookie. A defect in the implementation of DTLSv1_listen means that state is preserved in the SSL object from one invocation to the next that can lead to a segmentation fault. Errors processing the initial ClientHello can trigger this scenario. An example of such an error could be that a DTLS1.0 only client is attempting to connect to a DTLS1.2 only server.
- Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) – Severity: Moderate – The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication.
- Segmentation fault for invalid PSS parameters (CVE-2015-0208) – Severity: Moderate – The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and invalid parameters. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication.
- ASN.1 structure reuse memory corruption (CVE-2015-0287) – Severity: Moderate – Reusing a structure in ASN.1 parsing may allow an attacker to cause memory corruption via an invalid write. Such reuse is and has been strongly discouraged and is believed to be rare.
- PKCS7 NULL pointer dereferences (CVE-2015-0289) – Severity: Moderate – The PKCS#7 parsing code does not handle missing outer ContentInfo correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing.
- Base64 decode (CVE-2015-0292) – Severity: Moderate – A vulnerability existed in previous versions of OpenSSL related to the processing of base64 encoded data. Any code path that reads base64 data from an untrusted source could be affected (such as the PEM processing routines). Maliciously crafted base 64 data could trigger a segmenation fault or memory corruption. This was addressed in previous versions of OpenSSL but has not been included in any security advisory until now.
- DoS via reachable assert in SSLv2 servers (CVE-2015-0293) – Severity: Moderate – A malicious client can trigger an OPENSSL_assert (i.e., an abort) in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message.
- Empty CKE with client auth and DHE (CVE-2015-1787) – Severity: Moderate – If client auth is used then a server can seg fault in the event of a DHE ciphersuite being selected and a zero length ClientKeyExchange message being sent by the client. This could be exploited in a DoS attack.
- Handshake with unseeded PRNG (CVE-2015-0285) – Severity: Low – Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with an unseeded PRNG.
- Use After Free following d2i_ECPrivatekey error (CVE-2015-0209) – Severity: Low – A malformed EC private key file consumed via the d2i_ECPrivateKey function could cause a use after free condition. This, in turn, could cause a double free in several private key parsing functions (such as d2i_PrivateKey or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption for applications that receive EC private keys from untrusted sources. This scenario is considered rare.
- X509_to_X509_REQ NULL pointer deref (CVE-2015-0288) – Severity: Low – The function X509_to_X509_REQ will crash with a NULL pointer dereference if the certificate key is invalid. This function is rarely used in practice.
New versions of OpenSSL are available as listed below:
(LiveHacking.Com) – FREAK (or ‘Factoring attack on RSA-EXPORT Keys’) is a newly disclosed vulnerability that can force browsers into using weaker encryption keys. Once the connection is using weaker keys then the traffic can be cracked relatively quickly. This then exposes all the information that was being sent over the secure connection.
The vulnerability stems directly from an old U.S. government policy that made it illegal to export strong encryption and required that weaker “export-grade” products be shipped to customers in other countries. These export restrictions were lifted in the late 1990s, but the weaker encryption got built-in into widely used software, some of which made its way back into USA.
In the 1990s the USA only allowed companies to create technology with 512-bit encryption for use overseas. The law was designed to limit the trade in military technology. But 512-bit encryption has long been seen as “unacceptably weak” and most security experts thought that its use had ceased completely.
According to the Washington Post, it is possible to crack the export-grade encryption key in about seven hours, using computers on Amazon Web services. The site freakattack.com has a list of sites that are vulnerable to FREAK. The list “includes news organizations, retailers and financial services sites such as americanexpress.com.” According to Nadia Heninger, a University of Pennsylvania cryptographer, over 5 million sites are vulnerable to this attack vector.
FREAK has been assigned the Common Vulnerabilities and Exposures identifier CVE-2015-0204. According to the description, “The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k allows remote SSL servers to conduct RSA-to-EXPORT_RSA downgrade attacks and facilitate brute-force decryption by offering a weak ephemeral RSA key in a noncompliant role.”
According to a security advisory from OpenSSL, “an OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session.”
This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k, OpenSSL 1.0.0 users should upgrade to 1.0.0p, and OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team the following day.
It also looks like Android’s web browser and Apple’s Safari browser are vulnerable. According to Matt Green, “A group of cryptographers at INRIA, Microsoft Research and IMDEA have discovered some serious vulnerabilities in OpenSSL clients (e.g., Android) and Apple TLS/SSL clients (e.g., Safari) that allow a ‘man in the middle attacker’ to downgrade connections from ‘strong’ RSA to ‘export-grade’ RSA.”
(LiveHacking.Com) – A recent security advisory from Sucri has revealed that the popular WordPress plugin WP-Slimstat is vulnerable to SQL injection attacks because of a weak secret key.
If exploited fully the bug could allow hackers to use SQL injection attacks to download sensitive information from a susceptible site’s database, including username, and (hopefully) hashed passwords. According to Sucri it could even be possible, in certain situations, for the attacker to find the WordPress Secret Keys and then takeover the site completely.
The problem is with the secret key used by the plugin to sign data sent to/from the client. The key used is in fact the MD5 hash of the plugin’s installation timestamp. Although it would be impossible to guess the exact date and time of the plugin installation, it might be possible to guess the approximate date and therefore drastically reduce the number of combinations.
Only the correct year is needed to reduce the number of possibilities down to 30 million values, which according to Sucri is computable in around 10 minutes using modern setups. Part of the problem is that MD5 hashes are quite breakable using modern CPU/GPU combinations.
Once the correct MD5 hash has been discovered then fake data can be sent to the plugin. Then, due to a second bug – which allows an attacker to insert arbitrary data into an unserialize() call, the attacker can execute arbitrary SQL queries and allow them to get any data they want from the database.
“This is a dangerous vulnerability, you should update all of your websites using this plugin as soon as possible,” wrote Marc-Alexandre Montpas on Sucri’s blog.
WP-Slimstat is an analytics tool. Its listing on WordPress shows it has been downloaded more than 1.3 million times. People who operate websites that use the plugin should update immediately. All versions before 3.9.6 are vulnerable.
(LiveHacking.Com) – Google has been under fire in the last few weeks for arbitrarily disclosing zero-day vulnerabilities which give hackers the information they need to attack susceptible systems. When Google makes these disclosures it knows full well that it is risking the security and privacy of potentially millions of people.
The positive side of these disclosures is that Google guarantees that vendors, like Microsoft, Apple and Adobe, are informed of zero-day flaws and given enough time to patch those flaws before a disclosure is made. By informing the vendor and yet by giving them a period of time to fix the issue, Google is trying to ensure that both “the need of the public to be informed of security vulnerabilities” and the “vendors’ need for time to respond effectively” are balanced.
However until now Google’s 90 day deadline has been completely arbitrary without any consideration of real-world circumstances. The arbitrary nature of the 90 day rule was highlighted recently when Google published the details of a bug in Windows which Microsoft was scheduled to patch on January 13th, but the 90 days passed on January 11th, so Google just published the details anyway. In this way Google was sticking to the letter of the law rather than the spirit of it.
But now it seems that Google has seen the error of its ways and updated its disclosure policy. From now on:
- Weekends and holidays. If a deadline is due to expire on a weekend or US public holiday, the deadline will be moved to the next normal work day.
- Grace period. Google now has a 14-day grace period. If a 90-day deadline will expire but a vendor lets Google know before the deadline that a patch is scheduled for release on a specific day within 14 days following the deadline, the public disclosure will be delayed until the availability of the patch. Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed (2 weeks+).
- Assignment of CVEs. CVEs are an industry standard for uniquely identifying vulnerabilities. To avoid confusion, it’s important that the first public mention of a vulnerability should include a CVE. For vulnerabilities that go past deadline, Google will ensure that a CVE has been pre-assigned.
While Microsoft welcomes the changes, it would much rather see Google work more closely with software vendors to apply patches. “When finders release proof-of-concept exploit code, or other information publicly before a solution is in place, the risk of attacks against customers goes up,” Microsoft’s Chris Betz told The Register in an emailed statement. “While it is positive to see aspects of disclosure practices adjust, we disagree with arbitrary deadlines because each security issue is unique and end-to-end update development and testing time varies.”
(LiveHacking.Com) – A new Cross Site Scripting (XSS) vulnerability has been found in IE 11. According to an email sent by David Leo, a researcher with information security company Deusen, to the Full Disclosure mailing list, the vulnerability can allow an attacker to steal anything from a third party domain, and likewise inject anything into a third party domain.
Deusen has also posted a proof of concept which injects the words “Hacked by Deusen” into a third party website, in this case dailymail.co.uk. The disclosure is for Internet Explorer 11 on Windows 7, however I have tried it on Windows 8.1 and the vulnerability is present.
The way the PoC works is once the web page has been opened you need to click on a dialog box to proceed. Then a second window opens showing the dailymail.co.uk website, after a few seconds the contents of dailymail.co.uk are replaced with the hacked message. In a real world scenario the injected code would do something more malicious.
Since IE still shows that the domain is dailymail.co.uk users can be easily tricked into giving up usernames and passwords, or other private information. Imagine if the attacker used paypal.com rather than dailymail.co.uk.
However, phishing isn’t the only worry. The vulnerability also means attackers can access existing authentication cookies. This means that an attacker can masquerade as an already authorized user.
According to Joey Fowler, a Senior Security Engineer at Tumblr, the vulnerability allows hackers to bypass standard HTTP-to-HTTPS restrictions. “It looks like, through this method, all viable XSS tactics are open!” he wrote.
Joey also asked if Microsoft had been informed. David Leo confirmed that Microsoft was notified on Oct 13, 2014. In a statement to iTnews, Microsoft said that there were no known cases of this vulnerability being exploited in the wild. Microsoft is working on a fix.
(LiveHacking.Com) – Following Google’s disclose of a number of zero day vulnerabilities in OS X, Apple has released a huge set of patches that fix a range of Critical security problems on OS X, iOS, Apple TV, and Safari.
Starting with OS X, Apple’s patches fix 54 separate CVEs including 11 from Google’s Project Zero. Among the fixes are patches for the 3 bugs which Google disclosed last week:
- An error existed in the Bluetooth driver that allowed a malicious application to control the size of a write to kernel memory.
- Multiple type confusion issues existed in coresymbolicationd’s handling of XPC messages.
- A memory access issue existed in the handling of IOUSB controller user client functions.
A security vulnerability in the Intel graphics driver is also credited to Google’s project zero. According to the release notes, multiple vulnerabilities existed in the Intel graphics driver, the most serious of could lead to arbitrary code execution with system privileges.
Another six CVE’s were reported to Apple from another of Google security groups, this time the Google Security Team. Among its catches are a bug in the kernel: Multiple uninitialized memory issues existed in the network statistics interface, which led to the disclosure of kernel memory content.
The security update is available for OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, OS X Yosemite v10.10 and v10.10.1. You can read the full details here: http://support.apple.com/en-us/HT1222
Since iOS and OS X share much of the same code (certainly at the lower levels), Apple also released an update to its mobile operating system with many of the same fixes. The iOS update addresses 33 different CVEs and fixes some of the same vulnerabilities from Google’s Project Zero. You can read more about iOS 8.1.3 here: http://support.apple.com/kb/HT204245
Like iOS, Apple TV also uses lots of the same core technologies as OS X. In response to Google’s disclosures and in the light of other security issues, Apple has released Apple TV 7.0.3. It addresses 29 different CVEs including the disclosed problems with XPC: Multiple type confusion issues existed in networkd’s handling of interprocess communication. By sending a maliciously formatted message to networkd, it could be possible to execute arbitrary code as the networkd process.
Apple TV 7.0.3 is available for all 3rd generation and later Apple TV boxes. Full details can be found here: http://support.apple.com/kb/HT204246
To round off this huge security update, Apple has also updated Safari 8.0.3, Safari 7.1.3, and Safari 6.2.3 on OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, and OS X Yosemite v10.10.1 to fix a series of memory issues with WebKit. If exploited these vulnerabilities could allow an attacker to run arbitrary code on a victim’s Mac, if tricked into visiting a maliciously crafted website.
Apple has also updated its web plug-in blocking mechanism to disable all versions prior to Flash Player 22.214.171.1246 and 126.96.36.1994.
(LiveHacking.Com) – Google recently came under some heavy criticism when it disclosed a zero-day vulnerability in Windows just days before Microsoft was scheduled to release a fix. Now the search giant as done it again. But this time Google shows that it is truly non-partisan because the disclosures aren’t for Windows, but for OS X.
The first vulnerability allows an attacker to pass arbitrary commands to the networkd OS X system daemon in XPC messages. XPC provides a lightweight mechanism for basic interprocess communication. The problem is that the daemon uses the values from xpc_dictionary_get_value and xpc_array_get_value without subsequent checking of the type of the returned value. Google posted proof-of-concept (POC) code that allows a shell command to be executed as networkd on OS X 10.9.5. The POC uses a specially crafted XPC message which results in “touch /tmp/hello_networkd” being executed. That is a benign command, but it can be replaced with something more malicious.
The second vulnerability in IOKit IOService allows an attacker to execute code on an OS X machine with root privileges through a null pointer dereferencing. The third flaws also relates to IOKit, this time in the Bluetooth subsystem. To exploit it the machine needs to have a Bluetooth device attached, for example a Apple Bluetooth keyboard. Once exploited it allows an attacker to write into kernel memory, potentially allowing them to create a denial of service situation or to access private data.
The security flaws were reported to Apple in October 2014. All three advisories were subsequently published by Google after the expiration of the 90-day grace period give under Project Zero.
(LiveHacking.Com) – Microsoft will be issuing a series of security bulletins today (Patch Tuesday) to address security vulnerabilities in its products. One of these fixes will be for a vulnerability that Google intentionally disclosed to the public last week.
Security experts at Google found a bug which could allow an attacker to gain elevated privileges on a Windows 8.1 machine. After the vulnerability was found, Microsoft was informed of the problem, which was dubbed Windows Elevation of Privilege in User Profile Service.
According to Google standard security policy the bug was subject to a 90 day disclosure deadline. “If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.” On October 13th 2014 Microsoft was told about the bug and the 90 day clock started ticking.
Then on November 11th Microsoft contacted Google and told it that a patch would be ready for the vulnerability in February 2015. The cryptic comment attached to the bug report read, “Microsoft confirmed that they are on target to provide fixes for these issues in February 2015. They asked if this would cause a problem with the 90 day deadline.”
Google told Microsoft that “the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended. Further they were informed that the 90 day deadline for this issue expires on 11th Jan 2015.”
Microsoft further replied that it would release a patch in January. This demonstrates the power and need for the 90 day disclosure deadline. It forced Microsoft to act quicker. That is the purpose of the deadline.
But there is another problem, Microsoft’s update process is known by everyone in the security industry. It releases security fixes on the second Tuesday of the month, Patch Tuesday. The release of patches for operating systems and software applications that are used by millions of people is a heavy task. These releases require lots of testing and a top notch change management system.
The whole of Microsoft’s security engineering is geared towards Patch Tuesday. The problem is that for January, Patch Tuesday falls on January 13, but Google insisted on disclosing the details of the vulnerability on January 11, exactly 90 days after Microsoft was told of the problem.
According to Chris Betz from the Microsoft security response center, “Google has released information about a vulnerability in a Microsoft product, two days before our planned fix on our well known and coordinated Patch Tuesday cadence, despite our request that they avoid doing so.”
“Specifically, we asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix,” he added.
It does seem foolish of Google to behave in such a way. Google also understands the problems of releasing patches to software applications, services and operating systems, and it should (but doesn’t seem to) understand that the protection of consumers is the primary goal.
The idea behind the 90 day disclosure is to ensure that vendors actually take security seriously, but to disclose a vulnerability just two days before a major corporation releases the required patches is officious bureaucratic behavior. In these cases the spirit of the principle needs to be applied and not the letter.