Tech News - Security

On Wednesday, Germany’s biggest bank, Deutsche Bank, shared that it has found a bug in its decade old software that it has using for flagging suspicious transactions. This news came out just a day ahead of the bank’s annual shareholders meeting held on May 23. According to a Deutsche Bank spokesman the faulty software was one of the many anti-financial crime systems that the bank uses. The glitch happened because two of 121 parameters in the software were not defined accurately. It was detected when employees from the bank's anti-financial crime unit started working on improving the bank’s internal processes last year. In a statement the bank said, “Deutsche Bank is working on correcting the error as quickly as possible and is in close contact with the regulators." This news has further dealt a major blow to the bank's reputation as it is already facing several accusations regarding its involvement in money laundering. On Tuesday, The New York Times reported that during 2016-2017, the bank’s executives were informed by its anti-laundering-specialists about several suspicious transactions. These transactions, which also involved Donald J. Trump and his son-in-law, Jared Kushner, were first flagged by a computer system. Despite these reports, the bank refused to take any action. "Compliance staff members who then reviewed the transactions prepared so-called suspicious activity reports that they believed should be sent to a unit of the Treasury Department that polices financial crimes. But executives at Deutsche Bank, which has lent billions of dollars to the Trump and Kushner companies, rejected their employees’ advice," wrote The New York Times in its report. Following these news, the bank's share price reached a new record low on Thursday morning and needless to say, this left its shareholders unimpressed. At the bank's Annual General Meeting, Christian Sewing, the Deutsche Bank chief executive, faced discontent of the shareholders regarding the bank’s top management. He has now promised to improve the bank's internal controls and is planning to "make tough cutbacks” to reverse the damages. Addressing the investors, Sewing said, "We will accelerate transformation by rigorously focusing our bank on profitable and growing businesses which are particularly relevant to our clients." Read the full story on The New York Times. Lloyds Bank’s online services which were down due to DNSSEC issues have been restored! Wells Fargo’s online and mobile banking operations suffer a major outage Apple’s March Event: Apple changes gears to services, is now your bank, news source, gaming zone, and TV

A new study by researchers at Cambridge University’s Computer Laboratory has revealed that an attack called calibration fingerprinting or SENSORID, allows iOS and Android devices to be tracked across the internet. The researchers stated that this attack is easy to conduct by a website or an app in under 1 second as it requires no special permissions, does not require user interaction, and is computationally efficient. Yesterday, at the IEEE Symposium on Security and Privacy, the researchers presented a research paper titled “SENSORID: Sensor Calibration Fingerprinting for Smartphones”, that introduces the calibration fingerprinting attack. In this paper, the researchers have demonstrated the effectiveness of this attack on iOS devices and found the lack of precision in the M-series co-processor helps the generation of such a fingerprint. “Such an attack does not require direct access to any calibration parameters since these are often embedded inside the firmware of the device and are not directly accessible by application developers”, the research report states. “According to a team of academics from the University of Cambridge in the UK, SensorID impacts iOS devices more than Android smartphones. The reason is that Apple likes to calibrate iPhone and iPad sensors on its factory line, a process that only a few Android vendors are using to improve the accuracy of their smartphones' sensors”, reports ZDNet. The researchers used a new method of fingerprinting devices with embedded sensors by carefully analyzing the sensor output. Sensors do not require any special permissions, and the data can be accessed via both a native app installed on a device and also by JavaScript when visiting a website on an iOS and Android device. It can be generated by both apps and mobile websites and will require no user interaction. When the attack was experimented on an iPhone 6S, it was found that that the GYROID contains about 42 bits of entropy and the MAGID provides an additional 25 bits of entropy. The study has demonstrated that the combination of the MAGID and GYROID – the SENSORID – is globally unique for the iPhone 6S. This did not change on factory reset or after a software update. This shows that the attack can also be applied retrospectively to a historic archive of sensor data. In addition to iOS devices, it has been found that Google Pixel 2 and Pixel 3 can also be fingerprinted by SENSORID attack. The researchers claim that all iOS devices that have a gyroscope or magnetometer can be fingerprinted by this approach, including the latest iPhone XS and iPhone XS Max. The mainstream iOS browsers- Safari, Chrome, Firefox, and Opera and privacy enhanced browsers- Brave and Firefox Focus are all vulnerable to this calibration based fingerprinting attack, even if the fingerprinting protection mode is turned on. They added, “We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SENSORID either.” The researchers notified Apple about this vulnerability in August 2018 and Google in December 2018. Apple patched this issue with the release of iOS12.2 in March 2019. However, Google has not taken any prompt action and have just informed the researchers that they will investigate this issue. With the latest iOS 12.2 release, the new iPhones and iPads will generate a new fingerprint with every sensor calibration query, making SENSORID type of user tracking useless. Further, Apple also removed access to motion sensors from Mobile Safari by default. The researchers anticipate that calibration information used in other embedded sensors can also be recovered and used as a fingerprint. Thus future research will successfully perform calibration fingerprinting attacks on other types of sensor. Any iPhone, is vulnerable to an attack, unless it has been updated to to iOS 12.2. If a user is using a Pixel 2 or 3, it's vulnerable to attack. But the vulnerability to an Android phone is not yet known fully, but there is a sure possibility to it. Read More Apple proposes a “privacy-focused” ad click attribution model for counting conversions without tracking users Introducing Minecraft Earth, Minecraft’s AR-based game for Android and iOS users Apple Pay will soon support NFC tags to trigger payments  

