Home Tags Hash Function

Tag: Hash Function

Microsoft Makes it Official, Cuts off SHA-1 Support in IE, Edge

Yesterday’s Patch Tuesday release also included an update to Microsoft’s Internet Explorer and Edge browsers officially ending support for the SHA-1 hash function.

Git sprints carefully towards SHA-1 deprecation

The sky still isn't falling Following the February controversy over whether or not Google's SHA-1 collision broke Git, its community has taken the first small steps towards replacing the ancient hash function.…

First Practical SHA-1 Collision Attack Arrives

Researchers unveiled the first-ever practical collision attack the cryptographic hash function SHA-1.

At death’s door for years, widely used SHA1 function is now...

Algorithm underpinning Internet security falls to first-known collision attack.

Security! experts! slam! Yahoo! management! for! using! old! crypto!

Suits should have done more to protect users, rather than user numbers ANALYSIS Fallen web giant Yahoo! has been branded negligent for failing to tackle the prodigious challenge of upgrading its MD5 password security before some one billion accounts were stolen. The security-battered organisation revealed today that attackers had stolen more than a billion accounts in August 2013 in history's biggest breach. Hackers stole names, addresses, phone numbers, and MD5 hashed passwords in a coup for social engineers who could use the information to compromise the very identity of users. That eye-watering news followed the company's September admission that 500 million accounts had been stolen in seperate attacks by alleged state-sponsored hackers in 2014, an incident that came two years after staff became first aware of the hack. Yahoo! has since replaced its MD5 hashing with the far superior bcrypt, moving from the world's worst password protection mechanism to the best. Yet it is little comfort for those who use legitimate personal details when signing up to Yahoo!'s service, including scores of American subscribers to major cable and DSL telcos including AT&T which use Yahoo! for its default email services, along with Kiwi carrier Spark which ditched the service in September. It is not known if the MD5 hashes were salted, since Yahoo! did not mention the critical additive in its statement.

Doing so would mitigate much risks from using MD5, says Jeffrey Goldberg, security guru at AgileBits, makers of the 1Password credential vault. "What is most important is whether the hashes, be they MD5, SHA1, or SHA256, are salted," Goldberg says. "There is absolutely no excuse to use unsalted hashes." But that the Purple Palace was even using the algorithm has drawn steep criticism from established security boffins. "The MD5 hashing algorithm has been considered not just insecure, but broken, for two decades," says Ty Miller, director of Sydney-based security firm Threat Intelligence, noting that MD5 collision vulnerabilities were found in 1996 with practical attacks developed in 2005. "I consider it negligent of an organisation such as Yahoo!, which has an obligation to protect the private data of over one billion users, to be using such an outdated and ineffective control to protect the passwords of its customers." The gossamer thin algorithm is a joke in security circles. Rainbow table databases serve as directories that transform hashes into cleartext passwords, and the internet is now littered with free and paid services that can reveal logins within seconds. Image: Kenneth White David Taylor, principal security consultant with Perth-based Asterisk Information Security, offered a similar opinion: "Yes, it would be pretty poor form on their part [to be] still using MD5 for hashing in 2013," he says. "There has been numerous issues reported for MD5 dating back to the mid 2000s." Board director with the lauded Open Web Application Security Project (OWASP) Andrew van der Stock, also chief technology officer at Threat Intelligence, is an advocate of baking security into the development process and sees shortcomings in Yahoo!'s security models. "This breach clearly shows that Yahoo!'s previous approach to security was less than ideal, and it's obvious that the Paranoids (Yahoo!'s security team) were unable to move the needle sufficiently with management to upgrade password hashing from an outdated and insecure algorithm to something more modern and acceptable," he says. "That it (MD5) is still commonly found in many of the worst breaches is an indication that the continued use of MD5 is correlated with other poor security practices." The breach comes at a notably poor time for Yahoo!: The company will soon be acquired by Verizon, possibly at a damaged-goods discount, and is conducting a security recruitment drive in Australia in a bid to attract local security talent, van der Stock says. "We all understand that without a complete revamp of senior management support for security and alignment with customer desires for privacy and security of their data, there is no point in taking on a position at Yahoo!," he says. Take this with a pinch of salt Administrators were salting password hashes in the 1980s, but many still fail to apply the complexity additive today.

