Tech News - Security

Yesterday, Sennheiser, an audio device maker issued a fix for a major software blunder that let hackers  easily carry out man-in-the-middle attacks by cryptographically impersonating any website on the internet. What exactly happened? HeadSetup established an encrypted websocket with a browser to allow Sennheiser headphones and speaker phones to work smoothly with computers. A self-signed TLS certificate is installed in the central place that is reserved by the operating system for storing browser-trusted certificate authority roots. This location is called the Trusted Root CA certificate store in Windows and macOS Trust Store for Mac. This self-signed root certificate installed by version 7.3 of the HetSetup pro application gave rise to the vulnerability as it kept the private cryptographic key in such a way that it could be easily extracted. Since, the key was identical for all the installations of the software, hackers could easily use the root certificate for generating forged TLS certificates that impersonated any HTTPS website on the internet. Though the self-signed certificates were mere forgeries, they would still be accepted as authentic on computers as they store the poorly secured certificate root. Even the certificate pinning, a forgery defense can’t do anything to detect such hacks. According to Secorvo, a security firm, “the sensitive key was encrypted with the passphrase SennheiserCC. The key was then encrypted by a separate AES key and then base64 encoded. The passphrase was stored in plaintext in a configuration file. The encryption key was found by reverse-engineering the software binary.” Secorvo researcher André Domnick holds a control over a certificate authority which could be trusted by any computer that had installed the vulnerable Sennheiser app. Dominick said, “he tested his proof-of-concept only against Windows versions of HeadSetup but that he believes the design flaw is present in macOS versions as well.” A solution which didn’t prove to be succesful A later version of the Sennheiser app was released to solve this issue. This one came with a root certificate installed but it didn’t include the private key. It  seemed like a good solution until the update failed to remove the older root certificate. This was a major failure which caused anyone who had installed the older version, susceptible to the TLS forgeries. Also, uninstalling the app wasn’t enough as it didn’t remove the root certificates that made users vulnerable to the attack. For the computers that didn’t have the older root certificate installed, the newer version was still causing trouble as it installed a server certificate for the computer’s localhost, i.e. 127.0.0.1. Users have given a negative feedback as it was a major blunder. One of the users commented on ArsTechnica’s post, “This rises to the level of gross negligence and incompetence. There really should be some serious fines for these sorts of transgressions.” The company ended up violating CA/Browser Forum: Baseline Requirements to issue certificates which itself was a big problem. This latest threat opens up many questions including the most crucial ones ‘If there is still a safer way to get a HTTPS website communicate directly with a local device?’ Also, ‘if these companies are taking enough steps to protect the users from such frauds?’ All users that have installed  the app are advised that they should remove or block the installed root certificates. Microsoft has proactively removed the certificates so users need not take any further actions. However users have to manually remove the certificates from Macs and PCs. Read more about this news on ArsTechnica. Packt has put together a new cybersecurity bundle for Humble Bundle Blackberry is acquiring AI & cybersecurity startup, Cylance, to expand its next-gen endpoint solutions like its autonomous cars’ software IBM launches Industry’s first ‘Cybersecurity Operations Center on Wheels’ for on-demand cybersecurity support

Yesterday, Mingye Wang reported a bug in the Glibc, GNU C Library. According to him, the dl_platform detection performs "cripple AMD" in the sysdeps in Glibc. The dl_platform check is used for dispatching SIMD (Single instruction, multiple data) libraries. Explaining the bug in detail, Wang writes, that in 2017, Glibc got the capability to transparently load libraries for specific CPU families with some SIMD extensions combinations to benefit the x86 users. However, this implementation limits two "good" sets of modern SIMD instructions to only Intel processors that prevent competitor CPUs with equivalent capabilities to fully perform, something that should not work in any free software package.  He further added that this bug seemed like an implementation of Intel’s ‘cripple AMD’ bug which was reported in 2009, and hence the name. According to the author, Agner Fog, “software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.” A user commented on HackerNews, “Hm, is this really "crippling" AMD? Seems more like Intel submitted a performance patch that is only enabled for Intel processors, but could be extended to support AMD too. There's a moral difference. It is wrong to intentionally degrade the performance of your competitors. It is not wrong to not do something that benefits others.” Mingye Wang writes, “The crux of the problem lies in the `(cpu_features->kind == arch_kind_intel)` (LHS now renamed cpu_features->basic.kind) comparison that surrounds the entire x86_64 case. Although AMD has not yet made any processors with AVX512, their newer processors (Zen -- Epyc, Ryzen) should at least satisfy the haswell test case.” According to Wang, glibc should remove the dl platform check and the processors should use their feature flags. At 07:15:15 UTC, the page updated that the bug has been resolved and it is a duplicate of 2018, bug 23249, where Epyc and other current AMD CPUs couldn’t select the "haswell" platform subdirectory. This bug was reported by Allan Jensen, who wrote, “Recently a "haswell" sub-arch was introduced to be similar to the old i686 subarch for x86. It is documented as requiring BMI1, BMI2, LZCNT, MOVBE, POPCNT, AVX2 and FMA, but undocumented also checks the CPU is an Intel CPU before using the faster paths. I would suggest glibc fixes that before it becomes public knowledge.” Florian Weimer, author at Red Hat, writes, “We really need feedback from AMD for this change, and it has been difficult for us to talk to engineers there. If you have contacts there, please encourage them to reach out to Red Hat Engineer Partner Management via their own channels (or contact me directly). I agree that this situation is unfortunate, and that AMD customers may not get the best possible performance as the result.” Weimer further added, “The "haswell" platform subdirectory is somewhat ill-defined, see bug 24080. I don't think current AMD CPUs implement the ERMS feature, which Intel assumes is part of the "haswell" definition. This bug has been marked as a duplicate of bug 23249.” Few users are sceptical about this news and think that there might be a planned conspiracy behind this bug. A user commented on HackerNews, “Could this be a legitimate unintended consequence of the pull request or some new dirty pool tactic? Either way I agree with Mingye Wang's assessment, this kind of thing cannot be allowed to get into the source tree. Hopefully AMD will increase their Linux activities with their new bigger market share and income.” To know more about this news, check out the post by Sourceware Bugzilla. Other interesting news in Security  CircleCI reports of a security breach and malicious database in a third-party vendor account Hundreds of millions of Facebook users’ phone numbers found online, thanks to an exposed server, TechCrunch reports Espressif IoT devices susceptible to WiFi vulnerabilities can allow hijackers to crash devices connected to enterprise networks  

