Monthly Archives: August 2017

Session Hijacking Bug Exposed GitLab Users Private Tokens

GitLab, the popular web-based Git repository manager, fixed a vulnerability recently that could have exposed its users to session hijacking attacks.

Daniel Svartman, a security researcher with Imperva, discovered the issue in May but couldn’t disclose it until Wednesday, after GitLab was able to patch the issue and confirm it had been fixed.

If an attacker had exploited the vulnerability they could have carried out a laundry list of nefarious activities, Svartman told Threatpost on Thursday.

“If an attacker successfully brute-forced an account, the attacker would be able to manage the account, dump the code, perform updates to it, and of course steal potentially sensitive information, such as new versions of software unreleased to the public,” Svartman said, “Also, in other scenarios, by performing updates to the code, the attacker would be able to embed any kind of malware into it.”

The researcher said in a disclosure he knew something was up when he saw his session token in his URL. All he had to do was copy and paste the token around to secure access to GitLab dashboard, account information, individual projects, and even website code.

While having a session token out in the open like that, visible in a URL, is concerning enough, more alarming was Svartman’s second discovery: GitLab uses persistent private session tokens that never expire. If an attacker secured access to a user’s session token it wouldn’t expire, something that could let them stage an attack weeks or months after they stole it, with the victim left none the wiser.

The tokens were also only 20 characters long, something that left them susceptible to brute-forcing, according to the researcher.

“Given their persistent nature and the admin level access they granted, this added up to a real security concern,” Svartman wrote.

It’s unknown how long the vulnerability lingered until it was fixed, but Svartman notes that he wasn’t the first to point it out to GitLab; he also saw it mentioned on the company’s support forums.

When reached Thursday, GitLab told Threatpost there was no indication the vulnerability had been used to compromise an account.

Brian Neel, Security Lead at GitLab stressed that on its own the fact GitLab uses private tokens isn’t a problem.

According to Neel:

“This isn’t something that can be exploited directly. The existence of private tokens only becomes a problem when combined with a cross-site scripting or other vulnerability. Generally speaking, an account with a private token is at no more risk of compromise than if the tokens didn’t exist, unless another vulnerability is leveraged to steal the token. Most modern web services support the concept of a private token: AWS has access/secret keys, GitHub has access tokens, Digital Ocean has tokens, etc. The only real difference between their tokens and our private tokens is that they are limited to the API and typically encrypted. We support both of these options with personal access tokens. GitLab is currently phasing out private tokens in favor of personal access tokens.”

According to Svartman the company is also replacing private tokens with custom RSS tokens for fetching RSS feeds, something that should avoid leaking session IDs. In addition he says the company is “expanding personal access tokens that offer role-based access controls,” something that should bolster security as well.

GitLab fixed a similarly nasty command execution vulnerability in the repository last November, albeit in days, not months. The critical vulnerability could have let an authenticated user gain access to sensitive application files, tokens, or secrets. HackerOne cofounder Jobert Abma found the bug in late October and GitLab issued a fix a week later, on November 2.

from Threatpost – English – Global – thr…

Using Market Pressures to Improve Cybersecurity


Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within …


Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).


Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version…


Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.


Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

from Dark Reading – All Stories

New Facebook, Instagram Bugs Demonstrate Social Media Risk

New Facebook, Instagram Bugs Demonstrate Social Media Risk

Security flaws in Facebook Messenger and Instagram let hackers propagate attacks and steal personal data.

Researchers at Kaspersky Lab recently discovered cyberattacks on Instagram and Facebook Messenger intended to steal credentials and spread malware, respectively. Both instances demonstrate the potential danger when an attacker seeks power in a social network.

The two attacks, while similar in their use of social networks, were otherwise different in nature. The Instagram attacks were manual and targeted high-profile victims. The Facebook campaign used advanced tactics to infect a large and indiscriminate pool of users.

Instagram’s vulnerability exists in mobile version 8.5.1, which was released in 2016. Attackers can simply select “reset password,” capture the request using a Web proxy, select a victim, and submit a request to Instagram’s server with the target’s unique identifier or username. The server returns a JSON response with the victim’s personal data, like email and phone number.

