Tech News - Cybersecurity

Last week, the National Cyber Security Centre (NCSC) reported that they are investigating the exploitation, by Advanced Persistent Threat (APT) actors, of known vulnerabilities in VPN products. These VPN products are from vendors like Pulse secure, Palo Alto and Fortinet. It is an ongoing activity, targeted to the UK and other international organizations. According to NCSC, affected sectors include government, military, academic, business and healthcare. Vulnerabilities exist in several SSL VPN products As per the report, vulnerabilities exist in several SSL VPN products that can allow an attacker to retrieve arbitrary files containing authentication credentials. An attacker can use these stolen credentials to connect to the VPN and change configuration settings or connect to further internal infrastructure. The report also highlights that unauthorized connection to a VPN can provide the attacker with the privileges needed to run secondary exploits aimed at accessing a root shell. Read Also: MITRE’s 2019 CWE Top 25 most dangerous software errors list released Top Vulnerabilities in VPN exploited by APTs The highest-impact vulnerabilities known to be exploited by APTs are listed below: Pulse Connect Secure: CVE-2019-11510: Pre-auth arbitrary file reading CVE-2019-11539: Post-auth command injection Fortinet: CVE-2018-13379: Pre-auth arbitrary file reading CVE-2018-13382: Allows an unauthenticated attacker to change the password of an SSL VPN web portal user CVE-2018-13383: Post-auth heap overflow. This allows an attacker to gain a shell running on the router Palo Alto: CVE-2019-1579: Palo Alto Networks GlobalProtect Portal NCSC suggests that users of these VPN products should investigate their logs for evidence of compromise, especially if the security patches were not applied immediately after their release. Additionally, administrators should look for evidence of compromised accounts in active use, such as anomalous IP locations or times. The report also covers product-specific advice to detect exploitation in VPN connections. Steps to mitigate the vulnerabilities in VPN NCSC provides essential steps to be taken to mitigate the risk of these vulnerabilities. They suggest that owners of vulnerable products should take two steps promptly: Apply the latest security patches released by vendors Reset authentication credentials associated with affected VPNs and accounts connecting through them The most effective way to mitigate the risk of actors exploiting these vulnerabilities is to ensure that the affected products are patched with the latest security updates. Pulse secure, Palo Alto and Fortinet have released patches for these vulnerabilities. NCSC also emphasizes on reporting any current activity related to these threats at incidents@ncsc.gov.uk where they will offer help and guidance. On Hacker News, this report has gained significant traction and users are discussing the nature of various VPN products and services. One of them commented, “Commercial enterprise VPN products are an open sewer, and there aren't any, from any vendor, that I trust. I don't like OpenVPN or strongSwan, but you'd be better off with either of them than you would be with a commercial VPN appliance. The gold standard, as ever, is Wireguard.” To know more about this report, check out the official NCSC website. An unpatched security issue in the Kubernetes API is vulnerable to a “billion laughs” attack Google Project Zero discloses a zero-day Android exploit in Pixel, Huawei, Xiaomi and Samsung devices 10 times ethical hackers spotted a software vulnerability and averted a crisis A Cargo vulnerability in Rust 1.25 and prior makes it ignore the package key and download a wrong dependency VLC media player affected by a major vulnerability in a 3rd library, libebml; updating to the latest version may help

Google’s Project Zero disclosed a zero-day Android exploit in popular devices from Pixel, Huawei, Xiaomi, and Samsung, last Friday. This flaw unlocks root-level access and requires no or minimal customization to root a phone that’s exposed to the bug. A similar Android OS flaw was fixed in 2017 but has now found its way on newer software versions as well. The researchers speculate that this vulnerability is attributed to the NSO group based in Israel. Google has published a proof of concept which states that it is a kernel privilege escalation which uses a ‘use-after-free’ vulnerability, accessible from inside the Chrome sandbox. How does the zero-day Android exploit work As described in the upstream commit, “binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free.” Basically, the zero-day Android exploit can gain arbitrary kernel read/write when running locally. If the exploit is delivered via the web, it only needs to be paired with a renderer exploit, as this vulnerability is accessible through the sandbox. The vulnerability is exploitable in Chrome's renderer processes under Android's 'isolated_app' SELinux domain, making Binder as the vulnerable component. Affected devices include Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Huawei P20, Redmi 5A, Redmi Note 5, Mi A1, Oppo A3, Moto Z3, Oreo LG phones, Samsung Galaxy S7, Samsung Galaxy S8, and Samsung Galaxy S9.  This vulnerability was earlier patched in the Linux kernel version 4.14 and above, but without a CVE. Now, the vulnerability is being tracked as CVE-2019-2215. “This issue is rated as High severity on Android and by itself requires installation of a malicious application for potential exploitation. Any other vectors, such as via web browser, require chaining with an additional exploit,” Project Zero member Tim Willis wrote in the post. Project Zero normally offers a 90-day timeline for developers to fix an issue before making it public, but since this vulnerability was exploited in the wild, it was published in just seven days. In case 7 days elapse or a patch is made broadly available (whichever is earlier), the bug report will become visible to the public. Google said that affected Pixel devices will have the zero-day Android exploit patched in the upcoming October 2019 Android security update. Other OEMs have not yet acknowledged the vulnerability, but should ideally release patches soon. An unpatched security issue in the Kubernetes API is vulnerable to a “billions laugh attack” An unpatched vulnerability in NSA’s Ghidra allows a remote attacker to compromise exposed systems A Cargo vulnerability in Rust 1.25 and prior makes it ignore the package key and download a wrong dependency. New iPhone exploit checkm8 is unpatchable and can possibly lead to permanent jailbreak on iPhones. Google’s Project Zero reveals several serious zero-day vulnerabilities in a fully remote attack surface of the iPhone.