On Thursday, the US launched a cyber-attack on Iranian weapons systems, according to sources. This attack is a retaliation by the US govt after Iran shot down a US spy drone. In response to the drone’s destruction, the US was ready to carry out a military strike against Iran but US President Donald Trump said he called it off at the last minute after being told some 150 people could die. Although that didn’t stop him from secretly authorizing US Cyber Command to carry out a retaliatory cyber attack on Iran. Defense officials had prepared such a cyber response as a contingency plan for weeks preceding the attack. The cyber-attacks disabled computer systems controlling Iran’s rocket and missile launchers. Officials told the Guardian that the attack, which specifically targeted computer systems of Iran’s Islamic Revolutionary Guard Corps (IRGC), had been provided as options after two oil tankers were bombed. The IRGC has been designated a foreign terrorist group by the Trump administration. The AP news agency said the cyber-attack had disabled the Iranian systems. The New York Times said it was intended to take the systems offline for a period of time. The response by Iran An Iran Minister however rejected these claims stating that US cyber attacks on Iranian targets were not successful. “They try hard, but have not carried out a successful attack,” Mohammad Javad Azari Jahromi, Iran’s minister for information and communications technology, told Reuters. “Media asked if the claimed cyber attacks against Iran are true,” he said. “Last year we neutralized 33 million attacks with the (national) firewall.” Azari Jahromi called attacks on Iranian computer networks “cyber-terrorism”, referring to Stuxnet, the first publicly known example of a virus used to attack industrial machinery, which targeted Iran’s nuclear facilities in November 2007. In response to the shooting down of the U.S drone, an Iranian navy commander warned it could be repeated. “Everyone saw the downing of the unmanned drone,” navy commander Rear Admiral Hossein Khanzadi was quoted as saying by the Tasnim news agency. “I can assure you that this firm response can be repeated, and the enemy knows it.” On Saturday the US Department for Homeland Security warned that Iran was stepping up its own cyber-attacks on the US. Christopher Krebs, the director of the Cybersecurity and Infrastructure Security Agency, said "malicious cyber activity" was being directed at US industries and government agencies by "Iranian regime actors and their proxies.'' The US military and intelligence officials are drafting plans for additional cyber attacks against Iranian targets. It will also further impose sanctions on Iran. President Trump said these sanctions were "major" and were needed to prevent Tehran from obtaining nuclear weapons, and economic pressure would be maintained unless Tehran changed course. Technology plays a central role in national security and foreign policies. Most recently, the US-China trade war saw Huawei and Apple caught at the center of escalating tensions. US prohibited wide swath of technology deals with a “foreign adversary” for national security reasons. National security and technological environments are intertwined because technology has a strong influence on the ways wars are fought and the character of the missions reserve components are asked to perform. It is often caught in the web of trade wars. The US Iran cyber attack is a clear example of the way the lines between physical and digital warfare are blurring. Hacker destroys Iranian cyber-espionage data; leaks source code of APT34’s hacking tools on Telegram FireEye’s Global DNS Hijacking Campaign suspects Iranian-based group as the prime source Slack has terminated the accounts of some Iranian users, citing U.S. sanctions as the reason.