“The attacks are quite labor intensive,” Kaspersky Lab researchers explain. “Each one has to be done manually since Instagram uses mathematical calculations to prevent attackers from automating the request form.”

Hackers were found on an underground forum exchanging personal credentials for celebrity accounts. Researchers reported the bug to Instagram on August 29; on August 30, the photo-sharing app had warned users of the vulnerability and issued a fix. Users are advised to update their apps to the latest version and alert Instagram to emails about password restoration.

David Jacoby, senior security researcher for Kaspersky Lab’s Global Research and Analysis Team, picked up on the Facebook Messenger-driven malware when he received a suspicious note from a distant contact. Within minutes, he realized he had received an advanced form of multi-platform malware/adware, which was using multiple domains to prevent tracking.

Infected messages contain a shortened link, which leads victims to a Google Doc containing an image resembling a fake video player with the sender’s profile photo. Google Chrome users who click the link are redirected to a fake YouTube page, which prompts them to download a fake Chrome extension. If installed, it spreads malicious links to the victims’ online friends.

Chrome was the browser highlighted in a blog post co-authored by Jacoby and Frans Rosén, security advisor at Detectify, who was also investigating the Facebook malware. The two determined it was clear Chrome was a targeted browser for spreading the attack to other victims; in other browsers, ads were displayed and adware was downloaded on the victim’s machine.

Jacoby and Rosén found several Chrome extensions were used in this campaign. All were newly created with stolen code, and similar names, to legitimate extensions. Each contained obfuscated background script that would only fetch an external URL if installed from the Chrome Webstore. Locally installed versions would not trigger an attack.

“The script would like a page on Facebook that was hardcoded in the script,” researchers explain. “This was most likely used by the attackers to count the amount of infected users by keeping an eye on the amount of likes on this page.”

Indeed, when observed, the “like” count quickly rose from 8,900 at one point to 32,000 a few hours later.

Google Chrome’s security team disabled all malicious extensions to stop the spread of attack as much as possible; however, attackers had stolen all the access tokens from victims’ accounts. This means attackers can still access these profiles, even if victims have changed their passwords, signed out, or disabled platform settings.

“We are currently discussing this with Facebook,” Jacoby and Rosén report, “but at the moment it seems like there is no simple way for a victim to revoke the token the attackers stole.”

The Facebook attack heavily relied on realistic social interactions, dynamic user content, and legitimate domains to spread. Researchers advise users to be careful when letting extensions control the bowser, and know which extensions they are running in the browser.

Tip: In Chrome, you can write chrome://extensions/ in your URL field to see a list of enabled extensions.

Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Click for more info and to register.

Related Content:

Kelly Sheridan is Associate Editor at Dark Reading. She started her career in business tech journalism at Insurance & Technology and most recently reported for InformationWeek, where she covered Microsoft and business IT. Sheridan earned her BA at Villanova University. View Full Bio

More Insights

from Dark Reading – All Stories

Bugs in Arris Modems Distributed by AT&T Vulnerable to Trivial Attacks

Trivially exploitable vulnerabilities have been discovered in several Arris home modems, routers and gateways distributed to consumers and small businesses through AT&T’s U-verse service.

It’s unknown yet whether the firmware vulnerabilities were introduced by the OEM or the ISP since AT&T seems to have access to Arris firmware and can customize code on the devices before they’re sent to customers, researchers at security consultancy Nomotion told Threatpost. The researchers uncovered support interfaces easily accessible over SSH, and hidden services exposing the devices to remote and local attacks.

Nomotion security analyst Joseph Hutchins said his firm elected to publicly disclose the vulnerabilities because of their severity and because of Arris’ history with security issues of this sort. A request for comment from Arris was not returned in time for publication.

“Even as early as February, there was another incident where they had similar security issues and their blatant carelessness has gotten out of hand,” said Nomotion CEO Orlando Padilla. “I think with a little bit of pressure, hopefully they’ll fix things up.”

