The 1.5 Billion Dollar Market: IoT Security

https://blog.paessler.com/investments-in-iot-security-are-set-to-increase-rapidly-in-2018
The two biggest challenges in 2018 will continue to be protecting against unauthorized access, and patching/updating the software of the device. Companies must not neglect the security problems of IoT and IIoT devices. Cyberattacks on the Internet of Things (IoT) are already a reality.

According to Gartner‘s market researchers, global spending on IoT security will increase to $1.5 billion this year.

1,683 Comments

  1. Tomi Engdahl says:

    IoT Security
    MITRE EMB3D Threat Model Officially Released
    https://www.securityweek.com/mitre-emb3d-threat-model-officially-released/

    MITRE announced the public availability of the EMB3D threat model for embedded devices used in critical infrastructure.

    MITRE, the non-profit technology and R&D company, on Monday announced the public availability of its EMB3D threat model for embedded devices used in critical infrastructure and other industries.

    EMB3D was developed by MITRE in collaboration with cybersecurity and industrial sector partners such as Red Balloon Security, Narf Industries, and Niyo ‘Little Thunder’ Pearson of ONE Gas.

    Unveiled in December 2023, the framework provides a knowledge base of cyber threats to embedded devices used in the critical infrastructure, IoT, healthcare, automotive, and manufacturing sectors.

    The resource is recommended for vendors, asset owners and operators, testing organizations and cybersecurity researchers.

    The MITRE EMB3D™ Threat Model
    https://emb3d.mitre.org/

    The EMB3D Threat Model provides a cultivated knowledge base of cyber threats to embedded devices, providing a common understanding of these threats with security mechanisms to mitigate them.

    This initial release of EMB3D includes the Device Properties and Threats enumerations. The full set of Mitigations will be available in the Summer 2024 update.

    What is EMB3D™
    EMB3D is a threat model for embedded devices found in industries such as critical infrastructure, Internet of Things, automotive, healthcare, manufacturing, and many more. The threat model is intended to be a resource to help vendors, asset owners/operators, test organizations, and security researchers to improve the overall security of embedded devices’ hardware and software. This threat model aims to serve as a central repository of information, defining known threats to embedded devices and their unique device features/properties that enable specific threat actions. By mapping the threats to the associated device features/properties, the the user can easily enumerate threat exposure based on the known device features.

    Reply
  2. Tomi Engdahl says:

    https://medium.com/zkpass/a-primer-on-transport-layer-security-tls-a7495eeff004
    4 TLS AND FUTURE DEVELOPMENTS
    TLS, as a critical protocol for secure communication, is subject to ongoing development and advancements. Here are key aspects regarding TLS and future developments:
    1. TLS 1.4 and Beyond: TLS 1.4 is an upcoming version that aims to enhance security, performance, and feature set. While specific technical details about TLS 1.4 may not be available when writing, it is expected to introduce further improvements based on community feedback and emerging security requirements.
    2. Post-Quantum Cryptography (PQC): The advent of quantum computers poses a potential threat to current cryptographic algorithms. Post-Quantum Cryptography (PQC) is an active area of research that focuses on developing algorithms resistant to attacks by quantum computers. TLS will likely incorporate post-quantum algorithms as they are standardized, ensuring long-term security in a quantum computing era.
    3. Lightweight Implementations: The deployment of TLS in emerging technologies like the Internet of Things (IoT) and 5G networks requires lightweight implementations to accommodate resource-constrained devices. Optimized TLS protocols and cryptographic algorithms, such as those based on elliptic curve cryptography (ECC), are preferred to ensure efficient performance while maintaining security.
    4. Efficient Key Exchange Mechanisms: Efficient key exchange mechanisms are crucial in TLS deployments. As new key exchange algorithms and protocols are introduced, the focus is placed on their efficiency and attack resistance. Techniques such as Elliptic Curve Diffie-Hellman (ECDH) and its variants continue to be refined for secure and efficient key exchange.
    TLS is a dynamic protocol that adapts to emerging technologies, evolving security threats, and the need for efficient communication. Ongoing developments in TLS 1.4, post-quantum cryptography, lightweight implementations, and efficient key exchange mechanisms aim to ensure the protocol’s resilience, scalability, and security in the face of evolving challenges. By staying abreast of these developments, organizations can continue to leverage TLS as a trusted and secure protocol for their communication needs.

    Reply
  3. Tomi Engdahl says:

    https://www.reddit.com/r/crypto/comments/u7049t/will_postquantum_keyexchange_and_signatures_be/
    The key exchange algorithm used is part of a TLS ciphersuite. Ciphersuites can be added without bumping the TLS version.
    A new ciphersuite with a post-quantum key exchange algorithm can be spec’d and implemented for TLS 1.3, or potentially even include TLS 1.2 support as well.
    https://www.rapidsslonline.com/blog/introducing-tls-1-3-future-encryption/

    Reply
  4. Tomi Engdahl says:

    https://www.etsi.org/technologies/consumer-iot-security

    As mandated in EN 303 645, implementing a vulnerability disclosure policy is a key requirement in ensuring on-going strong cyber security after a product has been placed on the market. ETSI TR 103 838 provides a guide to coordinated vulnerability disclosure. It contains generic advice on how to respond to and manage a vulnerability disclosure, a defined triage process, advice on managing vulnerabilities in third party products or suppliers. It also includes an example of a vulnerability disclosure policy.

    https://www.etsi.org/deliver/etsi_tr/103800_103899/103838/01.01.01_60/tr_103838v010101p.pdf

    Reply
  5. Tomi Engdahl says:

    IoT Security
    Cybersecurity Labeling for Smart Devices Aims to Help People Choose Items Less Likely to be Hacked

    Under the new U.S. Cyber Trust Mark Initiative, manufacturers can affix the label on their products if they meet federal cybersecurity standards

    https://www.securityweek.com/cybersecurity-labeling-for-smart-devices-aims-to-help-people-choose-items-less-likely-to-be-hacked/

    Consumer labels designed to help Americans pick smart devices that are less vulnerable to hacking could begin appearing on products before the holiday shopping season, federal officials said Wednesday.

    Under the new U.S. Cyber Trust Mark Initiative, manufacturers can affix the label on their products if they meet federal cybersecurity standards. The types of devices eligible for labels include baby monitors, home security cameras, fitness trackers, refrigerators and other internet-connected appliances.

    The White House first announced the “Cyber Trust” labels last year and the Federal Communications Commission finalized the details in March, clearing the way for the labels to start showing up in several months.

    https://www.fcc.gov/cybersecurity-certification-mark

    Reply
  6. Tomi Engdahl says:

    ICS/OT
    Rockwell Automation Urges Customers to Disconnect ICS From Internet

    Rockwell Automation is concerned about internet-exposed ICS due to heightened geopolitical tensions and adversarial cyber activity globally.

    https://www.securityweek.com/rockwell-automation-urges-customers-to-disconnect-ics-from-internet/

    Reply
  7. Tomi Engdahl says:

    IoT Security
    Cybersecurity Labeling for Smart Devices Aims to Help People Choose Items Less Likely to be Hacked

    Under the new U.S. Cyber Trust Mark Initiative, manufacturers can affix the label on their products if they meet federal cybersecurity standards.

    https://www.securityweek.com/cybersecurity-labeling-for-smart-devices-aims-to-help-people-choose-items-less-likely-to-be-hacked/

    Reply
  8. Tomi Engdahl says:

    What’s the difference between a VPN and an SSL VPN?

    All SSL VPNs are VPNs, but not all VPNs are SSL VPNs. SSL is just one of the encryption protocols that VPNs can use. Some examples of VPNs that don’t use SSL encryption protocols include:

    IPsec
    SSTP
    IKEv2
    WireGuard VPNs

    https://us.norton.com/blog/privacy/ssl-vpn

    Reply
  9. Tomi Engdahl says:

    SSL VPN vulnerabilities refer to security weaknesses within SSL VPN products that could potentially be exploited by attackers. Here are some key points regarding these vulnerabilities:

    Rogue Users: Even with encrypted VPN connections, attackers connected to the VPN can exploit network resources1.
    Unprotected Connections: If a VPN connection drops, devices may revert to unsecured connections, risking data exposure. Some VPNs offer a kill-switch to prevent this1.
    Protocols and Patching: SSL/TLS protocols used in VPNs can have exploitable vulnerabilities. Regular patching is crucial to maintain security1.
    Recent Exploits: CVE-2024-21762 is a critical out-of-bound write vulnerability in Fortinet FortiOS’s SSL VPN daemon, which could allow remote code execution if exploited2.
    It’s important for organizations to stay informed about these vulnerabilities and implement measures to mitigate the risks.

    Reply
  10. Tomi Engdahl says:

    Cyberwarfare
    Europe’s Cybersecurity Chief Says Disruptive Attacks Have Doubled in 2024, Sees Russia Behind Many

    Disruptive digital attacks – many traced to Russia-backed groups – have doubled in the European Union in 2024 and are also targeting election-related services, according to the EU’s top cybersecurity official.

    https://www.securityweek.com/europes-cybersecurity-chief-says-disruptive-attacks-have-doubled-in-2024-sees-russia-behind-many/

    Reply
  11. Tomi Engdahl says:

    https://blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency

    But there are some disadvantages to this model. In the case of TLS (the most common standard used for sending encrypted data across in the Internet and the protocol your browser uses with visiting an https:// web site) the layering of TLS on top of TCP can cause delays to the delivery of a web page.

    That’s because TLS divides the data being transmitted into records of a fixed (maximum) size and then hands those records to TCP for transmission. TCP promptly divides those records up into segments which are then transmitted. Ultimately, those segments are sent inside IP packets which traverse the Internet.

    https://community.cisco.com/t5/email-security/any-overhead-with-tls/td-p/2199134

    there is usually no delay to be significant for message processing when sent/received via TLS. What however is important to know is that compared to normal SMTP connection, a TLS connection takes at least ten times more resources. That is important to know in if the customer plans to use TLS extensively.

    Reply
  12. Tomi Engdahl says:

    The TLS handshake is a relatively expensive process. Therefore, information about TLS sessions is cached so that the handshake can be optimized, which can have a significant impact on the performance. The mechanism for caching depends on how TLS sessions are made to CICS: Sysplex caching when you use TLS in CICS.

    https://www.ibm.com/docs/en/cics-ts/beta?topic=motion-performance-considerations-tls-connections

    Reply
  13. Tomi Engdahl says:

    What are the advantages of using the latest TLS version? In a nutshell, TLS 1.3 is faster and more secure than TLS 1.2.

    https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/

    What are the advantages of using the latest TLS version?

    In a nutshell, TLS 1.3 is faster and more secure than TLS 1.2. One of the changes that makes TLS 1.3 faster is an update to the way a TLS handshake works: TLS handshakes in TLS 1.3 only require one round trip (or back-and-forth communication) instead of two, shortening the process by a few milliseconds. And in cases when the client has connected to a website before, the TLS handshake will have zero round trips. This makes HTTPS connections faster, cutting down latency and improving the overall user experience.

    Many of the major vulnerabilities in TLS 1.2 had to do with older cryptographic algorithms that were still supported. TLS 1.3 drops support for these vulnerable cryptographic algorithms, and as a result it is less vulnerable to cyber attacks.

    Reply
  14. Tomi Engdahl says:

    Cisco Finds 15 Vulnerabilities in AutomationDirect PLCs

    Cisco Talos researchers have found over a dozen vulnerabilities in AutomationDirect PLCs, including flaws that could be valuable to attackers.

    ICS/OT

    Cisco Finds 15 Vulnerabilities in AutomationDirect PLCs
    Cisco Talos researchers have found over a dozen vulnerabilities in AutomationDirect PLCs, including flaws that could be valuable to attackers.
    https://www.securityweek.com/cisco-finds-15-vulnerabilities-in-automationdirect-plcs/

    Reply
  15. Tomi Engdahl says:

    ICS/OT
    Know Your Adversary: Why Tuning Intelligence-Gathering to Your Sector Pays Dividends

    Without tuning your approach to fit your sector, amongst other variables, you’ll be faced with an unmanageable amount of noise.

    https://www.securityweek.com/know-your-adversary-why-tuning-intelligence-gathering-to-your-sector-pays-dividends/

    Critical national infrastructure (CNI) sites and providers are targeted by some of the most advanced and persistent threat actors in the world. The nature of CNI – which encompasses everything from communications and transportation industries to energy networks and water utilities – makes it the ideal high-profile target for ideologically motivated threat actors. Successful attacks demonstrate adversary infiltration and digital superiority. To compound the challenge, CNI has become increasingly vulnerable due to ongoing digital transformation efforts. While these are essential to provide the level of service expected by today’s citizens, growing digital dependence unavoidably introduces a plethora of new risks and interdependencies between disparate systems and services that can be cumbersome to identify and manage.

    I was reminded of this with two recent stories that appeared in the press, one in The Wall Street Journal: U.S. Fears Undersea Cables Are Vulnerable to Espionage From Chinese Repair Ships. Google, Meta Platforms and other digital service providers have shared ownership of many cables that carry cross-global internet traffic, but they rely on third-party maintenance specialists, including some with foreign ownership. U.S. officials are concerned that these cables could be vulnerable to tampering by Chinese-owned repair ships. Another story concerns attacks on rural US water system facilities, of which there have been several over recent years attributed to bad actors backed by Russia and Iran.

    Reply
  16. Tomi Engdahl says:

    US, Allies Warn of Memory Unsafety Risks in Open Source Software

    Most critical open source software contains code written in a memory unsafe language, US, Australian, and Canadian government agencies warn.

    https://www.securityweek.com/us-allies-warn-of-memory-unsafety-risks-in-open-source-software/

    Reply
  17. Tomi Engdahl says:

    BlastRADIUS Attack Exposes Critical Flaw in 30-Year-Old RADIUS Protocol
    https://www.securityweek.com/blastradius-attack-exposes-critical-flaw-in-30-year-old-radius-protocol/

    Security vendor InkBridge Networks calls urgent attention to the discovery of a decades-old design flaw (CVE-2024-3596) in the popular RADIUS protocol.

    Security vendor InkBridge Networks on Tuesday called urgent attention to the discovery of a thirty-year-old design flaw in the RADIUS protocol and warned that advanced attackers can launch exploits to authenticate anyone to a local network, bypassing any multi-factor-authentication (MFA) protections.

    The company published a technical description of what is being called the BlastRADIUS attack and warned that corporate networks such as internal enterprise networks, Internet Service Providers (ISPs), and Telecommunications companies (telcos) are exposed to major risk.

    The flaw was discovered by researchers at Boston University, Cloudflare, BastionZero, Microsoft Research, Centrum Wiskunde & Informatica and the University of California, San Diego.

    The vulnerability is being tracked as CVE-2024-3596 and VU#456537.

    “The root cause of the attack is that in the RADIUS protocol, some Access-Request packets are not authenticated and lack integrity checks. An attacker can modify these packets in a way which allows them to control who gets onto the network,” the research team explained.

    The RADIUS protocol, first standardized in the late 1990s, is used to control network access via authentication, authorization, and accounting and is still used widely today in switches, routers, access points and VPN products.

    “All of those devices are likely vulnerable to this attack,” the researchers warned.

    “The key to the attack is that in many cases, Access-Request packets have no authentication or integrity checks. An attacker can then perform a chosen prefix attack, which allows modifying the Access-Request in order to replace a valid response with one chosen by the attacker. Even though the response is authenticated and integrity checked, the chosen prefix vulnerability allows the attacker to modify the response packet, almost at will,” according to the InkBridge Networks documentation.

    The company described the issue as “a fundamental design flaw of the RADIUS protocol” and noted that all standards compliant RADIUS clients and servers are likely vulnerable to this attack, even if they correctly implement all aspects of the RADIUS protocol.

    “Since all security of the RADIUS protocol for UDP and TCP transports is based on the shared secret, this attack is perhaps the most serious attack possible on the RADIUS protocol,” the company declared.

    At the absolute minimum, InkBridge Networks recommends that every single RADIUS server world-wide must be upgraded to address this vulnerability. “It is not sufficient to upgrade only RADIUS clients, as doing so will allow the network to remain vulnerable.”

    The company said a private proof-of-concept exploit has been created by its researchers but there is no indication that this vulnerability is being actively exploited in the wild.

    Even if someone managed to recreate the exploit, the researchers note that a successful attack will be costly. “It can take a significant amount of cloud computing power to succeed in performing the attack. This cost is also per packet being exploited, and cannot be automatically applied to many packets. If an attacker wants to perform 100 attacks, he has to use 100 times of computing power.”

    Blast-RADIUS Attack in More Detail
    https://www.blastradius.fail/attack-details

    The RADIUS (Remote Authentication Dial-In User Service) protocol is at the core of today’s network infrastructure. Although the protocol was first designed in 1991 — during the era of dial-up internet — it remains the de facto standard lightweight authentication protocol used for remote access for users and administrators to networked devices. RADIUS is supported by “essentially every switch, router, access point, and VPN concentrator product sold in the last twenty years” (source).

    In RADIUS, a NAS (Network Access Server) acts as a client that verifies an end user’s credentials via RADIUS requests to a central server. The RADIUS client and server share a fixed secret. The server responds with an accept or reject message (called Access-Accept and Access-Reject, respectively). Requests and responses may contain labeled fields called “attributes” that specify various parameters such as username and password in a request, or network access in a response. Request packets include a value called a Request Authenticator that is essentially a random nonce. Response packets include a value called a Response Authenticator value that is intended to integrity-protect server responses.

    In our paper, we give an attack against this ad hoc RADIUS Response Authenticator “MAC” construction. Our attack allows a man in the middle between the RADIUS client and server to forge a valid Access-Accept response to a failed authentication request. The attacker does this by injecting a malicious Proxy-State attribute into a valid client request. This Proxy-State attribute is guaranteed to be echoed back by the server in its response. The attacker constructs the Proxy-State so that the Response Authenticator values between the valid response and the response the attacker wishes to forge will be identical. This forgery will cause the NAS to grant the adversary access to network devices and services without the adversary guessing or brute forcing passwords or shared secrets.

    The MD5 collision attack that we exploit is a version of the chosen-prefix collision from Stevens et al..

    This description is simplified. In particular, we had to do cryptographic work to split the MD5 collision gibberish across multiple properly formatted Proxy-State attributes

    Reply
  18. Tomi Engdahl says:

    New Blast-RADIUS attack breaks 30-year-old protocol used in networks everywhere
    Ubiquitous RADIUS scheme uses homegrown authentication based on MD5. Yup, you heard right.
    https://arstechnica.com/security/2024/07/new-blast-radius-attack-breaks-30-year-old-protocol-used-in-networks-everywhere/

    One of the most widely used network protocols is vulnerable to a newly discovered attack that can allow adversaries to gain control over a range of environments, including industrial controllers, telecommunications services, ISPs, and all manner of enterprise networks.

    Short for Remote Authentication Dial-In User Service, RADIUS harkens back to the days of dial-in Internet and network access through public switched telephone networks. It has remained the de facto standard for lightweight authentication ever since and is supported in virtually all switches, routers, access points, and VPN concentrators shipped in the past two decades. Despite its early origins, RADIUS remains an essential staple for managing client-server interactions for:

    VPN access
    DSL and Fiber to the Home connections offered by ISPs,
    Wi-Fi and 802.1X authentication
    2G and 3G cellular roaming
    5G Data Network Name authentication
    Mobile data offloading
    Authentication over private APNs for connecting mobile devices to enterprise networks
    Authentication to critical infrastructure management devices
    Eduroam and OpenRoaming Wi-Fi

    RADIUS provides seamless interaction between clients—typically routers, switches, or other appliances providing network access—and a central RADIUS server, which acts as the gatekeeper for user authentication and access policies. The purpose of RADIUS is to provide centralized authentication, authorization, and accounting management for remote logins.

    The protocol was developed in 1991 by a company known as Livingston Enterprises. In 1997 the Internet Engineering Task Force made it an official standard, which was updated three years later. Although there is a draft proposal for sending RADIUS traffic inside of a TLS-encrypted session that’s supported by some vendors, many devices using the protocol only send packets in clear text through UDP (User Datagram Protocol).

    Roll-your-own authentication with MD5? For real?
    Since 1994, RADIUS has relied on an improvised, home-grown use of the MD5 hash function. First created in 1991 and adopted by the IETF in 1992, MD5 was at the time a popular hash function for creating what are known as “message digests” that map an arbitrary input like a number, text, or binary file to a fixed-length 16-byte output.

    For a cryptographic hash function, it should be computationally impossible for an attacker to find two inputs that map to the same output. Unfortunately, MD5 proved to be based on a weak design: Within a few years, there were signs that the function might be more susceptible than originally thought to attacker-induced collisions, a fatal flaw that allows the attacker to generate two distinct inputs that produce identical outputs. These suspicions were formally verified in a paper published in 2004 by researchers Xiaoyun Wang and Hongbo Yu and further refined in a research paper published three years later.

    The latter paper—published in 2007 by researchers Marc Stevens, Arjen Lenstra, and Benne de Weger—described what’s known as a chosen-prefix collision

    Despite the undisputed demise of MD5, the function remained in widespread use for years. Deprecation of MD5 didn’t start in earnest until 2012 after malware known as Flame, reportedly created jointly by the governments of Israel and the US, was found to have used a chosen prefix attack to spoof MD5-based code signing by Microsoft’s Windows update mechanism. Flame used the collision-enabled spoofing to hijack the update mechanism so the malware could spread from device to device inside an infected network.

    “Surprisingly, in the two decades since Wang et al. demonstrated an MD5 hash collision in 2004, RADIUS has not been updated to remove MD5,” the research team behind Blast RADIUS wrote in a paper published Tuesday and titled RADIUS/UDP Considered Harmful. “In fact, RADIUS appears to have received notably little security analysis given its ubiquity in modern networks.”

    The paper’s publication is being coordinated with security bulletins from at least 90 vendors whose wares are vulnerable. Many of the bulletins are accompanied by patches implementing short-term fixes, while a working group of engineers across the industry drafts longer-term solutions. Anyone who uses hardware or software that incorporates RADIUS should read the technical details provided later in this post and check with the manufacturer for security guidance.

    From hours to minutes
    Key to making Blast-RADIUS practical is a series of optimizations made to hashclash that radically reduce the time required to complete a chosen prefix attack.

    The 2008 attack used to create the rogue certificate authority, for instance, required about 2,800 core-days, a measurement of computational time equivalent to running one CPU for 2,800 days. The optimization devised for Blast-RADIUS whittles that time down to just 39 core hours. Distributing the load to a cluster of roughly 2,000 CPU cores ranging from 7 to 10 years old, plus four newer low-end GPUs—the modest resources available to the academic researchers—the wall time required for Blast-RADIUS to complete is about five minutes.

    This version of Blast-RADIUS isn’t practical for attacking RADIUS because logins typically time out after 30 to 60 seconds. The researchers say the five minutes they required is the result of them using commodity old hardware. They say they’re convinced their attack is sufficient when carried out on hardware better suited for hash collisions.

    The improvements also allow the attacker to split the gibberish block as multiple properly formatted small protocol attribute fields that get appended to the chosen prefix. This allows the Blast-RADIUS attacker to carry out the attack efficiently, within the RADIUS timeout limits of 30 to 60 seconds, and to squeeze the required data into the RADIUS protocol format. Blast-RADIUS affects all authentication modes of RADIUS/UDP apart from those that use EAP (Extensible Authentication Protocol).

    Threat model
    Blast-RADIUS requires the adversary to have the network access needed to act as an active adversary-in-the-middle attacker, meaning the adversary has the ability to read, intercept, block, and modify all data passing between the victim device’s RADIUS client and RADIUS server. When there are proxies between the two endpoints, the attack can occur between any hop.

    This access to RADIUS traffic can happen when RADIUS/UDP packets travel over the open Internet, a practice that’s discouraged but still known to happen. When traffic is restricted to an internal network, the attacker might first compromise a part of that network, another common occurrence. In the event RADIUS traffic is restricted to a protected part of an internal network, it may still be exposed as a result of configuration or routing errors. An attacker with partial network access might also be able to access RADIUS traffic by exploiting mechanisms such as DHCP to induce victim devices to send traffic outside of a dedicated VPN

    With that, the attacker has successfully logged in to the device with administrative system rights. The attacker does not need to wait for a real user to attempt to log in to a RADIUS client. Instead, the attacker triggers an authentication request on its own by using any password. From there, Blast-RADIUS changes the authentication outcome from unsuccessful to successful.

    Mitigations
    Over the long run, the researchers said, the only way to fix RADIUS is to transport it over TLS or DTLS, a move that provides modern security guarantees including confidentiality to the user data in the requests and ensures the integrity of the Access-Accept and Access-Reject responses. A working group within the IETF is drafting a specification update that aims to do just that. These sorts of major renovations take months or even years to complete. Some implementations of RADIUS, namely the one from Microsoft, have yet to support TLS.

    In the meantime, for those environments that must continue to transport RADIUS over UDP, the researchers recommend that both RADIUS clients and servers always send and require Message-Authenticator attributes for all requests and responses using what’s known as HMAC-MD5 for packet authentication. For Access-Accept and Access-Reject responses, the Message-Authenticator should be included as the first attribute. All five of the major RADIUS implementations—available from FreeRADIUS, Radiator, Cisco, Microsoft, and Nokia—have updates available that follow this short-term recommendation.

    “This measure breaks compatibility with old implementations that may not include Message-Authenticators in requests or responses,” the researchers cautioned. “However, unlike other options, it is not a fundamental change to the protocol and can be adopted as a fairly simple patch to clients and servers.”

    “Given the enormous amount of effort put into securing these protocols it is surprising that a protocol as ubiquitous as RADIUS has received so little cryptanalytic attention over the years,” they wrote. “TLS may be the charismatic megafauna of cryptographic protocol research, but in order to actually secure our infrastructure we need to analyze and secure the entire universe of enterprise security that academic cryptographers have little to no visibility into or insight in.”

    Reply
  19. Tomi Engdahl says:

    Minino ESP32-C6 board is designed for IoT security and penetration testing
    Minino security tool is a kitty-shaped ESP32-C6 powered cybersecurity device for analyzing 2.4GHz communications and probing IoT devices. It supports Bluetooth Low Energy, Wi-Fi 6, Zigbee, Thread, and Matter, and has a dedicated GNSS radio for receiving signals from various satellite constellations. Minino is compatible with CatSniffer analysis tools and Wireshark software, and can log packet captures on a microSD card. These features make this suitable for applications like assessing IoT device security, network analysis, and wireless protocol research.
    https://www.cnx-software.com/2024/07/15/minino-esp32-c6-board-is-designed-for-iot-security-and-penetration-testing/

    Reply
  20. Tomi Engdahl says:

    https://github.com/ElectronicCats/CatSniffer

    CatSniffer is an original multiprotocol and multiband board for sniffing, communicating, and attacking IoT (Internet of Things) devices using the latest radio IoT protocols. It is a highly portable USB stick that integrates TI CC1352, Semtech SX1262, and an RP2040 for V3 or a Microchip SAMD21E17 for V2

    Reply
  21. Tomi Engdahl says:

    UNDO ARDUINO ENCRYPTION WITH AN OSCILLOSCOPE
    https://hackaday.com/2024/07/14/undo-arduino-encryption-with-an-oscilloscope/

    Cryptography ain’t easy. Seemingly small details like how many times a computationally intensive loop runs can give the game away. [Lord Feistel] gives us a demo of how this could work with nothing more than poorly designed code, a resistor, and an oscilloscope.

    Power analysis attack over RSA
    https://github.com/lord-feistel/power_analysis

    Reply

Leave a Comment

Your email address will not be published. Required fields are marked *

*

*