Last week the DefCon security conference, which was held in Paris and Las Vegas, revealed that companies, govt and startups are inadvertently leaking their own files from the cloud. Ben Morris, a senior security analyst at cybersecurity firm Bishop Fox presented at DefCon on finding the secrets in publicly exposed EBS accounts. “You may have heard of exposed S3 buckets — those Amazon-hosted storage servers packed with customer data but often misconfigured and inadvertently set to “public” for anyone to access. But you may not have heard about exposed EBS snapshots, which poses as much, if not a greater, risk” Morris said. “Did you know that Elastic Block Storage (Amazon EBS) has a "public" mode that makes your virtual hard disk available to anyone on the internet? Apparently hundreds of thousands of others didn't either, because they're out there exposing secrets for everyone to see. I tore apart petabytes of data for you and have some dirty laundry to air: encryption keys, passwords, authentication tokens, PII, you name it and it's here. Whole (virtual) hard drives to live sites and apps, just sitting there for anyone to read. So much data in fact that I had to invent a custom system to process it all.” he added. Ahead of his talk at DefCon, Morris also spoke to a TechCrunch reporter and said that these elastic block storage (EBS) snapshots are the “keys to the kingdom”. “They have the secret keys to your applications and they have database access to your customers’ information.” “When you get rid of the hard disk for your computer, you know, you usually shredded or wipe it completely,” he said. “But these public EBS volumes are just left for anyone to take and start poking at.” He said that all too often cloud admins don’t choose the correct configuration settings, leaving EBS snapshots inadvertently public and unencrypted. “That means anyone on the internet can download your hard disk and boot it up, attach it to a machine they control, and then start rifling through the disk to look for any kind of secrets,” he said. Source: TechCrunch, Morris’ Def Con slides explaining how EBS snapshots can be exposed. Morris built a tool using Amazon’s own internal search feature to query and scrape publicly exposed EBS snapshots. He then attached it, made a copy and listed the contents of the volume on his system. “If you expose the disk for even just a couple of minutes, our system will pick it up and make a copy of it,” he said. It took him two months to build up a database of exposed data and just a few hundred dollars spent on Amazon cloud resources. Morris validates each snapshot and then deletes the data. Morris found dozens of snapshots exposed publicly in one region alone, it included application keys, critical user or administrative credentials, source code and more. He found data from several major companies, including healthcare providers and tech companies, exposed publicly. He also found VPN configurations, which could allow him to tunnel into a corporate network. Among the most damaging things he found a snapshot for one government contractor that provided data storage services to federal agencies. “On their website, they brag about holding this data,” he said, referring to collected intelligence from messages sent to and from the so-called Islamic State terror group to data on border crossings. Morris estimated the figure to be approximately 1,250 exposures across all Amazon cloud regions. An Amazon spokesperson said to TechCrunch, customers who set their Amazon EBS snapshots to public “have been notified and advised to take the snapshot offline if the setting was unintentional.” Morris plans to release his proof-of-concept code in the coming weeks. “I’m giving companies a couple of weeks to go through their own disks and make sure that they don’t have any accidental exposures,” he said. On Hacker News users are astonished to know about this fact and some of them say they have never come across such a situation after working on AWS for years. While some agree that the exposure of Amazon EBS snapshots it could be accidental or due to management pressure. One of the comments read, “I've been working almost exclusively in the AWS space for about 10 years now. Clients anywhere from tiny little three-person consultancies to Fortune 100. Commercial, govcloud, dozens of clients. Never once have I ever found a use case for making public EBS snapshots. Who on Earth is thinking that it is a good idea to take an EBS snapshot and make it public? Note, several of those engagements did involve multiple accounts, and the need to share / copy AMIs and/or snapshots between accounts. But never making them public.” Another user responded to this, “Laziness in attempting to share data with someone in another org? "Nope, can't access it" ... "Nope, still can't access it"... "My manager is harassing me to get access now"... "Look, just make it public then change it back after I get it copied"...” Ex-Amazon employee hacks Capital One’s firewall to access its Amazon S3 database; 100m US and 60m Canadian users affected Amazon S3 is retiring support for path-style API requests; sparks censorship fears Amazon S3 Security access and policies

Intel's’ chips have been struck with yet another significant flaw called ‘Foreshadow’. This flaw, alternatively called as L1 Terminal Fault or L1TF, targets Intel’s Security Guard Extensions (SGX) within its Core chips. The US government’s body for computer security testified that an attacker could take advantage of this vulnerability in Intel’s chips to obtain sensitive information. This security flaw affects processors released right from 2015. Thankfully,  Intel has released a patch to combat the problem. Check the full list of affected hardware on Intel's website. While Intel confirmed that they are not aware of reports that any of these methods have been used in real-world exploits, the tech giant is now under scrutiny. This was bound to happen as Intel strikes a  hattrick following two similar attacks - Spectre and Meltdown - that were discovered earlier this year in January. Intel confirms that future processors would be built in such a way as to not be affected by Foreshadow. How does Foreshadow affect your data? The flaw was first brought to Intel’s notice by researchers from KU Leuven University in Belgium and others from the universities of Adelaide and Michigan. Foreshadow can exploit various flaws in a computing technique known as speculative execution. It can specifically target a lock box within Intel’s processors. This would let a hacker leak any data desired. To give you a gist, a  processor can run more efficiently by guessing the next operation to be performed. A correct prediction will save resources, while work based on an incorrect prediction gets scrapped. However, the system leaves behind clues like how long it will take the processor to fulfill a certain request. This can be used by an attacker to find weaknesses, ultimately gaining the ability to manipulate what path the speculation takes. Thus, hacking into the data at opportune moments that leaks out of a process's data storage cache. Speculative execution is important to guard against, because an attacker could use them to access data and system privileges meant to be off-limits. The most intriguing part of the story, as stated by hardware security researcher and Foreshadow contributor Jo Van Bulck is,  “Spectre is focused on one speculation mechanism, Meltdown is another, and Foreshadow is another”.   "This is not an attack on a particular user, it’s an attack on infrastructure."                          YUVAL YAROM, UNIVERSITY OF ADELAIDE   After the discovery of Spectre and Meltdown, the researchers found it only too fitting to look for speculative execution flaws in the SGX enclave. To give you an overview, Security Guard Extensions, or SGX, were originally designed to protect code from disclosure or modification. SGX is included in 7th-generation Core chips and above, as well as the corresponding Xeon generation. It remains protected even when the BIOS, VMM, operating system, and drivers are compromised. Meaning that an attacker with full execution control over the platform can be kept away. SGX, allows programs to establish secure enclaves on Intel processors. These are regions of a chip that are restricted to run code that the computer's operating system can't access or change. The creates a safe space for sensitive data,. Even if the main computer is compromised by malware, the sensitive data remains safe. That apparently isn’t totally the case. Wired furthers stress on the fact that the Foreshadow bug could break down the walls between virtual machines, a real concern for cloud companies whose services share space with other theoretically isolated processes. Watch this youtube video for more clarity on how foreshadow works. https://www.youtube.com/watch?v=ynB1inl4G3c&feature=youtu.be The Quick Fix to Foreshadow Prior to details of the flaw being made public, Intel had created its fix and coordinated its response with the researchers on Tuesday. The fix disables some of chips features that were vulnerable to the attack. Along with software mitigations, the bug will also be patched at the hardware level with Cascade Lake, an upcoming Xeon chip, as well as future Intel processors expected to launch later this year. This mitigation limits the extent to which the same processor can be used simultaneously for multiple tasks, and hence companies running cloud computing platforms could see a significant hit to their collective computing power. On Tuesday, cloud services companies - Amazon, Google and Microsoft - said they had put in place a fix for the problem. Intel is working with these cloud providers—where uptime and performance is key—to “detect L1TF-based exploits during system operation, applying mitigation only when necessary,” Leslie Culbertson, executive vice president and general manager of Product Assurance and Security at Intel, wrote. Individual computer users are advised, as ever, to download and install any software updates available. The research team confirmed that is was unlikely that individuals would see any performance impact. As long as you’re system is patched up, you should be okay. Check out PCWorld’s guide on how to protect your PC against Meltdown and Spectre. You can also head over to the Red Hat Blog for more knowledge on Foreshadow. NetSpectre attack exploits data from CPU memory Intel’s Spectre variant 4 patch impacts CPU performance 7 Black Hat USA 2018 conference cybersecurity training highlights

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