Nomotion also said in a report published today that ISPs are responsible for ensuring the security of their network and equipment leased or sold to consumers.

The most serious of the five flaws affects the NVG589 and NVG599 modems, firmware update 9.2.2h0d83, which enabled SSH by default and also contains hardcoded credentials that afford anyone access to the cshell service on the modem.

Hutchins said cshell is capable of viewing or changing the Wi-Fi SSID or password, modifying network configurations, reflashing firmware from a file served from the internet, or controlling a kernel module that injects ads into unencrypted traffic.

The cshell binary runs as root, meaning that any exploitable command injection or buffer overflow vulnerability will give an attacker root on the device. Nomotion estimates, however, that only 15,000 hosts are vulnerable after a Censys search, a much lower number than the impact posed by some of the other vulnerabilities.

Victimized gateways, meanwhile, can be corralled into a botnet, similar to that used by the Mirai malware to DDoS Dyn and other web-based services last fall. An attacker can also use these bugs to run code on the device to inject ads into traffic, or exploit other vulnerabilities on client devices running on the local network. Hutchins also said that since there’s no certificate pinning, an attacker could force the victim’s browser to accept a certificate from the gateway.

“You have full control of the traffic at that point,” he said.

Nomotion also found default credentials on the NVG599’s caserver HTTPS server running on port 49955, as well as a command injection vulnerability in the same webserver. Hutchins said the server accepts commands that would allow an attacker to upload their own firmware image, and either access or change an internal SDB database configuration. Nomotion estimates from Shodan and Censys searches that around 220,000 devices are vulnerable to this bug alone.

A separate information disclosure vulnerability in a service running on port 61001 would be useful to attackers, but would require them knowing the device serial number in advance in order to make a request.

The final bug affects possibly every AT&T device, all of which have port 49152 open, likely for remote access and support. Nomotion calls it a firewall bypass, and said a predictable three-byte value followed by the MAC address affords an attacker remote access.

“It is believed that the original purpose of this service was to allow AT&T to connect to the AT&T issued DVR devices which reside on the internal LAN. However, it should be painfully obvious by now that there is something terribly wrong with this implementation,” Nomotion wrote in its report. “Added to the severity is the fact that every single AT&T device observed has had this port (49152) open and has responded to probes in the same way.”

Hutchins said the most of the bugs are trivial to exploit.

“There’s no way people are not exploiting this in the wild,” Hutchins said. “It’s so trivial, we just didn’t see any point in going through the process of disclosure to the vendor and the waiting period because we just can’t see anyone not using this in the wild.”

from Threatpost – English – Global – thr…

FDA Recalls 465K Pacemakers Tied to MedSec Research

The United States Federal Drug Administration is recalling 465,000 pacemakers that attackers can gain unauthorized access to issue commands, change settings and maliciously disrupt. Affected are four models manufactured by Abbott Laboratories.

According to the FDA, the recalls of affected pacemakers are tied to research by MedSec Holdings that originally brought St. Jude Medical equipment flaws to light about a year ago. Abbott Laboratories acquired St. Jude Medical in January.

“Abbott has produced a firmware patch to help mitigate the identified vulnerabilities in their pacemakers that utilize radio frequency communications. A third-party security research firm has verified that the new firmware version mitigates the identified vulnerabilities,” according to a FDA.

“This incident is a reminder of how software has become integral to almost every aspect of our lives,” said Mike Pittenger, director of security strategy for security firm Black Duck. “As software ages more vulnerabilities are discovered. Why would software in a pacemaker or in a drug infusion pump be any different?”

The U.S. Industrial Control System Cyber Emergency Response Team (ICS-CERT) cites three vulnerabilities in its advisory affecting Abbott Laboratories’ pacemakers manufactured prior to August, 2017 that include Accent/Anthem, Accent MRI, Assurity/Allure, and Assurity MRI.

The highest rated of the three vulnerabilities (CVE-2017-12712) is related to the pacemaker’s authentication algorithm, authentication key and time stamp that can be compromised or bypassed. That could allow a nearby attacker to issue unauthorized commands to the pacemaker via RF communications.