Yesterday, TechCrunch reported that thousands of TP-Link routers are still vulnerable to a bug, discovered in January 2018. This vulnerability can allow any low-skilled attacker to remotely gain full access to an affected vulnerable router. The attacker could also target a vulnerable device, in a massive way, by searching the web thoroughly and hijacking routers by using default passwords, the way Mirai botnet had downed Dyn. TP-Link updated the firmware page sharing this vulnerability to their customers, only after TechCrunch reached out to them. https://twitter.com/zackwhittaker/status/1131221621287604229 In October 2017, Andrew Mabbitt (founder of U.K. cybersecurity firm, Fidus Information Security) had first discovered and disclosed a remote code execution bug in TP-Link WR940N router. The multiple vulnerabilities occurred due to multiple code paths calling strcpy on user controllable unsanitized input. TP-Link later released a patch for the vulnerable router in November 2017. Again in January 2018, Mabbitt warned TP-Link that another router WR740N was also at risk by the same bug. This happened because the company reused the same vulnerable code for both the devices. TP-Link asked Mabbitt for more details about CVE-2017-13772 (wr940n model) vulnerability. After providing the details, Mabbitt requested for an update thrice and warned them of public disclosure in March, if they did not provide an update. Later on 28th March 2018, TP-Link provided Mabbitt with a beta version of the firmware to fix the issue. He confirmed that the issue has been fixed and requested TP-Link to release the live version of the firmware. After receiving no response from TP-Link for another month, Mabbitt then publicly disclosed the vulnerability on 26th April 2018. The patch was still not fixed by then. When TechCrunch enquired, the firmware update for WR740N was missing on the company’s website till 16th May 2019. A TP-Link spokesperson told TechCrunch that the update was, “currently available when requested from tech support” and did not explain the reason. It was only when TechCrunch highlighted this issue did TP-Link, they updated the firmware page on 17th May 2019, to include the latest security update. They have specified that the firmware update is meant to resolve issues that the previous firmware version may have and improve its current performance. In a statement to TechCrunch, Mabbitt said, “TP-Link still had a duty of care to alert customers of the update if thousands of devices are still vulnerable, rather than hoping they will contact the company’s tech support.” This has been a highly irresponsible behavior from TP-Link’s end. Even after, a third person discovered its bug more than a year ago, TP-Link did not even bother to keep their users updated about it. This news comes at a time when both the U.K. and the U.S. state of California are set to implement laws to improve Internet of Things security. Soon companies will require devices to be sold with unique default passwords to prevent botnets from hijacking internet-connected devices at scale and using their collective internet bandwidth to knock websites offline. https://twitter.com/dane/status/1131224748577312769 Read More Approx. 250 public network users affected during Stack Overflow’s security attack Intel discloses four new vulnerabilities labeled MDS attacks affecting Intel chips A WhatsApp vulnerability enabled attackers to inject Israeli spyware on user’s phones

Over the last three weeks, more than 12,000 unsecured MongoDB databases have been deleted. The cyber-extortionist have left only an email contact, most likely to negotiate the terms of data recovery. Attackers looking for exposed database servers use BinaryEdge or Shodan search engines to delete them and usually demand a ransom for their 'restoration services'. MongoDB is not new to such attacks, previously in September 2017 MongoDB databases were hacked, for ransom. Also, earlier this month, Security Discovery researcher Bob Diachenko found an unprotected MongoDB database which exposed 275M personal records of Indian citizens. The record contained a personal detailed identifiable information such as name, gender, date of birth, email, mobile phone number, and many more. This information was left exposed and unprotected on the Internet for more than two weeks. https://twitter.com/MayhemDayOne/status/1126151393927102464 The latest attack on MongoDB database was found out by Sanyam Jain, an independent security researcher. Sanyam first noticed the attacks on April 24, when he initially discovered a wiped MongoDB database. Instead of finding the huge quantities of leaked data, he found a note stating: “Restore ? Contact : [email protected]”. It was later discovered that the cyber-extortionists have left behind ransom notes asking the victims to get in touch, if they want to restore their data. Two email addresses were provided for the same: [email protected] or [email protected]. This method to find and wipe databases in such large numbers is expected to be automated by the attackers. The script or program used to connect to the publicly accessible MongoDB databases is also configured to indiscriminately delete every unsecured MongoDB it can find and later add it to the ransom table. In a statement to Bleeping Computer, Sanyam Jain says, “the Unistellar attackers seem to have created restore points to be able to restore the databases they deleted” Bleeping Computer have stated that there is no way to track if the victims have been paying for the databases to be restored because Unistellar only provides an email to be contacted and no cryptocurrency address is provided. Bleeping Computer also tried to get in touch with Unistellar to confirm if the wiped MongoDB databases are indeed backed up and if any victim have already paid for their "restoration services" but got no response. How to secure MongoDB databases MongoDB databases are remotely accessible and access to them is not properly secured. These frequent attacks highlight the need for an effective protection of data. This is possible by following fairly simple steps designed to properly secure one’s database. Users should take the simple preventive measure of enabling authentication and not allowing the databases to be remotely accessible. MongoDB has also provided a detailed manual for Security. It includes various features, such as authentication, access control, encryption, to secure a MongoDB deployments. There’s also a Security Checklist for administrators to protect the MongoDB deployment. The list discusses the proper way of enforcing authentication, enabling role-based access control, encrypt communication, limiting network exposure and many more factors for effectively securing MongoDB databases. To know more about this news in detail, head over to Bleeping Computer’s complete coverage. MongoDB is going to acquire Realm, the mobile database management system, for $39 million MongoDB withdraws controversial Server Side Public License from the Open Source Initiative’s approval process GNU Health Federation message and authentication server drops MongoDB and adopts PostgreSQL

