Tech News - Cybersecurity

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

Earlier this month, at DEF CON 2019, a Turkish security researcher, Özkan Mustafa Akkuş presented a zero-day remote code execution vulnerability in Webmin, a web-based system configuration system for Unix-like systems. Following this disclosure, its developers revealed that the backdoor was found in Webmin 1.890. A similar backdoor was also detected in versions 1.900 to 1.920. The vulnerability was found in a Webmin security feature that allows an administrator to enforce a password expiration policy for other users’ accounts. The security researcher revealed that the vulnerability was present in the password reset page. It allows a remote, unauthenticated attacker to execute arbitrary commands with root privileges on affected servers. They just need to add a simple pipe command ("|") in the old password field through POST requests. This vulnerability is tracked as CVE-2019-15107. The Webmin zero-day vulnerability was no accident Jamie Cameron, the author of Webmin, in a blog post talked about how and when this backdoor was injected. He revealed that this backdoor was no accident, and was in fact, injected deliberately in the code by a malicious actor. He wrote, “Neither of these were accidental bugs - rather, the Webmin source code had been maliciously modified to add a non-obvious vulnerability,” he wrote. The traces of this backdoor goes back to April 2018 when the development build server of Webmin was exploited and a vulnerability was introduced to the ‘password_change.cgi’ script. The team then reverted this file to its checked-in version from GitHub. The attacker again modified this file in July 2018. However, this time they added the exploit to code that executed only when changing of expired passwords was enabled. The team then replaced the vulnerable build server with a new server running CentOS7 in September 2018. But, this also did not solve the problem because the build directory that had the modified file was copied across from backups made on the original server. After being informed about the zero-day exploit on 17th August 2019, the team released an updated version of Webmin 1.930 and Usermin version 1.780 addressing the vulnerabilities. These releases also address cross-site scripting (XSS) vulnerabilities that were disclosed by a different security researcher. In order to ensure that such attacks are not repeated in the future the team is taking a few steps: Updating the build process to use only checked-in code from Github, rather than a local directory that is kept in sync. Rotated all passwords and keys accessible from the old build system. Auditing all GitHub check-ins over the past year to look for commits that may have introduced similar vulnerabilities. To know more in detail, check out the official announcement by Webmin. Attackers are exploiting vulnerabilities revealed at DEF CON and Black Hat A ZDNet report posted last week, revealed that attackers are now exploiting the vulnerabilities that were made public earlier this month. Bad Packet reported on Twitter that it detected several “active exploitation attempts” by attackers on Friday. https://twitter.com/bad_packets/status/1164764172044787712 Many attackers are also targeting vulnerabilities in Pulse Secure VPN and Fortinet's FortiGate VPN. Some of these vulnerabilities were discussed in a Black Hat talk named ‘Infiltrating Corporate Intranet Like NSA: Pre-auth RCE on Leading SSL VPNs.’ Bad Packets in a blog post shared that its honeypots have detected an “opportunistic mass scanning activity” targeting Pulse Secure VPN server endpoints vulnerable to CVE-2019-11510. This vulnerability discloses sensitive information using which unauthenticated attackers can get access to private keys and user passwords. https://twitter.com/bad_packets/status/1164592212270673920 Security researcher, Kevin Beaumont tweeted that hackers are scanning the internet for vulnerable devices to retrieve VPN session files from Fortinet's FortiGate. https://twitter.com/GossiTheDog/status/1164536461665996800 Puppet launches Puppet Remediate, a vulnerability remediation solution for IT Ops New Bluetooth vulnerability, KNOB attack can manipulate the data transferred between two paired devices Apple announces ‘WebKit Tracking Prevention Policy’ that considers web tracking as a security vulnerability  

