Catching up on Phrack 62 and 63, which I had not properly read until the past few weeks. The publication continues; the technical depth continues; the trajectory of increasingly-sophisticated exploitation techniques continues.
This post is a longer-than-usual writeup because the issues are dense and the reading has been substantial. The discipline of reading Phrack carefully, which I committed to in 2000, continues to pay back disproportionately to the time invested.
Phrack 62: highlights
The issue includes about a dozen articles. Three I found particularly useful.
A piece on bypassing modern stack-protection mechanisms. Stack canaries and similar mitigations have become more prevalent in recent years; the article describes specific techniques for working around them. The techniques include: overwriting the canary with its expected value (in cases where the canary is known to the attacker), flowing control through return-into-libc to avoid touching the protected stack, and using heap-based primitives to bypass stack-specific defences.
The defensive implication is the one I have been writing about for years: no single mitigation is sufficient. The defence-in-depth posture matters more than any individual mitigation. Stack canaries help; they do not solve the problem; the cumulative defence across all available mitigations is what raises the cost of exploitation enough to deter attackers.
An article on advanced kernel-rootkit techniques. Continuing the trajectory from Phrack 60. The techniques get harder to detect; the off-host observation argument I have been making continues to strengthen.
The specific new techniques in this issue:
- Memory-only rootkits that never touch the disk. Detection requires inspecting kernel memory; cannot be done by file-integrity tools.
- Hypervisor-level rootkits (early versions; not yet operational at scale, but the technique is described). Operating-system-level inspection cannot detect them.
- Hardware-level rootkits using SMM (System Management Mode). The kernel itself cannot detect them.
The trajectory is uncomfortable. Each generation of rootkit defeats the detection methods of the previous generation. The defensive answer continues to be off-host inspection from progressively-lower levels (kernel from outside the OS; OS from outside the host; host from outside the hardware). The infrastructure for this kind of inspection is years away from operational deployment.
A practitioner's piece on automating exploit development. The article describes tools and workflows for going from a vulnerability disclosure to a working exploit faster. The motivation is offensive — reducing the time between advisory and exploit code — but the defensive implications are substantial. If exploit development gets faster, the patch-to-exploit gap that operators rely on for safe patching shrinks further.
The specific defensive implication: patching needs to be even faster than it is today. The operators who patch within days of advisory remain safe; the operators who patch within weeks may not.
Phrack 63: highlights
More recent issue. Two articles particularly worth writing about.
A piece on web-application vulnerability classes. The article systematises the categories of web-application vulnerability: injection (SQL, command, LDAP), authentication failures, session-management issues, cross-site scripting, cross-site request forgery, insecure direct object references, security misconfiguration, sensitive data exposure, missing function-level access control, redirects-and-forwards problems.
The systematisation is useful because the web-application threat model is now substantially distinct from the network-protocol threat model that earlier security work focused on. The categories are different; the defensive disciplines are different; the tools are different.
For my own work: I am thinking about whether to write a focused post on web-application security that maps to my HTTP-authentication mistakes post from 2000 but with several years of additional knowledge. The post is overdue.
A long article on covert channels in network protocols. Covert channels — ways of transmitting information through protocol features that are not intended for that purpose — have been a research topic for decades. This article focuses on practical covert channels in widely-deployed protocols.
The specific channels described:
- Timing channels in TCP (modulating inter-packet intervals to encode bits).
- Field-reuse channels (using fields like IP-ID for non-standard purposes).
- Protocol-extension channels (using IPv6 extension headers).
- Application-layer channels (encoding bits in HTTP headers, in DNS query patterns, etc).
The defensive implication: data exfiltration from compromised hosts can use channels that traditional network monitoring does not see. An attacker who has compromised an internal host can exfiltrate data over channels that look like legitimate traffic to standard inspection.
This is a category that I have been under-writing about. Most defensive monitoring focuses on volume-and-pattern detection; covert channels can defeat both. The detection requires more sophisticated traffic analysis than typical.
For my own infrastructure: I have not deployed any sophisticated covert-channel detection. The cost-benefit, for my modest scale, has not yet justified it. For larger deployments where data exfiltration is a real concern, the investment may be worth considering.
What this teaches
Three generalisations.
The trajectory of exploitation sophistication continues. Each year's Phrack issues describe techniques more sophisticated than the previous year's. The defensive infrastructure improves; the offensive techniques improve faster.
The detection problem is structural. As exploitation techniques get more sophisticated, the detection requirements get harder. Off-host observation, behavioural detection, sophisticated traffic analysis — all are necessary; all are harder to deploy than the simpler signature-based approaches that dominated earlier years.
The defensive community needs to keep reading. The gap between attacker tradecraft and defender awareness widens whenever defenders stop reading. The discipline of reading Phrack and similar publications is not optional for serious operators.
What I am doing
For my own work: continue the reading discipline. Phrack issues are infrequent enough that the cumulative time investment is bounded; the value is substantial.
For my own infrastructure: I have updated my Snort sensor configuration to include rules for some of the specific exploitation patterns described in the Phrack articles. The rules will produce occasional false positives; the alternative (missing the patterns) is worse.
For my structured-log analysis: I am thinking about whether to add covert-channel detection. The implementation is non-trivial; the value depends on threat profile. For now, the answer is to continue the structured-log discipline and revisit when threat profile justifies the investment.
A reflection on adversarial publication
Phrack continues to publish high-quality offensive technical content. The work is, on balance, beneficial to the field — the defensive community reads it and adjusts; the offensive community uses it and adjusts. The asymmetry is partial; both sides benefit from the publication.
The alternative — restricting the publication — would benefit attackers more than defenders, because the offensive community has private channels for sharing techniques while the defensive community largely depends on public channels.
For anyone who finds this argument uncomfortable: I understand. The publication of exploitation techniques does enable specific attacks. The publication is also necessary for the defensive community to understand the threat landscape. The trade-off is real; my own assessment is that publication produces net benefit, but I respect the disagreement.
For my own writing: I will continue to engage with the publication. Reading it carefully, writing about what it teaches, applying the defensive implications to my own infrastructure. The discipline continues.
Specific techniques I want to track over the next year
Three.
Hypervisor-level rootkits. Currently described in research; not yet in widespread operational use. I expect this to change over the next 1-2 years. The defensive implications are substantial.
Web-application vulnerability tooling. The systematisation in Phrack 63 will produce better automated tooling for finding web-application vulnerabilities. The tooling will benefit both attackers (faster discovery) and defenders (faster auditing). The arms race continues.
Covert-channel exploitation. The techniques are described; the operational deployment is uneven. I expect specific incidents involving covert-channel exfiltration to emerge over the next 2-3 years.
More as the year develops.
A closing observation
The Phrack reading discipline has been one of the highest-leverage activities of my professional life. Two issues per year; substantial time per issue; cumulative knowledge that compounds.
For anyone in the field who has not been reading Phrack regularly: the catch-up is worth it. The archive is available online. A few hours per quarter, sustained over years, produces understanding that no other channel provides at similar density.
More in time.
A longer treatment of the Phrack reading discipline
Let me extend this issue-summary post with a more substantial reflection on Phrack as a publication and on the discipline of reading it carefully.
What Phrack does that nothing else does
Phrack publishes substantive technical content from working practitioners, with no commercial filter and minimal editorial constraint. The closest analogues — academic security conferences, vendor research blogs, security podcasts — all have constraints that Phrack does not have.
Academic conferences: peer review, formal publication standards, theoretical framing. Phrack: practical detail, working code, operational specifics.
Vendor research: commercial alignment, brand-protection considerations, sales motivations. Phrack: independent perspectives, willingness to criticise specific vendors, no commercial alignment.
Security podcasts: conversational format, broader audience, less technical depth. Phrack: written depth, specialist audience, high technical density.
The combination — practical, independent, deep — is rare. Phrack is essentially the only publication operating in this space at this level.
What this enables for readers
The specific value of reading Phrack carefully:
Direct access to attacker tradecraft. The articles describe specific techniques, with sufficient detail that the reader can understand exactly what is happening. Not summaries-of-summaries; actual technique descriptions.
Understanding of the offensive trajectory. Each issue's articles, taken together, indicate where the offensive community's attention is. Reading several issues over years gives a good picture of how the field is evolving.
Cross-pollination from offensive to defensive. The defensive community can use Phrack articles to inform their own work — both reactive (defending against the techniques described) and proactive (anticipating where the next techniques will go).
Calibration on what is realistic. Reading actual technical detail produces better calibration than reading summaries. Specific attack techniques become concrete; the gap between what is theoretically possible and what is operationally happening becomes visible.
The criticism, addressed
The defensive community has historically had some discomfort with Phrack's open publication of offensive techniques. The criticism: publication of attack tradecraft enables more attacks.
My own assessment, after years of reading: the criticism is partially correct but overstated.
Partially correct: specific attacks do follow specific Phrack articles. The publication does enable some attacks that would not have happened otherwise.
Overstated: the offensive community has private channels for sharing techniques. Restricting public publication would benefit attackers (who have private channels) more than defenders (who depend on public channels). The asymmetry favours publication.
The question is one of magnitude. The marginal increase in attacks from publication appears to be smaller than the marginal increase in defensive understanding from publication. The trade-off favours publication.
This is consistent with the broader open-disclosure norm in the security community. Specific cases vary; the general principle holds.
What other publications I read regularly
For context, the regular reading I do beyond Phrack:
Bugtraq. Daily reading; been doing it since 1998. The volume is high but the per-day attention required is bounded.
Specific vendor security advisories. Microsoft Security Bulletins, BIND advisories, OpenSSH advisories. These are operational reading rather than research reading.
The Honeynet Project's publications. Their cumulative analyses have been valuable; the trajectory continues.
Academic conference proceedings. USENIX, S&P, CCS. The papers are denser than Phrack and require more time per page; the cumulative value is real.
The occasional book. Specific books on cryptography, networking, operating systems. Books are less frequent reading than the others but produce sustained value.
The combination of these produces a fairly comprehensive view of the field. No single source is sufficient; the combination is.
The reading discipline more broadly
Reading discipline is, in my experience, the highest-leverage activity in the field. Two hours of careful reading per week produces more knowledge than ten hours of operational work alone.
The specific disciplines that have served me:
Reading source code. I started doing this in 1999; the practice has continued. Reading source produces understanding that documentation cannot match.
Reading academic papers. Slower than other reading but with longer-term value. The papers describe techniques that will be operational in 5-10 years.
Reading mailing-list archives. Specific technical mailing lists (netfilter, Snort, the various security lists) contain accumulated discussion that is valuable to read selectively.
Reading historical material. Older Phrack issues, older textbooks, older incident reports. The historical context is valuable; the current work builds on the historical work.
For anyone in the field who is not currently reading regularly: starting is worthwhile. The cumulative value compounds over years.
More in time.
A wider reflection on the reading discipline
Let me close with broader observations about technical reading and its place in professional development.
Technical reading is, in my experience, the highest-leverage activity in the field. The cumulative knowledge from years of careful reading exceeds what any operational experience alone could produce.
For anyone considering systematising their own reading: specific recommendations from years of practice.
Read source code when possible. Reading actual implementations produces deeper understanding than reading documentation. I started this discipline in 1999; the cumulative value has been substantial.
Read across disciplines. Cryptography, networking, operating systems, application security — the boundaries between sub-disciplines are artificial; cross-disciplinary reading produces better thinking.
Read older material. The historical context of current practice is itself valuable. Reading 1990s textbooks on networking, 1980s papers on cryptography, even older material on system design — all inform current work.
Read with intention to write. The discipline of writing about what you have read forces deeper engagement with the material. The notebook is one mechanism; private notes are another.
Read regularly rather than in bursts. Two hours per week of focused reading, sustained over years, produces more than ten hours per month of intensive reading interspersed with weeks of nothing.
The time investment is bounded; the cumulative value is substantial.
For anyone in the field who has been deferring this discipline: starting is worthwhile. The first year produces some immediate benefit; the cumulative value over many years is substantial in ways that are hard to predict in advance.
More in time.
A short note on specific Phrack issues to read
For anyone considering catching up on Phrack who has not read it before, a few specific recommended starting points:
Phrack 49: The Aleph One stack-overflow article. Foundational; if you only read one Phrack article ever, this is the one.
Phrack 55: The format-string vulnerability article. Establishes the technique that became central to subsequent exploitation work.
Phrack 56: The kernel-rootkit article that started serious public discussion of that category.
Phrack 58: The heap-overflow article that systematised that exploitation class.
Phrack 60: Multiple articles on advanced post-exploitation techniques.
These are the issues I would recommend a new reader prioritise. The full archive is worth working through over time; the highlighted issues produce particular insight per hour of reading.
The Phrack reading discipline pays back in proportion to depth. Skimming produces little; careful reading produces substantial knowledge. The technique is to budget specific time per article rather than treating each issue as casual reading.
For my own future reading: I will continue the discipline as long as Phrack continues to publish. The publication is now 20 years old; the specific authors change; the editorial direction varies; the cumulative archive grows. The time investment per issue is bounded; the cumulative knowledge compounds.
More as the next issue lands.