A malicious worm, Retadup, affected 850k Windows machines throughout Latin America. The objective of the Retadup worm is to obtain persistence on victims’ computers to spread itself far and wide and to install additional malware payloads on infected machines. Source: Avast.io The Avast antivirus team started closely monitoring activities of the Retadup worm in March 2019. Jan Vojtěšek, a malware analyst at Avast who led research into Retadup said, "The general functionality of this payload is pretty much what we have come to expect from common malicious stealthy miners."  “In the vast majority of cases, the installed payload is a piece of malware mining cryptocurrency on the malware authors’ behalf. However, in some cases, we have also observed Retadup distributing the Stop ransomware and the Arkei password stealer,” Vojtěšek writes. A few days ago, Vojtěšek shared a report informing users that Avast researchers, the French National Gendarmerie and FBI have together disinfected the Retadup virus, by making the threat to self-destruct. When the Avast team analyzed the Retadup worm closely they identified a design flaw in the (Command-and-Control) C&C protocol that “would have allowed us to remove the malware from its victims’ computers had we taken over its C&C server,” Vojtěšek writes. As Retadup’s C&C infrastructure was mostly located in France, Vojtěšek’s team decided to contact the  Cybercrime Fighting Center (C3N) of the French National Gendarmerie (one of two national police forces of France) at the end of March. The team shared their findings with the Gendarmerie proposing a disinfection scenario that involved taking over a C&C server and abusing the C&C design flaw in order to neutralize Retadup. In July 2019, the Gendarmerie received the green light to legally proceed with the disinfection. To do this, they replaced the malicious C&C server with a prepared disinfection server that made connected instances of Retadup self-destruct. “In the very first second of its activity, several thousand bots connected to it in order to fetch commands from the server. The disinfection server responded to them and disinfected them, abusing the C&C protocol design flaw,” the report states. The Gendarmerie also alerted the FBI of this worm as some parts of the C&C infrastructure were also located in the US. The FBI took them down successfully and on July 8, the malware authors no longer had any control over the malware bots, Vojtěšek said. “Since it was the C&C server’s responsibility to give mining jobs to the bots, none of the bots received any new mining jobs to execute after this takedown. This meant that they could no longer drain the computing power of their victims and that the malware authors no longer received any monetary gain from mining,” the report explained. Avast report highlights, “Over 85% of Retadup’s victims also had no third-party antivirus software installed. Some also had it disabled, which left them completely vulnerable to the worm and allowed them to unwittingly spread the infection further.” Retadup has many different variants of its core, which is written in either AutoIt or AutoHotkey. Both cases contain two files, the clean scripting language interpreter and the malicious script. “In AutoHotkey variants of Retadup, the malicious script is distributed as source code, while in AutoIt variants, the script is first compiled and then distributed. Fortunately, since the compiled AutoIt bytecode is very high-level, it is not that hard to decompile it into a more readable form,” the report states. Users and researchers are congratulating both the Avast team and the Gendarmerie to successfully disinfect the Retadup. https://twitter.com/nunohaien/status/1166636067279257600 To know more about Retadup in detail, read Avast’s complete report. Other interesting news in Security New Bluetooth vulnerability, KNOB attack can manipulate the data transferred between two paired devices A year-old Webmin backdoor revealed at DEF CON 2019 allowed unauthenticated attackers to execute commands with root privileges on server A security issue in the net/http library of the Go language affects all versions and all components of Kubernetes

