Insecure Socket Layer | TechSNAP 265

Posted on: May 5, 2016

A critical flaw in that bit of software tucked far far away that you never think about… Until now, we explain why ImageTragick is a pain. More OpenSSL flaws & fraudsters stealing tax data from the motherload.

Plus great questions, our answers, a packed Round up & more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Critical flaw found in ImageMagick

ImageMagick is a very popular suite of applications for working with images
It is used by many websites, to process, convert, and resize uploaded images
It is used for photos, avatars, and any other type of image a website might process
“There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.”
“If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities by doing at least one of these two things (but preferably both!):”
Verify that all image files begin with the expected “magic bytes” corresponding to the image file types you support before sending them to ImageMagick for processing. (see FAQ for more info)
Use a policy file to disable the vulnerable ImageMagick coders. The global policy for ImageMagick is usually found in “/etc/ImageMagick”. The below policy.xml example will disable the coders EPHEMERAL, URL, MVG, and MSL.
A first draft of the fix was released as ImageMagick to 6.9.3-9, on 2016-04-30
However, it is not clear that this entirely resolves the problem
“Insufficient filtering for filename passed to delegate’s command allows remote code execution during conversion of several file formats.”
“ImageMagick allows to process files with external libraries. This feature is called ‘delegate’. It is implemented as a system() with command string (‘command’) from the config file delegates.xml with actual value for different params (input/output filenames etc). Due to insufficient %M param filtering it is possible to conduct shell command injection. One of the default delegate’s command is used to handle https requests:”
“wget” -q -O “%o” “https:%M”
If instead of a URL, you provide say: https://example.com;ls -la
It runs your command in addition to the normal operation, allowing the attacker to run any command they wish
“The most dangerous part is ImageMagick supports several formats like svg, mvg, and maybe some others – which allow to include external files from any supported protocol including delegates. As a result, any service, which uses ImageMagick to process user supplied images and uses default delegates.xml / policy.xml, may be vulnerable to this issue.”
Why are you disclosing a vulnerability like this?
“We have collectively determined that these vulnerabilities are available to individuals other than the person(s) who discovered them. An unknowable number of people having access to these vulnerabilities makes this a critical issue for everyone using this software. ImageMagick also disclosed this on their forum a few hours ago.”
Additional Coverage – OSS Security List
Additional Coverage – Ars Technica – Huge number of sites imperiled by critical image-processing vulnerability [Updated]

Fraudsters steal tax and salary data from ADP

“Identity thieves stole tax and salary data from payroll giant ADP by registering accounts in the names of employees at more than a dozen customer firms”
“ADP says the incidents occurred because the victim companies all mistakenly published sensitive ADP account information online that made those firms easy targets for tax fraudsters.”
“ADP provides payroll, tax and benefits administration for more than 640,000 companies”
“Last week, U.S. Bancorp (U.S. Bank) — the nation’s fifth-largest commercial bank — warned some of its employees that their W-2 data had been stolen thanks to a weakness in ADP’s customer portal.”
“ID thieves are interested in W-2 data because it contains much of the information needed to fraudulently request a large tax refund from the U.S. Internal Revenue Service (IRS) in someone else’s name.”
US Bancorp: “Since April 19, 2016, we have been actively investigating a security incident with our W-2 provider, ADP. During the course of that investigation we have learned that an external W-2 portal, maintained by ADP, may have been utilized by unauthorized individuals to access your W-2, which they may have used to file a fraudulent income tax return under your name.”
“The incident originated because ADP offered an external online portal that has been exploited. For individuals who had never used the external portal, a registration had never been established. Criminals were able to take advantage of that situation to use confidential personal information from other sources to establish a registration in your name at ADP. Once the fraudulent registration was established, they were able to view or download your W-2.”
“ADP emphasized that the fraudsters needed to have the victim’s personal data — including name, date of birth and Social Security number — to successfully create an account in someone’s name. ADP also stressed that this personal data did not come from its systems, and that thieves appeared to already possess that data when they created the unauthorized accounts at ADP’s portal.”
“According to ADP, new users need to be in possession of two other things (in addition to the victim’s personal data) at a minimum in order to create an account: A custom, company-specific link provided by ADP, and a static code assigned to the customer by ADP.”
“The problem, ADP Chief Security Officer Roland Cloutier said, seems to stem from ADP customers that both deferred the signup process for some or all of their employees and at the same time inadvertently published online the link and the company code. As a result, for users who never registered, criminals were able to register as them with fairly basic personal info, and access W-2 data on those individuals.”
“We viewed the code as an identification code, not as an authentication code, and we posted it to a Web site for the convenience of our employees so they could access their W-2 information,” Ripley said. “We have discontinued that practice.”
A secret can only be protected if everyone that possesses it, knows it is a secret
“ADP’s portal, like so many other authentication systems, relies entirely on static data that is available on just about every American for less than $4 in the cybercrime underground (SSN/DOB, address, etc). It’s true that companies should know better than to publish such a crucial link online along with the company’s ADP code, but then again these are pretty weak authenticators.”
“Cloutier said ADP does offer an additional layer of authentication — a personal identification code (PIC) — basically another static code that can be assigned to each employee. He added that ADP is trialing a service that will ask anyone requesting a new account to successfully answer a series of questions based on information that only the real account holder is supposed to know.”
Of course, “supposed to know” is the problem
The IRS learned this the hard way, and has already had to replace 2 different authentication systems because the ‘knowledge based authentication’ questions were easily guessed by attackers
“It’s truly a measure of the challenges ahead in improving online authentication that so many organizations are still looking backwards to obsolete and insecure approaches. ADP’s logo includes the clever slogan, “A more human resource.” It’s hard to think of a more apt mission statement for the company. After all, it’s high time we started moving away from asking people to robotically regurgitate the same static identifiers over and over, and shift to a more human approach that focuses on dynamic elements for authentication. But alas, that’s fodder for a future post.”
Apparently Kreb’s report caused a large temporary dip in ADP’s stock price