Last week, a potentially serious and unpatched security issue was revealed in the Kubernetes API server GitHub repository by StackRox. The security lapse was due to the parsing of a  Kubernetes API server deployment called YAML (Yet Another Markup Language) which is used for specifying configuration-type information. This security issue makes the cluster’s Kubernetes API service vulnerable to an attack called “billion laughs”. The billion laughs attack is a type of denial-of-service (DoS) attack. The vulnerability has got a CVE-2019-11253, however, the details of the security attack are reserved till the Kubernetes organization makes the security problem public. Kubernetes has not yet released a security patch to fix the underlying vulnerability. StackRox states, “The issue once again serves as a reminder that, like all software, Kubernetes is vulnerable to zero-day exploits. Thus, mere access to your Kubernetes API server should be treated as sensitive, regardless of how tight your application-level authorization policies (i.e., Kubernetes RBAC) are.” Read Also: CNCF-led open-source Kubernetes security audit reveals 37 flaws in Kubernetes cluster; recommendations proposed The Kubernetes cluster’s master and its resources are contacted by the Kubernetes API service which is backed by the Kubernetes apiserver. The Kubernetes apiserver accepts the incoming connections, after checking their authenticity of the entity and then applies the corresponding request handlers. One of the types of payloads that is accepted by the Kubernetes API service is exclusive to the YAML manifests and is concerned with the use of “references”. These references to nodes can be used in nodes that are themselves referenced in other nodes. This nesting of references and its subsequent expansion is the reason behind the current security vulnerability in the Kubernetes API. The Kubernetes apiserver does not perform any input validation on the uploaded YAMLs, and also does not impose hard limits on the size of the expanded file. These non-responsive actions make the Kubernetes apiserver an easy target. Thus, StackRox believes that only a clear fix to the Kubernetes apiserver code can safeguard the Kubernetes GitHub repository from this “billion laughs” attack. Read Also: Kubernetes 1.16 releases with Endpoint Slices, general availability of Custom Resources, and other enhancements StackRox recommends to protect the Kubernetes API server Users should analyze the Role-based access control (RBAC) policies of the Kubernetes to ensure that only reliable entities hold privileged access to a cluster’s resources. The cluster roles must be audited regularly. Users should be cautioned to keep the privileges of entities with low or no trust as unauthenticated users. Users should also disable any anonymous access by passing the --anonymous-auth=false flag to both the API server and the Kubelets. It should be noted that any small information like the API server version or the fact that the Kubernetes API server is running on a particular host can also be a piece of valuable information to the attacker. The Kubernetes API server endpoint should not be exposed to the internet, instead, it should be made secure using network firewalls. The API server access should only be given to trustworthy (private) subnets or VPC networks. Head over to the Stackrox page for more details on the security vulnerability of Kubernetes API. 6 Tips to Prevent Social Engineering How Chaos Engineering can help predict and prevent cyber-attacks preemptively An unpatched vulnerability in NSA’s Ghidra allows a remote attacker to compromise exposed systems GitLab 11.7 releases with multi-level child epics, API integration with Kubernetes, search filter box and more Pivotal open sources kpack, a Kubernetes-native image build service

A report released by antivirus company Emisoft on October 1 sheds light on the increase in ransomware attacks on government and municipal entities. Per the report, in the first nine months of 2019, at least 621 government entities, healthcare service providers and school districts, colleges, and universities were affected by ransomware. Out of these, 68 state, county and municipal entities have been impacted, 491 ransomware attacks were targeted on healthcare providers and there were at least 62 incidents involving school districts and other educational establishments. “There is no reason to believe that attacks will become less frequent in the near future,” said Fabian Wosar, CTO at Emsisoft. “Organizations have a very simple choice to make: prepare now or pay later. Though there is no public dataset available for an estimate, however the Emisoft report estimates the total combined cost of all 621 incidents would be $186,300,000. Winnebago County’s Chief Information Officer, Gus Gentner, recently stated, “Statistics let us know that the average ransomware incident costs $8.1 million and 287 days to recover. We cannot comment on the accuracy of that statement but, if correct, it would put the total cost at more than $5 billion.” Trends identified by the report Cybercriminals are increasingly targeting software commonly used by MSPs and other third-party service providers. The average ransom demand has continued to increase in 2019. Insured entities may be more likely to pay demands which result in ransomware being more profitable than it otherwise would be. Email and attachments and Remote Desktop Protocol continue to be the attack vector of choice. The Emisoft report suggests two workarounds to reduce recovery costs. These workarounds may, in some cases, either completely eliminate the need for a ransom to be paid or enable recovery for significantly less than the amount of the ransom demand. The report also calls on improving coordination and communication channels between the private sector and law enforcement agencies. In sync with the Emisoft report last week, the US Senate passed a bill called the DHS Cyber Hunt and Incident Response Teams Act. Per this bill, the Department of Homeland Security (DHS) will maintain cyber hunt and incident response teams to help private and public entities defend against cyber-attacks such as ransomware attacks. "The Senate passing the DHS Cyber Hunt and Incident Response Teams Act is an important step in protecting Upstate New York school districts from the swaths of ransomware attacks that take hostage the personal information and vital data of our students, school employees and local governments," stated Senator Schumer in a press release. The bill previously passed the House and is expected to be signed into law by the President in the coming months. You can read the full report on Emisoft’s official blog post. New iPhone exploit checkm8 is unpatchable and can possibly lead to permanent jailbreak on iPhones. Researchers release a study into Bug Bounty Programs and Responsible Disclosure for ethical hacking in IoT DoorDash data breach leaks personal details of 4.9 million customers, workers, and merchants