Facebook’s public image suffered quite a few setbacks in recent times. The Cambridge analytica scandal has opened up a pandora’s box full of questions about user data security and privacy. In the recent senate hearings, Facebook CEO, Mark Zuckerberg had an apologetic tone and he promised to give utmost importance to user data security. The misfortunes however, doesn’t seem to be over for Zuckerberg and Facebook. In a latest security scare, a bug had caused quite a ruckus for the tech giant. Facebook composer bug Now let’s talk about the bugs, yes, you read that correctly, there were more than one recent Facebook bugs affecting user data and privacy. The first bug was related to the Facebook message composer. According to Facebook’s Chief Privacy Officer Erin Egan, the bug affected composer’s privacy settings in a way that when the users were creating new posts, it automatically changed the privacy settings to public. This meant that user updates which might have been private, were available publicly. This bug had affected 14 million users worldwide and it was active during 18th May to 22nd May 2018. It took Facebook till 27th May to identify the bug and then rectify the problem. As a trust building measure, Facebook had sent notifications to all the users affected by this breach. A snapshot of the Facebook notification looked like this:   Source: Techcrunch Automatic Unblocking bug The second incident occurred was between 29th May to 5th June. This particular incident was reported via a Facebook blog post which stated that a bug that had affected around 800k Facebook users, had temporarily unblocked contacts and enabled previously blocked contacts to message or view the details of the respective users. This security breach was in a way potentially dangerous since it openly allowed stalking or even harassment. Facebook had although stated that this bug had unblocked one contact per user. The official Facebook notification to the affected users looked like this: Source: Facebook Blog Facebook Analytics Data leak The story of bugs is not over yet. There were recent reports that the Facebook analytics data of around 3 percent Facebook apps were leaked to testers accidentally. This was  due to a faulty automated email system according to Facebook. Although Facebook insists on the fact that no personal user data was leaked, still this incident doesn’t go down well keeping in mind the company’s latest record of user privacy and data secrecy. Facebook is trying to be transparent in its approach to tackle this menace of recurring bugs, but how successful their efforts will be, only time and their future actions will tell. The Cambridge Analytica scandal and ethics in data science Mark Zuckerberg’s Congressional testimony: 5 things we learned F8 AR Announcements  

Last week, the team behind ZFS released zfs-0.8.2, an advanced file system. This release comes with support for 2.6.32 - 5.3 Linux kernels and comes with a list of changes. What’s new in zfs-0.8.2 The issue regarding the deadlock condition for scrubbing root pools on kernels has been resolved in this release. The team has made QAT related bug fixes. Fixes have been made to the zpool subcommands error message and unsupported options. zfs-dkms .deb package warning in the prerm script has been fixed. zvol_wait script now ignores partially received zvols. New service that waits on zvol links have been created. In etc/init.d/zfs-functions.in arch warning has been removed. Comments have been updated to match code. In this release, ZFS_DEV macro is used instead of literals. Slog test setup has been made more robust. Performance has been improved with the help of dmu_tx_hold_*_by_dnode(). In this release, default zcmd allocation has been increased to 256K. Error text for EINVAL in zfs_receive_one() has been fixed. Few users on Hacker News seem to be happy about this release and the progress made by the team behind zfs, a user commented on Hacker News, “I contributed a few patches to ZFS on Linux about 8 years ago - at a time when it was still very much in its infancy and panic'd when you looked at it in the wrong way. It's incredible how far they've come. We're using ZFS on Linux on about 120 servers at work and it's rock solid. Snapshots are a lifesaver in our day-to-day ops.”  Another user commented, “Always admired ZFS since when it came out. The talks by the creators were so enlightening.” Few others expected a block-pointer rewrite and background dedupe in this release. One of them commented, “Still no block-pointer rewrite?” To know more about this news, check out the official post. Other interesting news in programming Rust 1.38 releases with pipelined compilation for better parallelism while building a multi-crate project Mypy 0.730 releases with more precise error locations, display error codes and more! GNOME Foundation’s Shotwell photo manager faces a patent infringement lawsuit from Rothschild Patent Imaging  

Yesterday, Python’s core development team announced that PyPI now offers two-factor authentication to increase the security of Python package downloads and thus reduce the risk of unauthorized account access. The team announced that the 2FA will be introduced as a login security option on the Python Package Index. “We encourage project maintainers and owners to log in and go to their Account Settings to add a second factor”, the team wrote on the official blog. The blog also mentions that this project is a “grant from the Open Technology Fund; coordinated by the Packaging Working Group of the Python Software Foundation.” PyPI currently supports a single 2FA method that generates code through a Time-based One-time Password (TOTP) application. After users set up a 2FA on their PyPI account, they must provide a TOTP (along with your username and password) to log in. Therefore, to use 2FA on PyPI, users will need to provide an application (usually a mobile phone app) in order to generate authentication codes. Currently, only TOTP is supported as a 2FA method. Also, 2FA only affects login via the website, which safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without 2FA codes being provided. Developers said that they are working on WebAuthn-based multi-factor authentication, which will allow the use of Yubikeys for your second factor, for example. They further plan to add API keys for package upload, along with an advanced audit trail of sensitive user actions. A user on HackerNews answered a question, “Will I lock myself out of my account if I lose my phone?” by saying,  “You won't lock yourself out. I just did a quick test and if you reset your password (via an email link) then you are automatically logged in. At this point you can even disable 2FA. So 2FA is protecting against logging in with a stolen password, but it's not protecting against logging in if you have access to the account's email account. Whether or not that's the intended behaviour is another question…” To know more about the ongoing security measures taken, visit Python’s official blog post. Salesforce open sources ‘Lightning Web Components framework’ Time for data privacy: DuckDuckGo CEO Gabe Weinberg in an interview with Kara Swisher Which Python framework is best for building RESTful APIs? Django or Flask?