Last year, a GDPR complaint was filed against Google and other ad auction companies regarding data breach. The complaint alleged that tech companies broadcasted people’s personal data to dozens of companies, without proper security through a mechanism of “behavioural ads”. The complaint was filed by a host of privacy activists and pro-privacy browser firm Brave. This year in January, new evidences emerged indicating the broadcasted data includes information about people’s ethnicity, disabilities, sexual orientation and more. This sensitive information allows advertisers to specifically target incest, abuse victims, or those with eating disorders. This complaint was filed by an anti-surveillance NGO, the Panoptykon Foundation. The initial complaints were filed in Ireland, the UK, and Poland. Now, yesterday, a new GDPR complaint about Real-Time Bidding (RTB) in the online advertising industry was filed with Data Protection Authorities in Spain, Netherlands, Belgium, and Luxembourg. In total seven EU countries have raised the GDPR issue, this week when it marked completion of one year since Europe’s General Data Protection Regulation (GDPR) came into force. The complaints were lodged by Gemma Galdon Clavell , Diego Fanjul , David Korteweg , Jef Ausloos , Pierre Dewitte , and Jose Belo . The complaints suggest Google and other major companies have leaked vast scale of personal data to the “Ad Tech” industry. https://twitter.com/mikarv/status/1130374705440018433 How RTB system is used for data breach According to the complaint, Google’s DoubleClick recently renamed “Authorized Buyers”, has 8.4 million websites and uses it to broadcasts personal data about visitors to over 2,000 companies. Google is using Real-Time Bidding (RTB) system for it. This means every time a person visits Google web page, intimate personal data about the users and what they are viewing is broadcasted in a “bid request”. These requests are then sent to hundreds of other companies to solicit bids from potential advertisers’ for the opportunity to show an ad to a specific visitor. This data includes people’s exact locations, inferred religious, sexual, political characteristics. The data also includes what users are reading, watching, and listening to online, and a unique code which details to  'Expression of Interest' section on a website. The next biggest ad exchange is AppNexus, owned by AT&T, which conducts 131 billion personal data broadcasts every day. Once the data is broadcasted, there is no control as to what happens to the data thereafter. Google has a self-regulatory guideline for companies that rely on its broadcast, according to which, companies should inform them if they are breaking any rules. Google has assured that over 2,000 companies are “certified” in this way. However, Google DoubleClick/Authorized Buyers sends intimate personal information about virtually every single online person to these companies, billions of times a day. This is one of the massive leakage of personal data recorded so far as this occurs hundreds of billions of times every day. In a statement to Fix AdTech, CEO of Eticas, Gemma Galdon Cavell has said, “We hope that this complaint sends a strong message to Google and those using Ad Tech solutions in their websites and products. Data protection is a legal requirement must be translated into practices and technical specifications” Google will be fined heavy for not complying to GDPR Under the GDPR, a company is not permitted to use personal data unless it tightly controls what happens to that data. Article 5 (1)(f) requires that personal data be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss.” The largest GDPR fine ever, is issued to Google amounting to 50M euros. In January, a French data protection watchdog, CNIL alleged that the search engine giant was breaking GDPR rules around transparency. It also reported that Google did not have valid legal base, when processing people's data for advertising purposes. Meanwhile, Google is still appealing to the fine. Many users on Hacker News are having varied opinions regarding the need for regulation and also about the credibility of GDPR. A user states, “To be clear, I think some privacy regulation is necessary, but there seems to be some kind of dissonance. People want a service, but are unwilling to pay for it nor give their data. Then they complain to the government that they should be able to get the service without payment anyway.” Another user added, “From a user perspective, GDPR has no impact so far. I am still being tracked to death wherever I go. Neither do companies offer me a way to get the data they have about me.” GAO recommends for a US version of the GDPR privacy laws ProtonMail shares guidelines to help organizations achieve EU GDPR compliance As US-China tech cold war escalates, Google revokes Huawei’s Android support, allows only those covered under open source licensing

Today, the team at Elastic announced that the core security features of the Elastic Stack are now free. They also announced about releasing Elastic Stack versions 6.8.0 and 7.1.0 and the alpha release of Elastic Cloud on Kubernetestoday. With the free core security features, users can now define roles that protect index and cluster level access, encrypt network traffic, create and manage users, and fully secure Kibana with Spaces. The team had opened the code for these features last year and has finally made them free today which means the users can now run a fully secure cluster. https://twitter.com/heipei/status/1130573619896225792 Release of Elastic Stack versions 6.8.0 and 7.1.0 The team also made an announcement about releasing versions 6.8.0 and 7.1.0 of the Elastic Stack, today. These versions do not contain new features but they make the core security features free in the default distribution of the Elastic Stack. The core security features include TLS for encrypted communications, file and native realm to create and manage users, and role-based access control to control user access to cluster APIs and indexes. The features also include allowing multi-tenancy for Kibana with security for Kibana Spaces. Previously, these core security features required a paid gold subscription, however, now, they are free as a part of the basic tier. Alpha release of Elastic Cloud on Kubernetes The team has also announced the alpha release of Elastic Cloud on Kubernetes (ECK) which is the official Kubernetes Operator for Elasticsearch and Kibana. It is a new product based on the Kubernetes Operator pattern that lets users manage, provision, and operate Elasticsearch clusters on Kubernetes. It is designed for automating and simplifying how Elasticsearch is deployed and operated in Kubernetes. It also provides an official way for orchestrating Elasticsearch on Kubernetes and provides a SaaS-like experience for Elastic products and solutions on Kubernetes. The team has moved the core security features into the default distribution of Elastic Stack to ensure that all clusters launched and managed by ECK are secured by default at creation time. The clusters that are deployed via ECK include free features and tier capabilities such as Kibana Spaces, frozen indices for dense storage, Canvas, Elastic Maps, and more. Users can now monitor Kubernetes logs and infrastructure with the help of Elastic Logs and Elastic Infrastructure apps. Few users think that security shouldn’t be an added feature, it should be inbuilt. A user commented on HackerNews, “Security shouldn't be treated as a bonus feature.” Another user commented, “Security should almost always be a baseline requirement before something goes up for public sale.” Few others are happy about this news. A user commented, “I know it's hard to make a buck with an open source business model but deciding to charge more for security-related features is always so frustrating to me. It leads to a culture of insecure deployments in environments when the business is trying to save money. Differentiate on storage or number of cores or something, anything but auth/security. I'm glad they've finally reversed this.” To know more about this news, check out the blog post by Elastic. Elasticsearch 7.0 rc1 releases with new allocation and security features Elastic Stack 6.7 releases with Elastic Maps, Elastic Update and much more! AWS announces Open Distro for Elasticsearch licensed under Apache 2.0  

