Swisscom data breach Hits 800,000 Customers, 10% of Swiss population
9.2.2018 securityaffairs Incindent
Swisscom data breach – Telco company Swisscom confirmed it has suffered a data breach that affected roughly 800,000 of its customers, roughly 10% of the Swiss population.
Swiss telco company Swisscom confirmed it has suffered a data breach that affected roughly 800,000 of its customers, roughly 10% of the Swiss population.
According to Swisscom, unauthorized parties gained access to data in Autumn, the attackers accessed the customers’ records using a sales partner’s credentials.
The security breach was discovered by Swisscom during a routine check, most of the exposed data are related to the mobile services subscribers.
“In autumn of 2017, unknown parties misappropriated the access rights of a sales partner, gaining unauthorised access to customers’ name, address, telephone number and date of birth. Under data protection law this data is classed as “non-sensitive”.” reads the press release issued by the company.
“Prompted by this incident, Swisscom has now also tightened security for this customer information. The data accessed included the first and last names, home addresses, dates of birth and telephone numbers of Swisscom customers; contact details which, for the most part, are in the public domain or available from list brokers.”
Exposed data includes names, physical addresses, phone numbers, and dates of birth, the telecom giant collects this type of data when customers subscribe an agreement.
It is not clear how the hackers obtained the credentials, the good news is that sales partners are allowed to access only information for customers’ identification and to manage contracts.
Swisscom highlighted that data accessed by the intruders are not considered sensitive under data protection laws, anyway, accessed info is a precious commodity in the criminal underground because crooks can use them to conduct phishing campaigns against the company’s customers.
Swisscom has reported the data breach to the Swiss Federal Data Protection and Information Commissioner (FDPIC).
“Swisscom stresses that the system was not hacked and no sensitive data, such as passwords, conversation or payment data, was affected by the incident,” continues the press release.“Rigorous long-established security mechanisms are already in place in this case.”
After the Swisscom data breach, the company revoked the credentials used to access its systems and implemented tighter controls for partners.
Swisscom implemented a number of changes to improve its security, including:
Access by partner companies will now be subject to tighter controls and any unusual activity will automatically trigger an alarm and block access.
In the future, it will no longer be possible to run high-volume queries for all customer information in the systems.
In addition, two-factor authentication will be introduced in 2018 for all data access required by sales partners.
Customers are advised to report any suspicious calls or email.
The source code of the Apple iOS iBoot Bootloader leaked online
9.2.2018 securityaffairs Apple
The source code for Apple iOS iBoot secure bootloader has been leaked to GitHub, now we will try to understand why this component is so important for the iOS architecture.
The iBoot is the component loaded in the early stages of the boot sequence and it is tasked with loading the kernel, it is stored in a boot ROM chip.
“This is the first step in the chain of trust where each step ensures that the next is signed by Apple.” states Apple describing the iBoot.
The leaked code is related to iOS 9, but experts believe it could still present in the latest iOS 11.
Apple promptly reacted to the data leak asking to remove the content for a violation of the Digital Millennium Copyright Act (DMCA).
“This repository is currently disabled due to a DMCA takedown notice. We have disabled public access to the repository. The notice has been publicly posted.” reads the notice on the GitHub repository.
“Reproduction of Apple’s “iBoot” source code, which is responsible for ensuring trusted boot operation of Apple’s iOS software. The “iBoot” source code is proprietary and it includes Apple’s copyright notice. It is not open-source.”
The data leak is considered very dangerous because hackers and security experts can analyze the code searching for security vulnerabilities that could be triggered to compromise the iBoot.
Even is the code cannot be modified, the exploit of a flaw could allow loading other components compromising the overall security of the architecture.
The boot sequence is:
Bootrom → Low Level Bootloader → iBoot → Device tree → Kernel.
The Jailbreak consists of compromising one of the above phases, typically the kernel one.
Newer iPhones have an ARM-based coprocessor that enhances iOS security, so-called Secure Enclave Processor, it makes impossible the access to the code to conduct reverse engineering of the code.
But now the iBoot code has been leaked online and experts can analyze it.
The jailbreak could allow removing security restrictions making it possible to install third-party software and packages, also code that is not authorized by Apple and therefore not signed by the IT giant.
Compromising the iBoot could theoretically allow loading any malicious code in the boot phase or a tainted kernel.
Apple tried to downplay the issue saying that it implements a layered model of security
“Old source code from three years ago appears to have been leaked, but by design the security of our products doesn’t depend on the secrecy of our source code. There are many layers of hardware and software protections built into our products, and we always encourage customers to update to the newest software releases to benefit from the latest protection,” reads a statement issued by Apple.
Researcher found multiple vulnerabilities in NETGEAR Routers, update them now!
9.2.2018 securityaffairs Vulnerebility
Security researchers Martin Rakhmanov from Trustwave conducted a one-year-study on the firmware running on Netgear routers and discovered vulnerabilities in a couple of dozen models.
Netgear has just released many security updates that address vulnerabilities in a couple of dozen models.
The vulnerabilities have been reported by security researchers Martin Rakhmanov from Trustwave, which conducted a one-year-study on the firmware running on Netgear’s box.
Users are recommended to apply the security patches as soon as possible, they can be exploited by hackers to compromise gateways and wireless points.
The expert discovered that 17 different Netgear routers are affected by a remote authentication bypass that could be exploited by a remote attacker to access target networks without having to provide a password.
“This also affects large set of products (17 total) and is trivial to exploit. Authentication is bypassed if “&genie=1″ is found within the query string.” reads the analysis published by Rakhmanov.
Yes, it’s right, an attacker just needs to append the “&genie=1” the URL to bypass authentication, of course, the attack works against any gateways with remote configuration access enabled.
Attackers can access the device changing its DNS settings to redirect browsers to malicious sites.
Another 17 Netgear routers are affected by Password Recovery and File Access vulnerabilities. The flaws reside in the genie_restoring.cgi script used by the Netgear box’s built-in web server, the vulnerability can be triggered to extract files and passwords from its filesystem in flash storage and to pull files from USB sticks plugged into the router.
“Some routers allow arbitrary file reading from the device provided that the path to file is known. Proof-of-concept for Nighthawk X8 running firmware 1.0.2.86 or earlier:
curl -d “id=304966648&next_file=cgi-bin/../../tmp/mnt/usb0/part1/README.txt” http://192.168.1.1/genie_restoring.cgi?id=304966648
The above will fetch README.txt file located on a USB thumb drive inserted into the router. Total of 17 products are affected. Specific models are listed in the Advisory notes.” continues the analysis.
The list of issues discovered by the researcher includes a command Injection Vulnerability on D7000, EX6200v2, and Some Routers, PSV-2017-2181. After pressing the WPS button, the Netgear routers allows for two minutes a remote attacker to execute arbitrary code on the box with root privileges.
“Only 6 products are affected, this allows to run OS commands as root during short time window when WPS is activated.” states the analysis.
UDPOS PoS malware exfiltrates credit card data DNS queries
9.2.2018 securityaffairs Virus
A new PoS malware dubbed UDPoS appeared in the threat landscape and implements a novel and hard to detect technique to steal credit card data from infected systems.
The UDPoS malware was spotted by researchers from ForcePoint Labs, it relies upon User Datagram Protocol (UDP) DNS traffic for data exfiltration instead of HTTP that is the protocol used by most POS malware.
The UDPoS malware is the first PoS malicious code that implements this technique disguises itself as an update from LogMeIn, which is a legitimate remote desktop control application.
“According to our investigation, the malware is intended to deceive an unsuspecting user into executing a malicious email, link or file, possibly containing the LogMeIn name,” reads a blogpost published by LogMeIn noted.
“This link, file or executable isn’t provided by LogMeIn and updates for LogMeIn products, including patches, updates, etc., will always be delivered securely in-product. You’ll never be contacted by us with a request to update your software that also includes either an attachment or a link to a new version or update.”
The UDPoS malware only targets older POS systems that use LogMeIn.
“However, in amongst the digital haystack there exists the occasional needle: we recently came across a sample apparently disguised as a LogMeIn service pack which generated notable amounts of ‘unusual’ DNS requests. Deeper investigation revealed something of a flawed gem, ultimately designed to steal magnetic stripe payment card data: a hallmark of PoS malware.” reads the analysis published by ForcePoint.
The command and control (C&C) server are hosted by a Swiss-based VPS provider, another unusual choice for such kind of malware.
The server hosts a 7-Zip self-extracting archive, update.exe, containing LogmeinServicePack_5.115.22.001.exe and log that is the actual malware.
The malicious code implements a number of evasion techniques, it searches for antivirus software disables them, it also checks if it is running in a virtualized environment.
“For the anti-AV and anti-VM solution, there are four DLL and three Named Pipe identifiers stored in both service and monitor components:
However, only the monitor component makes use of these and, moreover, the code responsible for opening module handles is flawed: it will only try to open cmdvrt32.dll – a library related to Comodo security products – and nothing else.” continues the analysis.
“It is unclear at present whether this is a reflection of the malware still being in a relatively early stage of development/testing or a straightforward error on the part of the developers.”
It must be highlighted that currently there is no evidence of the UDPoS malware currently being used in attacks in the wild, but the activity of the C&C servers suggests crooks were preparing the attacks.
In the past other malware adopted the DNS traffic to exfiltrate data, one of them is the DNSMessenger RAT spotted by Talos experts in 2017. The researchers from Cisco Talos team spotted the malware that leverages PowerShell scripts to fetch commands from DNS TXT records.
Further info about the UDPoS malware, including IoCs, are available in the blog post.
Apple's iBoot Source Code for iPhone Leaked on Github
8.2.2018 thehackernews Apple
Apple source code for a core component of iPhone's operating system has purportedly been leaked on GitHub, that could allow hackers and researchers to discover currently unknown zero-day vulnerabilities to develop persistent malware and iPhone jailbreaks.
The source code appears to be for iBoot—the critical part of the iOS operating system that's responsible for all security checks and ensures a trusted version of iOS is loaded.
In other words, it's like the BIOS of an iPhone which makes sure that the kernel and other system files being booted whenever you turn on your iPhone are adequately signed by Apple and are not modified anyhow.
The iBoot code was initially shared online several months back on Reddit, but it just resurfaced today on GitHub (repository now unavailable due to DMCA takedown). Motherboard consulted some security experts who have confirmed the legitimacy of the code.
However, at this moment, it is unclear if the iBoot source code is completely authentic, who is behind this significant leak, and how the leaker managed to get his/her hands on the code in the first place.
The leaked iBoot code appears to be from a version of iOS 9, which signifies that the code is not entirely relevant to the latest iOS 11.2.5 operating system, but some parts of the code from iOS 9 are likely still used by Apple in iOS 11.
"This is the SRC for 9.x. Even though you can’t compile it due to missing files, you can mess with the source code and find vulnerabilities as a security researcher. It also contains the bootrom source code for certain devices…," a security expert said on Twitter.
The leaked source code is being cited as "the biggest leak in history" by Jonathan Levin, the author of a number of books on iOS and macOS internals. He says the leaked code seems to be the real iBoot code as it matches with the code he reverse-engineered himself.
Apple has open sourced some portions of macOS and iOS in recent years, but the iBoot code has been carefully kept private.
As Motherboard points out, the company treats iBoot as integral to the iOS security system and classifies secure boot components as a top-tier vulnerability in its bug bounty program, offering $200,000 for each reported vulnerability.
Therefore, the leaked iBoot code can pose a serious security risk, allowing hackers and security researchers to dig into the code to hunt for undisclosed vulnerabilities and write persistent malware exploits like rootkits and bootkits.
Moreover, jailbreakers could find something useful from the iBoot source code to jailbreak iOS and come up with a tethered jailbreak for iOS 11.2 and later.
It is worth noting that newer iPhones and other iOS devices ship with Secure Enclave, which protects against some of the potential issues that come with the leaked iBoot source code. So, I really doubt that the leaked code will be of much help.
Apple has yet to comment on the recent leak, though Github has already disabled the repository that was hosting the iBoot code after the company issued a DMCA takedown notice. However, the code is already out there.
We will update the article if we learn more.
Intel Releases New Spectre Patch Update for Skylake Processors
8.2.2018 thehackernews Vulnerebility
After leaving million of devices at risk of hacking and then rolling out broken patches, Intel has now released a new batch of security patches only for its Skylake processors to address one of the Spectre vulnerabilities (Variant 2).
For those unaware, Spectre (Variant 1, Variant 2) and Meltdown (Variant 3) are security flaws disclosed by researchers earlier last month in processors from Intel, ARM, and AMD, leaving nearly every PC, server, and mobile phone on the planet vulnerable to data theft.
Shortly after the researchers disclosed the Spectre and Meltdown exploits, Intel started releasing microcode patches for its systems running Broadwell, Haswell, Skylake, Kaby Lake, and Coffee Lake processors.
However, later the chip maker rollbacked the firmware updates and had to tell users to stop using an earlier update due to users complaining of frequent reboots and other unpredictable system behavior after installing patches.
Although it should be a bit quicker, Intel is currently working on new patches and already in contact with hardware companies so that they can include the new microcode patch in their new range of firmware updates.
So far, the new microcode update only addresses devices equipped with mobile Skylake and mainstream desktop Skylake chips, leaving the Broadwell, Haswell, Kaby Lake, Skylake X, Skylake SP, and Coffee Lake processors still vulnerable to Spectre (Variant 2) vulnerability.
So, everyone else still has to wait for the company to release microcode updates for their systems.
"Earlier this week, we released production microcode updates for several Skylake-based platforms to our OEM customers and industry partners, and we expect to do the same for more platforms in the coming days," the company says in a blog post.
"We also continue to release beta microcode updates so that customers and partners have the opportunity to conduct extensive testing before we move them into production."
Intel has strongly urged its customers to install this update as soon as possible, because if not patched, these processor vulnerabilities could allow attackers to bypass memory isolation mechanisms and access everything, including memory allocated for the kernel containing sensitive data like passwords, encryption keys, and other private information.
Moreover, after the release of proof-of-concept (PoC) exploit for the CPU vulnerabilities last month, hundreds of malware samples are spotted in the wild, most of which are based on the publicly released exploit and designed to work on major operating systems and web browsers.
Although we have not yet seen any fully-featured malware based on Spectre and Meltdown vulnerabilities, it doesn't take much time for hackers to develop one.
So, users are urged to always keep a close eye on any update that becomes available on their system, and install them as soon as they become available.
Source Code of iOS Security Component iBoot Posted on GitHub
8.2.2018 securityweek Apple
What appears to be the source code of iBoot, a key component of Apple’s iOS platform responsible for trusted boot operation, was posted on GitHub yesterday.
The code was posted on the open-source portal by an individual going by the username of ZioShiba. The repository, labeled iBoot, has since been taken down, after Apple filed a copyright takedown request with GitHub.
The code in question is what loads the iOS, being the first piece of software that runs when an iOS device is turned on. It is responsible for checking the integrity of the platform and whether the kernel is properly signed.
This clearly makes iBoot a critical operating system component, and Apple is aware of that. As part of its bug bounty program, the tech giant is willing to pay as much as $200,000 for critical flaws in secure boot firmware components, the highest award.
Vulnerabilities in the secure boot firmware components can be used to jailbreak devices. Hackers could also abuse them to gain access to vulnerable devices.
In the DMCA Notice sent to GitHub, Apple appears to confirm the legitimacy of the leak.
“Reproduction of Apple's "iBoot" source code, which is responsible for ensuring trusted boot operation of Apple's iOS software. The "iBoot" source code is proprietary and it includes Apple's copyright notice. It is not open-source,” the notice reads.
Following the takedown, the repo is no longer accessible, but its contents were undoubtedly already downloaded by interested parties.
This means that the iBoot source code likely continues to be available online for cybercriminals to abuse to find vulnerabilities they can exploit in attacks.
In fact, flaws in iOS have long already proved highly valuable, with some companies willing to pay millions of dollars for zero-day vulnerabilities in the mobile operating system. In fact, one team of hackers already earned $1 million for such a security bug.
Just like any other operating system out there, iOS isn’t infallible, and the new code leak clearly proves that, Rusty Carter, Vice President of Product Management for Arxan Technology, told SecurityWeek in an emailed comment.
“Apple iOS is widely viewed as the most trusted mobile operating system out there. But the leak of this source code is proof that no environment or OS is infallible, and application protection from within the application itself is crucial, especially for business-critical, data-sensitive applications. It's only a matter of time before the release of this source code results in new and very stealthy ways to compromise applications running on iOS,” Carter said.
SecurityWeek emailed Apple for an official comment and additional details on this incident.
“Old source code from three years ago appears to have been leaked, but by design the security of our products doesn’t depend on the secrecy of our source code. There are many layers of hardware and software protections built into our products, and we always encourage customers to update to the newest software releases to benefit from the latest protections,” an Apple spokesperson said.
Most of the iOS devices out there (93%) are already running newer platform releases, which diminishes any security impact of the leak. In fact, 65% of them run iOS 11, which includes Apple’s latest security improvements.
Apple is also running its own open source program, offering the platform to researchers interested in analyzing it.
*Updated with statement from Apple
Cisco Aware of Attacks Exploiting Critical Firewall Flaw
8.2.2018 securityweek Vulnerebility
Cisco informed customers on Wednesday that it has become aware of malicious attacks attempting to exploit a recently patched vulnerability affecting the company’s Adaptive Security Appliance (ASA) software.
No other information has been provided by the networking giant, but it’s worth noting that a proof-of-concept (PoC) exploit designed to cause a denial-of-service (DoS) condition on devices running ASA software was made public this week.
Cato Networks reported finding roughly 120,000 potentially vulnerable Cisco devices connected to the Internet, with a vast majority located in the United States and Europe.
The ASA software vulnerability, tracked as CVE-2018-0101, allows a remote and unauthenticated attacker to execute arbitrary code or cause a DoS condition.
The flaw affects several products running ASA software, including Firepower firewalls, 3000 series industrial security appliances, ASA 5000 and 5500 series appliances, 1000V cloud firewalls, ASA service modules for routers and switches, and Firepower Threat Defense (FTD) software. Cisco first notified customers about the availability of fixes on January 29.
Cisco initially said the security hole was related to the webvpn feature, but it later discovered that more than a dozen other features were impacted as well. The company released new patches this week after identifying new attack vectors and determining that the original fix had been incomplete.
The details of the vulnerability were disclosed on February 2 by Cedric Halbronn, the NCC Group researcher who reported the issue to Cisco.
“When exploited, this vulnerability known as CVE-2018-0101 allows the attacker to see all of the data passing through the system and provides them with administrative privileges, enabling them to remotely gain access to the network behind it,” NCC Group said. “Targeting the vulnerability without a specially-crafted exploit would cause the firewall to crash and would potentially disrupt the connectivity to the network.”
SecurityWeek has reached out to Cisco to see if the company can provide additional details regarding the malicious attacks and will update this article if the company responds.
Cisco on Wednesday also released new advisories describing several critical and high severity vulnerabilities, including a remote code execution flaw in RV132W ADSL2+ and RV134W VDSL2 routers, a DoS flaw in Cisco Virtualized Packet Core-Distributed Instance (VPC-DI) software, a command execution flaw in UCS Central, and an authentication bypass bug in Cisco Policy Suite.
Google Paid $2.9 Million in Vulnerability Rewards in 2017
8.2.2018 securityweek Vulnerebility
Google paid nearly $3 million to security researchers in 2017 who reported valid vulnerabilities in its products.
The internet giant said that it paid out $1.1 million in rewards for vulnerabilities discovered in Google products, and roughly the same amount to the researchers who reported security bugs in Android. With the bug bounties awarded for Chrome flaws added to the mix, a total of $2.9 million was paid throughout the year.
In the seven years since Google’s Vulnerability Reward Program was launched, the search giant has paid almost $12 million in rewards.
Last year, 274 researchers received rewards for their vulnerability reports, and a total of 1,230 individual rewards were paid, Google says.
“Drilling-down a bit further, we awarded $125,000 to more than 50 security researchers from all around the world through our Vulnerability Research Grants Program, and $50,000 to the hard-working folks who improve the security of open-source software as part of our Patch Rewards Program,” Jan Keller, Google VRP Technical Pwning Master explains in a blog post.
The biggest single reward paid in 2017 was of $112,500. This bug bounty went to researcher Guang Gong, for an exploit chain on Pixel phones, revealed in August 2017. The researcher discovered that it was possible to abuse a remote code execution bug in the sandboxed Chrome render process and a sandbox escape through Android’s libgralloc.
Google also paid a $100,000 pwnium award to researcher “Gzob Qq,” who discovered it was possible to achieve remote code execution in Chrome OS guest mode by leveraging a chain of bugs across five components.
Another award worth mentioning went to Alex Birsan, who discovered access to internal Google Issue Tracker data was open to anyone. The researcher received $15,600 for his efforts.
Last year, Google also worked on advancing the Android and Play Security Reward programs and announced increased top reward for an Android exploit chain (a remote exploit chain – or exploit leading to TrustZone or Verified Boot compromise) to $200,000. The top-end reward for a remote kernel exploit was increased to $150,000.
Now, the company reveals that the range of rewards for remote code executions is being increased from $1,000 to $5,000. Moreover, a new category for vulnerabilities leading to private user data theft, issues where information is transferred unencrypted, and bugs leading to access to protected app components has been included. Researchers can earn $1,000 for such bugs.
Malware is Pervasive Across Cloud Platforms: Report
8.2.2018 securityweek Virus
Leading Cloud Service Providers and Majority of AV Engines Failed to Detect New Ransomware Variant
Cloud Access Security Brokers (CASBs) provide visibility into the cloud. Some CASBs provide malware protection. Some clouds provide malware protection. Bitglass analyzed the efficacy of cloud-only protection by scanning the files of its customers that had not implemented its own Advanced Threat Protection (actually Cylance).
Bitglass scanned tens of millions of customer files and found (PDF) a remarkably high number of infections: 44% of organizations had at least one piece of malware in their cloud applications; and nearly one-in-three SaaS app instances contained at least one threat. Among the SaaS apps, 54.4% of OneDrive and 42.9% of Google Drive instances were infected. Dropbox and Box followed, both at 33%.
The research discovered that the average company had nearly 450,000 files held in the cloud, with more than 20 of the files containing malware. Forty-two percent of the infected file types were script and executable files, 21% were Office documents, 10% were Windows system files, and 8% were compressed formats. The other 19% were in various different file formats.
Among the infections it discovered a malware that Cylance confirmed as a zero-day ransomware -- which it calls ShurL0ckr. ShurL0ckr is ransomware-as-a-service , "meaning," says Bitglass, "the hacker generates a ransomware payload and distributes it via phishing or drive-by-download to encrypt files on disk in a background process until a Bitcoin ransom is paid." No analysis of the malware and its inner workings is provided.
It is, however, undetected by either Microsoft's or Google's cloud offerings.
"The sad truth," comments Meni Farjon, co-founder and CTO at SoleBIT Labs, "is that today, most cloud services providers still do not supply advanced malware detection capabilities, thus making this vector a perfect choice for attackers who aim to infect corporate users on a massive scale. I believe we will definitely see more ransomware variants targeting cloud application in the coming months, at least until the major cloud services providers offer malware detection capabilities to those services."
Bitglass checked whether mainstream anti-malware would detect the ShurL0ckr ransomware. "The team," writes Bitglass, "then leveraged VirusTotal to scrutinize a file containing the ransomware across dozens of antivirus engines. Only 7% of said engines (five in sixty-seven) detected the malware - one of these engines was Cylance, a Bitglass technology partner."
VirusTotal was acquired by Google in 2012.
The key takeaways from this research are that security teams' concerns about cloud security are valid, and there's a new ransomware that goes largely undetected. That last point is, however, not clear cut. The purpose of VirusTotal (VT) is to allow concerned users to gain insight into a suspect file -- could it be, or is it likely not, malicious? It is not an anti-malware comparative tool.
VirusTotal itself says, "Antivirus engines can be sophisticated tools that have additional detection features that may not function within the VirusTotal scanning environment. Because of this, VirusTotal scan results aren't intended to be used for the comparison of the effectiveness of antivirus products."
"In other words," comments ESET senior research fellow David Harley, "a VirusTotal report is not a reliable indicator as to whether a product detects or blocks a given sample out in the field, because VirusTotal doesnít necessarily make use of all the layers of protection made available by a specific product in the real world. To draw any conclusions about the efficacy of any product based on one sample isnít testing at all," he added; "itís just marketing."
Lenny Zeltser, VP of products at Minerva Labs, isn't surprised by the VT engines' low detection rate. "Attackers continually find ways of getting around AV tools, due to the inherent weaknesses of any approach to detecting malicious software on the basis of previously-seen patterns. This is a reality for all types of AV solutions," he told SecurityWeek, "regardless of whether they employ AI or not."
He believes that it is reasonable for Bitglass to quote a low VT detection rate because "this research focused on the way in which files stored on cloud services are identified as malware. I believe the providers of such services rely on static scans, which makes VirusTotal a reasonable approximation of AV efficacy in such scenarios. The findings show that organizations cannot rely solely on the scans performed by these providers, and should deploy anti-malware protection to their endpoints as well.î
What we now know is that there is another ransomware to worry about. We know that Cylance can detect it, but we don't know whether other anti-malware products deployed in the field will also catch it -- we do not know that only 7% will detect it. Bitglass hasn't provided any IOCs in its report, so it will be difficult for security teams to check for themselves.
However, since Bitglass uploaded an infected file to VirusTotal, VT will have shared details with its partner AV companies. They will now be making sure that they will detect it in the future -- so it might be useful for security teams to check directly with their own anti-malware provider to make sure they are already covered.
Silicon Valley-based Bitglass raised $45 million in a Series C funding round in January 2017, adding to the $25 million Series B round in 2014.
Swisscom Breach Hits 800,000 Customers
8.2.2018 securityweek Crime
Swiss telecoms giant Swisscom on Wednesday said it had tightened security controls after suffering a data breach that affected roughly 800,000 of its customers.
The company said unauthorized parties gained access to customer data by leveraging the access privileges of a sales partner. The attackers somehow obtained the partner’s credentials and used them to access contact information, including names, physical addresses, phone numbers, and dates of birth.
Swisscom pointed out that it collects this type of data legally from customers when they enter a subscription agreement, and sales partners are given limited access to records for identification and contracting purposes.
The company noted that this type of information is not considered sensitive under data protection laws, and it’s mostly either already in the public domain or in the hands of list brokers.
The data breach has affected approximately 800,000 Swisscom customers, mostly mobile services subscribers. The company said it had detected the incident during a routine check, but an in-depth investigation was launched following its discovery.
“Swisscom stresses that the system was not hacked and no sensitive data, such as passwords, conversation or payment data, was affected by the incident,” Swisscom stated. “Rigorous long-established security mechanisms are already in place in this case.”
While the compromised data is non-sensitive, Swisscom has reported the incident to the Swiss Federal Data Protection and Information Commissioner (FDPIC).
In response to the breach, the company has revoked access for the firm whose credentials were stolen and implemented tighter controls for partners. In the future, Swisscom wants to ensure that high-volume queries for customer information can no longer be run, and introduce two-factor authentication for sales partners when accessing its systems.
The company says it is not aware of any schemes leveraging the stolen data, but it has advised customers to be wary of any suspicious calls.
Joomla 3.8.4 release addresses three XSS and SQL Injection vulnerabilities
8.2.2018 securityaffairs Vulnerebility
Joomla development team has released the Joomla 3.8.4 that addresses many issues, including an SQL injection bug and three cross-site scripting (XSS) flaws.
Joomla development team has released the Joomla 3.8.4 that addresses a large number of issues, including an SQL injection bug and three cross-site scripting (XSS) vulnerabilities. The latest release also includes several improvements.
The XSS and SQL injection vulnerabilities have been classified as “low priority”
“Joomla 3.8.4 is now available. This is a security release for the 3.x series of Joomla addressing four security vulnerabilities and including over 100 bug fixes and improvements.” reads the announcement.
The most severe issue is the SQL injection vulnerability tracked as CVE-2018-6376 due to its high impact.
The issue was reported by the researcher Karim Ouerghemmi from RIPS Technologies (ripstech.com), it affects Joomla! CMS versions 3.7.0 through 3.8.3.
“The lack of type casting of a variable in SQL statement leads to a SQL injection vulnerability in the Hathor postinstall message.” states the security advisory published by Joomla.
“Recent updates to our analysis engine lead to the discovery of a new vulnerability in the Joomla! core affecting versions prior to 3.8.4. RIPS discovered a second-order SQL injection that could be used by attackers to leverage lower permissions and to escalate them into full admin permissions.” reads the analysis published by RIPS.
The experts explained that the flaw could be exploited to gain admin privileges and take over the Joomla installs.
“An attacker exploiting this vulnerability can read arbitrary data from the database. This data can be used to further extend the permissions of the attacker. By gaining full administrative privileges she can take over the Joomla! installation by executing arbitrary PHP code.” continues the post.
The researchers discovered the vulnerability by using their static code analyzer, an attacker can first inject arbitrary content into the targeted install’s database and then create a specially crafted query to gain admin privileges.
The XSS flaws affect the Uri class (versions 1.5.0 through 3.8.3), the com_fields component (versions 3.7.0 through 3.8.3), and the Module chrome (versions 3.0.0 through 3.8.3).
According to the development team, the Uri class (formerly JUri) fails to properly filter the input opening to XSS attacks.