David Wong, Security Consultant, at NCC Group, a global expert in cyber security and risk mitigation, revealed details about the new cryptographic attack, last week, that can break the encrypted TLS traffic. Wong collaborated with other security researchers and found out that out of the nine different TLS implementations against cache attacks, seven were found to be vulnerable, namely, OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS. TLS or Transport Layer Security refers to a cryptographic protocol that offers end-to-end communications security over networks. It is widely used for internet communications and online transactions. TLS (except TLS 1.3) makes use of RSA as a key exchange algorithm, which determines how the client and server will authenticate during the handshake to negotiate a shared secret. The client encrypts a shared secret under the server's RSA public key, the server then receives it and decrypts it. The latest attack isn’t entirely new; it is simply another variation of the original Bleichenbacher oracle attack that was able to decrypt an RSA encrypted message using the Public-Key Cryptography Standards (PKCS) #1 function. This new attack uses a side-channel leak via cache access timings of TLS implementations to break these RSA key exchanges of TLS implementations. It affects all versions of TLS (including TLS 1.3) as well as QUIC and makes use of the state-of-the-art cache attack techniques such as Flush+Reload, Prime+Probe, Branch-Prediction, etc. Attacking TLS 1.3 and downgrading to TLS 1.2 Since TLS 1.3 does not offer an RSA key exchange, researchers started with downgrading to an older version of TLS (TLS 1.2) for the exploitation of the attack. To downgrade a client’s connection attempt, a spoofed TLS 1.2 handshake technique is used. The server’s RSA certificate was presented in a ServerCertificate message and then the handshake was put to an end with a ‘ServerHelloDone’ message. However, if at this point, the server does not have a trusted certificate that allows RSA key exchanges or the client refuses to support RSA key exchanges or older versions than TLS 1.2, the attack halts. Otherwise, the client will make use of the RSA public key contained in the certificate to encrypt the TLS premaster secret. It will then send it in a ClientKeyExchange message and ends its part of the handshake using a ChangeCipherSpec and a Finished message. It is at this time, the attack is performed to decrypt the RSA encrypted premaster secret. The last Finished message being sent should contain an authentication tag (with HMAC) of the whole transcript and should be encrypted with the transport keys derived from the premaster secret.                                                    NCC Group Now, even if some clients might have zero handshake timeouts, most serious applications such as browsers can give up on the connection attempt if the response takes too much time to arrive. So, there are several techniques that can slow down the handshake such as sending the ChangeCipherSpec message to reset the client’s timer and sending TLS warning alerts to reset the handshake timer. After the decryption attack terminates, the expected Finished message is sent to the client and a handshake is finalized. This downgrade attack is able to bypass multiple downgrade mitigations, namely, one server-side and two client-side. TLS 1.3 servers that negotiate older versions of TLS must also advertise this information to their peers. TLS 1.3 clients that negotiate an older version of TLS must check for these values and abort the handshake if found. On the other hand, a TLS 1.3 client that goes back to an older version of TLS must advertise this information in their subsequent client hellos. Furthermore, a client should also include the version used by the client hello inside the encrypted premaster secret. “As it stands, RSA is the only known downgrade attack on TLS 1.3, which we are the first to successfully exploit in this research”, states Wong. The researchers also state that it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP (Optimal asymmetric encryption padding) and ECEIS (Elliptic Curve Integrated Encryption Scheme) for asymmetric encryption or Elliptic Curve Diffie-Hellman in case of key exchanges. For more information, check out the official NCC Group blog. Zimperium zLabs discloses a new critical vulnerability in multiple high-privileged Android services to Google A kernel vulnerability in Apple devices gives access to remote code execution FreeRTOS affected by 13 vulnerabilities in its TCP/IP stack

Security Researchers have discovered a new backdoor trojan, dubbed as ‘SpeakUp’ which exploits known vulnerabilities in six different Linux distributions and has the ability to infect MacOS. This trojan discovered by Check Point Research, is being utilised in a crypto mining campaign that has targeted more than 70,000 servers worldwide so far. Attackers have been using SpeakUp in a campaign to deploy Monero cryptocurrency miners on infected servers thus earning around 107 Monero coins (around $4,500). Last month, the backdoor was spotted for the first time and researchers discovered a built-in Python script that allowed the trojan to spread through the local network, laterally. The virus remains undetected, has complex propagation tactics, and the threat surface contains servers that run the top sites on the internet. What can this trojan do? Vulnerable systems that have been affected by this trojan allow the hackers to perform a host of  illicit activities like modification of the local cron utility to gain boot persistence, take control over shell commands, execute files downloaded from a remote command and control (C&C) server, and update or uninstall itself. According to the researchers, SpeakUp has already been spotted exploiting the Linux servers that run more than 90 percent of the top 1 million domains in the U.S. The hackers behind SpeakUp are using an exploit for the ThinkPHP framework to infect servers and the researchers have not  seen the attackers targeting anything except ThinkPHP. The trojan has been crafted with complexity and can scan local networks for open ports, use a list of pre-defined usernames and passwords to brute-force nearby systems and take over unpatched systems using one of these seven exploits: CVE-2012-0874: JBoss Enterprise Application Platform Multiple Security Bypass Vulnerabilities CVE-2010-1871: JBoss Seam Framework remote code execution JBoss AS 3/4/5/6: Remote Command Execution CVE-2017-10271: Oracle WebLogic wls-wsat Component Deserialization RCE CVE-2018-2894: Vulnerability in the Oracle WebLogic Server component of Oracle Fusion Middleware. Hadoop YARN ResourceManager - Command Execution CVE-2016-3088: Apache ActiveMQ Fileserver File Upload Remote Code Execution Vulnerability. Security researchers have also pointed out to the fact that the SpeakUp’s authors have the ability to download any code they want to the servers. “SpeakUp’s obfuscated payloads and propagation technique is beyond any doubt the work of a bigger threat in the making. It is hard to imagine anyone would build such a compound array of payloads just to deploy few miners. The threat actor behind this campaign can at any given time deploy additional payloads, potentially more intrusive and offensive. It has the ability to scan the surrounding network of an infected server and distribute the malware.” According to Threatpost, Oded Vanunu, head of products vulnerability research for Check Point, said that “the scope of this attack includes all servers running ThinkPHP, Hadoop Yarn, Oracle WebLogic, Apache ActiveMQ and Red Hat JBoss. Since these software can be deployed on virtual servers, all cloud infrastructure are also prone to be affected.” According to the analysis by Check Point Research, the malware is currently distributed to Linux servers mainly located in China. Lotem Finkelstein, one of the Check Point researchers told ZDNet that “the infections in non-Chinese countries comes from SpeakUp using its second-stage exploits to infect companies' internal networks, which resulted in the trojan spreading outside the normal geographical area of a Chinese-only PHP framework.” You can head over to Check Point Research official post for a break down of how this trojan works as well as an analysis of its impact. Git-bug: A new distributed bug tracker embedded in git Fortnite just fixed a bug that let attackers to fully access user accounts, impersonate real players and buy V-Buck 35-year-old vulnerabilities in SCP client discovered by F-Secure researcher