On Monday, August 19, the Cisco Talos research team disclosed eight security vulnerabilities in Google’s Nest Cam IQ, a high-end security indoor camera (IoT device). These vulnerabilities allow hackers to take over the camera, prevent its use or allow code execution. The two researchers, Lilith Wyatt and Claudio Bozzato, said that these eight vulnerabilities  apply to version 4620002 of the Nest Cam IQ indoor device and were located in the Nest implementation of the Weave protocol. The Weave protocol is designed specifically for communications among Internet of Things or IoT devices. Per Cisco Talos, Nest Labs’ Cam IQ Indoor integrates security-enhanced Linux in Android, Google Assistant and facial recognition all into a compact security camera. Nest, on the other hand, has provided a firmware update that the company says will fix the vulnerabilities. Nest says that these updates will happen automatically if the user’s camera is connected to the internet. The researchers in their official statement said, "Nest Cam IQ Indoor primarily uses the Weave protocol for setup and initial communications with other Nest devices over TCP, UDP, Bluetooth, and 6lowpan.” "It is important to note that while the weave-tool binary also lives on the camera and is vulnerable, it is not normally exploitable as it requires a local attack vector (i.e. an attacker-controlled file) and the vulnerable commands are never directly run by the camera," they further added. The eight vulnerabilities in Google Nest Cam IQ TCP connection denial-of-service vulnerability This vulnerability (CVE-2019-5043) is an exploitable denial-of-service vulnerability that exists in the Weave daemon of the Nest Cam IQ Indoor, version 4620002. A set of TCP connections can cause unrestricted resource allocation, resulting in a denial of service. An attacker can connect multiple times to trigger this vulnerability. Legacy pairing information disclosure vulnerability This exploitable information disclosure vulnerability (CVE-2019-5034) exists in the Weave legacy pairing functionality of the Nest Cam IQ Indoor, version 4620002. A set of specially crafted Weave packets can cause an out-of-bounds read, resulting in information disclosure. PASE pairing brute force vulnerability This vulnerability (CVE-2019-5035) exists in the Weave PASE pairing functionality of the Nest Cam IQ Indoor, version 4620002. Here, a set of specially crafted weave packets can brute force a pairing code, resulting in greater Weave access and potentially full device control. KeyError denial-of-service vulnerability This vulnerability (CVE-2019-5036) exists in the Weave error reporting functionality of the Nest Cam IQ Indoor, version 4620002. Here, a specially crafted weave packet can cause an arbitrary Weave Exchange Session to close, resulting in a denial of service. WeaveCASEEngine::DecodeCertificateInfo vulnerability This vulnerability (CVE-2019-5037) exists in the Weave certificate loading functionality of the Nest Cam IQ Indoor camera, version 4620002, where a specially crafted weave packet can cause an integer overflow and an out-of-bounds read to occur on unmapped memory, resulting in a denial of service. Tool Print-TLV code execution vulnerability This exploitable command execution vulnerability (CVE-2019-5038) exists in the print-tlv command of Weave tools. Here, a specially crafted weave TLV can trigger a stack-based buffer overflow, resulting in code execution. An attacker can trigger this vulnerability by convincing the user to open a specially crafted Weave command. ASN1Writer PutValue code execution vulnerability This exploitable command execution vulnerability (CVE-2019-5039) exists in the ASN1 certificate writing functionality of Openweave-core, version 4.0.2. Here, a specially crafted weave certificate can trigger a heap-based buffer overflow, resulting in code execution. An attacker can exploit this vulnerability by tricking the user into opening a specially crafted Weave. DecodeMessageWithLength information disclosure vulnerability This vulnerability (CVE-2019-5040) exists in the Weave MessageLayer parsing of Openweave-core, version 4.0.2 and the Nest Cam IQ Indoor, version 4620002. A specially crafted weave packet can cause an integer overflow to occur, resulting in PacketBuffer data reuse. In a statement to ZDNet, Google said, "We've fixed the disclosed bugs and started rolling them out to all Nest Camera IQs. The devices will update automatically so there's no action required from users." To know more about this news in detail, read Cisco Talos’ official blog post. Vulnerabilities in the Picture Transfer Protocol (PTP) allows researchers to inject ransomware in Canon’s DSLR camera Google’s Project Zero reveals several serious zero-day vulnerabilities in a fully remote attack surface of the iPhone Docker 19.03 introduces an experimental rootless Docker mode that helps mitigate vulnerabilities by hardening the Docker daemon

On August 19, the Kubernetes Community disclosed that a security issue has been found in the net/http library of the Go language affecting all versions and all components of Kubernetes. This can further result in a DoS attack against any process with an HTTP or HTTPS listener. The two high severity vulnerabilities, CVE-2019-9512 and CVE-2019-9514 have been assigned CVSS v3.0 base scores of 7.5 by the Kubernetes Product Security Committee. These vulnerabilities allow untrusted clients to allocate an unlimited amount of memory until the server crashes. The Kubernetes' development team has released patched versions to address these security flaws to further block potential attackers from exploiting them. CVE-2019-9512 Ping Flood In CVE-2019-9512, the attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service. CVE-2019-9514 Reset Flood In CVE-2019-9514, the attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service. The Go team announced versions go1.12.8 and go1.11.13, following which the Kubernetes developer team has released patch versions of Kubernetes built using the new versions of Go. Kubernetes v1.15.3 - go1.12.9 Kubernetes v1.14.6 - go1.12.9 Kubernetes v1.13.10 - go1.11.13 On August 13, Netflix announced the discovery of multiple vulnerabilities that can affect server implementations of the HTTP/2 protocol. The popular video streaming website issued eight CVEs in their security advisory and two of these also impact Go and all Kubernetes components designed to serve HTTP/2 traffic (including /healthz). The Azure Kubernetes Service community has recommended customers to upgrade to a patched release soon. “Customers running minor versions lower than the above (1.10, 1.11, 1.12) are also impacted and should also upgrade to one of the releases above to mitigate these CVEs”, the team suggests. To know more about this news in detail, read AKS Guidance and updates on GitHub. Security flaws in Boeing 787 CIS/MS code can be misused by hackers, security researcher says at Black Hat 2019 CNCF-led open source Kubernetes security audit reveals 37 flaws in Kubernetes cluster; recommendations proposed Cybersecurity researcher "Elliot Alderson" talks Trump and Facebook, Google and Huawei, and teaching kids online privacy [Podcast]

Yesterday, GitHub announced that it now supports Web Authentication (WebAuthn) for security keys. In addition to time-based one-time password (TOTP) applications and text messages, you can now also configure two-factor authentication using a security key. https://twitter.com/github/status/1164240757278027779 WebAuthn is a standard by W3C that uses a public key instead of passwords or SMS texts for registering and authentication. It leverages strong authenticators that come built into devices like Windows Hello or Apple’s Touch ID. The purpose behind WebAuthn is not only to address security problems like phishing and data breaches but also significantly increase ease of use. Citing the reason behind bringing this support, Lucas Garron, GitHub’s Security Engineer, wrote in the announcement, “Account security is critical for GitHub. Although we support strong authentication options, many people still don’t use a password manager or two-factor authentication because individual passwords have always been the easiest choice.” You will be able to use physical security keys on GitHub if you are using the following: Firefox and Chrome-based browsers on Windows, macOS, Linux, and Android Edge users on Windows Brave on iOS using the new YubiKey 5Ci Safari Technology Preview on macOS GitHub also allows using your laptop or phone as a security key if you do not want to carry an actual physical key. For this, you are required to register your device first. People using Microsoft Edge on Windows can register their device using Windows Hello with facial recognition, fingerprint reader, or PIN. Chrome users on macOS can use Touch ID, while on Android they can use the fingerprint reader to register their device. Currently, security keys are secondary to authentication with a TOTP application or a text message. As more platforms start supporting security keys, GitHub plans to eventually make them the primary second factor. “Because platform support is not yet ubiquitous, GitHub currently supports security keys as a supplemental second factor. But we’re evaluating security keys as a primary second factor as more platforms support them. In addition, WebAuthn can make it possible to support login using your device as a “single-factor” security key with biometric authentication instead of a password,” Garron said. This announcement got mixed reactions from users. While some think that security keys are future of online authentication, others believe that we are better off with just a plain username-and-password authentication. The concerns users have for fingerprints and other biometric means for authentication is that they are not really a secret and if in case they are compromised there is no way to reset them. https://twitter.com/probonopd/status/1164241777089548289 Those supportive of this step are excited about the ease of use WebAuthn brings. A user on Hacker News commented, "This is fantastic. I look forward to finally having much easier authentication on the web. Imagine browsers syncing between devices a single encryption key that will authenticate you to all sites, which you can easily back up to a piece of paper." Another user suggested, "In a somewhat related vein: it would be really fantastic if Github allowed the same SSH key (in my case: a Yubikey-resident SSH key) on multiple accounts; we use separate accounts for different clients, and Github's refusal to allow an SSH key to be used on multiple accounts means I can't use Yubikey SSH keys for those." If you’d like to add support for security keys as an authentication option for your web service, you can use a JSON. Check out the official announcement by GitHub to know in detail. 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 Apache Software Foundation finally joins the GitHub open source community  