Salesforce informed its customers that it was facing a major issue with its service, early Friday morning, and mentioned that it was working towards resolving the issue soon. The popular cloud-based software company experienced an outage due to its faulty database script after the company made changes to its production environment. Due to this, users got access to a broad amount of data than intended where they could see all the company’s data irrespective of the permissions. Salesforce said that the outage, which began on Friday and lasted just over 15 hours, is over - although some may experience a few issues as the platform gets back up to speed. Salesforce’s chief technology officer and a co-founder, Parker Harris, acknowledged the issue at 12:40 p.m. Eastern time the same day, and tweeted that Salesforce employees were working on the problem. https://twitter.com/parkerharris/status/1129426438325587969 According to reports on Reddit, users not only received read access but also received write permissions, thus, making it easy for malicious employees to steal or tamper with a company's data. Salesforce said the script only impacted customers of Salesforce Pardot or have used Pardot in the past. According to The Register, “To deal with the mess, Salesforce's IT team has denied all access to more than 100 cloud instances that host Pardot users, shutting out everyone else using those same systems, whether or not they were using Pardot.” Customers who were not affected may have also experienced certain service disruptions including customers using Marketing Cloud integrations. https://twitter.com/sfdcmitch/status/1129403764513787905 Salesforce customers in Europe and North America were the most impacted by the company shutting down access to its own service. Salesforce said, “We have started unblocking customers who were not affected by the permission issues.” https://twitter.com/sfdcmitch/status/1129403764513787905 https://twitter.com/RealSalesAdvice/status/1129421822007566336 On the 18th, at 5.40 a.m. Eastern time, Salesforce, on its status page, announced that access had been restored for administrators of all organizations that had been affected by the permission issues. “We are preparing a set of instructions for admins that may need guidance on how to manually restore those permissions. As soon as the instructions are final, we will inform admins via an email that will contain a link to the instructions,” the company said. The company further updated: “We have restored administrators' access to all affected orgs as of 08:04 UTC. We have prepared a set of instructions for admins that may need guidance on how to manually restore those user permissions. We notified admins via an email that contained a link to the instructions. A subset of admins may still be experiencing issues such as logging in to their orgs, modifying perms that are uneditable, or timeouts.” To know more about this in detail, visit Salesforce’s status page. DockerHub database breach exposes 190K customer data including tokens for GitHub and Bitbucket repositories Facebook confessed another data breach; says it “unintentionally uploaded” 1.5 million email contacts without consent Justice Department’s indictment report claims Chinese hackers breached business  and government network

Earlier this month, Cisco announced a critical vulnerability in its Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software. This vulnerability allows an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user. This vulnerability is only exploitable over IPv6; however, the IPv4 is not vulnerable. Cisco has released free software updates that address the vulnerability. This vulnerability(CVE-2019-1804), with a CVSS severity rating of 9.8, is due to the presence of a default SSH key pair that is present in all devices. An attacker could exploit this vulnerability by opening an SSH connection via IPv6 to a targeted device using the extracted key materials. There are no workarounds, so Cisco is encouraging users to update to the latest software release. However, the fix is only an interim patch. The company also issued a “high” security warning advisory for the Nexus 9000, with a CVSS severity rating of 10.0. This involves an exploit that allows attackers to execute arbitrary operating-system commands as root on an affected device. In order to succeed, an attacker would need valid administrator credentials for the device, Cisco said. The vulnerability is due to overly broad system-file permissions where an attacker could exploit this vulnerability by authenticating to an affected device, creating a crafted command string and writing this crafted string to a specific file location. Critical vulnerabilities Cisco’s web-based management interface Multiple critical vulnerabilities in the web-based management interface of Cisco Prime Infrastructure (PI) and Cisco Evolved Programmable Network (EPN) Manager were revealed yesterday. These vulnerabilities could allow a remote attacker to gain the ability to execute arbitrary code with elevated privileges on the underlying operating system. These vulnerabilities affect Cisco PI Software Releases prior to 3.4.1, 3.5, and 3.6, and EPN Manager Releases prior to 3.0.1 One of these issues, CVE-2019-1821, can be exploited by an unauthenticated attacker that has network access to the affected administrative interface. For the second and third issues(CVE-2019-1822 and CVE-2019-1823), the attacker needs to have valid credentials to authenticate to the impacted administrative interface. Cisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities. To know more about these and other vulnerabilities, visit Cisco’s Security Advisories and Alerts page. Cisco merely blacklisted a curl instead of actually fixing the vulnerable code for RV320 and RV325 Cisco announces severe vulnerability that gives improper access controls for URLs in its Small Business routers RV320 and RV325 A WhatsApp vulnerability enabled attackers to inject Israeli spyware on user’s phones