The cryptography measure introduces random data into one-way functions preventing the use of rainbow tables by ensuring identical passwords have unique hashes. Goldberg points to the 2012 breach at LinkedIn to demonstrate the importance of salting, something the security boffin wrote about at the time. "LinkedIn had used SHA1, an improvement over MD5 in general, but it really didn’t matter that it was SHA1 instead of MD5," Goldberg tells The Register. "What mattered is that it was not salted.
I argued in 2012 that it was irresponsible for LinkedIn to have used unsalted hashes, and so that certainly applies to Yahoo! using unsalted hashes in 2013, if indeed, their hashes were unsalted." Put simply, a bland salt-free password earns the "contempt" of Goldberg and his kin, while the use of slow hashes like bcrypt, PBKDF2, or the upcoming Argon2 wins their praise. Attackers can guess salted passwords, whereas bcrypt and friends slow the rate at which those guesses can be made. "With a simple cryptographic hash function [like] SHA256, MD5, etcetera, an attacker might be able to make 10 million guesses per second on a single hash.

But with the 'slow hashing' functions, that might be reduced to a few tens of thousands of guesses per second," he says. The decreased rate gives users a window to change their passwords; yet even that may not have helped Yahoo! "But after four years, the details of the hashing scheme don’t really matter.

Any guessable password will have been guessed by now," he says. Not easy Yahoo!, like so many other companies offering free technology services, wants to attract the highest possible number of subscribers and has been criticised for perceived attempts to kneecap fleeing users. That mindset may have dissuaded the company from more efficiently jettisoning MD5 hashing for passwords prior to the 2013 pillaging. "The only practical way to speed up the conversion process (to bcrypt) is to force a password reset, maybe across the board, but more likely on a web property by web property basis," says noted cryptologist and director of the Open Crypto Audit Project's Kenneth White. "And therein lies the problem: there is often a very real tension between the business to be able to claim the highest user count, versus the reality that a years-old email reminds millions of people to log in to an account they had long ago forgotten." Using Yahoo! to find Yahoo! MD5 hashes, here revealing 'Password1'.
Image: Ty Miller. An email shipped to users asking them to log in so their passwords may be upgraded from MD5 hashing to bcrypt risks a "virtually overnight mass exodus of users" and a social media complaint storm that sends more rats from the burning Palace, he says. Bcrypt is the powerful hashing function designed to slow decryption attempts while minimising legitimate use performance overheads, and is favoured, along with PBKDF2 (Miller prefers the latter with hashes bearing 100,000 iterations), by each of the security boffins The Register has spoken to for this story, and many more in the broader security community including OWASP . Yet migrating to the top notch function is not as simple as just "switching to bcrypt", White says. A bootstrapping process can be followed, but it requires users to log in for bcrypt or PBKDF2 to be called and saved to a new column. Moreover, White says Yahoo! is a patchwork of web properties bearing decades-old Perl, PHP, and C code and so cannot be compared to the ease of upgrading a purpose-built modern web app. "Consider the legacy managed business mail systems," White says. "The myriad e-commerce shopping cart apps, ad accounts, to say nothing of Flickr, Yahoo! IM, and the hundreds of millions of webmail users who hadn't logged in for years, and you begin to see the scope of the engineering challenge." Van der Stock, acknowledging his outsider's position, reckons Yahoo! should immediately deploy two factor verification for all of its services, and again reset passwords, noting that the use of mere usernames and passwords puts users at "serious risk" and that leaving accounts exposed would be a "serious breach of trust". yahoo pic.twitter.com/LSxdm1wNdx December 15, 2016 Yahoo! could take a leaf from Microsoft's Xbox Live endeavours and deploy similar authentication smarts, if it has not already done so. "… I would strongly recommend some sort of real time authentication intelligence around compromised accounts, so that the authentication system itself assigns a risk score to logins to ensure that unusual patterns of abuse, such as brute force attacks, logging in from a distant country, or popping out of multiple IPs is blocked or alerted to the user for further action." Burning questions remain, not least how it took the technology giant three years to disclose that such a massive share of its accounts have been breached. "It's baffling why it's taken so long to fully scope and disclose the extent of their breach," White says. ® Sponsored: Want to know more about PAM? Visit The Register's hub