Recently, a group of researchers exposed a severe vulnerability called Key Negotiation Of Bluetooth (KNOB) that allows an attacker to break the Bluetooth Basic Rate/Extended Data Rate (BR/EDR) security. The vulnerability allows the attacker to intercept, monitor, or manipulate encrypted Bluetooth traffic between two paired devices, without being detected. The vulnerability was identified by researchers at the Center for IT-Security, Privacy and Accountability (CISPA) who shared their findings in a paper “The KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of Bluetooth BR/EDR”. The paper was included in the proceedings of the 28th USENIX Security Symposium (August 14–16), USA. In November 2018, the researchers of the paper shared the details of the attack with the Bluetooth SIG, the CERT Coordination Center, and the International Consortium for the Advancement of Cybersecurity on the Internet (ICASI), which is an industry-led coordination body founded by Intel, Microsoft, Cisco, Juniper and IBM. The vulnerability has been assigned CVE ID CVE-2019-9506. [box type="shadow" align="" class="" width=""]The Bluetooth BR/EDR is a popular wireless technology which is used for low-power short-range communications, and is maintained by the Bluetooth Special Interest Group (SIG).[/box] How does the KNOB attack the victim’s devices The researchers specify that such an attack would “allow a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key—enabling the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time)." Researchers add that the attack is “standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected." In some cases, it can also allow an attacker to reduce the length of an encryption key to a single octet. "In addition, since not all Bluetooth specifications mandate a minimum encryption key length, it is possible that some vendors may have developed Bluetooth products where the length of the encryption key used on a BR/EDR connection could be set by an attacking device down to a single octet,” according to an advisory released by Bluetooth. This in turn would make it much easier for an attacker to brute force the encryption key used by the paired devices to communicate with each other. The KNOB attack is effective, stealthy and cheap The KNOB attack is a serious threat to the security and privacy of all Bluetooth device users. It exploits the vulnerable encryption key negotiation protocol, hence risking all standard compliant Bluetooth devices irrespective of their Bluetooth version number and implementation details. This attack is highly ‘effective’ and severe as it can even attack secure Bluetooth connections. The KNOB attack is considered ‘stealthy’ (secretive), as the users and the Bluetooth application developers do not come to know about the attack, since it generally uses a Bluetooth link-layer encryption as a trusted service. Also, the protocol is transparent to the Bluetooth host (OS) and the Bluetooth application used by the victims. The KNOB attack is also cheap because the attacker does not need an expensive resource or an attacker model to conduct the attack. The researchers say, “We were surprised to discover such fundamental issues in a widely used and 20 years old standard. We urge the Bluetooth SIG to update the specification of Bluetooth according to our findings. Until the specification is not fixed, we do not recommend to trust any link-layer encrypted Bluetooth BR/EDR link.” Proposed countermeasures to the KNOB attack The researchers have proposed two classes of countermeasures to the KNOB attack. The first class is called the Legacy compliant countermeasure which requires a standard amount of negotiable entropy that cannot be easily brute-forced, e.g.,16 bytes of entropy. It also includes automated checks by the Bluetooth host to confirm the amount of negotiated entropy each time the link layer encryption is activated. This will enable the hosts to abort the connection if the entropy does not meet the minimum requirement. Another class of countermeasure is called the Non-legacy compliant which modifies the encryption key negotiation protocol by securing it using the link key. The link key should be a shared and an authenticated secret should always be made available before starting the entropy negotiation protocol. It should also have message integrity and confidentiality. Devices vulnerable to the KNOB attack The researchers have conducted the attack on more than 17 unique Bluetooth chips including Broadcom, Qualcomm, Apple, Intel, and Chicony manufacturers and all the devices were found to be vulnerable to the KNOB attack. On August 13th, Bluetooth released a Security Notice stating that the Bluetooth SIG has updated the Bluetooth Core Specification to recommend a minimum encryption key length of 7 octets for further BR/EDR connections. However, the Bluetooth SIG says, “There is no evidence that the vulnerability has been exploited maliciously and the Bluetooth SIG is not aware of any devices implementing the attack having been developed, including by the researchers who identified the vulnerability. ” The researchers of this paper also disclosed KNOB attack to the Bluetooth Chip vendors in late 2018, following which some vendors have implemented workarounds for the vulnerability on their devices. These vendors include Apple macOS, iOS, and watchOS, Google, Cisco IP phones and Webex and Blackberry powered by Android phones who have added fixes to this vulnerability in their latest updates. Last week, the CERT Coordination Center also released an advisory to this attack. Last week, Microsoft released an update titled “CVE-2019-9506 | Encryption Key Negotiation of Bluetooth Vulnerability” They have proposed “a default 7-octet minimum key length to ensure that the key negotiation does not trivialize the encryption.” The researchers of this paper have also notified users that if their device has not been updated since late 2018, then it is likely to be vulnerable. Many people  are surprised to learn about the KNOB attack and are advising others to update their devices. https://twitter.com/aiacobelli_sec/status/1162348463402684416 https://twitter.com/4jorge/status/1162983043969236992 https://twitter.com/lgrangeia/status/1162170365541605377 https://twitter.com/jurajsomorovsky/status/1162119755475537926 To know more details about the KNOB attack, check out the “The KNOB is Broken” paper. Google to provide a free replacement key for its compromised Bluetooth Low Energy (BLE) Titan Security Keys Amazon FreeRTOS adds a new ‘Bluetooth low energy support’ feature Security flaws in Boeing 787 CIS/MS code can be misused by hackers, security researcher says at Black Hat 2019