Today, Google announced a security bug in its Bluetooth Low Energy (BLE) Titan Security Keys. This issue is due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, which is currently affecting the BLE versions in the U.S. Google has provided users with quick actions to protect themselves against the attack and to gain a free replacement key. However, the bug affects Bluetooth pairing only, so non-Bluetooth security keys are not affected. “Current users of Bluetooth Titan Security Keys should continue to use their existing keys while waiting for a replacement since security keys provide the strongest protection against phishing”, the official post reads. Attackers can only gain access to a user’s device if they are within close proximity (approximately 30 feet) while the user is using the security key. With this, the attacker can easily communicate with a user’s security key or also communicate with the device to which the user’s key is paired. The two cases an attacker might use to exploit the security keys in the BLE are: While trying to sign into an account on the device, a user is normally asked to press the button on their BLE security key to activate it. At this time, the attacker will have to connect their own device to the user’s affected security key before the user’s own device connects, for the bug to be exploited. However, this case is only possible if they have already obtained the victim’s username and password. The attacker could also use their device to masquerade as the user’s affected security key and connect to the user’s device at the moment the user is asked to press the button on the key. After that, they could attempt to change their device to appear as a Bluetooth keyboard or mouse and potentially take actions on the user’s device. Google also mentions that this issue does not affect the primary purpose of security keys (to protect you against phishing by a remote attacker). They also suggest that security keys remain the strongest available protection against phishing and it is still safer to use a key that has this issue, rather than turning off security key-based two-step verification (2SV) on one’s Google Account or downgrading to less phishing-resistant methods (e.g. SMS codes or prompts sent to a user’s device). This local proximity Bluetooth issue does not affect USB or NFC security keys. “To determine if your key is affected, check the back of the key. If it has a “T1” or “T2” on the back of the key, your key is affected by the issue and is eligible for free replacement”, the official post states. Mark Risher, Director of Product Management at Google tweeted: https://twitter.com/mrisher/status/1128703153397030913 Google has also provided some additional steps that users can take to minimize the remaining risk until they receive their replacement keys on their official blog post. To know more about this news in detail, head over to Google’s official blog post. Go 1.11.3 and Go 1.10.6 released with fixes to security issues Amazon FreeRTOS adds a new ‘Bluetooth low energy support’ feature Google I/O 2019: Flutter UI framework now extended for Web, Embedded, and Desktop

Microsoft has taken steps to release security updates for unsupported but still widely-used Windows operating systems like XP and Windows 2003. The company took this move as a part of its May 14 Patch Tuesday, due to the discovery of a “wormable” flaw that could be a major threat similar to the WannaCry ransomware attacks of 2017. The WannaCry ransomware threat was quick to spread across the world in May 2017 due to a vulnerability that was prevalent among systems running Windows XP and older versions of Windows. On Tuesday, Microsoft released 16 updates that target at least 79 security issues in Windows and related software. Now let’s have a look at the vulnerabilities,  CVE-2019-0708 and CVE-2019-0863. CVE-2019-0708, remote desktop services vulnerability The  CVE-2019-0708 vulnerability is in remote desktop services into supported versions of Windows, including Windows 7, Windows Server 2008 R2, and Windows Server 2008. It is present in computers powered by Windows XP and Windows 2003. To attack the system, an unauthenticated attacker connects to the target system using Remote Desktop Protocol (RDP) and then sends specially crafted requests. This security update now corrects how Remote Desktop Services handles connection requests. Though the vulnerability CVE-2019-0708 does not affect Microsoft’s latest operating systems, including,  Windows 10, Windows 8, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012. The company hasn’t observed any evidence of attacks against this security flaw, but it might head off a serious and imminent threat. Simon Pope, director of incident response for the Microsoft Security Response Center said, “This vulnerability is pre-authentication and requires no user interaction. In other words, the vulnerability is ‘wormable,’ meaning that any future malware that exploits this vulnerability could propagate from vulnerable computer to vulnerable computer in a similar way as the WannaCry malware spread across the globe in 2017. It is important that affected systems are patched as quickly as possible to prevent such a scenario from happening.” CVE-2019-0863, zero-day vulnerability One of the security updates fixed a zero-day vulnerability, (CVE-2019-0863) in the Windows Error Reporting Service. An attacker who can successfully exploit this vulnerability can run arbitrary code in kernel mode.The attacker can then install programs; change, view, or delete data; or create new accounts with administrator privileges. An attacker has to gain unprivileged execution on the victim’s system in order to exploit the vulnerability. Microsoft’s security update addresses this vulnerability by correcting the way WER (Windows Error Reporting) handles files. According to Chris Goettl, director of product management for security vendor Ivanti, this vulnerability has already been seen in targeted attacks. Microsoft Office and Office365, Sharepoint, .NET Framework and SQL server are some of the other Microsoft products that received patches. To know more about this news, check out Microsoft’s page. #MSBuild2019: Microsoft launches new products to secure elections and political campaigns Microsoft Build 2019: Introducing Windows Terminal, application packed with multiple tab opening, improved text and more Microsoft Build 2019: Introducing WSL 2, the newest architecture for the Windows Subsystem for Linux  