Microsoft plans St Valentine’s Day massacre for SHA‑1

End of the line for weak hash as web giants finally act The death knell for the SHA‑1 cryptographic hash function will be sounded, now that all of the main browser builders have decided to cut off support – only 12 years after its flaws were first discovered. On Friday, Mozilla and Microsoft both announced that support for SHA‑1 would be dropped – Moz with build 51 of Firefox in January and Microsoft on February 14 for its Edge and Internet Explorer 11 browsers.

Google has already said that Chrome will block SHA‑1 from build 56, due out by the end of January. "The SHA-1 hash algorithm is no longer secure. Weaknesses in SHA‑1 could allow an attacker to spoof content, execute phishing attacks, or perform man-in-the-middle attacks when browsing the web," Redmond said. "Though we strongly discourage it, users will have the option to ignore the error and continue to the website." SHA-1 will still hang around, like a fart in a spacesuit, for many years to come because some people are lazy enough not to make the change.

The delays have been driving some of the tech community up the wall, given that SHA‑1 was proven to be deeply flawed back in 2005 and has been getting progressively more insecure since then. The hash algorithm was published in 1993 as SHA‑0 by the US National Institute of Standards and Technology (NIST). Researchers at the National Security Agency did some tweaking to its compression function and turned out SHA‑1 two years later.
It was made mandatory for all US government crypto-code and became a default standard. It was a decade before researchers realized there were potential problems.
In 2005, Xiaoyun Wang and Hongbo Yu from Shandong University and Yiqun Lisa Yin from Princeton University published a paper showing it was possible to find collisions (two messages that hash to the same hash value) in 269 operations, and possibly as low as 233 – not the 280 operations first envisaged. This was worrying, but not necessarily fatal – it would still take an enormous amount of computing power to defeat, although nowhere near as much as first thought.

But as time went on, computing power increased and the advent of virtualization made more processing available to anyone with a credit card.
It became clear that decryption times would drop. The number of operations needed to cause a collision continued to decrease and remained largely theoretical. Nevertheless, NIST recommended that government users upgrade to SHA‑2 (the hash published ten years earlier) as early as 2012, but there were plenty of hold-outs, even in the US military. In 2015, a paper (dubbed The ShAppening) published by Marc Stevens of the Dutch research institute Centrum Wiskunde, with Pierre Karpman and Thomas Peyrin from Singapore's Nanyang Technological University, showed you could break SHA‑1 with just $75,000 of compute power. This finally got the industry to remove its collective digit and start setting some decent security standards.
It has taken them long enough, and now it's time to find the laggards and get them fixed. ® Sponsored: Customer Identity and Access Management

Adult FriendFinder Hack Exposes 400 Million Accounts

Account data for more than 400 million users of adult-themed FriendFinder Network has been exposed.

The breach includes personal account data from five sites including Adult FriendFinder, Penthouse.com and Stripshow.com.