An unnamed iOS researcher that goes by the Twitter handle @axi0mX has released a new iOS exploit, checkm8 that affects all iOS devices running on A5 to A11 chipsets. This exploit explores vulnerabilities in Apple’s bootroom (secure boot ROM) which can give phone owners and hackers deep level access to their iOS devices. Once a hacker jailbreaks, Apple would be unable to block or patch out with a future software update. This iOS exploit can lead to a permanent, unblockable jailbreak on iPhones. Jailbreaking can allow hackers to get root access, enabling them to install software that is unavailable in the Apple App Store, run unsigned code, read and write to the root filesystem, and more. https://twitter.com/axi0mX/status/1178299323328499712 The researcher considers checkm8 possibly the biggest news in the iOS jailbreak community in years. This is because Bootrom jailbreaks are mostly permanent and cannot be patched. To fix it, you would need to apply physical modifications to device chipsets. This can only happen with callbacks or mass replacements.  It is also the first bootrom-level exploit publicly released for an iOS device since the iPhone 4, which was released almost a decade ago. axi0mX had also released another jailbreak-enabling exploit called alloc8 that was released in 2017. alloc8 exploits a powerful vulnerability in function malloc in the bootrom applicable to iPhone 3GS devices. However, checkm8 impacts devices starting with an iPhone 4S (A5 chip) through the iPhone 8 and iPhone X (A11 chip). The only exception being A12 processors that come in iPhone XS / XR and 11 / 11 Pro devices, for which Apple has patched the flaw. The full jailbreak with Cydia on latest iOS version is possible, but requires additional work. Explaining the reason behind this iOS exploit to be made public, @axi0mX said “a bootrom exploit for older devices makes iOS better for everyone. Jailbreakers and tweak developers will be able to jailbreak their phones on latest version, and they will not need to stay on older iOS versions waiting for a jailbreak. They will be safer.” The researcher adds, “I am releasing my exploit for free for the benefit of iOS jailbreak and security research community. Researchers and developers can use it to dump SecureROM, decrypt keybags with AES engine, and demote the device to enable JTAG. You still need additional hardware and software to use JTAG.” For now, the checkm8 exploit is released in beta and there is no actual jailbreak yet. You can’t simply download a tool, crack your device, and start downloading apps and modifications to iOS. Axi0mX's jailbreak is available on GitHub. The code isn't recommended for users without proper technical skills as it could easily result in bricked devices. Nonetheless, it is still an unpatchable issue and poses security risks for iOS users. Apple has not yet acknowledged the checkm8 iOS exploit. A number of people tweeted about this iOS exploit and tried it. https://twitter.com/FCE365/status/1177558724719853568 https://twitter.com/SparkZheng/status/1178492709863976960 https://twitter.com/dangoodin001/status/1177951602793046016 The past year saw a number of iOS exploits. Last month, Apple has accidentally reintroduced a bug in iOS 12.4 that was patched in iOS 12.3. A security researcher, who goes by the name Pwn20wnd on Twitter, released unc0ver v3.5.2, a jailbreaking tool that can jailbreak A7-A11 devices. In July, two members of the Google Project Zero team revealed about six “interactionless” security bugs that can affect iOS by exploiting the iMessage Client. Four of these bugs can execute malicious code on a remote iOS device, without any prior user interaction. Researchers release a study into Bug Bounty Programs and Responsible Disclosure for ethical hacking in IoT ‘Dropbox Paper’ leaks out email addresses and names on sharing document publicly DoorDash data breach leaks personal details of 4.9 million customers, workers, and merchants

Today, DoorDash revealed to its users that their platform suffered a major data breach on May 4, 2019, affecting approximately 4.9 million consumers, dashers, and merchants who joined the platform on or before April 5, 2018. When DoorDash became aware of the attack earlier this month they recruited private security experts to investigate it. The investigation revealed that user data was accessed by an unauthorized third party, who is still unknown. The food delivering company has taken preventive actions to block further unauthorized access. Though DoorDash is uninformed of any user passwords being compromised in the breach, they have requested all their users to reset their passwords and use an exclusive password just for DoorDash. In the official blog post, DoorDash has listed the type of user data that might have got compromised in the data breach. Profile information including names, email addresses, delivery addresses, order history, phone numbers, and more. For some customers, the last four digits of their consumer payment cards. However, DoorDash maintains that customers “full credit card information such as full payment card numbers or a CVV was not accessed.” Also, DoorDash confirms that the accessed information is not enough to make any fraudulent charges on the payment card. For some Dashers and merchants, the last four digits of their bank account number. Again DoorDash confirms that the full bank account information was not accessed and the accessed information is insufficient to perform any illicit withdrawals from the bank account. Approximately 1 lakh Dashers driver’s license numbers were also compromised Read Also: DoorDash buys Square’s food delivery service Caviar for $410 million In the blog post, DoorDash says that they have now taken necessary remedial steps to avoid such security breaches by including additional protective security layers around the data, security protocols that govern access to systems and have also enrolled private expertise to identify and repel threats more accurately in the future. Currently, DoorDash is in the process of reaching out to its affected customers. DoorDash has also clarified that the customers who joined the platform after April 5, 2018, are not affected by this data breach. However, DoorDash has neither clarified the details of how the third party accessed the user’s data nor have they explained how the company came to know about the data breach. The blog post also does not throw any light on why the company took so long in detecting this security breach. Many users are indignant about DoorDash’s lack of detailing in the blog post. https://twitter.com/peterfrost/status/1177572308136976385 https://twitter.com/benrothke/status/1177339060282523648 Many people are also of the opinion that until substantial penalties are levied against these companies, data breaches will continue to occur. Many are of the opinion that companies should stop asking for personal information while confirming a customer. A user on Hacker News comments, “In other words... "We leaked a bunch of your personal information, but at least it's not enough data to steal your money!" All of these leaks have the cumulative effect of making ineffective very commonly used security verification questions: "Can I verify that last 4 of your social? And the last 4 of your credit card?" How long will it take for us to accept that this kind of data can no longer be assumed private? The sooner, the better, mainly so companies stop using it as a secondary form of identity verification.” Head over to the DoorDash blog for more details about the data breach. StockX confirms a data breach impacting 6.8 million customers Following Capital One data breach, GitHub gets sued and AWS security questioned by a U.S. Senator Facebook fails to fend off a lawsuit over a data breach of nearly 30 million users Cloudflare finally launches Warp and Warp Plus after a delay of more than five months Tesla Software Version 10.0 adds Smart Summon, in-car karaoke, Netflix, Hulu, and Spotify streaming