Yesterday, Intel and a group of microarchitecture security researchers disclosed four new hackable vulnerabilities in Intel’s chips. These vulnerabilities expose extremely sensitive data and processes from a victim’s CPU to the attacker. Intel has grouped these vulnerabilities together and labeled them as Microarchitectural Data Sampling or MDS attacks. MDS is a sub-class of previously disclosed speculative execution side channel vulnerabilities and is comprised of four closely related CVEs. These vulnerabilities were first identified by Intel’s internal researchers and partners and independently reported to Intel by external researchers. These include: Microarchitectural Load Port Data Sampling (MLPDS) - CVE-2018-12127 Fallout: Microarchitectural Store Buffer Data Sampling (MSBDS) - CVE-2018-12126 ZombieLoad or RIDL: Microarchitectural Fill Buffer Data Sampling (MFBDS) - CVE-2018-12130 Microarchitectural Data Sampling Uncacheable Sampling (MDSUM) - CVE-2019-11091 Researchers have named few of these vulnerabilities as ZombieLoad, Fallout, and RIDL, or Rogue In-Flight Data Load, with ZombieLoad being the most dangerous as it can scrape more data than the rest. Intel said that the ARM and AMD are not likely vulnerable to these MDS attacks. Also, some models released last month include a fix for this problem. However, all of Intel's chips that the researchers tested, going back as early as 2008, were affected. According to a report by ZDNet, “The good news is that Intel had more than a year to get this patched, and the company worked with various OS and software vendors to coordinate patches at both the hardware and software level. Both the hardware (Intel CPU microcode updates) and software (OS security updates) protections must be installed at the same time to fully mitigate MDS attacks. If patches aren't available yet, disabling the Simultaneous Multi-Threading (SMT) feature on Intel CPUs will significantly reduce the impact of all MDS attacks.” In these new cases, researchers found that they could use speculative execution to trick Intel's processors into grabbing sensitive data that's moving from one component of a chip to another. Unlike Meltdown, which used speculative execution to grab sensitive data sitting in memory, MDS attacks focus on the buffers that sit between a chip's components, such as between a processor and its cache, the small portion of memory allocated to the processor to keep frequently accessed data close at hand. Cristiano Giuffrida, one of the researchers in the VUSec group at Vrije Universiteit Amsterdam who discovered the MDS attack said, "It's kind of like we treat the CPU as a network of components, and we basically eavesdrop on the traffic between them. We hear anything that these components exchange." Zombieload side-channel attack Zombieload, a side-channel attack, is the leading attack among the new vulnerabilities and also falls in the same category as Meltdown, Spectre, and Foreshadow. It is exploited by taking advantage of the speculative execution process, which is an optimization technique that Intel added to its CPUs to improve data processing speeds and performance. Read Also: Seven new Spectre and Meltdown attacks found ZombieLoad gets its name from a “zombie load,” an amount of data that the processor can’t understand or properly process, forcing the processor to ask for help from the processor’s microcode to prevent a crash. Apps are usually only able to see their own data, but this bug allows that data to bleed across those boundary walls. ZombieLoad will leak any data currently loaded by the processor’s core, the researchers said. Intel said patches to the microcode will help clear the processor’s buffers, preventing data from being read. “Like Meltdown and Spectre, it’s not just PCs and laptops affected by ZombieLoad — the cloud is also vulnerable. ZombieLoad can be triggered in virtual machines, which are meant to be isolated from other virtual systems and their host device”, the TechCrunch reports. Daniel Gruss, one of the researchers who discovered the latest round of chip flaws, said it works “just like” it does on PCs and can read data off the processor. That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware. Although no attacks have been publicly reported, the researchers couldn’t rule them out nor would any attack necessarily leave a trace, they said. Gruss said it was “easier than Spectre” but “more difficult than Meltdown” to exploit — and both required a specific set of skills and effort to use in an attack. But if exploit code was compiled in an app or delivered as malware, “we can run an attack,” he said. Intel has released microcode to patch vulnerable processors. Apple, Microsoft, and Google have also released patches, with other companies expected to follow. “In a call with TechCrunch, Intel said the microcode updates, like previous patches, would have an impact on processor performance. An Intel spokesperson told TechCrunch that most patched consumer devices could take a 3 percent performance hit at worst, and as much as 9 percent in a datacenter environment. But, the spokesperson said, it was unlikely to be noticeable in most scenarios. And neither Intel nor Gruss and his team have released exploit code, so there’s no direct and immediate threat to the average user”, TechCrunch reports. Is Zombieload a security threat for Linux system? As a defense against Zombieload, a ZDNet report suggests, “To defend yourself, your processor must be updated, your operating system must be patched, and for the most protection, Hyper-Threading disabled.” Red Hat rated CVE-2018-12130(Zombieload) as a severity impact of "important," while the others have moderate severity. Greg Kroah-Hartman, the stable Linux kernel maintainer, in an announcement email wrote, “I'm announcing the release of the 5.1.2 kernel. All users of the 5.1 kernel series must upgrade. Well, kind of, let me rephrase that...All users of Intel processors made since 2011 must upgrade.” “Red Hat noted all its Linux distributions from Red Hat Enterprise Linux (RHEL) 5 on up to the new RHEL 8 are affected. Platforms based on these Linux distros, such as Red Hat Virtualization and Red Hat OpenStack, are also vulnerable”, ZDNet reports. Chris Robinson, Red Hat's product security assurance manager, explained: "These vulnerabilities represent an access restriction bypass flaw that impacts many Intel CPU's and many of the operating systems that enable that hardware. Working with other industry leaders, Red Hat has developed kernel security updates for products in our portfolio to address these vulnerabilities. We are working with our customers and partners to make these updates available, along with the information our customers need to quickly protect their physical systems, virtual images, and container-based deployments." According to a Wired post, “VUSec's Giuffrida notes that his team was paid $100,000 by Intel for their work as part of the company's "bug bounty" program that rewards researchers who warn the company about critical flaws. That's hardly the kind of money paid out for trivial issues, he points out. But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws. VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.” To know more about this news, read Intel’s official blog post. A WhatsApp vulnerability enabled attackers to inject Israeli spyware on user’s phones ChaCha20-Poly1305 vulnerability issue affects OpenSSL 1.1.1 and 1.1.0 Drupal releases security advisory for ‘serious’ Remote Code Execution vulnerability