FriendFinder Network did not confirm the breach and is investigating reports. According to LeakedSource, which obtained the data and reported the breach Sunday, a total of 412 million accounts are impacted. LeakedSource reports that the hack occurred in the October 2016 timeframe and was not related to a similar breach at that time by hacker Revolver. In a statement issued to Threatpost, FriendFinder Network said: “Our investigation is ongoing but we will continue to ensure all potential and substantiated reports of vulnerabilities are reviewed and if validated, remediated as quickly as possible.” According to the statement, the company has received a number of reports of “potential” security vulnerabilities from a “variety of sources” over the past several weeks.
It says it has hired external resources to support its investigation. According to a news report by ZDNet, this most recent breach was conducted by an “underground Russian hacking site” that took advantage of a local file inclusion flaw first revealed by Revolver in October. A local file inclusion vulnerability can allow a hacker to add local files to web servers via script and execute code. Hackers can take advantage of a LFI vulnerability when sites allow user-supplied input without proper validation, something Adult FriendFinder is guilty of, according to an October interview by Threatpost with Revolver, who also goes by the handle 1×0123. In the case of the FriendFinder Network, Dale Meredith, ethical hacking expert and author at Pluralsight, hackers implemented a LFI allowing them to move folder structures on targeted servers in what is called a directory transversal. “This means they can issue commands to a system that would allow the attacker to move around and download any file on this computer,” he said. LeakedSource bills itself as independent researchers who run a site that acts as a repository for breached data.

The website sells one-time or paid subscriptions to such breached data.
In May, LeakedSource faced a cease and desist order by LinkedIn for offering a paid subscription to access to 117 million  breached LinkedIn user logins. LeakedSource did not return requests for comment for this story. According to a blog post by LeakedSource, the FriendFinder Network data included 20 years of customer data.

The breach includes data tied to 340 million AdultFriendFinder.com accounts, 62 million accounts from Cams.com, 7 million from Penthouse.com and 15 million “deleted” accounts that were not purged from the databases.

Also impacted was a site called iCams.com and account data for 1 million users. “We have decided that this data set will not be searchable by the general public on our main page temporarily for the time being,” according to the blog post on LeakedSource’s website. According to several independent reviews of the breached data supplied by LeakedSource, the datasets included usernames, passwords, email addresses and dates of last visits.

According to LeakedSource, passwords were stored as plaintext or protected using the weak cryptographic standard SHA-1 hash function.  LeakedSource claims it has cracked 99 percent of the 412 million passwords. This most recent breach follows an unconfirmed breach in October where hacker Revolver who claimed to have compromised “millions” of Adult FriendFinder accounts when he leveraged a local file inclusion vulnerability used to access the site’s backend servers.
In 2015, more than 3.5 million Adult FriendFinder customers had intimate details of their profiles exposed.

At the time, hackers put user records up for sale on the Dark Web for 70 Bitcoin, or $16,000 at the time.

According to third-party reviews of this most recent FriendFinder Network breach, no sexual preference data was contained in the breached data. In 2012, the website MilitarySingles.com fell victim to a similar local file inclusion vulnerability.

The social network said, at the time, the vulnerability was tied to user generated content uploaded to the site. “Allowing the upload of user-generated content to the Web site can be extremely dangerous as the server which is usually considered by other users and the application itself as ‘trusted’ now hosts content that can be generated by a malicious source,” MilitarySingles.com said in a statement at the time of the intrusion.

Stupid encryption mistakes criminals make

Writing secure code can be challenging, and implementing cryptography correctly in software is just plain hard.

Even experienced developers can get tripped up.

And if your goal is to swindle people quickly, not to wow them with the quality of your software, there are sure to be serious crypto mistakes in your code. Malware authors may provide significant lessons in how not to implement cryptography.
Such was the upshot of research by Check Point’s Yaniv Balmas and Ben Herzog at the recent Virus Bulletin conference in Denver. Malware authors may be more likely to insert crypto doozies in their code than developers working on legitimate software because they may not care as much about code quality or design, said Balmas and Herzog.

These criminals are focused on getting a product that does enough to satisfy their immediate requirements -- and no more. Here’s a look at the crypto mistakes of recent malware headliners -- and how to identify similar missteps in future malware scripts in hopes of cracking their malicious code. Fuzzy-headed thinking on crypto Mistakes are inevitable when you have only a “fuzzy understanding of the details” and a very tight time frame.

Analyzing the work of malware authors, Balmas and Herzog identified four “anti-patterns,” when it came to implementing encryption, including voodoo programming, cargo cult technique, reinventing the square wheel, and bluffing.