Update: Six days after an anonymous researcher had disclosed a zero-day pre-auth remote code execution vulnerability in vBulletin, Cloudflare has deployed a new rule within their Cloudflare Specials Rulesets (ruleId: 100166).  The Cloudflare team states, “We assess this vulnerability to be very significant as it has a CVSS score of 9.8/10 and affects 7 out of the 10 key risk areas of the OWASP 2017 Top 10. Protection against common RCE attacks is a standard feature of Cloudflare's Managed Rulesets.” Cloudflare customers with Managed Rulesets and Cloudflare Specials can be protected against this vulnerability by enabling the WAF Managed Rulesets in the Firewall tab of Cloudflare. Head over to the Cloudflare blog for more details about Cloudflare’s protection against this vulnerability. On September 23rd, an anonymous researcher published a zero-day pre-authentication remote code execution vulnerability in vBulletin, which allows an attacker to remotely execute malicious shell commands on any vBulletin server running versions 5.0.0 up to 5.5.4. The vulnerability was disclosed on Full Disclosure, a public access mailing list. Yesterday, the vBulletin team issued a security patch for this vulnerability, which is now tracked under the CVE-2019-16759. How does the zero-day vulnerability in vBulletin work Ryan Seguin, a research engineer at Tenable explains in his blog that this vulnerability utilizes default vBulletin configurations. This enables an unauthenticated attacker to send a specially crafted HTTP POST request to a vulnerable vBulletin host and execute commands. He further states, “These commands would be executed with the permissions of the user account that the vBulletin service is utilizing. Depending on the service user’s permissions, this could allow complete control of a host.” Another security researcher, Troy Mursch of the Bad Packets security intelligence service told Arstechnica that the attackers are employing botnets to actively exploit vulnerable servers. The exploit, Mursch says, can modify the includes/vb5/frontend/controller/bbcode.php via the "sed" command to add a backdoor to the code. Mursch adds, “This is done by setting a “password” (epass) of 2dmfrb28nu3c6s9j. By doing this, the compromised site will only execute code in the eval function if 2dmfrb28nu3c6s9j is set in future requests sent to the server. This would allow a botnet command-and-control (C2) server to exclusively exploit CVE-2019-16759 and issue commands to the targeted site. The vulnerability itself has been regarded by some as a backdoor.” The vBulletin vulnerability is exploiting websites via the backdoor to build a list of bots that can configure supplementary ways of exploiting the infected hosts. The backdoor can infect the compromised hosts with DDoS malware and conduct denial-of-service attacks. It is not known yet if the anonymous publisher of this vulnerability had reported the vulnerability to the vBulletin team or not. Another possibility is that the vBulletin team could not find a timely solution to this issue, encouraging the user to publish the vulnerability on Full Disclosure. The anonymous researcher has published about the zero-day vulnerability from an unnamed email service. Why is a vulnerability in vBulletin so severe? vBulletin, a popular web forum software package has around 0.1% market share of all the running forums across the internet. Though the percentage looks small, the vulnerability in vBulletin can impact billions of internet users, reports ZDNet. vBulletin is designed to collect user information about registered users. “While billions of internet sites don't store any info about users, a handful of online forums could very easily store data on most internet users. Therefore, a market share of 0.1% is actually pretty significant, when we factor in how many users could be registered on these forums.” Steam, EA, Zynga, NASA, Sony, BodyBuilding.com, the Houston Texans, and the Denver Broncos are some of the customers that use the vBulletin server. Yesterday, GreyNoise, a cybersecurity company has tweeted that the vBulletin hackers are actively using this vulnerability to attack vulnerable forums. https://twitter.com/GreyNoiseIO/status/1176898873622781954 According to Chaouki Bekrar, founder and CEO of the Zerodium exploit broker, the vulnerability is known for many years. https://twitter.com/cBekrar/status/1176803541047861249 The vBulletin team has already issued a patch for CVE-2019-16759 for vBulletin versions 5.5.2, 5.5.3, and 5.5.4. Users on earlier versions of vBulletin 5.x are advised to update to one of the supported versions in order to implement the patch. The vBulletin cloud version has already updated and fixed this issue. Silicon-Interconnect Fabric is soon on its way to replace Printed Circuit Boards, new UCLA research claims Google Chrome Keystone update can render your Mac system unbootable ReactOS 0.4.12 releases with kernel improvements, Intel e1000 NIC driver support, and more

A vulnerable municipality software, Click2Gov, is known to be part of a breach involving eight cities last month, Threatpost reports. The Click2Gov software is used in self-service bill-paying portals used by utilities and community development organizations for paying parking tickets online etc. This is not the first time the software vulnerability has affected a huge bunch of people. The flaw was first discovered in December 2018, where using the vulnerable software, hackers compromised over 300,000 payment card records from dozens of cities across the United States and Canada between 2017 and late 2018. Also Read: Researchers reveal a vulnerability that can bypass payment limits in contactless Visa card Hackers are taking a second aim at Click2Gov The team of researchers at Gemini Advisory who covered the breach in 2018 have now observed a second wave of Click2Gov breaches beginning in August 2019 and affecting over 20,000 records from eight cities across the United States. The portals of six of the eight cities had been compromised in the initial breach. They also revealed that these user records have been offered for sale online via illicit markets. The impacted towns include Deerfield Beach, Fla., Palm Bay, Fla., Milton, Fla., Coral Springs. Fla., Bakersfield Calif., Pocatello Ida., Broken Arrow, Okla. and Ames, Iow “While many of the affected cities have patched their systems since the original breach, it is common for cybercriminals to strike the same targets twice. Thus, several of the same cities were affected in both waves of breaches,”  the Gemini Advisory researchers write in their official post. The researchers said, “Analysts confirmed that many of the affected towns were operating patched and up-to-date Click2Gov systems but were affected nonetheless. Given the success of the first campaign, which generated over $1.9 million in illicit revenue, the threat actors would likely have both the motive and the budget to conduct a second Click2Gov campaign,” they further added. Also Read: Apple Card, iPhone’s new payment system, is now available for select users According to a FireEye report published last year, in the 2018 attack, attackers compromised the Click2Gov webserver. Due to the vulnerability, the attacker was able to install a web shell, SJavaWebManage, and then upload a tool that allowed them to parse log files, retrieve payment card information and remove all log entries. Superion (now CentralSquare Technologies and owner of the Click2Gov software) acknowledged directly to Gemini Advisory that despite broad patch deployment the system remains vulnerable for an unknown reason. On similar lines of this year’s attack, researchers say “the portal remains a viable attack surface. These eight cities were in five states, but cardholders in all 50 states were affected. Some of these victims resided in different states but remotely transacted with the Click2Gov portal in affected cities, potentially due to past travels or to owning property in those cities.” Map depicting cities affected only by the original Click2Gov breach (yellow) and those affected by the second wave of Click2Gov breaches (blue). Source: Gemini Advisory These eight towns were contacted by Threatpost wherein most of them did not respond. However, some towns confirmed the breach in their Click2Gov utility payment portals. Some even took their Click2Gov portals offline shortly after contact. CentralSquare Technologies did not immediately comment on this scenario. To know more about this news in detail, read Gemini Advisory’s official post. Other news in security MITRE’s 2019 CWE Top 25 most dangerous software errors list released Emotet, a dangerous botnet spams malicious emails, “targets 66,000 unique emails for more than 30,000 domain names” reports BleepingComputer An unsecured Elasticsearch database exposes personal information of 20 million Ecuadoreans including 6.77M children under 18

Data leaks have become commonplace. Every week we hear of at least one data breach that has existed maybe over months or years without the users knowing their data is compromised. Yesterday, a team of researchers from vpnMentor reported a massive data breach that may impact millions of Ecuadorians. The research team led by Noam Rotem and Ran Locar discovered a leaky Elasticsearch database that included 18GB of personal data affecting over 20 million individuals, outnumbering the total number of citizens (16.6 million) in the small South American country. The vpnMentor research team discovered the Ecuador breach as part of our large-scale web mapping project. The team further discovered the data breach on an unsecured server located in Miami, Florida. This server appears to be owned by Ecuadorian company, Novaestrat, a consulting company providing services in data analytics, strategic marketing, and software development. The major information leaked during this breach includes personal information of individuals and their family members, employment details, financial information, automotive records, and much more. The researchers said the breach was closed on September 11, 2019, and are still unaware of the exact details of the breach. However, they said that the information exposed appears to contain information provided by third-party sources.“These sources may include Ecuadorian government registries, an automotive association called Aeade, and Biess, an Ecuadorian national bank,” the researchers wrote in their official document. Details of the data exposed during the Ecuador breach The researchers said that in the database, the citizens were identified using by a ten-digit ID code. In some places in the database, that same ten-digit code is referred to as “cedula” and “cedula_ruc”. “In Ecuador, the term “cédula” or “cédula de identidad” refers to a person’s ten-digit national identification number, similar to a social security number in the US. The term “RUC” refers to Ecuador’s unique taxpayer registry. The value here may refer to a person’s taxpayer identification number,” the researchers mention. On running a search with a random ID number to check the validity of the database, the researchers were able to find a variety of sensitive personal information. Personal information such as an individuals name, gender, dates of birth, place of birth, addresses, email addresses, phone numbers, marital status, date of marriage if married, date of death if deceased, and educational details. Financial information related to accounts held with the Ecuadorian national bank, Biess. Details such as account status, the current balance in the account, amount financed, credit type, location and contact information for the person’s local Biess branch. Automotive records including car’s license plate number, make, model, date of purchase, most recent date of registration, and other technical details about the model. Employment information including employer name, employer location, employer tax identification number, job title, salary information, job start date, and end date was also exposed. ZDNet said it “verified the authenticity of this data by contacting some users listed in the database. The database was up to date, containing information as recent as 2019.” “We were able to find records for the country's president, and even Julian Assange, who once received political asylum from the small South American country, and was issued a national ID number (cedula),” ZDNet further reports. Also Read: Wikileaks founder, Julian Assange, arrested for “conspiracy to commit computer intrusion” 6.77m children’s data under the age of 18 were exposed Under a database index named "familia" (means family in Spanish), “information about every citizen's family members, such as children and parents, allowing anyone to reconstruct family trees for the entire country's population,” ZDNet reports. This index included details of children, some of whom were born as recent as this spring. They found 6.77 million entries for children under the age of 18. These entries contained names, cedulas, places of birth, home addresses, and gender. Also Read: Google faces multiple scrutinies from the Irish DPC, FTC, and an antitrust probe by US state attorneys over its data collection and advertising practices The information leaked may pose a huge risk to individuals as using their email ids and phone numbers, attackers may send them phishing emails to target individuals with scams and spam Hackers and other malicious parties could use the leaked email addresses and phone numbers to target individuals with scams and spam. Researchers said that these phishing attacks could be tailored to the individuals using exposed details to increase the chances that people will click on the links. The Ecuador breach was closed on September 11, 2019, and the database was eventually secured only after vpnMentor reached out to the Ecuador CERT (Computer Emergency Response Team) team, which served as an intermediary. A user on Hacker News writes, “There needs to be fines for when stuff like this happens. The bottom line is all that matters to bosses, so unless engineers can credibly point to the economic impact of poor security decisions, these things will keep happening.” https://twitter.com/ElissaBeth/status/1173532184935878658 To know more about the Ecuador breach in detail, read vpnMentor’s official report. Other interesting news in Security A new Stuxnet-level vulnerability named Simjacker used to secretly spy over mobile phones in multiple countries for over 2 years: Adaptive Mobile Security reports UK’s NCSC report reveals significant ransomware, phishing, and supply chain threats to businesses Endpoint protection, hardening, and containment strategies for ransomware attack protection: CISA recommended FireEye report Highlights

Two days ago, Intel disclosed a vulnerability in their 2011 released line of micro processors with  Data Direct I/O Technology (DDIO) and Remote Direct Memory Access (RDMA) technologies. The vulnerability was found by a group of researchers from the Vrije Universiteit Amsterdam and ETH Zurich. The researchers have presented a detailed security analysis of the attack in their paper, NetCAT: Practical Cache Attacks from the Network. The analysis has been implemented by reverse engineering the behavior of Data-Direct I/O (DDIO), also called as Direct Cache Access (DCA) on recent Intel processors. The security analysis resulted in the discovery of the first network-based PRIME+PROBE Cache attack, named NetCAT. The NetCAT attack enables attacks in cooperative and general adversarial settings. The cooperative setting can enable an attacker to build a covert channel between a network client and a sandboxed server process without network. In the general adversarial settings, an attacker can enable disclosure of network timing-based sensitive information. On June 23, 2019, the researchers coordinated the disclosure process with Intel and NCSC (the Dutch national CERT). Intel acknowledged the vulnerability with a bounty and have assigned CVE-2019-11184 to track the issue. What is a NetCAT attack? The threat model implemented in the paper targets victim servers with DDIO equipped Intel processors, which are mostly enabled in all Intel server-grade processors, by default since 2012. The launched cache attack is conducted over a network to a target server, such that secret information can be leaked from the connection between the server and a different client. The researchers say that there are many potential ways to exploit DDIO. The paper states, “For instance, an attacker with physical access to the victim machine could install a malicious PCIe device to directly access the LLC’s DDIO region. Our aim in this paper is to show that a similar attack is feasible even for an attacker with only remote (unprivileged) network access to the victim machine, without the need for any malicious PCIe devices.”  The threat model uses the RDMA in modern NICs to bypass the operating system at the data plane. This provides the remote machines with direct read and write access to a previously specified memory region. The below figure illustrates the model’s target topology, which is also common in data centers. Image Source: NetCAT: Practical Cache Attacks from the Network In order to launch the remote PRIME+PROBE attack, the researchers have used the remote read/write primitives provided by the PCIe device’s DDIO capabilities to remotely measure the cache activity. The paper explains two cooperative DDIO-based attacks. In the first scenario, a covert channel between two clients that are not on the same network is used and in the second scenario a covert channel between a client and a sandboxed process on a server is used. In both scenarios, it was found that the transmission rounds are loosely synchronized with a predefined time window. An attacker can control the machine with an RDMA link to an application server by using the remote PRIME+PROBE to detect network activity in the LLC as shown in the above figure. The user then opens an interactive SSH session to the application server from a different machine. In an interactive SSH session, each keystroke is sent in a separate packet. The attacker is able to recover the inter-packet times from the cache using the ring buffer location and map them to keystrokes. The security analysis successfully explored the implications of the NetCAT attack, and proved that the DDIO feature on modern Intel CPUs does exposes the system to cache attacks over the network. The researchers believe that “We have merely scratched the surface of possibilities for network-based cache attacks, and we expect similar attacks based on NetCAT in the future. We hope that our efforts caution processor vendors against exposing microarchitectural elements to peripherals without a thorough security design to prevent abuse.” A video demonstrating the NetCAT attack is shown below: https://www.youtube.com/watch?v=QXut1XBymAk In the paper, various other NetCAT-like attacks like the PCIe to CPU attacks have been discussed which may be generalized beyond the given proof-of-concept scenarios. The researchers have also explained various possible mitigations like disabling DDIO, LLC partitioning, and DDIO improvement against these last-level cache side-channel attacks from PCIe devices. With repeated vulnerabilities being found in Intel, many are beginning to distrust Intel. Some are even considering moving away to other alternatives. A Redditor comments, “Another one? Come on man, my i7 2600k already works like crap, and now another vulnerability that surely will affect performance via patches appeared? It is settled, next month I'm ditching Intel.” Another comment read, “Soooo the moral of the story is, never buy Intel chips.” For more information about the attack, interested readers can head over to the NetCAT: Practical Cache Attacks from the Network paper for more information. Other Intel news Intel discloses four new vulnerabilities labeled MDS attacks affecting Intel chips Intel unveils the first 3D Logic Chip packaging technology, ‘Foveros’, powering its new 10nm chips, ‘Sunny Cove’ IBM open-sources Power ISA and other chips; brings OpenPOWER foundation under the Linux Foundation