For most of us, it is difficult to remember passwords across multiple devices and accounts. Also, if one account gets hacked, then attackers can manage to gain access to all the other accounts. Even though features like two-factor authentication (2FA) exist but not many use them. To make things simpler for its customers, Microsoft has introduced a "Make your device passwordless” feature in its Windows 10 devices. Just two days ago, the team at Microsoft announced Windows 10 Insider Preview Build 18936 in the Fast ring. The test build comes with a new sign-in option, "Make your device passwordless" in Settings. This means PCs can use Windows Hello face authentication, fingerprints, or a PIN code. The password option will no longer be there on the login screen if users opt-in for “Make your device passwordless” feature. https://twitter.com/msftsecurity/status/1064926596778401792 According to Microsoft, a PIN code is far more secure than a password, even though it appears to be very simple to use a four-digit code. The advantage is that it uses unknown variables and also the code is stored on a device and not shared online. Windows 10 stores the private key on a device with a Trusted Platform Module (TPM), which is also a secure chip that keeps a PIN local to the device only.  In case of a server being compromised or a password being stolen, an attacker can access the user’s device or account. But such an attack wouldn’t be effective with a Windows Hello PIN because the passwordless feature will still work through Azure Active Directory. It will further lock down business devices and protect valuable data by removing the password. This feature is currently available only for a set of Fast Ring Insiders and will be made available for others later this week. Users need a FIDO2-compatible security key for trying out these new capabilities. Microsoft has made public preview of FIDO2 security keys support in Azure Active Directory, available. It seems the company has been trying to convince Windows 10 users to opt into two-factor authentication processes such as basic SMS, Windows Hello, a separate Microsoft Authenticator app, or even physical security keys with the FIDO2 standard.  Microsoft Defender ATP detects Astaroth Trojan, a fileless, info-stealing backdoor Microsoft will not support Windows registry backup by default, to reduce disk footprint size from Windows 10 onwards Microsoft is seeking membership to Linux-distros mailing list for early access to security vulnerabilities            