Defenders who uncover hints of these categories of mistakes can break the encryption and hinder malware execution, or they can uncover its secrets via reverse-engineering. “These are basic misunderstandings of how to use cryptographic tools properly, which at best broadcast, ‘I have no idea what I am doing,’ and at worst, catastrophically cripple the malware such that it does not actually do what it set out to do,” Balmas and Herzog wrote. Professional or amateurish, these malware authors recognize that cryptography is increasingly essential to malware development -- in ransomware, to extort money from victims; in hiding communications from the infected device to the command-and-control server; in stealthily evading detection by security tools; and in signing malware as a trusted application.

But analysis shows that many appear to have trouble using encryption effectively, to their detriment.
Security analysts and network administrators who recognize the main classes of cryptographic errors have a big advantage in foiling ransom demands and thwarting infections. “Malware authors compose primitives based on gut feeling and superstition; jump with eagerness at opportunities to poorly reinvent the wheel; with equal eagerness, at opportunities to use ready-made code that perfectly solves the wrong problem,” Balmas and Herzog wrote in the conference whitepaper. No idea what this does, but it looks cool The authors behind the Zeus banking Trojan and Linux-based ransomware Linux.Encoder fell into the “voodoo programming” trap.

Their cryptographic implementation “betrays a deep confusion about the functionality being invoked -- what it is, what it does, and why it might fail,” the researchers said. In the case of Zeus, the authors chose popular stream cipher RC4 to encrypt all Zeus C&C traffic, but added another tweak.

They took the already encrypted stream and modified every byte by XORing it with the next byte. While RC4 has its own security weaknesses, the cipher is secure enough to do what Zeus needed, and the tweaked variant was “exactly as secure as plain, vanilla RC4,” the researchers noted. With Linux.Encoder, the authors seeded the rand() function with the current time stamp to generate its encryption key. When security researchers pointed out that it was really easy to break the ransomware keys, the authors tried generating an AES key by hashing the time stamp eight times. “Using a hash function eight consecutive times on an input shows a deep misunderstanding of what hash functions are,” the researchers wrote, noting that repeating the function does not yield a better hash.
In fact, it could result in “an odd creation that has weaker security properties.” Copy and paste this code I found The second class, “cargo cult programming,” refers to copying what looks like a working solution to the problem and pasting that block of code into the program without understanding why or how the code works.

Copying code isn’t a big deal -- if it was, Stack Overflow wouldn’t exist -- but if the programmer doesn’t know what is actually happening in that block, then the programmer doesn’t know whether the code is actually the correct solution. “[They] might end up using code that performs almost what they had in mind, but not quite,” the researchers wrote, noting that the authors behind the CryptoDefense ransomware fell in this trap. While most of CryptoDefense’s features -- RSA-2048 encryption, payment via bitcoin, communication with C&C servers via Tor -- were copied from the original CryptoLocker ransomware, the actual RSA implementation relied on a low-level cryptographic Windows API.

The actual code can be found in Microsoft Developer Network documentation, along with the explanation that when a flag is not set correctly, the application saves the private key in local key storage.

The CryptoDefense authors didn’t set that flag, so security researchers worked with victims to find the private key on their computers to decrypt the files. Because the malware authors didn’t thoroughly read the documentation, the defenders were able to save the day. Cobble together the code The typical software developer would gladly link to an open source project that handles a necessary task and save the time and effort to write it from scratch. Unfortunately for malware authors, compiling with statically linked third-party code is not always an option, as the extra code can enlarge the resulting executable or make it easier for security tools to detect the malware.
Instead of linking, authors tend to improvise and cobble together something that works.

The groups behind the Nuclear exploit kit and the ransomware families Petya and DirCrypt attempted to “reinvent the square wheel,” and to everyone else’s benefit, they did so poorly. “If you believe anything in cryptography is completely straightforward to implement, either you don’t understand cryptography, or it doesn’t understand you,” the researchers wrote. The widely distributed Nuclear exploit kit obfuscates exploit delivery by using the Diffie-Hellman Key Exchange to encrypt the information passed to the payloads.

