Tech News - Security

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  

Russia is looking forward to its September 2019 elections for the representatives at the Parliament of the city (the Moscow City Douma). For the first time ever, Russia will use Internet voting in its elections. The internet-based system will use blockchain developed in-house by the Moscow Department of Information Technology. Since the news broke out, security experts have been quite skeptical about the overall applicability of blockchain to elections. Moscow’s voting system has a critical flaw in the encryption scheme Recently, a French security researcher Pierrick Gaudry has found a critical vulnerability in the encryption scheme used in the coding of the voting system. The scheme used was the ElGamal encryption, which is an asymmetric key encryption algorithm for public-key cryptography. Gaudry revealed that it can be broken in about 20 minutes using a standard personal computer and using only free software that is publicly available. The main problem, Gaudry says is in the choice of three cyclic groups of generators. These generators are multiplicative groups of finite fields of prime orders each of them being Sophie Germain primes. These prime fields are all less than 256-bit long and the 256x3 private key length is too little to guarantee strong security. Discrete logarithms in such a small setting can be computed in a matter of minutes, thus revealing the secret keys, and subsequently easily decrypting the encrypted data. Gaudry also showed that the implemented version of ElGamal worked in groups of even order, which means that it leaked a bit of the message. What an attacker can do with these encryption keys is currently unknown, since the voting system's protocols weren't yet available in English, so Gaudry couldn't investigate further. Following Gaudry's discovery, the Moscow Department of Information Technology promised to fix the reported issue. In a medium blog post, they wrote, "We absolutely agree that 256x3 private key length is not secure enough. This implementation was used only in a trial period. In a few days, the key's length will be changed to 1024." (Gaudry has mentioned in his research paper that the current general recommendation is at least 2048 bits). Even after the response, Gaudry was still concerned about potential flaws caused by the recent big changes fixing the key length issue. Gaudy concerns proved true as recently another security researcher Alexander Golovnev, found an attack on the revised encryption scheme. The revised encryption algorithm still leaks messages Alexander Golovnev is the current fellow for Michael O. Rabin Postdoctoral Fellowship in Theoretical Computer at Harvard University. His research reveals that the new implementation of the encryption system also leaks a bit of the message. This is caused by the usage of ElGamal where the message is not mapped to the cyclic group under consideration. This flaw can be misused for counting the number of votes cast for a candidate, which is illegal (until the end of the election period). Golovnev says that security vulnerability is a major issue of the implemented cryptographic scheme. The attack does not recover the secret key as required by the public testing scenario but rather breaks the system without recovering the secret key. There is no response or solution from the Moscow Department of Information Technology regarding this vulnerability. Many people took to Twitter to express their disappointment at Moscow’s lamentable internet voting system. https://twitter.com/mjos_crypto/status/1166252479761330176 https://twitter.com/KevinRothrock/status/1163750923182780416 In 2018, Robert Mueller’s report indicated that there were 12 Russian military officers who meddled with the 2016 U.S. Presidential elections. They had hacked into the Democratic National Committee, the Democratic Congressional Campaign Committee, and the Clinton campaign. This year, Microsoft revealed that Russian hackers ‘Fancy Bear’ 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. Microsoft reveals Russian hackers “Fancy Bear” are the culprit for IoT network breach in the US. FireEye reports infrastructure-crippling Triton malware linked to Russian government tech institute Russian government blocks ProtonMail services for its citizens

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

