Smashing the Stack for Fun and Profit (1996)
phrack.org
phrack.org
Here's a few I'm aware of:
Rafale - https://www.rafale.org
I think one big change these days is just that more people will self-publish their writeups and research. There are also a lot more security conferences that people present at some with a more narrow focus than the well known conferences too leading to more specialty content.
I do a weekly podcast[0] talking just about the latest exploits and strategies/research from the last week and pulling content for that is basically just following a ton of RSS feeds. There is a lot more getting written these days compared with the years when Phrack was regularly released. Unfortunately its also more spread out and harder to find.
Great way to spend my teenage years, and a great foundation to have while programming in any language. :)
Phrack is standard required reading
Those games were very rewarding for a high schooler on the early internet.
Books like that should be required reading when learning C. It shows you so much that the typical book won't cover.
This was an interesting excercise because there were NO logs of this happening on the Cisco ASA, not even when ramping every loglevel to debug. Well only on the console port. Exception in readline() or something like it. Doing stuff for security monitoring in daily life this ehm was alarming, but not unexpected. Fixing “No logs” is often a challenge for blue teams.
Anyway it was alarming enough to find and read through the Common Criteria EAL4+ certification docs for the Cisco ASA only to find that SNMP was excluded from certification scope. I still have the idea in the back of my head to explore scope exclusions in other certification docs for other unfortunate exclusions.
Also the lack of mitigations like stack canaries, ASLR or others was quite surprising for a certified black box security device on the network perimeter.
It isn't like the CC folks aren't aware of the problem. The idea was that the Security Target (definition of the system) could declare conformance to a standardized Protection Profile which consumers could use as a shortcut to understanding what was promised.
However, nobody looks at STs nor PPs except the vendor and the certifier, so all that work is for naught. You could absolutely get a CC cert with the environment that it is unplugged from a network.
Beyond getting slower updates, etc, FIPS mode has the unintentional side effect of being the "look at me I have interesting stuff" flag for potential attackers. It is usually quite easy to determine remotely that a networked device is in FIPS mode, too (due to allowed crypto protocols, etc).
I thought there were others but maybe not? Single-comment threads from 2016, 2014, 2012, 2011:
https://news.ycombinator.com/item?id=11007757
https://news.ycombinator.com/item?id=10821934
https://news.ycombinator.com/item?id=8773298
I wonder if anyone's ever automated it.
Phrack has you covered, eg: from 2001:
The advanced return-into-lib(c) exploits: PaX case study by Nergal <nergal@owl.openwall.com>
http://phrack.org/issues/58/4.html#article
Think I actually looked at this and an (at the time) recent 0day for opensshd that was found and written up by a couple of Finnish students - as a motivational presentation for PaX and/or grsecurity while at university.
However the stack protection will probably require a separate information leak (to find the canary value) or arbitrary write (to overwrite it) to bypass. Unless the attacker is fortunate to find an unprotected function which the compiler missed, or a value that can be overwritten which changes the control flow and isn't protected by the canary.
ASLR is also a decent mitigation against ROP, and requires an information leak so the exploit code can calculate the memory offset to find the library gadgets.
In short, ROP isn't the solution to all the mitigations the parent posted; in fact ASLR is designed to make ROP harder to exploit.
Every instance of the bytes C3, CB, C2 or CA in the executable page could potentially be abused, via carefully-chosen instruction alignment.
https://steve.fi/security/exploits/
These days these things are less useful, but recreating known-exploits is still educational. Once you get buffer-overflows handled you can look for more exotic things, format-string attacks, and similar.
http://web.archive.org/web/20190325214351/https://debian-adm...
Without going too far side-tracked: I think the Arch wiki has demonstrated that a community wiki can be very useful - I do hope people continue to contribute to the Debian wiki (although I find myself mostly on Ubuntu of late).
Anyway, there's a certain path from phrack through debian-administration.org that maps out where I find myself today, so happy coincidence to see the two line up in the threads.
I think it must have been in university, unfortunately when I look up the course number, the resources seem to be (understandably, I suppose) date gated.
Actually, I take that back: it is also the tools' fault. GCC should just refuse to compile any reference to strcpy().
It describes new kinds of metadata leakage attacks that can be launched against privacy coins, by adversaries with large budgets, such as professional criminal organizations, blockchain analysis companies and nation states. The privacy coin HUSH has developed this defensive technology and was first to implement it in September 2019.
There is a YouTube video where the author explains why he named the paper this way, this link has the timestamp where it's talked about: https://youtu.be/berM7Dnnoz4?t=405
"This is a whole new research field I am creating, that is why I called it Attacking Zcash Protocol For Fun And Profit, just like Smashing The Stack for Fun And Profit, it created a whole new field"
Also, for the hardcore HN nerds: The paper focuses on Zcash Protocol, but the ideas apply to any cryptocoin with a transaction graph, so Monero is definitely vulnerable. Much more vulnerable that Zcash Protocol.
There are very few unique source codebases which implement privacy coins, maybe a half dozen depending on how lenient you are (i.e. is DASH a privacy coin? Barely, but it could be considered one. Blockchain analysis companies make fun of the "privacy" of DASH.)
I believe when he says "inventing a whole new field" he means inventing a whole new field of attacks and defenses, just like the Phrack paper invented a whole new industry of attacks and then their defenses.
Taking these new kinds of attacks into account, all existing privacy coins are vulnerable. Monero is more vulnerable than Zcash Protocol, since it does not have Zero Knowledge Math. It uses Group Theory, which leaks metadata like crazy.
What I am trying to get at is, what value does Hush have in the real world? It's a privacy coin cool, but how can it be adopted/used by institutions etc. And if the tech is so great why is no one using it right now?
[0] https://en.m.wikipedia.org/wiki/Buffer_overflow (See buffer overflow protection)
> The Smash the Stack Wargaming Network hosts several Wargames. A Wargame in our context can be described as an ethical hacking environment that supports the simulation of real world software vulnerability theories or concepts and allows for the legal execution of exploitation techniques. Software can be an Operating System, network protocol, or any userland application.
If the Morris worm used them in 88, how did the technique get lost until this phrack article come out?
Makes me wonder if there are still entire classes of exploits that are undiscovered out there.
https://news.ycombinator.com/item?id=6656303
Since then, I've talked to some people I trust who say they were exploiting overflows prior to 1995 (by like a year or so), so it was in the air before then, but I haven't seen much evidence that anything like a full-fledged stack overflow had been exploited in the 5 years between '88 and '95.
(Also: Neil Woods tweeted the 8lgm syslog shellcode, which was pretty rad: https://twitter.com/tqbf/status/1332579786682724354).
Know thy stack!
Yes, you still have a .text section!
This one ages extremely well.