The variables needed for the key exchange are sent to the server as a JSON file containing strings of hex digits, and the values are parsed and decoded using Base64. However, the researchers noted the implementation was “absurd” as it set the secret key to 0, rendering the whole process useless. Petra’s authors implemented Salsa20, a lesser-known stream cipher that is considered to be more resistant to attacks than RC4, from scratch. However, three major flaws in Petya’s implementation means the ransomware generates a 512-bit key containing 256 bits of constant and predictable values. “When your implementation of a cipher cuts its effective key size by half, and the required time for a break by 25 orders of magnitude, it’s time to go sit in the corner and think about what you’ve done,” the researchers said. DirCrypt didn’t fare much better, as the authors made the common mistake of reusing the same key when encrypting each file with RC4. Key-reuse is an understandable mistake, especially if the person doesn’t have elementary knowledge of how stream ciphers work and how they can fail. However, the group made a bigger mistake by appending the key to the encrypted file.
Victims could directly access the key and use it recover portions of locked files and, in some case, recover entire files. Fake it The last category isn’t actually a coding mistake, but rather the malware author’s intentional social engineering shortcut. Ransomware authors, for example, don’t need to create the “impeccable cryptographic design and implementation” when it’s far easier to lie, Check Point’s Balmas and Herzog said.

Few victims are going to question the malware’s encryption claims when it comes to retrieving their data. This was the case with Nemucod, a JavaScript Trojan that recently transformed into ransomware, which claimed to encrypt files with RSA-1024 encryption when it was actually using a simple rotating XOR cipher. Nemucod also displays the ransom note before the files are actually encrypted, so if the victim’s antivirus or security tools were vigilant enough to prevent the malware from downloading the encryption components, the files remain intact. Similarly, the ransomware Poshcoder originally used AES, instead of either RSA-2048 or RSA-4096 encryption listed on the ransom note. Poshcoder also claims to use strong asymmetric encryption, except AES is a symmetric cipher and is vulnerable to a number of attacks. The group behind Nemucod believes “would-be adversaries will become light-headed and weak in the knees the moment they hear the phrase ‘RSA-1024,’” the researchers wrote, noting that Nemucod “sets the gold standard for minimal effort.” If the victims are scared enough, they may be less likely to take a closer look at the malware’s capabilities. Take advantage of the mistakes Cryptography is hard, and many software developers screw up when trying to implement encryption.

Consider that the Open Web Application Security Project’s Top 10 list of web application vulnerabilities identifies only two common cryptographic mistakes that developers can make.
It’s no surprise the bad guys are struggling, too. “Evidence heavily suggests that most malware authors view those tools as wondrous black boxes of black magic, and figure they should be content if they can get the encryption code to run at all,” the researchers wrote. It’s tempting to pay the ransom or begin restoring from backup right away when files have been locked by ransomware or to assume that there is no way to break open the communications between an infected endpoint and the malware’s C&C servers.
Security analysts and IT administrators willing to take the time to look for these common mistakes in the offending malware may be able to change the outcome.
Someday, the bad guys will learn how to use encryption properly; until then, the defenders have the edge as they can get around broken implementations and coding errors. Related articles

Be wary of claims that 32 million Twitter passwords are circulating...

Matthew KeysThe jury is still out, but at this early stage, there's good reason to doubt the legitimacy of claims that more than 32 million Twitter passwords are circulating online. The purported dump went live on Wednesday night on LeakedSource, a sit...

JSA10694 – 2015-10 Security Bulletin: Junos: OpenSSL June-July 2015 advisories