An additional bug (CVE-2017-12714) could significantly reduce the battery life of a pacemaker. “The pacemakers do not restrict or limit the number of correctly formatted ‘RF wake-up’ commands that can be received, which may allow a nearby attacker to repeatedly send commands to reduce pacemaker battery life,” according to the ICS-CERT advisory.

A third flaw (CVE-2017-12716) found in Accent and Anthem pacemakers is related to the fact the devices transmit unencrypted patient information via RF communications to programmers and home monitoring units. Also problematic is that both pacemakers store patient data in clear text on the devices themselves.

“These vulnerabilities could be exploited via an adjacent network. Exploitability is dependent on an attacker being sufficiently close to the target pacemaker as to allow RF communications,” according to recall information.

This is the second time Abbott Laboratories has updated the heart implants. Last October, as a result of a U.S. government probe into potentially life-threatening hacks that could prematurely drain pacemaker batteries, St. Jude recalled a number of implanted heart devices. According to a Reuters report, premature battery depletion have been linked to two deaths in Europe.

Mitigation will require patients to visit their doctor for a short-range wireless update. Abbott warns the firmware updates should be approached with caution. “Like any software update, firmware updates can cause devices to malfunction,” it states. A botched update could result in a loss of settings to complete loss of device functionality.

In April, the FDA sent Abbott Laboratories a warning letter citing that it had inadequately addressed the security of the maligned Merlin@home Transmitter. The Merlin@home Transmitter is a radio frequency transmitter designed by St. Jude Medical for at-home monitoring of patients with implanted defibrillators.

Vulnerabilities in the Merlin device and in others sold by St. Jude Medical and Abbott Laboratories, were at the center of a report published last August by hedge fund Muddy Waters and MedSec Holdings. The disclosure was compounded by a short position Muddy Waters held on St. Jude Medical stock that allowed it and MedSec to profit should St. Jude stock drop in value.

“Healthcare providers and patients should discuss the risk and benefits of the cybersecurity vulnerabilities and associated firmware update during the next regularly scheduled visit,” according to the FDA recall. As part of this discussion, it is important to determine if the update is appropriate given the risk of update for the patient, ICS-CERT said.

from Threatpost – English – Global – thr…

Verizon Report: Businesses Hit with Payment Card Breaches Not Fully PCI-Compliant

Verizon Report: Businesses Hit with Payment Card Breaches Not Fully PCI-Compliant

Companies struggle to maintain PCI compliance within a year of meeting it, according to a new payment security report by Verizon.

The number of businesses achieving full compliance with their annual Payment Card Industry Data Security Standard (PCI DSS) review reached a record 55.4% last year, but half of companies fall out of compliance within a year, according to the Verizon 2017 Payment Security Report released today.

Even more telling: in all of the nearly 300 payment card data breaches that Verizon investigated in 2010 to 2016, the businesses hit were not fully PCI DSS-compliant at the time of their breach.

“There has been a year-over-year increase in the number of companies that are able to meet the first initial interim validation [first attempt] and that’s great news. But is that good enough?” says Ron Tosto, global manager of the Verizon PCI Advise and Assessment Services. “We know that a number of these companies are not able to stay in compliance and only make it to the nine-month mark.”

[Source: Verizon 2017 Payment Security Report]

Nearly half of companies reviewed by Verizon’s qualified security assessors last year failed to reach full compliance in the initial review.

PCI DSS is comprised of 12 security requirements that businesses are expected to comply with if they accept, process, or store payment card information. And within each of these requirements, there are specific security actions that need to be performed, otherwise known as controls, to remain in compliance. There are over 200 controls in total, and PCI DSS regularly revises them, potentially making it difficult to remain compliant.

Although there are no federal laws that require companies to comply with PCI DSS, banks and the payment card brands such as, Visa, Mastercard, American Express, and Discover, as well as some states, enforce the requirements and will levy fines and penalties for non-compliance. The Payment Card Industry Security Standards Council (PCI SSC), meanwhile, is responsible for managing the standards.