Update: On September 4, 2019, Supermicro released security updates to address vulnerabilities affecting the Baseboard Management Controller (BMC). Administrators can review Supermicro’s Security Advisory and Security Vulnerabilities Table and apply the necessary updates and recommended mitigations.  A cybersecurity firm, Eclypsium reported yesterday that over 47K Supermicro servers have been detected with new vulnerabilities dubbed ‘USBAnywhere’ in their baseboard management controllers (BMCs). These vulnerabilities “allow an attacker to easily connect to a server and virtually mount any USB device of their choosing to the server, remotely over any network, including the Internet,” Eclypsium mention in their official report. Also Read: iPhone can be hacked via a legit-looking malicious lightning USB cable worth $200, DefCon 27 demo shows Issues with BMCs on various Supermicro platforms The problem arises because of how BMCs on Supermicro X9, X10 and X11 platforms implement virtual media; i.e. they remotely connect a disk image as a virtual USB CD-ROM or floppy drive. On accessing the virtual media service remotely, it allows plaintext authentication, sends most traffic unencrypted, uses a weak encryption algorithm for the rest, and is susceptible to an authentication bypass. Thus, these issues allow an attacker to easily gain access to a server, either by capturing a legitimate user’s authentication packet, using default credentials and in some cases, without any credentials at all. After the connection is established, the virtual media service allows the attacker to interact with the host system as a raw USB device. This means attackers can attack the server in the same way as if they had physical access to a USB port, such as loading a new operating system image or using a keyboard and mouse to modify the server, implant malware, or even disable the device entirely. The combination of easy access and straightforward attack avenues can allow unsophisticated attackers to remotely attack some of an organization’s most valuable assets. Analysis of the remote USB authentication A user can gain access to the virtual media service via a small Java application served on the BMC’s web interface. Further, the Java application connects to the service by listening on TCP port 623 on the BMC. The service, on the other hand, uses a custom packet-based format to authenticate the client and transport USB packets between client and server. The Eclypsium team analyzed this authentication process and have revealed some issues with it, including: Plaintext Authentication: While the Java application uses a unique session ID for authentication, the service also allows the client to use a plaintext username and password.  Unencrypted network traffic: Encryption is available but must be requested by the client. The Java application provided with the affected systems use this encryption for the initial authentication packet but then use unencrypted packets for all other traffic.  Weak encryption: When encryption is used, the payload is encrypted with RC4 using a fixed key compiled into the BMC firmware. This key is shared across all Supermicro BMCs. RC4 has multiple published cryptographic weaknesses and has been prohibited from use in TLS (RFC7465). Authentication Bypass (X10 and X11 platforms only): After a client has properly authenticated to the virtual media service and then disconnected, some of the service’s internal state about that client is incorrectly left intact. As the internal state is linked to the client’s socket file descriptor number, a new client that happens to be assigned the same socket file descriptor number by the BMC’s OS inherits this internal state. In practice, this allows the new client to inherit the previous client’s authorization even when the new client attempts to authenticate with incorrect credentials. The report highlights, “A scan of TCP port 623 across the Internet revealed 47,339 BMCs from over 90 different countries with the affected virtual media service publicly accessible.” Source: Eclypsium.com Eclypsium first reported the vulnerability to Supermicro on June 19 and some more additional findings on July 9. Further, on July 29, Supermicro acknowledged the report and developed a fix. On learning that a lot of systems were affected by this vulnerability, Eclypsium notified CERT/CC of the issue, twice in August. On August 23, Eclypsium notified network operators whose networks contain affected, Internet-accessible BMCs. Supermicro also confirmed its intent to publicly release firmware by September 3rd, on August 16. In order to secure the BMCs, the ones “that are not exposed to the Internet should also be carefully monitored for vulnerabilities and threats. While organizations are often fastidious at applying patches for their software and operating systems, the same is often not true for the firmware in their servers,” the report suggests. “Just as applying application and OS security updates has become a critical part of maintaining IT infrastructure, keeping abreast of firmware security updates and deploying them regularly is required to defend against casual attacks targeting system firmware,” Eclypsium further suggests. Also Read: What’s new in USB4? Transfer speeds of upto 40GB/second with Thunderbolt 3 and more As mitigation to this issue, the company suggests that along with the vendor-supplied updates, organizations should also adopt tools to proactively ensure the integrity of their firmware and identify vulnerabilities, missing protections, and any malicious implants in their firmware. A user on Hacker News writes, “BMC's (or the equivalent for whatever vendor you are using) should never be exposed to the internet- they shouldn't even be on the same network as the rest of the server. Generally speaking. I put them on a completely separate network that has to be VPN'd into explicitly. Having BMC access is as close to having physical access as you can get without actually touching the machine.” To know more about this news in detail, read Eclypsium’s official report on USBAnywhere. Other news in security attacks A security issue in the net/http library of the Go language affects all versions and all components of Kubernetes GitHub now supports two-factor authentication with security keys using the WebAuthn API New Bluetooth vulnerability, KNOB attack can manipulate the data transferred between two paired devices

Intel recently announced their fix for Spectre variant 4 attack that would significantly decrease CPU performance. While working on this fix, Intel anticipated some performance questions that were around the combined software and firmware microcode updates that helps mitigate Spectre variant 4. As discovered by Jann Horn of Google Project Zero and Ken Johnson of Microsoft Spectre variant 4 is a speculative store bypass. Speculative bypass is a variant 4 vulnerability, with this an attacker can leverage variant 4 to read older memory values in a CPU’s stack or other memory locations. This vulnerability allows less privileged code to read arbitrary privileged data and run older commands speculatively. Intel call its mitigation of this Spectre attack as Speculative Store Bypass Disable (SSBD). Intel delivers this as a microcode update to appliance manufacturers, operating system vendors and other ecosystem partners. According to Intel, this patch will be ‘off” by default but if enabled Intel has observed an impact on the the performance from 2%-8% approximately but this would all depend on the overall scores from benchmarks such as SPECint, SYSmark® 2014 SE, and more. Back in January, Intel was less forthcoming in communicating about the CPU performance impact caused by Spectre variant 2 mitigation. They just waved-off such concerns with claiming that the performance would vary depending on the workload. However, Google pushed back stating the impact was severe and ended-up developing its very own Retpoline software alternative. Recently, Intel tested the impact of SSBD running it on an unspecified Intel reference hardware and 8th Gen Intel Core desktop microprocessor. The results on the performance impact of the overall score are as follows: SYSmark 2014 SE: 4% SPECint_rate_base2006 (n copy): 2% SPECint_rate_base2006 (1 copy): 8% These benchmark results are similar even on a Skylake architecture Xeon processor. Intel has clearly stated that this mitigation will be set to ‘off’ by default giving customers a choice to enable it. This is because Intel speculates that most industry software partners will go with the default option to avoid overall performance degradation. They also noted that SSBD would add an extra layer of protection to the hardware of consumers and original equipment manufacturers to prevent the Speculative Store Bypass from occurring. They also stated that the existing browser mitigations against Spectre variant 1 will help to an extend in mitigating variant 4. You can know more about the latest security updates on Intel products form Intel security center. Top 5 penetration testing tools for ethical hackers 12 common malware types you should know Pentest tool in focus: Metasploit