At the Black Hat 2019 security conference in Las Vegas, Ruben Santamarta, an IOActive Principal Security Consultant in his presentation said that there were vulnerabilities in the Boeing 787 Dreamliner’s components, which could be misused by hackers. The security flaws are in the code for a component known as a Crew Information Service/Maintenance System. “The CIS/MS is responsible for applications like maintenance systems and the so-called electronic flight bag, a collection of navigation documents and manuals used by pilots,” according to Bruce Schneier's (public-interest technologist) blog.  Boeing, however, strongly disagreed with Santamarta’s findings saying that such an attack is not possible and rejected Santamarta’s “claim of having discovered a potential path to pull it off.” SantaMarta says, “An attacker could potentially pivot from the in-flight entertainment system to the CIS/MS to send commands to far more sensitive components that control the plane's safety-critical systems, including its engine, brakes, and sensors.” According to Wired, “Santa­marta himself admits that he doesn't have a full enough picture of the aircraft—or access to a $250 million jet—to confirm his claims.” In a whitepaper Santamarta released earlier this month, he points out that in September 2018, a publicly accessible Boeing server was identified using a simple Google search, exposing multiple files. On further analysis, the exposed files contained parts of the firmware running on the Crew Information System/Maintenance System (CIS/MS) and Onboard Networking System (ONS) for the Boeing 787 and 737 models respectively. These included documents, binaries, and configuration files. Also, a Linux-based Virtual Machine used to allow engineers to access part of the Boeing’s network access was also available.  “The research presented in this paper is based on the analysis of information from public sources, collected documents, and the reverse engineering work performed on the 787’s CIS/MS firmware, which has been developed by Honeywell, based on a regular (nonavionics, non-certified, and non-ARINC-653-compliant) VxWorks 6.2 RTOS (x86) running on a Commercial Off The Shelf (COTS) CPU board (Pentium M),” the whitepaper states.  Santamarta identified three networks in the 787, the Open Data Network (ODN), the Isolated Data Network (IDN), and the Common Data Network (CDN). The ODN talks with the outside, handling communication with potentially dangerous devices. The IDN handles secure devices, but not necessarily ones that are connected to aircraft safety systems; a flight data recorder is an example. Santamarta described the CDN as the "backbone communication of the entire network," connecting to electronics that could impact the safety of the aircraft. According to PCMag, “Santamarta was clear that there are serious limitations to his research, since he did not have access to a 787 aircraft. Still, IOActive is confident in its findings. "We have been doing this for many years, we know how to do this kind of research." SantaMarta said "We're not saying it's doomsday, or that we can take a plane down. But we can say: This shouldn't happen." Boeing, on the other hand, denies the claims put forward by SantaMarta and says that the claims do not represent any real threat of a cyberattack. In a statement to Wired, Boeing writes, "IOActive's scenarios cannot affect any critical or essential airplane system and do not describe a way for remote attackers to access important 787 systems like the avionics system." The statement further reads, "IOActive reviewed only one part of the 787 network using rudimentary tools, and had no access to the larger system or working environments. IOActive chose to ignore our verified results and limitations in its research, and instead made provocative statements as if they had access to and analyzed the working system. While we appreciate responsible engagement from independent cybersecurity researchers, we're disappointed in IOActive's irresponsible presentation." "Although we do not provide details about our cybersecurity measures and protections for security reasons, Boeing is confident that its airplanes are safe from cyberattack," the company's statement concludes. In a follow-up call with WIRED, Boeing’s company spokesperson said that “in investigating IOActive's claims, Boeing had gone so far as to put an actual Boeing 787 in "flight mode" for testing, and then had its security engineers attempt to exploit the vulnerabilities that Santamarta had exposed. They found that they couldn't carry out a successful attack.”  Further, according to Wired, Boeing also consulted with the Federal Aviation Administration and the Department of Homeland Security about Santamarta's attack hypothesis. The DHS didn't respond to a request for comment, but an FAA spokesperson wrote in a statement to WIRED that it's "satisfied with the manufac­turer’s assessment of the issue." The Boeing fleet has been in the news for quite some time ever since Boeing's grounded 737 MAX 8 aircraft killed a total of 346 people in two fatal air crashes in October last year and in March this year.  Stefan Savage, a computer science professor at the University of California at San Diego, said,"The claim that one shouldn't worry about a vulnerability because other protections prevent it from being exploited has a very bad history in computer security." Savage is currently working with other academic researchers on an avionics cybersecurity testing platform. "Typically, where there's smoke there's fire," he further adds.  Per Wired, “The Aviation Industry Sharing and Analysis Center shot back in a press release that his findings were based on "technical errors." Santamarta countered that the A-ISAC was "killing the messenger," attempting to discredit him rather than address his research.” PCMag writes, “Santamarta is skeptical. He conceded that it's possible Boeing added mitigations later on, but says there was no evidence of such protections in the code he analyzed." A reader on Schneier’s blog post writes that Boeing should allow SantaMarta’s team to conduct a test, for the betterment of the passengers, “I really wish Boeing would just let them test against an actual 787 instead of immediately dismissing it. In the long run, it would work out way better for them, and even the short term PR would probably be a better look.” Another reader commented about lax FAA standards on schneier’s blog post, “Reading between the lines, this would infer that FAA/EASA certification requires no penetration testing of an aircrafts systems before approving a new type. That sounds like “straight to the scene of the accident” to me…” A user who is responsible for maintenance of 787’s wrote on HackerNews, “Unlike the security researcher, I do have access to multiple 787s as I am one of many people responsible for maintaining them. I'm obviously not going to attempt to exploit the firmware on an aircraft for obvious reasons, but the security researcher's notion that you can "pivot" from the in flight entertainment to anything to do with aircraft operation is pure fantasy.” He further added, “These systems are entirely separate, including the electricity that controls the systems. This guy is preying on individuals' lack of knowledge about aircraft mechanics in order to promote himself.” Another user on HackerNews shared, “I was flying about a year ago and was messing with the in flight entertainment in a 787. It was pretty easy to figure out how to get to a boot menu in the in flight entertainment. I was thinking "huh, this seems like maybe a way in". Seeing how the in-flight displays navigational data it must be on the network as the flight systems. I'm sure there is some kind of segregation but it’s probably not ultimately secure.” Savage tells Wired, "This is a reminder that planes, like cars, depend on increasingly complex networked computer systems. They don't get to escape the vulnerabilities that come with this." To know more about this news, read the whitepaper by the IOActive team. You can also head over to Wired’s detailed analysis.  “Deep learning is not an optimum solution for every problem faced”: An interview with Valentino Zocca 4 common challenges in Web Scraping and how to handle them Microsoft workers protest the lethal use of Hololens2 in the $480m deal with US military