Degree of Difficulty

The report found that nearly half of the companies that pass compliance will fall out of it within a year or sooner. Companies have 60 days from their initial review to become compliant. Once that is achieved, they receive a final PCI DSS compliance report, which must be revaluated again 12 months later.

“Compliance is incredibly challenging because you never fully arrive. It’s a process that must be managed day in and day out. It requires that everyone in the organization own their part in security, which integrates with how they get their job done.” says Dawn Koenninger, a vice president at SOLE Financial, which manages a payroll card program and is currently PCI DSS compliant. “Not easy to do when you’re in high growth mode. You must have buy-in at all levels, but most importantly from the top.” 

The security testing requirement in PCI DSS continues to top the list of requirements that are difficult to comply with. Only 71.9% of companies are able to fully comply with this requirement when initially evaluated, Verizon found. This requirement calls for vulnerability scanning, penetration testing, use of intrusion detection, and file integrity monitoring.

“To be effective, testing has to be on a routine basis and follow any major change to an operating environment. Following the companies have to understand the findings, remediate the issues, then retest the environment,” Tosto says. “Common mistakes include missing periodic testing, taking action to correct security issues found documented in the test report, and not validating the security issue correction with a retest.”

Some companies don’t full grasp the differences between the types of testing within Requirement 11 of the PCI DSS, he notes. He recommends companies fully understand testing and develop testing control effectiveness using the Pin Security Requirements (PSR) as a guide.  

PCI DSS’s requirement #11 – develop and maintain secure systems – and requirement #12, maintain a policy that addresses information security for all personnel, ranked among the second most difficult to achieve full compliance, with each only garnering success among 77.7% of the companies initially evaluated.

Companies that failed their initial compliance review last year were also missing more controls than in the previous year, the report found. Companies were missing an average of 13% of the controls overall last year, whereas the previous year it was 12.4%.

Source of the Pain

Meeting PCI DSS requirements is like training to be a long-distance runner, Tosto says:  “A runner doesn’t show up to run on day one, they practice,” he says.

But he notes there are common challenges companies face to make those “practice” sessions happen. A shortage of IT security workers, an insufficient security budget, and an absence of a process to keep the maintenance of the requirement controls in place, are the three main contributors that make it challenging for companies to meet and maintain PCI DSS compliance, Tosto says.

Troy Leach, chief technology officer of the PCI Security Standards Council, agrees those three challenges can trip up a company in their compliance efforts, especially the one when it comes to developing a maintainable process.

When the person heading up a business’ PCI compliance process leaves the company, for example, that can disrupt compliance, he says, as can a merger. A documented process should be put in place, he notes.

“Your people and technology may change, but if the process remains the same, it will not have as great of an impact,” Leach says.

Avivah Litan, a Gartner analyst, says budget and funding to fulfill the PCI DSS requirements weigh heavy on the minds of CISOs. “When I talk to CISOs in the hotel and restaurant industries, they are frustrated they can’t get the CEO’s support,” Litan says. “They [CEOs] say, ‘why fund it when we haven’t had a breach?'”

Verizon’s report shows that IT services achieved the highest level of compliance, with 61.3% hitting the mark during evaluation process, followed by financial services, 59.1%; and retail, 50%. Less than 43% of the hospitality industry, which includes hotels, was compliant.

Litan says PCI DSS compliance should fall on the payment card brands and banks – not on merchants. “The standards are unrealistic for merchants to meet because this is not their business and core competency,” she says. “It should fall on the banks to develop a secure system.”

Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Click for more info and to register.

Related Content:


Dawn Kawamoto is an Associate Editor for Dark Reading, where she covers cybersecurity news and trends. She is an award-winning journalist who has written and edited technology, management, leadership, career, finance, and innovation stories for such publications as CNET’s … View Full Bio

More Insights

from Dark Reading – All Stories

Pacemaker gets firmware update – go and see your doctor

When a cardiac pacemaker or defibrillator is implanted into a patient, thin, flexible wires called leads are attached to deliver electric shock from the pulse generator directly to the heart.

