r/netsec

As per WABT's SECURITY.txt, #2831 issue exists

For context:

WABT is a Binary Toolkit for WebAssembly developed by WebAssembly.org (W3C)

wasm2c is a tool inside of it, which is used by many projects like FireFox (via RLBox) to compile wasm down to a sandboxed c library, the assumption is the built C code preserves all WebAssembly's sandbox security features.

This PoC demonstrates escaping that sandbox.

The DOJ unsealed a 14-count superseding indictment last week (US v. Rafatnejad, S2 18 Cr. 94, SDNY) adding 8 defendants to the original 2018 case and extending the documented timeline to at least March 2022. The headline numbers (31.5 TB, 144 US universities, $3.4B in licensing value) got the coverage. The operational detail in the document itself is worth a closer look.

Three-phase university attack model

Phase 1: open-source reconnaissance on individual professors. Publications, research interests, co-authors, institutional network. The goal was a convincing impersonation before any contact.

Phase 2: spearphishing email appearing to come from a professor at a peer institution, referencing the target's actual recent publications and offering links to related papers. Clicking resolved to a typosquatted domain (single character off the legitimate university URL, or an alternate TLD) hosting a cloned login page for that specific institution. Credentials logged.

Phase 3: using stolen credentials to log into victim accounts and exfiltrate everything accessible: journals, dissertations, monographs, raw data. In many cases, automated forwarding rules were set on the compromised account, silently copying all subsequent incoming and outgoing mail to attacker-controlled servers. Persistent access even after a password reset.

Private sector targets got a different approach: password spraying against employee email lists compiled via OSINT. Lower sophistication, higher volume. Same forwarding rule technique on success. Full mailbox exfiltration.

The commercial layer is what makes this operationally unusual. The stolen academic access was not only delivered to the IRGC. Two websites, Megapaper.ir and Gigapaper.ir, resold it inside Iran. Megapaper sold individual articles to Iranian public universities on invoice. Gigapaper offered subscriptions: customers received persistent access to a compromised Western professor's library account for direct browsing. Iranian universities were confirmed paying customers. State-sponsored IP theft with a working B2B revenue model built on top of it.

Two of the defendants were simultaneously FATA members (Iran's internal cyber police) and Mabna contractors. One had also developed a website for the Supreme Leader's office. The overlap between the domestic surveillance apparatus and foreign offensive operations is documented explicitly in the indictment.

An operator left their full working directory exposed on an open HTTP server. Hunt.io crawled it, 2,616 files, and rebuilt the campaign from the corpus.

• Three exploitation paths in parallel: an asyncio credential brute-forcer, a CVE-2021-33044/33045 auth-bypass chain, and P2P relay abuse reaching cameras by serial number
• The relay path never authenticates the connecting party, only the session, via a cloud-issued token obtainable with the fixed SDK credentials in every Dahua client
• Two CVE labels in the tooling don't hold up: CVE-2024-39943 is an unrelated Rejetto HFS flaw, and CVE-2025-31702 is a narrower post-auth case, not the unauthenticated relay abuse (that path is a separate non-CVE issue documented by ITRES)
• Full PTCP tunnel breakdown, including the Inverted STUN packet and the bind-to-127.0.0.1 technique

Neutral attribution throughout, the corpus shows how the operation was built and run, not who ran it.

Check the full breakdown, IOCs and mitigation strategies:
https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised

I finally found some time to organize my notes on secure boot, remote attestation, measured boot and in general embedded security.

This is not ground breaking zero-day research but I figured some of you might like a good story. Good here is obviously subjective but I felt like it came out quite readable.

This blog builds heavily on public research so as already stated at the end of article if you liked some particular section, show the respective person some love :)

P.S.: yes I know the image is AI generated please don’t give me shit for that

A depth-8 ftrace analysis of how the Linux kernel processes ICMP Timestamp (Type 13/14) requests — covering the full call chain, payload validation, conntrack behavior, and ts_ori echo mechanics.
————————

Most security tooling treats ICMP as a monolith: ping works, or it doesn’t. ICMP Timestamp (Type 13/14) sits in that overlooked middle ground — defined in RFC 792, implemented in every Linux kernel, but rarely scrutinized at the source level.
This post documents a depth-8 ftrace investigation of icmp_timestamp() on Linux kernel 6.17.13. Beyond cataloguing individual findings, the goal is to map the architectural reality of how the kernel processes ICMP Timestamp requests — every code path, every decision point, every place where the implementation diverges from what RFC 792 specifies.
What emerged was a set of concrete, reproducible behaviors: a silent payload threshold, a Code field that is never read, ts_ori that is echoed without any range check, and a netfilter pipeline that creates a conntrack entry for every single exchange.

Author here. I audited NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Airflow and disclosed 14 findings. Every platform inherited the same assumption anyone who can touch a workflow is trusted to run code on the host, which is fine for a dev tool on your laptop but not fine for a multi-tenant HTTP service with an unauthenticated webhook. The chain I'd point people to first is the Flowise one (section 2.2): an unauthenticated request → prompt injection → LLM emits Python → a 38-pattern regex blocklist passes it because the dangerous library was pre-imported before the model was asked anything → RCE.

Two vendors closed their reports as working-as-intended, and I tried to represent their position fairly.

This research was also presented at DEFCON 34 but now available publicly.

Happy to answer questions.

Full whitepaper is available here: https://www.endorlabs.com/learn/how-ai-orchestration-platforms-ship-rce-by-design

I registered an expired DMARC reporting domain (gca-emailauth[.]org) for $10. It had been published as the aggregate-reporting address in Global Cyber Alliance DMARC training docs going back to a 2019 bootcamp, and at some point it lapsed.

Shortly after registration, aggregate DMARC reports for 86 domains across 20+ organizations started arriving.

56 belonged to The Toro Company (NYSE-listed), including myturf[.]com, their distributor platform, which sits at p=none. The rest - University of Wisconsin–Stevens Point (14 subdomains), the North Carolina School of Science and Mathematics, Ennis ISD (Texas), Great Prairie AEA (an Iowa education agency serving 35,000 students), two county governments, and several commercial domains.

For most of these it was a second rua address sitting behind a working commercial processor (Proofpoint, in Toro's case). Reports still arrived at the primary.

GCA's engineers later traced it to a former partner who'd held the domain and let it lapse - the dependency was never written down.

As of my last sweep, 65 of the 86 still publish the endpoint. We disclosed to everyone whose reports we were receiving; only 21 domains stopped publishing the endpoint, and almost nobody replied.

After 8 months of owning the domain, we coordinated a transfer back to GCA.