This month, during the Microsoft Build 2019, the team behind .NET Core announced that .NET Core 5 will be coming in 2020. Yesterday the team at .NET Core released the .NET Core May 2019 updates for 1.0.16, 1.1.14, 2.1.11 and 2.2.5. The updates include security, reliability fixes, and updated packages. Expected updates in .NET Core Security .NET Core Tampering Vulnerability(CVE-2019-0820) When .NET Core improperly processes RegEx strings, a denial of service vulnerability exists. In this case, the attacker who can successfully exploit this vulnerability can cause a denial of service against a .NET application. Even a remote unauthenticated attacker can exploit this vulnerability by issuing specially crafted requests to a .NET Core application. This update addresses this vulnerability by correcting how .NET Core applications handle RegEx string processing. This security advisory provides information about a vulnerability in .NET Core 1.0, 1.1, 2.1 and 2.2. Denial of Service vulnerability in .NET Core and ASP.NET Core (CVE-2019-0980 & CVE-2019-0981) When .NET Core and ASP.NET Core improperly handle web requests, denial of service vulnerability exists. An attacker who can successfully exploit this vulnerability can cause a denial of service against a .NET Core and ASP.NET Core application. This vulnerability can be exploited remotely and without authentication. A remote unauthenticated attacker can exploit this vulnerability by issuing specially crafted requests to a .NET Core application. This update addresses this vulnerability by correcting how .NET Core and ASP.NET Core web applications handle web requests. This security advisory provides information about the two vulnerabilities (CVE-2019-0980 & CVE-2019-0981) in .NET Core and ASP.NET Core 1.0, 1.1, 2.1, and 2.2. ASP.NET Core Denial of Service vulnerability(CVE-2019-0982) When ASP.NET Core improperly handles web requests, a denial of service vulnerability exists. An attacker who can successfully exploit this vulnerability can cause a denial of service against an ASP.NET Core web application. This vulnerability can be exploited remotely and without authentication. A remote unauthenticated attacker can exploit this vulnerability by issuing specially crafted requests to the ASP.NET Core application. This update addresses this vulnerability by correcting how the ASP.NET Core web application handles web requests. This security advisory provides information about a vulnerability (CVE-2019-0982) in ASP.NET Core 2.1 and 2.2. Docker images .NET Docker images have now been updated. microsoft/dotnet, microsoft/dotnet-samples, and microsoft/aspnetcore repos have also been updated. Users can get the latest .NET Core updates on the .NET Core download page. To know more about this news, check out the official announcement. .NET 5 arriving in 2020! Docker announces collaboration with Microsoft’s .NET at DockerCon 2019 .NET for Apache Spark Preview is out now!  

Yesterday, Atlassian Bitbucket, GitHub, and GitLab published a joint incident report in the wake of the recent Git ransomware attack on the three platforms earlier this month. The post sheds light on the ransom event details, what measures the platforms are taking to protect users, and what are the next steps to be taken by the affected repo owners. https://twitter.com/github/status/1128332167229202433 The Git ransom attack On May 2, the security teams at Atlassian Bitbucket, GitHub, and GitLab started getting numerous reports from users about their accounts being compromised. The reports mentioned that the source code from their repositories, both private and public, was being wiped off and replaced with the following ransom note: “To recover your lost data and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at [email protected] with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we don't receive your payment in the next 10 Days, we will make your code public or use them otherwise.” The user accounts were compromised with legitimate user credentials including passwords, app passwords, API keys, and personal access tokens. After getting access to the user accounts, the attackers performed command-line Git commits, which resulted in overwriting the source code in repositories with the ransom note. To recover your repository, in case you have its latest copy on your computer, you can force push the local copy to the current HEAD using the ‘git push origin HEAD:master --force’ command. If not, you can clone the repository and use the git reflog or git fsck commands to find your last commit and change the HEAD. What the investigation revealed? A basic GitHub search shows that 267 repositories were affected by the ransom attack. While investigating how the credential leakage happened, the security teams found a public third-party credential dump, which was hosted by the same hosting provider where the attack had originated. The dump had credentials of nearly one-third of the attacked accounts. After finding this out, the platforms took steps to invalidate the credentials by resetting or revoking them. On further investigation, it was found that continuous scanning has been conducted by the same IP address as the attacker for publicly exposed .git/config and other environment files, which may have sensitive information like credentials and personal access tokens. Similar scanning behavior from other IPs residing on the same hosting provider was also found. How you can protect your repositories from such attacks? Strong and unique passwords: Users should use strong and unique passwords as attackers can easily crack simple passwords through brute-force attacks. Enabling multi-factor authentication (MFA): Users are recommended to use multi-factor authentication, which is supported on all three platforms. MFA provides better security by combining two or more independent credentials for authentication. Understanding personal access tokens (PATs) and their risks: PATs serve as an alternative to passwords when you are using two-factor authentication. Users should ensure that these are not publicly accessible in repositories or on web servers as in some situations these tokens may have read or write access to repositories. The report further recommends that users should use them as environment variables and avoid hardcoding them into their programs. Additionally, the three platforms also offer other features through which we can prevent such attacks from recurring. Bitbucket gives admins the authority to control access of users through IP Whitelisting on their Premium plan. GitHub does token scanning on public repositories to check for known token formats and notifies the service providers if secrets are published to public GitHub repositories. GitLab 11.9 comes with a feature called Secret Detection that scans repositories to find API keys and other information that should not be there. To read the official announcement, check out the joint incident report on GitLab blog. GitHub announces beta version of GitHub Package Registry, its new package management service GitHub deprecates and then restores Network Graph after GitHub users share their disapproval DockerHub database breach exposes 190K customer data including tokens for GitHub and Bitbucket repositories  