While our phones are running low on battery, we do not think twice before inserting a USB to charge it. Also, while transferring files to and fro other devices, we consider the simple wire as benign. Recently, in a demonstration at DefCon 27, a hacker by the online handle MG infected a simple iPhone USB lightning cable with “a small Wi-Fi-enabled implant, which, when plugged into a computer, lets a nearby hacker run commands as if they were sitting in front of the screen”, TechCrunch reports. Per Motherboard, MG made these cables by hand, painstakingly modifying real Apple cables to include the implant. MG told Motherboard, "It looks like a legitimate cable and works just like one. Not even your computer will notice a difference. Until I, as an attacker, wirelessly take control of the cable.” These dummy cables named as “O.MG cables” are visually indistinguishable from the original cables. They also work similar to an original piece, allowing users to charge their devices via USB or transfer files from their iOS devices. The hacker not only showcased the infected cable at DefCon but has also put these similar cables on sale for $200. "There has been a lot of interest and support behind this project," MG says on his blog, "and lots of requests on how to acquire a cable. That's a great feeling!" Once the cable is plugged into a device, it enables an attacker to mount a wireless hijack of the computer. “Once plugged in, an attacker can remotely control the affected computer to send realistic-looking phishing pages to a victim’s screen, or remotely lock a computer screen to collect the user’s password when they log back in,” TechCrunch writes. “In the test with Motherboard, MG connected his phone to a wifi hotspot emanating out of the malicious cable in order to start messing with the target Mac itself. MG typed in the IP address of the fake cable on his own phone's browser and was presented with a list of options, such as opening a terminal on my Mac. From here, a hacker can run all sorts of tools on the victim's computer”, Motherboard’s Joseph Cox writes. On being asked how close an attacker should be plugged in device, MG said, "I’m currently seeing up to 300 feet with a smartphone when connecting directly." “A hacker could use a stronger antenna to reach further if necessary. But the cable can be configured to act as a client to a nearby wireless network. And if that wireless network has an internet connection, the distance basically becomes unlimited." he added. Now MG wants to get the cables produced as a legitimate security tool; he said the company Hak5 is onboard with making that happen. These cables would be made from scratch rather than modified Apple ones, according to Motherboard. MG said, "Apple cables are simply the most difficult to do this to, so if I can successfully implant one of these, then I can usually do it to other cables." How can one avoid getting tricked by the dummy USB lightning cables? Users should ensure they do not go by the looks of the external packaging if any random cable is simply lying around. One should also avoid accepting unsolicited chargers, USB dongles, or similar components as gifts from people they do not trust. Also, one should avoid borrowing chargers from people they do not know.   While purchasing any tech component, users should choose from legit sources online or from any physical ensured locations where the packaging hasn’t been tampered with. While out in public places, one should always ensure their devices, cables, USB dongles, and other components are nearby and secure. A user on HackerNews is infuriated over why major vendors like Windows, macOS, and Linux have not implemented these basic precautions “It's a severe discredit to the major operating system vendors that plugging in a USB stick can still compromise a system.” The user further adds, “If a USB device identifies itself as a keyboard, the system shouldn't accept its keystrokes until either that keyboard has typed the user's login password, or the user uses a different input device to authorize it. If it identifies itself as a storage device, the filesystem driver should be hardened. If it identifies itself as an obscure 90s printer with a buggy driver written in C, it should prompt the user to confirm the device type before it loads the driver.” Another user on HackerNews wondered how one could ensure the cables sold online are legitimate; he writes, “Even more frightening, people selling them as seemingly legitimate cables on Amazon? People will pay you and you get a new botnet. How many could you sell before it's discovered? How can I, as a consumer, even tell? Amazon will even allow you to sell your malcable under the Apple brand.” To know more about this news in detail, head over to Motherboard complete report.  Google Project Zero reveals six “interactionless” bugs that can affect iOS via Apple’s iMessage Google’s Project Zero reveals several serious zero-day vulnerabilities in a fully remote attack surface of the iphone Apple Card, iPhone’s new payment system, is now available for select users

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

