Archive for the ‘en-US’ Category
[DefCon32] Listen to the Whispers: Web Timing Attacks that Actually Work
Timing attacks, long dismissed as theoretically potent yet practically elusive, gain new life through innovative techniques. James Kettle bridges the “timing divide,” transforming abstract concepts into reliable exploits against live systems. By amplifying signals and mitigating noise, Kettle unveils server secrets like masked misconfigurations, blind injections, hidden routes, and untapped attack surfaces.
Traditional hurdles—network jitter and server noise—once rendered attacks unreliable. HTTP/2’s concurrency, enhanced by Kettle’s single-packet method, synchronizes requests in one TLS record, eliminating jitter. Coalescing headers via sacrificial PING frames counters sticky ordering, making attacks “local” regardless of distance.
Server noise, from load variances to cloud virtualization, demands signal amplification: repeating headers for cumulative delays or denial-of-service tactics like nested XML entities. Repetition exploits caching, reducing variability; trimming requests minimizes unnecessary processing.
Parameter Discovery and Control Flow Insights
Kettle adapts Param Miner for time-based parameter/header guessing, uncovering hidden features on thousands of bug bounty sites. Timing reveals parameters altering responses subtly, like JSON-validated headers or cache keys signaling web cache poisoning risks.
Control flow changes, such as exceptions, emerge vividly. A Web Application Firewall (WAF) bypass exemplifies: repeated “exec” parameters trigger prolonged analysis, escalating to denial-of-service; excess parameters expose max-header limits, enabling evasion.
IP spoofing headers like “True-Client-IP” induce DNS caching delays, confirmed via pingbacks. Non-caching variants suggest third-party geo-lookups, bypassing with hostnames.
Server-Side Injection Vulnerabilities
Timing excels at blind injections in non-sleep-capable languages. Serde JSON injections manifest as microsecond differentials; combining with client-side reflections infers standalone processing, aiding exploitation.
Blind Serde parameter pollution contrasts reserved/unreserved characters, yielding exploits. Doppelgangers—non-blind equivalents—guide understanding, turning detections into impacts.
SQL injections via sleep evade WAFs but overlap existing tools; timing shines where sleep fails, though exploitation demands deep target insight.
Scoped Server-Side Request Forgery Detection
Overlooked for years, scoped SSRF—proxies accessing only target subdomains—defies DNS pingbacks. Timing detects via DNS caching or label-length timeouts: valid hostnames delay; invalids accelerate or prolong.
Automating exploration, Kettle probes subdomains directly and via proxies, flagging discrepancies like missing headers. Exploits span firewall bypasses, internal DNS resolutions uncovering staging servers, pre-launch consoles, and frontend circumventions.
Frontend impersonation leverages trusted internal headers for authentication bypasses, exploitable via proxies, direct backend access, or smuggling. Timing guesses header names, enabling severe breaches.
Links:
EN_DEFCON32MainStageTalks_004_005.md
[DotJs2024] Adding Undo/Redo to Complex Web Apps
Enhancing user agency in labyrinthine applications hinges on forgiving interactions, where missteps dissolve with a keystroke. Bassel Ghandour, a senior software engineer at Contentsquare, distilled this essence into a brisk yet profound primer at dotJS 2024. From Paris’s vibrant tech scene—now his U.S. outpost—Ghandour lamented a botched virtual Tokyo greeting, swiftly invoking undo’s allure. His focus: retrofitting undo/redo into state-heavy web apps, sidestepping snapshot pitfalls for action-centric resilience.
Ghandour commenced with state management basics in a todo app: frontend mirrors app state, enter-press morphs it—additions, UI ripples. Naive undo? Timestamped snapshots, hopping between epochs. Reality intrudes: actions cascade side effects, backend ops interweave, concurrency clashes. Rapid todo barrages spawn interleaved sequences; snapshot reversion mid-thread invites chaos. Solution: encapsulate sequences under UUIDs, treating batches as atomic units. Parallel: forge inverses—add’s delete, toggle’s revert—mapping each to its antithesis.
This duality—do and undo in tandem—preserves fidelity. User crafts todo: UUID wraps creation, displays; inverse queues deletion. Subsequent show-toggle: nested UUID, inverse queued. Undo invokes the stack’s apex inverse, state reverts cleanly; redo replays forwards. Ghandour’s flow: capture actions, inverse-map, sequence-bundle, command-apply. Backend sync? Optimistic updates, rollbacks on failure. Contentsquare’s engineering blog details implementations, from Redux sagas to custom dispatchers.
Ghandour’s brevity belied depth: this pattern scales to e-commerce carts, design canvases, empowering serene navigation amid complexity. By prioritizing actions over states, developers liberate users, fostering trust in intricate digital environs.
Encapsulating Actions for Resilience
Ghandour advocated UUID-wrapped sequences, neutralizing concurrency: todo volleys become discrete do/undo pairs, applied reversibly. Inverse mapping—add-to-delete—ensures symmetry, backend integrations via optimistic commits. This sidesteps snapshot bloat, embracing flux with grace.
Implementing Undo/Redo Commands
Stacks manage history: push do with inverse, pop applies antithesis. Redo mirrors. Ghandour teased Contentsquare’s saga: Redux orchestration, UI hooks triggering cascades—scalable, testable, user-delighting.
Links:
[DefCon32] Breaking Secure Web Gateways for Fun and Profit
Secure Web Gateways (SWGs), integral to enterprise Secure Access Service Edge (SASE) and Security Service Edge (SSE) frameworks, promise robust defenses against web threats. Vivek Ramachandran and Jeswin Mathai expose architectural flaws in these systems, introducing “Last Mile Reassembly Attacks” that evade detection across major vendors. Their findings underscore the limitations of network-level analysis in confronting modern browser capabilities.
SWGs intercept SSL traffic for malware scanning, threat prevention, URL filtering, and data loss prevention (DLP). Yet, as browsers evolve into sophisticated compute environments, attackers exploit client-side processing to reassemble threats post-proxy. Ramachandran highlights how SWGs lack context on DOM changes, events, and user interactions, operating blindly on flat traffic. Cloud constraints—file size limits (15-50 MB) and incomplete archive scanning—exacerbate vulnerabilities, often forcing blanket policies.
Vendors’ service level agreements (SLAs) claim 100% prevention of known malware, but these attacks shatter such guarantees. Pricing models ($2-4 per user/month) prioritize efficiency over exhaustive analysis, leaving gaps in protocol support and file handling.
Unmonitored Channels and Hiding in Plain Sight
Mathai demonstrates unmonitored protocols like WebRTC, WebSockets, gRPC, and Server-Sent Events smuggling malware undetected. These channels, essential for real-time apps, bypass interception; blocking them degrades user experience. Demos show seamless downloads of known malicious files via these vectors, indistinguishable from standard HTTP.
Further evasion involves embedding payloads in HTML, CSS, JavaScript, or SVG, extracting them client-side for reconstruction. SWGs scan individual resources but miss browser-side assembly. Encryption/decryption and encoding/decoding (e.g., Base64, UUencode) transform binaries in memory, dropping unencrypted files without triggering content disposition headers.
Last Mile Reassembly Techniques
Core to their research, Last Mile Reassembly fragments files into chunks—straight splits, reverses, randomized sizes, or mixes—fetched via multiple requests and reassembled via JavaScript. SWGs analyze fragments independently, failing to detect malice. Extending to WebAssembly modules constructing documents (e.g., malicious Excel) locally, no file download occurs from the proxy’s view.
File uploads reverse this: insiders fragment sensitive data, sending as form submissions evading DLP rules. Overlapping fragments mimic historical network attacks, fully bypassing inspections.
Phishing sites, converted to MHTML archives and smuggled via reassembly, repaint via canvas, reusing known malicious pages undetected. SWGs fingerprint server-side but overlook client-side rendering.
Architectural Challenges and Vendor Responses
SWGs’ server-side nature precludes real-time browser syncing or per-tab emulation, unscalable amid millions of events. Ramachandran argues for browser-integrated security to access rich data, contrasting cloud-centric models’ economic allure with practical failures.
Vendor engagements yielded mixed results: some acknowledged issues and pursued fixes; others claimed partial detection or disengaged. Open-sourcing 25 bypasses at browser.security empowers testing, urging vendors to address rather than block the site.
Their toolkit facilitates red-team simulations, exposing SLAs’ fragility. Enterprises must rethink web threat defenses, prioritizing client-side visibility over network proxies.
Links:
[OxidizeConf2024] Exploring Slint as a Rust Alternative to QML for GUI Development
The Evolution of GUI Development
In the ever-evolving realm of graphical user interface (GUI) development, the quest for robust, safe, and efficient tools is paramount. David Vincze, a senior software engineer at Felgo, presented a compelling exploration of Slint as a Rust-based alternative to QML at OxidizeConf2024. With a background steeped in C++ and Qt, particularly in automotive instrument clusters, David shared his insights into how Slint offers a fresh perspective for developers accustomed to QML’s declarative approach within the Qt framework. His presentation illuminated the potential of Slint to address the limitations of QML, particularly its reliance on C++ and JavaScript, which can introduce runtime errors that challenge developers in safety-critical environments.
QML, a mature language with over a decade of use, has been a cornerstone for cross-platform GUI development, enabling developers to write a single codebase that runs on embedded, mobile, desktop, and web platforms. Its JSON-like syntax, coupled with reactive property bindings and JavaScript logic, simplifies prototyping and maintenance. However, David highlighted the inherent risks, such as performance bottlenecks due to JavaScript’s runtime interpretation and the dependency on the extensive Qt ecosystem, which can entail licensing costs. Slint, a newer toolkit built with Rust, emerges as a promising alternative, compiling to native code to catch errors at build time, thus enhancing reliability for embedded systems.
Comparing Slint and QML
David’s analysis centered on a practical comparison between Slint and QML, drawing from a demo weather application and home automation UI developed at Felgo. This project, available on Felgo’s GitHub as the Rusty Weather App, reimplemented a QML-based application in Slint, showcasing its multiplatform capabilities on desktop, embedded Raspberry devices, and Android. The comparison revealed striking similarities in their declarative syntax, with both languages using component-based structures to define UI elements. However, Slint’s code is notably more compact, and its components can be exported to native code, offering greater integration flexibility compared to QML’s C++-centric approach.
A key differentiator is Slint’s compilation to native code, which eliminates runtime errors common in QML’s JavaScript logic. This is particularly advantageous for embedded systems, where performance and reliability are critical. David demonstrated how Slint’s lightweight runtime and reactive property bindings mirror QML’s strengths but leverage Rust’s memory safety to prevent common programming errors. However, Slint lacks some of QML’s advanced features, such as multimedia support, 3D rendering, and automated UI testing, which are still in development. Despite these gaps, Slint’s rapid evolution, with frequent releases, signals its potential to rival QML in the future.
Challenges and Opportunities in Transitioning
Transitioning from QML to Slint presents both opportunities and challenges. David emphasized Slint’s benefits, including its integration with Rust’s ecosystem, which offers a robust package manager (Cargo) and seamless cross-compilation. The Slint VS Code extension, with its live preview feature, accelerates development by allowing real-time UI modifications without recompilation. This contrasts with QML’s reliance on tools like Qt Creator, which, while comprehensive, tie developers to the Qt ecosystem. Slint’s open-source nature and multi-language APIs (supporting Rust, C++, JavaScript, and Python) further enhance its appeal for diverse projects.
However, David acknowledged challenges, particularly in areas like internationalization, where Slint’s reliance on the Gettext library complicates translation processes compared to Qt’s well-established framework. Features like multi-window support and internal timers are also underdeveloped in Slint, posing hurdles for developers accustomed to QML’s mature ecosystem. Despite these, David advocated for Slint’s adoption in Rust-centric projects, citing its predictability and performance advantages, especially for embedded development. The community’s active development and planned UI testing support suggest that Slint’s limitations may soon be addressed, making it a compelling choice for forward-thinking developers.
Links:
[DefCon32] Abusing Windows Hello Without a Severed Hand
In the realm of cybersecurity, exploring vulnerabilities in authentication mechanisms often reveals unexpected pathways for exploitation. Ceri Coburn and Dirk-jan Mollema delve into the intricacies of Windows Hello, Microsoft’s passwordless technology, highlighting how attackers can manipulate its components without relying on physical biometric data. Their presentation uncovers the architecture of Windows Hello, from key storage providers to protectors and keys, demonstrating real-world abuses that challenge the system’s perceived robustness.
Coburn begins by outlining the foundational elements of Windows Hello, emphasizing its role in generating keys for operating system logins, passkeys, and third-party applications. The distinction between Windows Hello and Windows Hello for Business lies primarily in the latter’s focus on certificate-based authentication for Active Directory environments. Both utilize key storage providers (KSPs), which serve as APIs for cryptographic operations. Traditional providers include software-based ones, TPM-backed platforms, and smart card integrations, but Windows Hello introduces the Passport KSP, acting as a proxy to these existing systems.
The Passport KSP comprises two services: the NGC service for application communication via RPC and the NGC controller service for metadata storage under the local service account, accessible only with system-level privileges. Each user enrollment creates a unique container folder identified by a GUID, housing protectors, key metadata, and recovery options. Protectors represent authentication methods like PINs or biometrics, encrypting intermediate PINs that unlock enrolled keys. These intermediate PINs—split into signing, decryption, and external variants—remain constant across protectors, allowing bypasses once accessed.
Unprivileged Attacks and Primary Refresh Tokens
Shifting focus, Mollema addresses attacks feasible without administrative privileges, centering on Primary Refresh Tokens (PRTs) in Windows Hello for Business scenarios. PRTs function as single sign-on tokens, requested via JSON Web Tokens (JWTs) signed by device certificates, ensuring trust from Entra (formerly Azure AD). When using Windows Hello, these requests incorporate data signed by private keys, including nonces to prevent replays.
A critical flaw arises from the ability to generate assertions without prompting for PINs or biometrics post-login, as keys are cached in sessions. Mollema demonstrates crafting “golden assertions” with extended validity, though Microsoft mitigated this by enforcing nonces server-side in May 2024. Nonetheless, within a five-minute window, attackers can request new PRTs on rogue devices, bypassing TPM protections and enabling persistence for up to 90 days.
This technique exploits RDP scenarios where PRTs on non-TPM devices expose credentials. Even with virtualization-based security or LSA protections, such attacks persist, underscoring the need for device compliance monitoring and restrictions on RDP to non-TPM systems.
Privileged Exploitation of Containers and Protectors
Under privileged access, Coburn dissects container structures, revealing metadata in .dat files detailing user SIDs, backing KSPs, and recovery keys. Protectors encrypt intermediate PINs differently: PIN protectors use PBKDF2 derivation for software KSPs or hex conversion for TPM unsealing. Biometric protectors, surprisingly, rely on system DPAPI keys, enabling reversal without actual biometrics via Vault decryption.
Recovery protectors, exclusive to business scenarios, involve Azure-encrypted blobs requiring MFA claims, yet their storage outside protector folders poses risks. Pre-boot and deprecated companion device protectors receive brief mentions, with further research needed.
Abuses include brute-forcing software-backed PINs via Hashcat masks, exploiting known lengths for rapid cracks—seconds for eight digits. TPM-backed PINs resist better, though four-digit variants succumb in months due to anti-hammering.
Key Types and Persistence Implications
Enrolled keys leverage intermediate PINs: vault keys decrypt local passwords in consumer setups, entry keys handle business enrollments and passkeys, and external keys support third-party apps like Okta FastPass. Software-backed keys allow extraction off-device, amplifying risks.
Mollema extends this to PRT theft, using cached keys for assertions on different devices, even without TPMs, facilitating identity persistence. Reported vulnerabilities led to CVE assignments, with server-side enforcements post-July 2023.
Endpoint mitigations include Windows Hello Extended Session Security (ESS), rewriting containers in JSON under secure processes. Detections monitor NGC metadata access, alerting on non-controller processes.
Their tools—Shay for Hello abuses and ROADtools for Azure AD—aid offensive and defensive efforts, drawing from blogs by Teal and others.
Links:
[DefCon32] Taming the Beast: Inside Llama 3 Red Team Process
As large language models (LLMs) like Llama 3, trained on 15 trillion tokens, redefine AI capabilities, their risks demand rigorous scrutiny. Alessandro Grattafiori, Ivan Evtimov, and Royi Bitton from Meta’s AI Red Team unveil their methodology for stress-testing Llama 3. Their process, blending human expertise and automation, uncovers emergent risks in complex AI systems, offering insights for securing future models.
Alessandro, Ivan, and Royi explore red teaming’s evolution, adapting traditional security principles to AI. They detail techniques for discovering vulnerabilities, from prompt injections to multi-turn adversarial attacks, and assess Llama 3’s resilience against cyber and national security threats. Their open benchmark, CyberSecEvals, sets a standard for evaluating AI safety.
The presentation highlights automation’s role in scaling attacks and the challenges of applying conventional security to AI’s unpredictable nature, urging a collaborative approach to fortify model safety.
Defining AI Red Teaming
Alessandro outlines red teaming as a proactive hunt for AI weaknesses, distinct from traditional software testing. LLMs, with their vast training data, exhibit emergent behaviors that spawn unforeseen risks. The team targets capabilities like code generation and strategic planning, probing for exploits like jailbreaking or malicious fine-tuning.
Their methodology emphasizes iterative testing, uncovering how helpfulness training can lead to vulnerabilities, such as hallucinated command flags.
Scaling Attacks with Automation
Ivan details their automation framework, using multi-turn adversarial agents to simulate complex attacks. These agents, built on Llama 3, attempt tasks like vulnerability exploitation or social engineering. While effective, they struggle with long-form planning, mirroring a novice hacker’s limitations.
CyberSecEvals benchmarks these risks, evaluating models across high-risk scenarios. The team’s findings, shared openly, enable broader scrutiny of AI safety.
Cyber and National Security Threats
Royi addresses advanced threats, including attempts to weaponize LLMs for cyberattacks or state-level misuse. Tests reveal Llama 3’s limitations in complex hacking, but emerging techniques like “obliteration” remove safety guardrails, posing risks for open-weight models.
The team’s experiments with uplifting non-expert users via AI assistance show promise but highlight gaps in achieving expert-level exploits, referencing Google’s Project Naptime.
Future Directions and Industry Gaps
The researchers advocate integrating security lessons into AI safety, emphasizing automation and open-source collaboration. Alessandro notes the psychological toll of red teaming, handling extreme content like nerve gas research. They call for more security experts to join AI safety efforts, addressing gaps in testing emergent risks.
Their work, supported by CyberSecEvals, sets a foundation for safer AI, urging the community to explore novel vulnerabilities.
Links:
[PyData Global 2024] Making Gaussian Processes Useful
Bill Engels and Chris Fonnesbeck, both brilliant software developers from PyMC Labs, delivered an insightful 90-minute tutorial at PyData Global 2024 titled “Making Gaussian Processes Useful.” Aimed at demystifying Gaussian processes (GPs) for practicing data scientists, their session bridged the gap between theoretical complexity and practical application. Using baseball analytics as a motivating example, Chris introduced Bayesian modeling and GPs, while Bill provided hands-on strategies for overcoming computational and identifiability challenges. This post explores their comprehensive approach, offering actionable insights for leveraging GPs in real-world scenarios.
Bayesian Inference and Probabilistic Programming
Chris kicked off the tutorial by grounding the audience in Bayesian inference, often implemented through probabilistic programming. He described it as writing software with partially random outputs, enabled by languages like PyMC that provide primitives for random variables. Unlike deterministic programming, probabilistic programming allows modeling distributions over variables, including functions via GPs. Chris explained that Bayesian inference involves specifying a joint probability model for data and parameters, using Bayes’ formula to derive the posterior distribution. This posterior reflects what we learn about unknown parameters after observing data, with the likelihood and priors as key components. The computational challenge lies in the normalizing constant, a multidimensional integral that probabilistic programming libraries handle numerically, freeing data scientists to focus on model specification.
Hierarchical Modeling with Baseball Data
To illustrate Bayesian modeling, Chris used the example of estimating home run probabilities for baseball players. He introduced a simple unpooled model where each player’s home run rate is modeled with a beta prior and a binomial likelihood, reflecting hits over plate appearances. Using PyMC, this model is straightforward to implement, with each line of code corresponding to a mathematical component. However, Chris highlighted its limitations: players with few at-bats yield highly uncertain estimates, leaning heavily on the flat prior. This led to the introduction of hierarchical modeling, or partial pooling, where individual home run rates are drawn from a population distribution with hyperparameters (mean and standard deviation). This approach shrinks extreme estimates, producing more realistic rates, as seen when comparing unpooled estimates (with outliers up to 80%) to pooled ones (clustered below 10%, aligning with real-world data like Barry Bonds’ 15% peak).
Gaussian Processes as a Hierarchical Extension
Chris transitioned to GPs, framing them as a generalization of hierarchical models for continuous predictors, such as player age affecting home run rates. Unlike categorical groups, GPs model relationships where similarity decreases with distance (e.g., younger players’ performance is more similar). A GP is a distribution over functions, parameterized by a mean function (often zero) and a covariance function, which defines how outputs covary based on input proximity. Chris emphasized two key properties of multivariate Gaussians—easy marginalization and conditioning—that make GPs computationally tractable despite their infinite dimensionality. By evaluating a covariance function at specific inputs, a GP yields a finite multivariate normal, enabling flexible, nonlinear modeling without explicitly parameterizing the function’s form.
Computational Challenges and the HSGP Approximation
One of the biggest hurdles with GPs is their computational cost, particularly for latent GPs used with non-Gaussian data like binomial home run counts. Chris explained that the posterior covariance function requires inverting a matrix, which scales cubically with the number of data points (e.g., thousands of players). This makes exact GPs infeasible for large datasets. To address this, he introduced the Hilbert Space Gaussian Process (HSGP) approximation, which reduces cubic compute time to linear by approximating the GP with a finite set of basis functions. These functions depend on the data, while coefficients rely on hyperparameters like length scale and amplitude. Chris demonstrated implementing an HSGP in PyMC to model age effects, specifying 100 basis functions and a boundary three times the data range, resulting in a model that ran in minutes rather than years.
Practical Debugging with GPs
Bill took over to provide practical tips for fitting GPs, emphasizing their sensitivity to priors and the need for debugging. He revisited the baseball example, modeling batting averages with a hierarchical model before introducing a GP to account for age effects. Bill showed that a standard hierarchical model treats players as exchangeable, pooling information equally across all players. A GP, however, allows local pooling, where players of similar ages inform each other more strongly. He introduced the exponentiated quadratic covariance function, which uses a length scale to define “closeness” in age and a scale parameter for effect size. Bill highlighted common pitfalls, such as small length scales reducing a GP to a standard hierarchical model or large length scales causing identifiability issues with intercepts, and provided solutions like informative priors (e.g., inverse gamma, log-normal) to constrain length scales to realistic ranges.
Advanced GP Modeling for Slugging Percentage
Bill concluded with a sophisticated model for slugging percentage, a metric reflecting hitting power, using 10 years of baseball data. The model included player, park, and season effects, with an HSGP to capture age effects. He initially used an exponentiated quadratic covariance function but encountered sampling issues (divergences), a common problem with GPs. Bill fixed this by switching to a Matern 5/2 covariance function, which assumes less smoothness and better suits real-world data, and adopting a centered parameterization for stronger age effects. These changes reduced divergences to near zero, producing a reliable model. The resulting age curve peaked at 26, aligning with baseball wisdom, and showed a decline for older players, demonstrating the GP’s ability to capture nonlinear trends.
Key Takeaways and Resources
Bill and Chris emphasized that GPs extend hierarchical models by enabling local pooling over continuous variables, but their computational and identifiability challenges require careful handling. Informative priors, appropriate covariance functions (e.g., Matern over exponential quadratic), and approximations like HSGP are critical for practical use. They encouraged using PyMC for its high-level interface and the Nutpie sampler for efficiency, while noting alternatives like GPFlow for specialized needs. Their GitHub repository, linked below, includes slides and notebooks for further exploration, making this tutorial a valuable resource for data scientists aiming to apply GPs effectively.
Links:
- Bill Engels’ LinkedIn
- Chris Fonnesbeck’s LinkedIn
- PyMC Labs
- PyMC
- GitHub Repository
- PyData Global 2024
- NumFOCUS
[DefCon32] Securing CCTV Cameras Against Blind Spots
As CCTV systems underpin public safety, their vulnerabilities threaten to undermine trust. Jacob Shams, a security researcher, exposes a critical flaw in object detection: location-based confidence weaknesses, or “blind spots.” His analysis across diverse locations—Broadway, Shibuya Crossing, and Castro Street—reveals how pedestrian positioning impacts detection accuracy, enabling malicious actors to evade surveillance. Jacob’s novel attack, TipToe, exploits these gaps to craft low-confidence paths, reducing detection rates significantly.
Jacob’s research spans five object detectors, including YOLOv3 and Faster R-CNN, under varied lighting conditions. By mapping confidence levels to position, angle, and distance, he identifies areas where detection falters. TipToe leverages these findings, offering a strategic evasion tool with implications for urban security and beyond.
The study underscores the need for robust CCTV configurations, urging developers to address positional biases in detection algorithms to safeguard critical infrastructure.
Understanding Blind Spots
Jacob’s experiments reveal that pedestrian position—distance, angle, height—affects detector confidence by up to 0.7. Heatmaps from lab and real-world footage, including Shibuya Crossing, highlight areas of low confidence, persisting across YOLOv3, SSD, and others. These blind spots, independent of video quality or lighting, create exploitable gaps.
For instance, at Shibuya, TipToe reduces average path confidence by 0.16, enabling stealthy movement. This phenomenon, consistent across locations, exposes systemic flaws in current detection models.
The TipToe Evasion Attack
TipToe constructs minimum-confidence paths through CCTV scenes, leveraging positional data to minimize detection. Jacob demonstrates its efficacy, achieving significant confidence reductions in public footage. Unlike invasive methods like laser interference, TipToe requires no suspicious equipment, relying solely on strategic positioning.
This attack highlights the ease of exploiting blind spots, urging integrators to reassess camera placement and algorithm tuning.
Mitigating Detection Weaknesses
Jacob proposes recalibrating object detectors to account for positional variances, enhancing confidence in weak areas. Multi-angle camera setups and advanced models could further reduce blind spots. His open-source tools encourage community validation, fostering improvements in surveillance security.
The research calls for a paradigm shift in CCTV design, prioritizing resilience against evasion tactics to protect public spaces.
[DefCon32] Smishing Smackdown: Unraveling the Threads of USPS Smishing and Fighting Back
In an era where digital scams proliferate, SMS phishing, or smishing, has surged, exploiting trust in institutions like the United States Postal Service (USPS). S1nn3r, a red team operator and founder of Phantom Security Group, recounts her journey tackling the “Smishing Triad,” a sophisticated operation distributing scam kits. Motivated by personal encounters with these fraudulent texts, S1nn3r’s investigation uncovers vulnerabilities in the kits, enabling access to their admin panels and exposing over 390,000 stolen credit card details across 900 domains.
S1nn3r’s expertise in web application testing, honed through bug bounties, drives her to reverse-engineer these kits. Collaborating with peers, she identifies two critical flaws, granting entry to administrative interfaces. This access reveals not only victim data but also scammer details like login IPs and passwords. Her findings, shared with banks and the USPS Inspector’s Office, aid in protecting nearly 880,000 victims, highlighting the power of proactive cybersecurity.
The talk illuminates the technical ingenuity behind smishing campaigns and offers strategies to combat them, emphasizing client-side filtering to thwart future attacks.
Anatomy of the Smishing Triad
S1nn3r begins by dissecting the USPS smishing campaign, which spiked during the holiday season. These messages, mimicking USPS alerts, lure users to fraudulent sites via links. The Smishing Triad’s kit, a scalable tool sold to scammers, automates these attacks, capturing credentials and financial data.
Through meticulous analysis, S1nn3r uncovers the kit’s structure, leveraging web vulnerabilities to infiltrate admin panels. This access exposes databases containing victim information, revealing the campaign’s vast reach.
Exploiting Kit Vulnerabilities
The investigation reveals two pivotal weaknesses: insecure authentication and misconfigured APIs. By exploiting these, S1nn3r gains administrative control, extracting data from over 40 panels. This includes scammer metadata, such as IPs and cracked passwords, offering insights into their operations.
Her collaboration with a Wired journalist and law enforcement underscores the real-world impact, linking stolen credit cards to specific scams. This evidence strengthens investigations, despite challenges in victim identification.
Countermeasures and Future Defenses
S1nn3r advocates enhanced client-side filtering, suggesting AI-driven solutions to detect suspicious texts. Third-party integrations, like Truecaller, offer practical defenses by flagging non-official USPS links. She cautions against man-in-the-middle attacks on SMS, emphasizing scalable, user-friendly protections.
Her work, shared via open-source tools, invites further research to dismantle smishing ecosystems, urging collective action against evolving scams.
Links:
[Scala IO Paris 2024] Escaping the False Dichotomy: Sanely Automatic Derivation in Scala
In the ScalaIO Paris 2024 session “Slow Auto, Inconvenient Semi: Escaping False Dichotomy with Sanely Automatic Derivation,” Mateusz Kubuszok delivered a user-focused exploration of typeclass derivation in Scala. With over nine years of Scala experience and as a co-maintainer of the Chimney library, Mateusz examined the trade-offs between automatic and semi-automatic derivation, proposing a “sanely automatic” approach that balances usability, compile-time performance, and runtime efficiency. Using JSON serialization libraries like Circe and Jsoniter-Scala as case studies, the talk highlighted how library design choices impact users and offered a practical solution to common derivation pain points, supported by benchmarks and a public repository.
Understanding Typeclasses and Derivation
Mateusz began by demystifying typeclasses, describing them as parameterized interfaces (e.g., an Encoder[T] for JSON serialization) whose implementations are provided by the compiler via implicits or givens. Typeclass derivation automates creating these implementations for complex types like case classes or sealed traits by combining implementations for their fields or subtypes. For example, encoding a User(name: String, address: Address) requires encoders for String and Address, which the compiler recursively resolves.
Derivation comes in two flavors: automatic and semi-automatic. Automatic derivation, popularized by Circe, uses implicits to generate implementations on-demand, but can lead to slow compilation and runtime performance issues. Semi-automatic derivation requires explicit calls (e.g., deriveEncoder[Address]) to define implicits, ensuring consistency but adding manual overhead. Mateusz emphasized that these choices, made by library authors, significantly affect users through compilation times, error messages, and performance.
The Pain Points of Automatic and Semi-Automatic Derivation
Automatic derivation in Circe recursively generates encoders for nested types, checking for existing implicits before falling back to derivation. This can cause circular dependencies or stack overflows if not managed carefully. Semi-automatic derivation avoids this by always generating new instances, but requires users to define implicits for every intermediate type, increasing code verbosity. Mateusz shared anecdotes of developers banning automatic derivation due to compilation times ballooning to 10 minutes for complex JSON hierarchies.
Benchmarks on a nested case class (five levels deep) revealed stark differences. On Scala 2.13, Circe’s automatic derivation took 14 seconds to compile a single file, versus 12 seconds for semi-automatic. On Scala 3, automatic derivation soared to 46 seconds (cold JVM) or 16 seconds (warm), while semi-automatic took 10 seconds or 1 second, respectively. Runtime performance also suffered: automatic derivation on Scala 3 was up to 10 times slower than semi-automatic, likely due to large inlined methods overwhelming JVM optimization.
Comparing Libraries: Circe vs. Jsoniter-Scala
Mateusz contrasted Circe with Jsoniter-Scala, which prioritizes performance. Jsoniter-Scala uses a single macro to generate recursive codec implementations, avoiding intermediate implicits except for custom overrides. This reduces memory allocation and compilation overhead. Benchmarks showed Jsoniter-Scala compiling faster than Circe (e.g., 2–3 times faster on Scala 3) and running three times faster, even when Circe was given a head start by testing on JSON representations rather than strings.
Jsoniter-Scala’s approach minimizes implicit searches, embedding logic in macros instead of relying on the compiler’s typechecker. For example, encoding a User with an Address field involves one codec handling all nested types, unlike Circe’s recursive implicit resolution. This results in fewer allocations and better error messages, as macros can pinpoint failure causes (e.g., a missing implicit for a specific field).
Sanely Automatic Derivation: A New Approach
Inspired by Jsoniter-Scala, Mateusz proposed “sanely automatic derivation” to combine automatic derivation’s convenience with semi-automatic’s performance. Using his Chimney library as a testbed, he split typeclasses into two traits: one for user-facing APIs and another for automatic derivation, invisible to implicit searches to avoid circular dependencies. This allows recursive derivation with minimal implicits, using macros to handle nested types efficiently.
Mateusz implemented this for a Jsoniter-Scala wrapper on Scala 3, achieving compilation times comparable to Jsoniter-Scala’s single-implicit approach and faster than Circe’s semi-automatic derivation. Runtime performance matched Jsoniter-Scala’s, with negligible overhead. Error messages were improved by logging macro actions (e.g., which field caused a failure) via Scala’s macro settings, viewable in IDEs like VS Code without console output.
A Fair Comparison: Custom Typeclass Benchmark
To ensure fairness, Mateusz created a custom Show typeclass (similar to Circe’s ShowPretty) for pretty-printing case classes using StringBuilder. He implemented it with Shapeless (Scala 2), Mirrors (Scala 3), Magnolia (both), and his sanely automatic approach. Initial results showed his approach outperforming Shapeless and Mirrors but trailing Magnolia’s semi-automatic derivation. By adding caching within macros (reusing derived implementations for repeated types), his approach became the fastest across all platforms, compiling in less time than Shapeless, Mirrors, or Magnolia, with better runtime performance.
This caching, inspired by Jsoniter-Scala, avoids re-deriving the same type multiple times within a macro, reducing method size and enabling JVM optimization. The change required minimal code, demonstrating that library authors can adopt this approach with a single, non-invasive pull request.
Implications for Scala’s Future
Mateusz concluded by addressing Scala’s reputation for slow compilation, citing a Virtus Lab survey where 53% of developers complained about compile times, often tied to typeclass derivation. Libraries like Shapeless and Magnolia prioritize developer convenience over user experience, leading to opaque errors and performance issues. His sanely automatic derivation offers a user-friendly alternative: one import, fast compilation, efficient runtime, and debuggable errors.
By sharing his Chimney Macro Commons library, Mateusz encourages library authors to rethink derivation strategies. While macros require more maintenance than Shapeless or Magnolia, they become viable as libraries scale and prioritize user needs. He urged developers to provide feedback to library maintainers, challenging assumptions that automatic and semi-automatic are the only options, to make Scala more accessible and production-ready.
Links:
- ScalaIO Paris 2024 Session Page
- Benchmark Repository
- Chimney GitHub
- @MateuszKubuszok on Twitter/X
- Mateusz on LinkedIn
- Mateusz on GitHub
Hashtags: #Scala #TypeclassDerivation #ScalaIOParis2024 #Circe #JsoniterScala #Chimney #Performance #Macros #Scala3