Last week, the Rust team was informed about a vulnerability in Rust’s standard library, the details of which they shared yesterday. The vulnerability is caused by a function that was stabilized in the Rust 1.34.0 and 1.34.1 versions. The Common Vulnerabilities and Exposures (CVE) Id for this vulnerability is CVE-2019-12083. What is the vulnerability? The Rust standard library contains the `Error::type_id` method, which allows you to acquire TypeId (a globally unique identifier for a type) of the underlying error type to downcast back to the original type. The vulnerability happens when the method is manually implemented or interacts with ‘Error::downcast’ family of functions to cast a type to the wrong type. Though the standard library has a default implementation of ‘Error::type_id’, it can also be manually implemented by downstream crates. This can cause security issues such as out of bounds reads and writes. If your code does not have a manual implementation of ‘Error::type_id’, then it is safe. This vulnerability affects two versions, Rust 1.34.0 and 1.34.1, which were released last month. Also, since the function has been a part of all the releases starting from Rust 1.0.0, this vulnerability may have affected the code compiled with the nightly distribution as well. What are the mitigation steps? The Rust team recommends to immediately remove the manual implementations of Error::type_id and inherit the default implementation which is a safe option. As a long term measure, the team plans to destabilize this function, which will be a breaking change for users calling Error::type_id and for users overriding Error::type_id. The team further wrote, “We will be releasing a 1.34.2 point release on 2019-05-14 (tomorrow) which reverts #58048 and destabilizes the Error::type_id function. The upcoming 1.35.0 release along with the beta/nightly channels will also all be updated with a destabilization.” Read the full announcement on Rust’s official website. Rust shares roadmap for 2019 Rust 1.34 releases with alternative cargo registries, stabilized TryFrom and TryInto, and more Chris Dickinson on how to implement Git in Rust

Earlier this month, a major vulnerability was discovered in Whatsapp by its security team that allowed attackers to remotely install surveillance software on iOS and Android smartphones. The malicious software was injected in users phone by making WhatsApp voice calls, regardless of whether the user has answered the call or not. In some cases, these calls just vanished from the call logs leaving the targeted users clueless of the attack. There is a possibility that this spyware would have allowed an attacker to read messages from the affected device. Facebook, who owns Whatsapp, published an advisory to security specialists yesterday, describing the attack as, “A buffer overflow vulnerability in WhatsApp VOIP stack that allowed remote code execution via specially crafted series of SRTCP packets sent to a target phone number.” What steps have been taken by WhatsApp? WhatsApp engineers worked through Sunday before deploying a patch for its 1.5 Billion customers yesterday and urging them to update their app as an added precaution. The Financial Times reported, “WhatsApp said that teams of engineers had worked around the clock in San Francisco and London to close the vulnerability. It began rolling out a fix to its servers on Friday last week, WhatsApp said, and issued a patch for customers on Monday.” Not much detail about the vulnerability or the impact of the attack has been revealed yet as WhatsApp is still in its early stages of the investigation. Reportedly, last week the company disclosed the attack to the United States Department of Justice. WhatsApp in a statement shared on Monday said, "This attack has all the hallmarks of a private company known to work with governments to deliver spyware that reportedly takes over the functions of mobile phone operating systems. We have briefed a number of human rights organisations to share the information we can, and to work with them to notify civil society.” Who was behind this attack? According to the Financial Times, this malicious software was developed by NSO Group, which is headquartered in the Israeli city of Herzliya. While the company tries to keep its work under wraps, it has been accused of selling its flagship software Pegasus to Saudi Arabia and UAE. It also licenses Pegasus to intelligence and law enforcement agencies worldwide. The NSO Group in its defense shared a statement: "NSO's technology is licensed to authorized government agencies for the sole purpose of fighting crime and terror. The company does not operate the system, and after a rigorous licensing and vetting process, intelligence and law enforcement determine how to use the technology to support their public safety missions. We investigate any credible allegations of misuse and if necessary, we take action, including shutting down the system. "Under no circumstances would NSO be involved in the operating or identifying of targets of its technology, which is solely operated by intelligence and law enforcement agencies. NSO would not or could not use its technology in its own right to target any person or organization." Human rights advocates against NSO Group NSO group does not have a good reputation with human rights organizations and groups. Its software has been linked to human rights abuses, unethical surveillance, and also to the gruesome murder of the Saudi Arabian critic Jamal Khashoggi. Back in 2016, it was revealed by Citizen Lab and Lookout Mobile Security that the company exploited three unpatched iOS vulnerabilities, which are also known as zero-days, to jailbreak on user phones. This allowed the installation of Pegasus on user phones, which is capable of reading texts, tracking calls, collecting passwords, tracking location, and gathering information from apps. Yesterday, human rights advocates, along with Amnesty International, shared their plans to file a petition against NSO Group. They are taking the Israeli Ministry of Defence (MoD) to court demanding the revocation of the mobile spyware vendor’s export license. This decision comes after an Amnesty International researcher was targeted by the company’s Pegasus surveillance software. Amnesty International wrote in a post, “In a petition to be filed tomorrow at the District Court of Tel Aviv, approximately 30 members and supporters of Amnesty International Israel and others from the human rights community set out how the MoD has put human rights at risk by allowing NSO to continue exporting its products.” To know more in detail, check out the report by the Financial Times. DARPA plans to develop a communication platform similar to WhatsApp The Indian government proposes to censor social media content and monitor WhatsApp messages Facebook hires top EEF lawyer and Facebook critic as Whatsapp privacy policy manager