Google has announced a FIDO2 based local user verification for Google Accounts, for a simpler authentication experience when viewing saved passwords for a website. Basically, you can now use fingerprint or screen lock instead of passwords when visiting certain Google services. This password-free authentication service will leverage the FIDO2 standards, FIDO CTAP, and WebAuthn, which is designed to “provide simpler and more secure authentication experiences. They are a result of years of collaboration between Google and many other organizations in the FIDO Alliance and the W3C” according to a blog post from the company. This new authentication process is designed to speed up the process of logging into Google accounts as well as being more secure by replacing the password typing system with a direct biometric authentication system. How this works is that if you tap on any one of your saved passwords on passwords.google.com, then Google will prompt you to "Verify that it’s you," at which point, you can authenticate using your fingerprint or any other method you usually use to unlock your phone (such as using a pin number or a touch pattern). Google has not yet made it clear which Google services could be used by the biometric method; the blog post cited Google's online Password Manager, as the example. Source: Google Google is also being cautious about data privacy, noting, “Your fingerprint is never sent to Google's servers - it is securely stored on your device, and only a cryptographic proof that you've correctly scanned it is sent to Google's servers. This is a fundamental part of the FIDO2 design. This sign-in feature is currently available on all Pixel devices. It will be made available to all Android phones running 7.0 Nougat or later "over the next few days.  Google Titan Security key with secure FIDO two factor authentication is now available for purchase Google to provide a free replacement key for its compromised Bluetooth Low Energy (BLE) Titan Security Keys Cloud Next 2019 Tokyo: Google announces new security capabilities for enterprise users

In a recent report, Motherboard reveals, “Contractors working for Microsoft are listening to personal conversations of Skype users conducted through the app's translation service.” This allegation was done on the basis of a cache of internal documents, screenshots, and audio recordings obtained by Motherboard. These files also reveal that the contractors were also listening to voice commands given to its Cortana. While Skype FAQs does mention that it collects and uses conversations to improve products and services and also that company may analyze audio of phone calls that a user wants to translate in order to improve the chat platform's services; however, it nowhere informs users that some of the voice analysis may be done manually. Earlier this year, Apple, Amazon, and Google faced scrutiny over how they handle user’s voice data obtained from their respective voice assistants. After the Guardian’s investigation into Apple employees’ listening in on Siri conversations was published, Apple announced it has temporarily suspended human transcribers to listen to conversations users had with Siri. Google agreed to stop listening in and transcribing Google Assistant recordings for three months in Europe. Google’s decision to halt its review process was disclosed after a German privacy regulator started investigating the program after “a contractor working as a Dutch language reviewer handed more than 1,000 recordings to the Belgian news site VRT which was then able to identify some of the people in the clips.” TechCrunch reports. On the other hand, Amazon now allows users to opt-out of the program that allows contractors to manually review voice data. Bloomberg was the first to report in April that “Amazon had a team of thousands of workers around the world listening to Alexa audio requests with the goal of improving the software”. The anonymous Microsoft contractor who shared the cache of files with Motherboard said, “The fact that I can even share some of this with you shows how lax things are in terms of protecting user data.” In an online chat, Frederike Kaltheuner, data exploitation program lead at activist group Privacy International, told Motherboard, “People use Skype to call their lovers, interview for jobs, or connect with their families abroad. Companies should be 100% transparent about the ways people's conversations are recorded and how these recordings are being used." She further added, “If a sample of your voice is going to human review (for whatever reason) the system should ask them whether you are ok with that, or at least give you the option to opt-out." Pat Walshe, an activist from Privacy Matters, in an online chat with Motherboard said, "The marketing blurb for [Skype Translator] refers to the use of AI not humans listening in. This whole area needs a regulatory review." "I’ve looked at it (Skype Translator FAQ) and don’t believe it amounts to transparent and fair processing," he added. A Microsoft spokesperson told Motherboard in an emailed statement, "Microsoft collects voice data to provide and improve voice-enabled services like search, voice commands, dictation or translation services. We strive to be transparent about our collection and use of voice data to ensure customers can make informed choices about when and how their voice data is used. Microsoft gets customers’ permission before collecting and using their voice data." The statement continues, "We also put in place several procedures designed to prioritize users’ privacy before sharing this data with our vendors, including de-identifying data, requiring non-disclosure agreements with vendors and their employees, and requiring that vendors meet the high privacy standards set out in European law. We continue to review the way we handle voice data to ensure we make options as clear as possible to customers and provide strong privacy protections."  How safe is user data with these smart assistants looped with manual assistance? According to the documents and screenshots, when a contractor is given a piece of audio to transcribe, they are also given a set of approximate translations generated by Skype's translation system. “The contractor then needs to select the most accurate translation or provide their own, and the audio is treated as confidential Microsoft information, the screenshots show,” Motherboard reports. Microsoft said this data is only available to the transcribers “through a secure online portal, and that the company takes steps to remove identifying information such as user or device identification numbers.” The contractor told Motherboard, "Some stuff I've heard could clearly be described as phone sex. I've heard people entering full addresses in Cortana commands or asking Cortana to provide search returns on pornography queries. While I don't know exactly what one could do with this information, it seems odd to me that it isn't being handled in a more controlled environment."  In such an environment users no longer feel safe even after the company’s FAQ assures them that their data is safe but actually being listened to. A user on Reddit commented, “Pretty sad that we can not have a secure, private conversation from one place to another, anymore, without taking extraordinary measures, which congress also soon wants to poke holes in, by mandating back doors in these systems.” https://twitter.com/masonremaley/status/1159140919247036416 After this revelation, people may take steps in a jiffy like uninstalling Skype or not sharing extra personal details in the vicinity of their smart home devices. However, such steps won’t erase everything the transcribers might have heard in the past. Will this effect also result in a reduction in sales of the smart home devices that will directly affect the IoT market for each company that offers it? https://twitter.com/RidT/status/1159101690861301760 To know more about this news in detail, read the Motherboard’s report. Microsoft reveals Russian hackers “Fancy Bear” are the culprit for IoT network breach in the U.S. Microsoft introduces public preview of Azure Dedicated Host and updates its licensing terms Data Transfer Project: Now Apple joins Google, Facebook, Microsoft and Twitter to make data sharing seamless