The ​OpenSSL project has published a set of security advisories for vulnerabilities resolved in the OpenSSL library in June and July 2015: CVE CVSS v2* base score Summary CVE-2015-1791 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P) Race condition in the ssl3_get_new_session_ticket function in ssl/s3_clnt.c in OpenSSL before 0.9.8zg, 1.0.0 before 1.0.0s, 1.0.1 before 1.0.1n, and 1.0.2 before 1.0.2b, when used for a multi-threaded client, allows remote attackers to cause a denial of service (double free and application crash) or possibly have unspecified other impact by providing a NewSessionTicket during an attempt to reuse a ticket that had been obtained earlier. CVE-2015-1793 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)​ An error in the implementation of the alternative certificate chain logic could allow an attacker to cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.​ CVE-2015-1790 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) The PKCS7_dataDecodefunction in crypto/pkcs7/pk7_doit.c in OpenSSL before 0.9.8zg, 1.0.0 before 1.0.0s, 1.0.1 before 1.0.1n, and 1.0.2 before 1.0.2b allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a PKCS#7 blob that uses ASN.1 encoding and lacks inner EncryptedContent data. CVE-2015-1792 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) The do_free_upto function in crypto/cms/cms_smime.c in OpenSSL before 0.9.8zg, 1.0.0 before 1.0.0s, 1.0.1 before 1.0.1n, and 1.0.2 before 1.0.2b allows remote attackers to cause a denial of service (infinite loop) via vectors that trigger a NULL value of a BIO data structure, as demonstrated by an unrecognized X.660 OID for a hash function. CVE-2015-1788 4.3 (AV:N/AC:M/Au:N/C:N/I:N/A:P) The BN_GF2m_mod_inv function in crypto/bn/bn_gf2m.c in OpenSSL before 0.9.8s, 1.0.0 before 1.0.0e, 1.0.1 before 1.0.1n, and 1.0.2 before 1.0.2b does not properly handle ECParameters structures in which the curve is over a malformed binary polynomial field, which allows remote attackers to cause a denial of service (infinite loop) via a session that uses an Elliptic Curve algorithm, as demonstrated by an attack against a server that supports client authentication. CVE-2015-1789 4.3 (AV:N/AC:M/Au:N/C:N/I:N/A:P) The X509_cmp_time function in crypto/x509/x509_vfy.c in OpenSSL before 0.9.8zg, 1.0.0 before 1.0.0s, 1.0.1 before 1.0.1n, and 1.0.2 before 1.0.2b allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted length field in ASN1_TIME data, as demonstrated by an attack against a server that supports client authentication with a custom verification callback. *CVSS v2 scores provided for backward compatibility with NVD.Junos OS is affected by one or more of these vulnerabilities.  Note that CVE-2014-8176 was also included in an OpenSSL advisory, but no Juniper products use DTLS for communication. ​The following software releases have been​ updated to resolve this specific issue: Junos OS 12.1X44-D55, 12.1X46-D40, 12.1X47-D25​, 12.3R11, 12.3X48-D20, 13.2X51-D40, 13.3R7, 14.1R6, 14.2R4, 15.1R2, 15.1X49-D20​, and all subsequent releases.OpenSSL library has been upgraded to 0.9.8zg in Junos OS 12.1X44-D55, 12.1X46-D40, 12.1X47-D25​, 12.3R11, 12.3X48-D20, 13.2X51-D40 and subsequent releases.OpenSSL library has been upgraded to 1.0.1p in Junos OS 12.1X46-D55, 12.1X47-D45, 12.3X48-D30, 13.3R7, 14.1R6, 14.2R4, 15.1R2, 15.1X49-D20​, and all subsequent releases to resolve all vulnerabilities listed above. Juniper SIRT is not aware of any malicious exploitation of this vulnerability.This issue is being tracked for Junos OS as PRs 1095598, ​1095604​, 1103020 and 1153463 which are visible on the Customer Support website.KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.​​​Since SSL is used for remote network configuration and management applications such as J-Web and SSL Service for JUNOScript (XNM-SSL), viable workarounds for this issue in Junos may include:Disabling J-Web Disable SSL service for JUNOScript and only use Netconf, which makes use of SSH, to make configuration changes Limit access to J-Web and XNM-SSL from only trusted networks How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version.
In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame.

For these cases, Service Releases are made available in order to be more timely.
Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release.

Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.Modification History: 2015-10-14: Initial publication2016-10-05: Update the list of Junos releases which have OpenSSL 1.0.1p or later (i.e added 12.1X46-D55, 12.1X47-D45, 12.3X48-D30). Information for how Juniper Networks uses CVSS can be found at KB16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories"