Here we are again with the newest information on what happened in cyber and network security from June 15 to June 20. There has been a lot of events, so let's roll with the most critical ones.
The JSOF research lab has discovered a series of zero-day vulnerabilities in a widely used low-level TCP/IP software library developed by Treck, Inc. The 19 vulnerabilities, given the name Ripple20, affect hundreds of millions of devices (or more) and include multiple remote code execution vulnerabilities. The risks inherent in this situation are high. Just a few examples: data could be stolen off of a printer, an infusion pump behavior changed, or industrial control devices could be made to malfunction. An attacker could hide malicious code within embedded devices for years. One of the vulnerabilities could enable entry from outside into the network boundaries; and this is only a small taste of the potential risks.
The interesting thing about Ripple20 is the incredible extent of its impact, magnified by the supply chain factor. The wide-spread dissemination of the software library (and its internal vulnerabilities) was a natural consequence of the supply chain "ripple-effect". A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies, and people.
Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections. Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known as JOP) are two such techniques that has been gaining popularity. JOP or ROP attacks can be particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.
Intel has announced today that its experimental CET security feature will be first made available in the company's upcoming Tiger Lake mobile CPUs - ZDNet.
"Because there is no effective software mitigation against ROP, CET will be very effective at detecting and stopping this class of vulnerability," Ionescu told me. "Previously, operating systems and security solutions had to guess or infer that ROP had happened, or perform forensic analysis, or detect the second stage payloads/effect of the exploit." - ArsTechnica.
"These are all insidious types of attacks that have been plaguing the industry for some time," Tom Garrison, Intel's client computing group VP and general manager of security strategies and initiatives, told The Register. "They are nearly impossible to address with software-based mitigation." - The Register.
AMD is aware of new research related to a potential vulnerability in AMD software technology supplied to motherboard manufacturers for use in their Unified Extensible Firmware Interface (UEFI) infrastructure and plans to complete delivery of updated versions designed to mitigate the issue by the end of June 2020.
The targeted attack described in the research requires privileged physical or administrative access to a system based on select AMD notebook or embedded processors. If this level of access is acquired, an attacker could potentially manipulate the AMD Generic Encapsulated Software Architecture (AGESA) to execute arbitrary code undetected by the operating system.
AMD said the bugs impact a small fraction of Accelerated Processing Unit (APU) CPUs released between 2016 and 2019. AMD APU processors, formerly known as AMD Fusion, are small-sized 64-bit microprocessors that include both a central processing unit (CPU) and graphics processing unit (GPU) on the same silicon die - ZDNet.
'We have modified about 20 per cent of all the files' - The Register.
Vulnerabilities in the GPRS Tunnelling Protocol (GTP) will continue to impact mobile operators even as they migrate to 5G infrastructure.
In reports published last week and in December 2019, cyber-security firms Positive Technologies and A10 Networks detailed a series of vulnerabilities in this legacy mobile protocol. These include:
- Disclosure of subscriber information (including location data, used for user tracking)
- Spoofing, which can be used for fraud and impersonation attacks
- Denial-of-Service (DoS) attacks on network equipment, resulting in mass disruption of mobile communication
- Researchers say that because mobile providers will have to support the protocol on their 5G networks for legacy reasons, users will remain vulnerable to attacks even if the 5G protocol itself contains security features to prevent similar attacks.
Zoom is doing the right thing: it's making end-to-end encryption available to all users, paid and unpaid. Thank you, Zoom, for coming around to the right answer.
And thank you to everyone for commenting on this issue. We are learning -- in so many areas -- the power of continued public pressure to change corporate behavior. - Bruce Schneier.
Requiring the successful completion of a CAPTCHA means analysis will only happen when a live human being downloads the sample. Without the automation, the chances of the malicious file flying under the radar are much better. Microsoft has dubbed Chimborazo’s ongoing attack campaign Dudear.
"CHIMBORAZO, the group behind Dudear campaigns that deploy the info-stealing Trojan GraceWire, evolved their methods once again in constant pursuit of detection evasion," Microsoft’s Security Intelligence group wrote in a Tweet on Wednesday. "The group is now using websites with CAPTCHA to avoid automated analysis."
Tsunami: An extensible network scanning engine from Google for detecting high severity vulnerabilities with high confidence
When an attacker begins to exploit security vulnerabilities or security misconfigurations, such as weak passwords, an organization needs to react quickly in order to protect potentially vulnerable assets. With attackers increasingly investing in automation, the time window to react to a newly released, high severity vulnerability is usually measured in hours. This poses a significant challenge for large organizations with thousands or even millions of internet-connected systems. In such hyperscale environments, security vulnerabilities must be detected and, ideally, remediated in a fully automated fashion. To make this possible, information security teams need to be able to roll out detectors for novel security issues at scale in a very short amount of time. Furthermore, it is important that the detection quality is consistently very high. To handle these challenges, we created Tsunami: an extensible network scanning engine for detecting high severity vulnerabilities with high confidence.
- Java is the most popular primary programming language.
- Websites are the most common type of application developers work on.
- Web (Backend) is the most popular platform.
- Go, Kotlin, Python are the top 3 languages developers are planning to adopt or migrate to.
- Python has overtaken Java in the list of languages used in the last 12 months. It is the most studied language. In the last 12 months 30% of respondents have started or continued to learn Python — even more than last year.
Rust is a programming language that aims to unite memory safety and high performance while providing the tools to write correct code in a productive, friendly environment. It started as a research project within Mozilla in the late 2000s and reached a stable, ready-for-production status in 2015. At NLnet Labs, we chose Rust when starting two related projects for the routing security framework RPKI, the certification authority Krill and relying party software Routinator. Initially attracted by the memory safety guarantees, we learned to love the expressive type system that prevents many common mistakes at compile time and the excellent native build tooling.
But how difficult is it to use Rust and its ecosystem to write network applications that support IPv6?
Of all the things a registry operator may, or should, concern themselves about, there is little to find in DNS privacy and encryption that touches upon their operation. So, why is this topic even on the agenda of a registration operations workshop?
But perhaps this is a little too simplistic. Perhaps there are some elements of the way in which DNS resolution is being used in today's network that point to further changes that may impinge on the name registration function and the coherence of the Internet's namespace as a whole? Let's see if we can build a credible case that privacy and encryption have the potential to facilitate fragmentation on the DNS namespace.
Relevant academics papers this week:
Peerlock: Flexsealing BGP
BGP route leaks frequently precipitate serious disruptions to inter-domain routing. These incidents have plagued the Internet for decades while deployment and usability issues cripple efforts to mitigate the problem. Peerlock, introduced in 2016, addresses route leaks with a new approach. Peerlock enables filtering agreements between transit providers to protect their own networks without the need for broad cooperation or a trust infrastructure. We outline the Peerlock system and one variant, Peerlock-lite, and conduct live Internet experiments to measure their deployment on the control plane. Our measurements find evidence for significant Peerlock protection between Tier 1 networks in the peering clique, where 48% of potential Peerlock filters are deployed, and reveal that many other networks also deploy filters against Tier 1 leaks. To guide further deployment, we also quantify Peerlock's impact on route leaks both at currently observed levels and under hypothetical future deployment scenarios via BGP simulation.
These experiments reveal present Peerlock deployment restricts Tier 1 leak export to 10% or fewer networks for 40% of simulated leaks. Strategic additional Peerlock-lite deployment at all large ISPs (<1% of all networks), in tandem with Peerlock within the peering clique as deployed, completely mitigates about 80% of simulated Tier 1 route leaks.
DDoS Hide & Seek: On the Effectiveness of a Booter Services Takedown
Booter services continue to provide popular DDoS-as-a-service platforms and enable anyone irrespective of their technical ability, to execute DDoS attacks with devastating impact. Since booters are a serious threat to Internet operations and can cause significant financial and reputational damage, they also draw the attention of law enforcement agencies and related counter activities. In this paper, we investigate booter-based DDoS attacks in the wild and the impact of an FBI takedown targeting 15 booter websites in December 2018 from the perspective of a major IXP and two ISPs. We study and compare attack properties of multiple booter services by launching Gbps-level attacks against our own infrastructure. To understand spatial and temporal trends of the DDoS traffic originating from booters we scrutinize 5 months, worth of inter-domain traffic. We observe that the takedown only leads to a temporary reduction in attack traffic. Additionally, one booter was found to quickly continue operation by using a new domain for its website.
At the start of this essay, we noted that in his biographical statement on his website, Ritchie quipped, "My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones." While his predilection for procedural languages is without question, our exploration of his lost dissertation puts the lie to his self-assessment that he was not smart enough for theoretical computer science. More likely, Ritchie's graduate school experience was one in which the lure of the theoretical gave way to the enchantments of implementation, of building new systems and new languages as a way to explore the bounds, nature, and possibilities of computing.
Thanks for reading!
For feedback, please write to us at firstname.lastname@example.org.