Two days ago, on September 7, Wikipedia confirmed with an official statement that it was hit by a malicious attack a day before causing it to go offline in many countries at irregular intervals. The “free online encyclopedia” said the attack was ongoing and the Site Reliability Engineering team is working to curb the attack and restore access to the site. According to downdetector, users across Europe and parts of the Middle East experienced outages shortly before 7pm, BST on September 6. Also Read: Four versions of Wikipedia goes offline in a protest against EU copyright Directive which will affect free speech online The UK was one of the first countries that reported a slow and choppy use of the site. This was followed by reports of the site then being down in several other European countries, including Poland, France, Germany, and Italy. Source: Downdetector.com By Friday evening, 8.30 pm (ET), the attack extended to an almost-total outage in the United States and other countries. During this time, there was no spokesperson available for comment at the Wikimedia Foundation. https://twitter.com/netblocks/status/1170157756579504128 On September 6, at 20:53 (UTC) Wikimedia Germany then informed users by tweeting that a “massive and very” broad DDoS (Distributed Denial of Service) attack on the Wikimedia Foundation servers, making the website impossible to access for many users. https://twitter.com/WikimediaDE/status/1170077481447186432 The official statement on the Wikimedia foundation reads, “We condemn these sorts of attacks. They’re not just about taking Wikipedia offline. Takedown attacks threaten everyone’s fundamental rights to freely access and share information. We in the Wikimedia movement and Foundation are committed to protecting these rights for everyone.” Cybersecurity researcher, Baptiste Robert, with the online name Elliot Anderson wrote on Twitter, “A new skids band is in town. @UKDrillas claimed they are behind the DDOS attack of Wikipedia. You’ll never learn... Bragging on Twitter (or elsewhere) is the best way to get caught. I hope you run fast.” https://twitter.com/fs0c131y/status/1170093562878472194 https://twitter.com/atoonk/status/1170400761722724354 To know about this news in detail, read Wikipedia’s official statement. Other interesting news in Security “Developers need to say no” – Elliot Alderson on the FaceApp controversy in a BONUS podcast episode [Podcast] CircleCI reports of a security breach and malicious database in a third-party vendor account Hundreds of millions of Facebook users’ phone numbers found online, thanks to an exposed server, TechCrunch reports

Last week, the team at CircleCI came across with a security breach incident that involved CircleCI and a third-party analytics vendor. An attacker got access to the user data including usernames, email addresses that were associated with GitHub and Bitbucket, user IP addresses as well as user-agent strings from their third-party vendor account.  According to the CircleCI team, information about repository URLs and names, organization name, branch names, and repository owners might have got exposed during this incident. CircleCI user secrets, build artifacts, source code,  build logs, or any other production data wasn’t accessed during this incident. Data regarding the auth tokens, password hashes, credit card or financial information also wasn’t assessed.  The security and the engineering teams at CircleCI revoked the access of the compromised user and further launched an investigation. The official page reads, “CircleCI does not collect social security numbers or credit card information; therefore, it is highly unlikely that this incident would result in identity theft.” How did the security breach occur? The incident took place on 31st August at 2:32 p.m. UTC and it came in the notice when a CircleCI team member saw an email notification about the incident from one of their third-party analytics vendors. And it was then suspected that some unusual activity was taking place in a particular vendor account.  The employee then forwarded the email to their security and engineering teams after which the investigation started and steps were taken in order to control the situation.  According to CircleCI’s engineering team, the added database was not a CircleCI resource. The team then removed the malicious database and the compromised user from the tool and further reached out to the third-party vendor to collaborate on the investigation.  At 2:43 p.m. UTC, the security teams started disabling the improperly accessed account and by 3:00 p.m. UTC, this process ended. According to the team, the customers who accessed the platform between June 30, 2019, and August 31, 2019, could possibly be affected. The page further reads, “In the interest of transparency, we are notifying affected CircleCI users of the incident via email and will provide relevant updates on the FAQ page as they become available.” CircleCI will strengthen its platform’s security The team will continue to collaborate with the third-party vendor so that they can find out the exact vulnerability that caused the incident. The team will review their policies for enforcing 2FA on third-party accounts and continue their transition to single sign-on (SSO) for all of their integrations. This year, the team also doubled the size of their security team. The official post reads, “Our security team is taking steps to further enhance our security practices to protect our customers, and we are looking into engaging a third-party digital forensics firm to assist us in the investigation and further remediation efforts. While the investigation is ongoing, we believe the attacker poses no further risk at this time.” The page further reads, “However, this is no excuse for failing to adequately protect user data, and we would like to apologize to the affected users. We hope that our remediations and internal audits are able to prevent incidents like this and minimize exposures in the future. We know that perfect security is an impossible goal, and while we can’t promise that, we can promise to do better.” Few users on HackerNews discuss how CircleCI has taken user's data and its security for granted by handing it over to the third party.  A user commented on HackerNews, “What's sad about this is that CircleCI actually has a great product and is one of the nicest ways to do end to end automation for mobile development/releases. Having their pipeline in place actually feels quite liberating. The sad part is that they take this for granted and liberate all your data and security weaknesses too to unknown third parties for either a weird ideological reason about interoperability or a small marginal profit.” Few others are appreciating the company’s efforts for resolving the issue. Another user commented, “This is how you handle a security notification. Well done CircleCI, looking forward to the full postmortem.” What’s new in security this week? CircleCI Over 47K Supermicro servers’ BMCs are prone to USBAnywhere, a remote virtual media vulnerability Cryptographic key of Facebook’s Free Basics app has been compromised Retadup, a malicious worm infecting 850k Windows machines, self-destructs in a joint effort by Avast and the French police