Another OpenSSL Advisory

More fun with OpenSSL
Memory corruption in the ASN.1 encoder (CVE-2016-2108) [HIGH]
The advisory notes that the most severe of the issues was partially fixed over a year ago: “This issue affected versions of OpenSSL prior to April 2015. The bug causing the vulnerability was fixed on April 18th 2015, and released as part of the June 11th 2015 security releases. The security impact of the bug was not known at the time.”
However, because of a second bug, this issue turned out to be a critical flaw
Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) [HIGH]
- “This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes.”
In both of these cases it seems that, in a rush to fix a bug, a further flaw was created
Additional Fixes:
EVP_EncodeUpdate overflow (CVE-2016-2105) [LOW]
EVP_EncryptUpdate overflow (CVE-2016-2106) [LOW]
ASN.1 BIO excessive memory allocation (CVE-2016-2109) [LOW]
EBCDIC overread (CVE-2016-2176) [LOW]
Note: support for OpenSSL version 1.0.1 will cease on 31st December 2016. Support for versions 0.9.8 and 1.0.0 already ended on 31st December 2015. Those versions are no longer receiving security updates.
Additional Coverage: Ars Technica

How do fraudsters get the CVV number for your credit card?

“A longtime reader recently asked: “How do online fraudsters get the 3-digit card verification value (CVV or CVV2) code printed on the back of customer cards if merchants are forbidden from storing this information? The answer: If not via phishing, probably by installing a Web-based keylogger at an online merchant so that all data that customers submit to the site is copied and sent to the attacker’s server.”
The CVV is the 3 (or 4 in the case of AMEX) digit number on the back of your credit card
This number is not normally used for “card present” transactions, like checking out at the supermarket
The CVV is designed for “card not present” transactions, like shopping online
The idea was, this number was NEVER to be stored, so even in the event of a credit card database breach, the attackers would not get the CVV number, and so could not use the stolen cards in online transactions
The CVV is basically how you prove that you have the card in your hands
This of course works in theory, but just because merchants are not SUPPOSED to not store the CVV, doesn’t mean they don’t
“The vast majority of the time, this CVV data has been stolen by Web-based keyloggers. This is a relatively uncomplicated program that behaves much like a banking Trojan does on an infected PC, except it’s designed to steal data from Web server applications.”
“PC Trojans like ZeuS, for example, siphon information using two major techniques: snarfing passwords stored in the browser, and conducting “form grabbing” — capturing any data entered into a form field in the browser before it can be encrypted in the Web session and sent to whatever site the victim is visiting.”
“Web-based keyloggers also can do form grabbing, ripping out form data submitted by visitors — including names, addresses, phone numbers, credit card numbers and card verification code — as customers are submitting the data during the online checkout process.”
“These attacks drive home one immutable point about malware’s role in subverting secure connections: Whether resident on a Web server or on an end-user computer, if either endpoint is compromised, it’s ‘game over’ for the security of that Web session. With PC banking trojans, it’s all about surveillance on the client side pre-encryption, whereas what the bad guys are doing with these Web site attacks involves sucking down customer data post- or pre-encryption (depending on whether the data was incoming or outgoing).”