Security analysts from Google’s Project Zero investigated the remote attack surface of the iPhone and reviewed SMS, MMS, VVM, Email, and iMessage. They found several serious zero-day vulnerabilities in the remote, interaction-less attack surface of the iPhone. The majority of vulnerabilities occurred in iMessage due to its broad and difficult to enumerate attack surface. Visual Voicemail also had a large and unintuitive attack surface that likely led to a single serious vulnerability being reported in it.   Vulnerability in Visual Voicemail Visual Voicemail (VVM) is a feature of mobile devices that allows voicemail to be read in an email-like format. It informs devices of the location of the IMAP server by sending a specially formatted SMS message containing the URL of the IMAP server.  Any device can send a message that causes Visual Voicemail to query an IMAP server specified in the message. So an attacker can force a device to query an IMAP server they control without the user interacting with the device in any way. This results in an object lifetime issue in the iPhone IMAP client. It happens when a NAMESPACE command response contains a namespace that cannot be parsed correctly. It leads to the mailbox separator being freed, but not replaced with a valid object. This leads to a selector being called on an object that is not valid. This vulnerability was assigned id CVE-2019-8613. This issue was fixed on Tuesday, May 14. Vulnerabilities in iMessage CVE-2019-8624: A bug was found in the Digital Touch extension which led to a crash in SpringBoard requiring no user interaction.  This extension allows users to send messages containing drawings and other visual elements. This bug was fixed in Apple’s July 24 update. CVE-2019-8663: This vulnerability was found in deserializing the SGBigUTF8String class, which is a subclass of NSString. The initWithCoder: implementation of this class deserializes a byte array that is then treated as a UTF-8 string with a null terminator, even if it does not have one. This can lead to a string that contains out-of-bounds memory being created. CVE-2019-8661: This vulnerability is present in [NSURL initWithCoder:] and affects Mac only. It results in a heap overflow in [NSURL initWithCoder:] that can be reached via iMessage and likely other paths. It also results in a crash in soagent requiring no user interaction. This issue can be resolved by removing CarbonCore from the NSURL deserialization path. It was fixed on Saturday, Aug 3, 2019. CVE-2019-8646: This vulnerability allows deserializing in the class _NSDataFileBackedFuture even if secure encoding is enabled. Classes do not need to be public or exported to be available for deserialization. This issue was fixed in iOS 12.4 by preventing this class from being decoded unless it is explicitly added to the allow list. Better filtering of the file URL was also implemented. CVE-2019-8647: It occurs when deserializing class _PFArray, which extends NSArray and implements [_PFArray initWithObjects:count:], which is called by[NSArray initWithCoder:]. This vulnerability results in NSArray deserialization invoking a subclass that does not retain references. This issue can be reached remotely via iMessage and crash Springboard with no user interaction. This issue was fixed in 12.4 by implementing [_PFArray classForKeyedUnarchiver] and similar that returns NSArray. CVE-2019-8660. This vulnerability involved cycles in serialized objects. There is a memory corruption vulnerability when decoding an object of class  NSKnownKeysDictionary1. It was fixed in iOS 12.4 with improved length checking. They found another vulnerability CVE-2019-8641, which they are not yet disclosing because its fix did not fully remediate the issue. The analysts concluded that reducing the remote attack surface of the iPhone would likely improve its security. You can read their complete analysis on Project Zero’s blog. Google Project Zero reveals six “interactionless” bugs that can affect iOS via Apple’s iMessage Google Project Zero reveals an iMessage bug that bricks iPhone causing repetitive crash and respawn operations Cloud Next 2019 Tokyo: Google announces new security capabilities for enterprise users

Two days ago, Microsoft revealed that Russian hackers are attempting to compromise IoT devices including a VOIP, a printer, and a video decoder across multiple locations. These attacks were discovered in April, by security researchers in the Microsoft Threat Intelligence Center. According to the Microsoft report, “These devices became points of ingress from which the actor established a presence on the network and continued looking for further access,” “Once the actor had successfully established access to the network, a simple network scan to look for other insecure devices allowed them to discover and move across the network in search of higher-privileged accounts that would grant access to higher-value data.” Microsoft officials said, “We attribute the attacks on these customers using three popular IoT devices to an activity group that Microsoft refers to as STRONTIUM,” which is a Russian-based hacking group also known as Fancy Bear or ATP28. “In two of the cases, the passwords for the devices were deployed without changing the default manufacturer’s passwords and in the third instance the latest security update had not been applied to the device,” the officials further added. “After gaining access to each of the IoT devices, the actor ran tcpdump to sniff network traffic on local subnets. They were also seen enumerating administrative groups to attempt further exploitation,” the officials added. “As the actor moved from one device to another, they would drop a simple shell script to establish persistence on the network which allowed extended access to continue hunting. Analysis of network traffic showed the devices were also communicating with an external command and control (C2) server.” “Microsoft said it identified and blocked these attacks in their early stages, so its investigators weren't able to determine what Strontium was trying to steal from the compromised networks,” ZDNet reports. Microsoft has notified the makers of the targeted devices so that they can explore the possibility of adding new protections. Microsoft’s report also provided IP addresses and scripts that organizations can use to detect if they have also been targeted or infected. Microsoft plans to reveal more information about the Strontium April 2019 attacks later this week at the Black Hat USA 2019 security conference. To know more about this news in detail, read Microsoft's complete report. Winnti Malware: Chinese hacker group attacks major German corporations for years, German public media investigation reveals An IoT worm Silex, developed by a 14 year old resulted in malware attack and taking down 2000 devices A cybersecurity primer for mid sized businesses