In September 2018, LightYear acquired Chain to form a combined company called Interstellar. The company is working on a new blockchain architecture with a focus on privacy, security, and safety named Slingshot. https://twitter.com/go_interstellar/status/1039164551139287040 The Slingshot project encapsulates the following sub-protocols and components: Zero-knowledge Virtual Machines (ZkVM) The authors of TxVM, a virtual machine for blockchain transactions have come up with ZkVM. https://twitter.com/oleganza/status/1126612382728372224 It is a blockchain transaction format with cloaked assets and zero-knowledge smart contracts. Its goal is to make transactions customizable, confidential, highly efficient, and simple. It allows custom contracts via programmable constraints over encrypted data and assets. Slingshot also has an API called Token for issuing assets using ZkVM. ZkVM ensures confidentiality by fully encrypting quantities and types of assets. It also makes it certain that the asset flow is hidden at the transaction level allowing individuals and organizations to safely perform their transactions directly on the shared ledger. Its data model is compact, taking up only a few kilobytes. You can verify transactions parallelly in 1-2 ms per CPU core and bootstrap nodes instantly from a network-verified snapshot. Spacesuit, Rust implementation of the Cloak protocol Slingshot's Spacesuit is the implementation of the Cloak protocol in Rust. Cloak is a protocol for confidential assets based on the Bulletproofs zero-knowledge circuit proof system. With cloaked transactions, you can exchange values that have different asset types. Musig, a signature scheme for signing messages Slingshot's Musig is the Rust implementation of Simple Schnorr Multi-Signatures. It is a signature scheme for signing single or multiple messages. You can sign a single message with one public key. This public key can be created from a private key of a single party or by aggregating multiple public keys. Multiple messages can be signed with multiple public keys. Keytree, a key blinding scheme for deriving hierarchies of public keys Keytree is a 'key blinding scheme' with which you can derive hierarchies of public keys for Ristretto-based signatures. It can derive a set of public keys with only one key without using any private keys. This enables a system to generate unique receiving addresses without knowing any details about the private key. For instance, an online merchant can generate invoices with unique keys by keeping only public keys on the server, without compromising the security of the private keys. Slidechain, a demonstration of a minimal Stellar sidechain Slingshot includes Slidechain that allows you to peg funds from the Stellar testnet. You can then import them to a sidechain and move them back to Stellar if needed. A sidechain is generally used for operations that aren’t possible or permitted on the originating network. The sidechain in Slidechain is based on TxVM for allowing safe, general-purpose smart contracts and token issuance. The pegged funds will remain immobilized on the originating network while the imported funds exist on the sidechain. On a Reddit thread, a user explained, “Looks more like an entire network upgrade to me. An overhaul that offers privacy, more scalability, and sidechains. It would be odd to offer a sidechain that operates as a better version of stellar.” Another user added, “Ever since Chain was acquired, there has been little information about what Interstellar is building for Stellar. Chain offered a blockchain service called Sequence. Sequence allowed you to easily setup a ledger/blockchain and integrate it with your application/business. I believe this repo details an enhanced version of Chain with Stellar integration. Businesses can create their own private network while having full access to the Stellar network to transact with other chain networks. This would function as a second layer solution on top of Stellar. Other networks such as OMG and Cosmos function similarly to this iirc.” To know more about Slingshot, check out its GitHub repository. Blast through the Blockchain hype with Packt and Humble Bundle Installing a blockchain network using Hyperledger Fabric and Composer[Tutorial] Google expands its Blockchain search tools, adds six new cryptocurrencies in BigQuery Public Datasets

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 the United States’ Department of Justice (DOJ) stated that Muhammad Fahd, a 34-year-old citizen of Pakistan had bribed the employees from AT&T’s Seattle-area offices and call centers by paying more than $1 million. Fahd bribed those employees in order to install malware on AT&T’s network so that he could unlock millions of smartphones. Fahd was supported by Ghulam Jiwani in this conspiracy, who is believed to be deceased. They tried to get illegal access to 2 million of the company’s phones from 2012 and 2017. Last year in February, on United States’ request, Muhammad Fahd got arrested in Hong Kong in the same month and was extradited to the United States last week. Fahd has a serious criminal history which includes intentional damage to a protected computer, wire fraud, and conspiracy to violate the Computer Fraud and Abuse Act, violate the Travel Act. AT&T uses proprietary locking software on its phone in order to prevent its phone from getting used on any other wireless network except for the AT&T network until the phones were unlocked. On unlocking the phones, the proprietary locking software would get disabled and which would let the phone work on multiple carrier systems. According to the Wireless Customer Agreement between AT&T and its customers, the company would unlock the customers' phone once the customers have fulfilled their terms of service contract or installment plan. These unlocked phones could be resold and be used by any other network. When the customers’ phone got fraudulently switched to another network, AT&T got deprived of some of the customers’ remaining payments that were under a customer’s installment plan and terms of service contract. As a result, millions of phones got removed from AT&T service and payment plans which costs the company millions of dollars. Fahd had paid tens of thousands of dollars to the AT&T insiders and to one of the co-conspirators he paid $428,500 over the five-year scheme.  The conspiracy started in 2012 and is still under investigation Last year in March, the second superseding indictment was filed that stated how Fahd bribed AT&T employees and used their computer credentials and disabled AT&T’s proprietary locking software.  As per the indictment, between April 2012 to April 2013, they gave instructions to AT&T’s insiders with the help of wires in interstate and foreign commerce. Fahd had also sent the list of cellular IMEI numbers for the phones to the insiders. Between April 2013 to October 2013 the AT&T insiders were bribed to plant malware on the computer systems to get information about the company’s computer network and software applications. This information was then used for creating another malware that interacted with the company’s internal protected computer systems for processing the fraudulent unlock requests. Between November 2014 to September 2017, they again bribed the AT&T insiders for getting access to AT&T’s physical workspace for installing unauthorized hardware devices such as wireless access points to get unauthorized access to the company’s computers.  Fahd used to contact these insiders through telephone, Facebook, anonymous email accounts and other channels. They were instructed to open shell companies and business accounts on the names of these shell companies for receiving payments. The insiders even helped Fahd and Jiwani for developing and installing tools that would help them in unlocking the phones even from a remote location. Till now, three of those co conspirators have pleaded guilty and have admitted that they were paid thousands of dollars for serving Fahd’s fraudulent scheme.  Assistant Attorney General Brian A. Benczkowski of the Justice Department’s Criminal Division, said, “This arrest illustrates what can be achieved when the victim of a cyber attack partners quickly and closely with law enforcement.”  Benczkowski further added, “When companies that fall prey to malware work with the Department of Justice, no cybercriminal—no matter how sophisticated their scheme—is beyond our reach.” U.S. Attorney Brian T. Moran for the Western District of Washington said, “This defendant thought he could safely run his bribery and hacking scheme from overseas, making millions of dollars while he induced young workers to choose greed over ethical conduct.”   Attorney Brian T. Moran added, “Now he will be held accountable for the fraud and the lives he has derailed.” Currently, the U.S. Secret Service Electronic Crimes Task Force is investigating this case. Community demands for strict security measures as employees were involved too According to a few users, the companies need to take strict security measures and shouldn’t ignore any security threat to them and implement encryption for user data.  A user commented on HackerNews, “Companies need to assume that their network is compromised. Ignoring anything else that means they need to adopt E2E encryption for all user data (except where legally mandated to be insecure, or when the data has a fundamental need to be accessible - e.g. your bank needs to know how much money you have). Anything else, including dumbass politicians demanding magic crypto, makes your user data a valuable and achievable target.” Few others are shocked about the fact that AT&T employees were involved in this. https://twitter.com/harrymccracken/status/1158745600399159297 https://twitter.com/rstephens/status/1158759723870482437 https://twitter.com/BobbyChesney/status/1158746997790257155 To know more about this news, check out the official page. Google, Amazon, AT&T met the U.S Senate Committee to discuss consumer data privacy, yesterday Winnti Malware: Chinese hacker group attacks major German corporations for years, German public media investigation reveals 25 million Android devices infected with ‘Agent Smith’, a new mobile malware