Those leads sometimes fail. Sometimes, they get infected. Other times, they’re recalled. Removal involves surgery – a complex, delicate procedure that risks damage to the heart tissue.

So what happens when the manufacturer of an internet-connected, radio frequency (RF)-enabled pacemaker finally, begrudgingly stops fighting and litigating over potentially life-threatening attacks and issues a firmware fix for its pacemakers?

Fortunately, it’s not open heart surgery, though it will entail an in-person trip to a healthcare provider’s office.

Abbott (formerly St. Jude Medical) fixed the software side of the security vulnerabilities in January. Now, on Monday, it got to the vulnerabilities in the devices themselves.

In a Dear Doctor letter, Abbott described the firmware update as a three-minute process, during which the pacemaker will operate in backup mode, pacing at 67 beats per minute.

Essential, life-sustaining features will remain available. At the completion of the update, the device will return to its pre-update settings.

Abbott said that with any firmware update, there’s always a (low) risk of an update glitch. Based on the company’s previous firmware update experience, installing the updated firmware could potentially result in the following malfunctions, with the tiny rates of occurrence that St. Jude Medical has previously observed:

  • 0.161% chance of reloading of previous firmware version due to incomplete update
  • 0.023% chance of loss of currently programmed device settings
  • 0% (as in, none have been reported on other firmware upgrades) loss of diagnostic data
  • 0.003% chance of complete loss of device functionality

That last one may seem like a vanishingly small potential, but it’s a dire one. Pacemaker failure has two outcomes, depending on how well the patient’s heart works: you get sick, or you die.

But fortunately, that tiny chance of pacemaker failure will likely be smaller still, given that both Abbott and the US Food and Drug Administration (FDA) say they’re not recommending prophylactic removal and replacement of affected devices.

Here’s the list of St. Jude’s/Abbott’s affected implantable cardiac pacemakers, including cardiac resynchronization therapy pacemaker (CRT-P) devices:

  • Accent
  • Anthem
  • Accent MRI
  • Accent ST
  • Assurity
  • Allure

We’re talking about a total of 465,000 implanted devices that are affected by the firmware flaws, which leave the devices vulnerable to tampering that could cause them to pace at potentially dangerous rates or fail by rapidly draining their batteries.

In January, St. Jude had announced security updates for its Merlin remote monitoring system, which is used with implantable pacemakers and defibrillator devices.

The fixes were designed to reduce what St. Jude claimed to be extremely low cyber-security risks.

At the time, the pacemaker company said it was unaware of any security incidents related to, nor any attacks explicitly targeting, its devices. The same was true as of this week: there have been no known security incidents.

Well, that’s a blessing. Still, that January software update addressed some, but not all, known cyber-security problems in the heart devices. The holes left in place by the incomplete fix were those in the firmware. They were deemed to be pretty serious: Matthew Green, an assistant professor at John Hopkins University, described the pacemaker vulnerability scenario as the fuel of nightmares: for one, weak authentication protocol left the devices open to commands sent via RF, from a distance, leaving no trace, by anybody who knows the protocol (including home devices).

After installing the update that Abbott made available on Tuesday, any device attempting to communicate with the implanted pacemaker would have to provide authorization – received from the Merlin Programmer and Merlin@home Transmitter – to do so.

Pacemakers manufactured from August 28 2017 will have this update pre-loaded in the device and won’t need the update.

Abbott and the FDA are recommending that doctors discuss the risks and benefits of the vulnerabilities and the firmware update with their patients at their next regularly scheduled visit. They’re saying that it’s important to consider factors such as each patient’s level of pacemaker dependence, the age of the device, and patient preference.

Their suggestions:

  • For pacing-dependent patients, consider performing the firmware update in a facility where temporary pacing and pacemaker generator can be readily provided.
  • Print or digitally store the programmed device settings and the diagnostic data in case of loss during the update.
  • After the update, confirm that the device maintains its functionality, is not in backup mode, and that the programmed parameters have not changed.

from Naked Security – Sophos