Yesterday, TechCrunch reported of an exposed server with more than 419 million records from Facebook phone numbers are discovered online. According to Zack Whittaker, TechCrunch security reporter, the server was not protected with a password and was accessible to anyone. It featured 133 million records from U.S.-based Facebook users, 18 million records from users in the UK, and 50 million records on users in Vietnam. The records contained each person's unique Facebook ID along with the phone number listed on the account. Facebook IDs are unique numbers that can be associated with an account to discover a person's username. TechCrunch was able to verify multiple records in the database by matching a known Facebook user's phone number against a listed Facebook ID. Other records were verified by matching phone numbers with Facebook's password reset feature, which can be used to partially reveal a phone number linked to an account. Records primarily had phone numbers, but in some cases, also had usernames, genders, and country location. "This dataset is old and appears to have information obtained before we made changes last year to remove people's ability to find others using their phone numbers," a Facebook spokesperson said to TechCrunch. "The dataset has been taken down and we have seen no evidence that Facebook accounts were compromised,'' they added. The database was originally discovered by security researcher and a member of GDI Foundation, Sanyam Jain, who was able to locate phone numbers associated with several celebrities as well. It's not clear who owned the database or where it originated from, but it was taken offline after TechCrunch contacted the web host. Phone number security has become increasingly important over the course of the last few years due to SIM-hacking. This technique of hacking involves calling a phone carrier and asking for a SIM transfer for a specific number, thereby giving access to anything linked to that phone number, such as two-factor verification, password reset info, and more. Leaked phone numbers also expose Facebook users to spam calls, which have become more and more prevalent over the last several years. Last week one of the security & privacy researchers, Jane Manchung Wong, in a series of tweets showed a Global Library Collector in the Facebook’s Android App code. According to Wong this GLC allows the mobile app to upload data from user’s device to Facebook servers. The tweet went viral and the general public had their say in it. https://twitter.com/wongmjane/status/1167463054709334017 Most responses received from mobile app developers said that it is a known fact and Android phones upload system libraries to Facebook server to check the app stability. And the libraries do not contain any personal data. However, this report by TechCrunch is the latest security lapse involving Facebook and user’s personal data after a string of data breach incidents since the Cambridge Analytica scandal. On Hacker News, the community expressed their distrust of Facebook’s statements. On user commented, “Facebook: "This dataset is old and appears to have information obtained before we made changes last year to remove people’s ability to find others using their phone numbers." Not that "old." Some of those "update" dates are just a few days ago.” Another user commented, “But the data appeared to be loaded into the exposed database at the end of last month — though that doesn’t necessarily mean the data is new. Somewhat curious what the Status key represents in this dump, personally.” What’s new in security this week? Over 47K Supermicro servers’ BMCs are prone to USBAnywhere, a remote virtual media vulnerability Cryptographic key of Facebook’s Free Basics app has been compromised Retadup, a malicious worm infecting 850k Windows machines, self-destructs in a joint effort by Avast and the French police  

Matheus Eduardo Garbelini a member of the ASSET (Automated Systems SEcuriTy) Research Group at the Singapore University of Technology and Design released a proof of concept for three WiFi vulnerabilities in the Espressif IoT devices, ESP32/ESP8266. 3 WiFi vulnerabilities on the ESP32/8266 IoT device Zero PMK Installation (CVE-2019-12587) This WiFi vulnerability hijacks clients on version ESP32 and ESP8266 connected to enterprise networks. It allows an attacker to take control of the WiFi device EAP session by sending an EAP-Fail message in the final step during the connection between the device and the access point. The researcher discovered that both the IoT devices update their Pairwise Master Key (PMK) only when they receive an EAP-Success message. If the EAP-Fail message is received before the EAP-Success, the device skips to update the PMK received during a normal EAP exchange (EAP-PEAP, EAP-TTLS or EAP-TLS). During this time, the device normally accepts the EAPoL 4-Way handshake. Each time ESP32/ESP8266 starts, the PMK is initialized as zero, thus, if an EAP-Fail message is sent before the EAP-Success, the device uses a zero PMK. Thus allowing the attacker to hijack the connection between the AP and the device. ESP32/ESP8266 EAP client crash (CVE-2019-12586) This WiFi vulnerability is found in SDKs of ESP32 and ESP8266 and allows an attacker to precisely cause a crash in any ESP32/ESP8266 connected to an enterprise network. In combination with the zero PMK Installation vulnerability, it could increase the damages to any unpatched device. This vulnerability allows attackers in radio range to trigger a crash to any ESP device connected to an enterprise network. Espressif has fixed such a problem and committed patches for ESP32 SDK, however, the SDK and Arduino board support for ESP8266 is still unpatched. ESP8266 Beacon Frame Crash (CVE-2019-12588) In this WiFi vulnerability, CVE-2019-12588 the client 802.11 MAC implementation in Espressif ESP8266 NONOS SDK 3.0 and earlier does not correctly validate the RSN AuthKey suite list count in beacon frames, probe responses, and association responses. This allows attackers in radio range to cause a denial of service (crash) via a crafted message. Two situations in a malformed beacon frame can trigger two problems: When sending crafted 802.11 frames with the field Auth Key Management Suite Count (AKM) in RSN tag with size too large or incorrect, ESP8266 in station mode crashes. When sending crafted 802.11 frames with the field Pairwise Cipher Suite Count in RSN tag with size too large or incorrect, ESP8266 in station mode crashes. “The attacker sends a malformed beacon or probe response to an ESP8266 which is already connected to an access point. However, it was found that ESP8266 can crash even when there’s no connection to an AP, that is even when ESP8266 is just scanning for the AP,” the researcher says. A user on Hacker News writes, “Due to cheap price ($2—$5 depending on the model) and very low barrier to entry technically, these devices are both very popular as well as very widespread in those two categories. These chips are the first hits for searches such as "Arduino wifi module", "breadboard wifi", "IoT wifi module", and many, many more as they're the downright easiest way to add wifi to something that doesn't have it out of the box. I'm not sure how applicable these attack vectors are in the real world, but they affect a very large number of devices for sure.” To know more about this news in detail, read the Proof of Concept on GitHub. Other interesting news in IoT security Cisco Talos researchers disclose eight vulnerabilities in Google’s Nest Cam IQ indoor camera Microsoft reveals Russian hackers “Fancy Bear” are the culprit for IoT network breach in the U.S. Researchers reveal vulnerability that can bypass payment limits in contactless Visa card

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