Yesterday, at Black Hat 2019, Mimecast Limited, a leading email and data security company, introduced Mimecast Threat Intelligence which offers a deeper understanding of the cyber threats faced by organizations. The cybersecurity landscape changes daily, and attackers are constantly changing their techniques to avoid detection. According to Mimecast’s recent State of Email Security Report 2019, 94% of organizations saw phishing attacks in the last 12 months and 61% said it was likely or inevitable that they would be hit with an email-borne attack. The new features in Mimecast Threat Intelligence are designed to give organizations access to threat data and analytics specific to overall organization. Additionally it offers a granular view of the attacks blocked by Mimecast. The Mimecast Threat Intelligence dashboard highlights users who are most at-risk, malware detections, malware origin by geo-location, Indicators of Compromise (IoCs) and malware forensics based on static and behavioral analysis. The data is consolidated into a user-friendly view and will be available for integration into an organization’s security ecosystem through the Threat Feed API. This targeted threat intelligence will provide greater visibility and insight to security professionals, enabling them to easily respond and remediate against threats and malicious files. “As the threat landscape evolves, arming our organization and people with the best possible tools is more important now than ever,” said Thomas Cronkright, CEO at CertifID. “Mimecast’s Threat Intelligence is a unique, incredibly easy to use value-added service that provides an outstanding benefit to organizations in search of a secure ecosystem.” “The cyber threat landscape is dynamic, complex and driven by a relentless community of adversaries. IT and security teams need threat intelligence that is easy to digest and actionable, so they can better leverage the information to proactively prevent and defend against cyberattacks,” said Josh Douglas, Vice President of threat intelligence at Mimecast. “Mimecast sees a lot of data, as we process more than 300 million emails every day to help customers block hundreds of thousands of malicious emails. Mimecast Threat Intelligence helps organizations get the deep insights they need to build a more cyber resilient environment.” Mimecast Threat Intelligence consists of a Threat Dashboard, Threat Remediation and Threat Feed with Threat Intelligence APIs. To know more, check out this page on Mimecast Threat Intelligence. International cybercriminals exploited Citrix internal systems for six months using password spraying technique A zero-day vulnerability on Mac Zoom Client allows hackers to enable users’ camera, leaving 750k companies exposed An IoT worm Silex, developed by a 14 year old resulted in malware attack and taking down 2000 devices

Last week, Avinash Jain, a Lead Infrastructure Security Engineer at Grofers, reported that a misconfiguration in JIRA publicly exposed sensitive information about employees and projects of many big companies. These included organizations like NASA, Google, Yahoo, Zendesk, Lenovo, 1password, Informatica, as well as governing bodies across the world. https://twitter.com/logicbomb_1/status/1157311534395056128 What was the JIRA misconfiguration JIRA is Atlassian’s proprietary product used for bug tracking, issue tracking, and agile project management. When you create a dashboard or filter in JIRA it will set their visibility to “Everyone” and “All users” by default. While these settings seem like you are giving access to everyone in the organization, they are instead shared publicly. JIRA also has a user picker functionality that provides a complete list of every user’s username and email address. This happens because of an authorization misconfiguration in Jira’s Global Permissions settings. These misconfiguration issues in JIRA exposed internal user data including their names, emails, roles via JIRA groups, project details, upcoming milestones through JIRA dashboards/filters. An attacker with good knowledge of search queries just need to have access to find the link and they will have access to this information from anywhere. Jain further explained that he found the link to these dashboards, user pickers, and filters with something called “Google dorks”. He just had to fire a search query in Google and the results showed links to all the companies that had the user picker functionality misconfigured: Credits: Avinash Jain Jain has already contacted the affected companies. “I reported this to various companies, some rewarded me, some fixed it while some are still living with it,” he wrote. It is, however, unclear whether he has reported this vulnerability to Atlassian as there is no reply from the JIRA creator yet. What steps Atlassian and users can take to avoid this vulnerability Jain and many other users also feel that JIRA’s UX is a little bit confusing. He urges Atlassian to be more explicit about what it means by “Everyone” and “All users” and also recommends it should set the visibility to “Private” by default. Explaining the issue, a user on Hacker News said, “This issue arises because, if the site allows any public sharing, the "create filter" UI gives team members the option to share a new filter with "Everyone", which sounds like an org-local scope but is in fact a public/non-logged-in scope. The org-level scope is called, "Open", and is not part of this UI. Sigh.” The Hacker News user further recommends, “To prevent this issue as a site admin on Jira cloud, go to: Jira Settings -> System -> General Configuration and disable "Allow users to share dashboards and filters with the public." This doesn't affect existing filters, which you have to manually fix. In true Jira fashion, if you try to reassign a filter after flipping this setting, it will deny the operation and ask you to edit the ACL, which there is no convenient admin UI to do.” To know more, you can read Jain’s Medium post about the JIRA misconfiguration. Atlassian overhauls its Jira software with customizable workflows, new tech stack, and roadmaps tool Atlassian acquires OpsGenie, launches Jira Ops to make incident response more powerful A vulnerability found in Jira Server and Data Center allows attackers to remotely execute code on systems