- Dailydave - mm4.emwd.com

Phase changes in international relations
by Dave Aitel 23 Aug '22

23 Aug '22

Right now, there is a, to put it mildly, ongoing discussion between proponents of coercion and deterrence in cyber policy, and adherents of a new theory, called *persistent engagement.* Maybe the sum total of the people in the argument is less than a thousand, but as academic circles go, it heavily influences the US Defense Department and IC, and through that, the rest of the world, so it is fun to watch. Also obviously it has added to infosec Twitter drama, which of course is the most important thing in the whole Universe. But while I try to keep this list technical, I wanted to put it into context for people here, so they can better appreciate the Twitter drama. But before I do that, I want to talk about a Defcon talk I attended. I'm not going to say WHICH talk, since it was under Chatham House Rule, but it was about cyber policy. When I pressed someone on an aspect of their policy efforts and how it implicated technical experts without involving their feedback (export control around penetration testing tools) they said "Well, that was more an expression of our country's VALUES and so we didn't need to listen to our technical experts". And I thought that was very interesting! Because the technical community is highly connected and paying attention to these sorts of things in a way that didn't used to be the case. If your message on one issue is going to be "When our values and the technical community's values don't align, we don't bother listening to them" then they will all know immediately, and all your other outreach efforts might as well be wasted air. And this is true across the board - disintermediation via cyber is now a universal truth. I believe you can come at the theories of persistent engagement by looking at it from a different perspective: Instead of saying "Here's a bunch of data about what we see in cyber, and it looks a certain way, and that way requires a new way of thinking" you ask yourself whether the fundamental way of dealing with conflict in international relations literature can be simplified down to coercion and deterrence when the system is a highly connected network. In other words, the game theory math you would use for dyads and bilateral relationships is great for looking at nuclear conflict because that's how the problem is presented, but doesn't scale to the problems we have for cyber conflicts, which are about emergent effects of much more complicated systems. That's why it's not just different, but downright wrong, to talk about offense-defense balances when we look at cyber or cyber-enabled conflicts. It's why the previous international relations work on deterrence and coercion just doesn't apply cleanly, if at all. On one side (the wrong side) you have people saying "Cyber is not strategic because it cannot hold ground like infantry can!" and on the other side you have people building international relations theories based on cycles of attack, on responses and counter-responses to aggression in the cyber domain because you can lead an entire country around by the nose ring that is TikTok. At some level, we are going to have to stop talking about offensive cyber operations as a corollary of SIGINT capability, and going to look more holistically at COGINT. To sum it up: Complexity in connectivity introduces phase changes in systems. We now live in a highly connected world, and this means we need new paradigms of international relations, whether you are under Chatham House Rule or not. -dave

3 2

The top of the whale
by Dave Aitel 25 Jun '22

25 Jun '22

People think that finding vulnerabilities is about finding holes in code. But at some level it's not really about that. It's about understanding that the code itself is a hole in the swirling chaos of the world and just letting a little bit of that chaos in allows you to illuminate the whole thing. Spending time in Seattle is a little bit like buying a pair of high-powered binoculars to look down the train tracks at that weird light that's heading towards you. Seattle is a city perpetually timeless and jet lagged - as far away as a giraffe's head from the country's dual beating hearts of New York City and DC. The city rests on an absolute bedrock of code. Code that feeds on lives everywhere as voraciously and implacably as a blue whale gulping krill. In that sense, the inhabitants of Seattle are those who have realized it's better to be on top of the whale than inside it. It is perhaps why all the architecture is as boxy as an early software package. If you pulled the lid of any of the buildings next to the water you might see the packaging for a Windows 95 CD ROM, or a bunch of floppies with a forgotten database. When you go running past all these horribly efficient buildings down to the water on the lone sunny day, you will be surprised with a bunch of naked people, stripping down next to an old industrial park turned into a playground, covering themselves in body paint before some eldritch streaking ritual for the parade over the hill. Around them buzz photographers immortalizing the moment. Memes infecting other memes like an endless series of smaller wasp larvae. Flying back to Miami, amongst the bridal parties and vacationers, over an endless survey of drying rivers and lakes, the ravages of unchecked climate change exposing raw pale edges the exact beige color of army pants. The whole country - a patchwork tinderbox of exposed nerves. With the right kind of eyes you can see a little bit of chaos being let in. -dave

1 0

Using microarchitecture bugs to beat authenticated pointers.
by Dave Aitel 11 Jun '22

11 Jun '22

If you've walked through the Underworld long enough, you've run into demons. Or maybe it's the other way around - by running into enough demons, you might realize you are walking through the Underworld. And by making friends with them, if you are lucky, you might realize you are a demon yourself. [image: image.png] My brother in Zeus - this is just tempting the Fates. Every so often an exploit from the Underworld is found. Maybe one or two a year is dragged screaming curses in a long-dead language out into the sunlight, pinned against a Kaspersky GReaT blogpost, and vivasected for the world. Sometimes these are simple bugs, with complex exploitation chains. Sometimes these are complex bugs, but with reliable simple exploit chains. Occasionally you see a host of bugs, all linked together like fire ants fording a stream. If you've walked through the Underworld enough you'll simply nod in recognition of them, perhaps stop to admire the artwork of the Runes carved into their skins by some unknown spellcrafter. My point is this: it doesn't matter what the real-world utility is for an exploit, because demons don't care. They operate partially in the future, perhaps. Or maybe ignoring real-world utility evolved as a sense of necessity of staying ahead of the eyes hunting for them. I'm not sure. But my rule - a core axiom of persistent engagement - is that if it can be done, it is being done already. -dave

1 0

Computer Science
by Dave Aitel 27 May '22

27 May '22

I remember when fuzzing was just sending long strings to RPC programs, and tapping the cloaca of all Unix programs, the signal handler, to see what came out. But now, to be a hacker, you have to be a scientist. Computer science is a real thing. But most computer scientists I know can't explain how to do it because it comes out sounding like a deep dive into a dungeons and dragons campaign run by toddlers. And perhaps, the hardest thing with computer science is knowing when you're stuck, when the noise inherent in your system has overwhelmed the signal, and hence, you. Really I lied. The hardest thing is knowing when someone else on your team is stuck and being able to reach into their understanding of the System and unstick them. Because science, like digestion, is a team sport. You can, if you want, undertake fun experiments. For example, you could as a hacker just say publicly what 0day you know are sitting around, waiting to be found. You can be as loud and annoying about it as possible, then just wait a few years and see if there are any cool BlackHat talks on the subject <https://www.blackhat.com/us-20/briefings/schedule/#room-for-escape-scribbli…> or not, and if the market makes any particular changes to how it deals with that technology. There will not be any. This might make you ask more questions - more uncomfortable ones. "What is an acceptable parasitic load in a system?" you might ask in this way. In the animal kingdom, it is an astonishing 40% <https://www.nationalgeographic.com/animals/article/animals-evolution-parasi….>. In computers, it is probably the same, where the science of hacking is equally ignored and reviled, both profitable and prophetless. Most hackers you know are specialized in the mystic art of Transformation. A heap overrun becomes an information leak which becomes code execution. A denial of service becomes a side channel attack becomes a local privilege escalation. Sometimes it's hard to see the science in this. A friend of yours will look down upon it as "just engineering". But it's not enough to just find one bug anymore, or even one transformation of a single bug. Every bug must pass through multiple slits at the same time now, like a lost waveform. This takes some science. My point is this: If you think you are defending against Engineers, but really you are defending against Scientists, you've already lost. And if a country wants to build and maintain offensive power in cyberspace, it has to understand how to care for and nurture the places that treat it as a science. -dave

1 0

SBOMs and Jellyfish
by Dave Aitel 22 Apr '22

22 Apr '22

The most annoying thing with talking to computer scientists about anything is they will look at any problem that remotely touches software and ask you "Is that the right data structure? Are you ... sure?" Like, this is what happens to every programming language - it's why you get NaN or an empty list for any given arbitrary code fragment in Javascript. People had a normal data structure, say a dictionary, and were like "What if we OPTIMIZED IT for all the common situations?" And so now a Dictionary is like a hybrid "Dictionary-List-Cache-Semi-Ordered-ViewMap" and it changes everything about how it operates according to some internal heuristic only some ancient and primal god of mischief could understand. So when someone asks me why, in certain cases, my program returns weird results right now, the REAL answer is, "Some computer scientist took what could have been a perfectly good data structure, and gave it performance anxiety". But project managers hate that answer. So instead they get to hear about graph databases. This brings me to two important and closely linked subjects: SBOM, and venomous jellyfish. As the mighty Halvar Flake once probably said to himself, "I can take any hideously boring problem, and turn it into a fascinating and only a bit unsolvable graph algorithm solution!" And this is where SBOMs currently live. Software is amazing, and people in cyber policy like to think of it as if it was a book or long journal article, and you can take a snapshot of it, and send it to your friend Bob with a version number 1.0 on it and Track Changes and then they send it back with a version number 1.1 or 1.0-BobEdits and that's that. But that is only what Loki, the god of lies, wants you to think. Environment is a huge part of the equation! You can go to your local pond, and get a carnivorous tadpole, an angry little hungry frog baby with a giant beak that eats other frog babies, and show it to a biologist and ask them the species, and they will tell you Spadefoot, and then find one eating plants in the corner, just a cute little guy, and the biologist will also tell you Spadefoot, and when you look at them confused they will shrug and mumble something about phenotypic plasticity which is clearly a bunch of words they made up to sound cool. It is so with software. What software are we running? Well, the description of software is rarely smaller than the software itself. It is usually much bigger. An SBOM could be described as a nested manifest of metadata about software. But if you say that to a computer scientist you found drowsing on the beach they will perk up like an evil sea otter who has spotted a bivalve and say "Wait, are you sure about that data structure? Is it truly a directed acyclic TREE structure, or is it more a ..." an awkwardly long pause will ensue as they struggle to control their emotions "...graph?" At this point you will realize you've made a mistake. If you somehow manage to escape by diverging the topic into something about eagles and Mordor, you can go on your merry way, building and selling tools that work on Trees and only Trees. You will be arboreal, but rich. And then someday someone will deliver a copy of Nature to your yacht by mistake, which by this point will be the only way to traverse most of the East coast, and you'll read about Jellyfish, or as the biologists will haughtily inform you are now called simply, "Jellies". (The less money a scientist makes, the more haughty and good looking.) But because you are a "learned person" you will read this article <https://www.nature.com/articles/news.2008.1134> about jellyfish and they will let you know about horizontal gene transference, which breaks every idea you had about how evolution worked. But it also might remind you about backporting and cherry-picking and a lot of crazy stuff that happens in the software world. So you might boat over to where that computer scientist was, and ask them maybe if they can port all your Tree-working code to Graph-working code. And then, unfortunately for you, the story gets dark. -dave

1 0

Re: GraphQL
by Jim Manico 05 Mar '22

05 Mar '22

For many years GraphQL implementations have had massive issues with access control/authorization and denial of service. This is a common problem when you are essentially give a database prompt to the client. GraphQL is better off on the back end only, IMO. At OWASP we have an older cheatsheet on this topic that gets a lot of hits. https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html If you have suggestions to make this better let me know! Regards, jim(a)manicode.com > >> On Mar 5, 2022, at 10:14 AM, Dave Aitel via Dailydave >> <dailydave(a)lists.aitelfoundation.org> wrote: >> One of the best ways to get more performance out of your networked >> system is to trust the client more. This is always a bad idea from a >> security perspective, as everyone on this list knows, but it's fun to >> see it reincarnated a thousand times in different bodies. >> >> So for example if your web application has endless structured data >> always changing and you're sick of writing REST APIs and middleware >> you start thinking - what if instead, I had a flexible Javascript API >> in the client that just grabbed data right from the database, and >> that database did the user-authorization? >> >> Anyways, GraphQL is interesting and makes the hacker in me, and >> probably all of you, hungry. In general, from a security perspective, >> "Let the user talk directly to the database, but we FILTER it a bit" >> is always a hilarious losing perspective, like trying to outswim a >> shark, or having just one more drink of Goldschlager. >> >> Any filter or translation layer starts introducing protocol >> desynchronization vulnerabilities, of course, but also you have to >> worry about timing oracles, denial of service via resource >> exhaustion, authorization mistakes, and a whole host of nightmares >> that hackers at this point can pull out of endless old Bugtraq posts >> whenever they feel like they need a conference talk at your expense. >> >> People often make the mistake of correlating "No plugin exists in >> BURP for this attack surface" with "this new technology is more >> secure than the last one!" >> >> What confuses me is when people deploy huge web applications based on >> this sort of thing you would think they would at least ask the giant, >> VC funded companies, "Which security team looked at and gave you a >> review of this tech? What if the whole thing is a bad idea?" Like in >> five years are we going to realize that you can't give users the >> ability to run arbitrary regular expressions on your extremely >> complicated database without so many checks and balances that it >> ruins the whole point of having them connect to the database in the >> first place? Yes, yes we are. >> >> On one hand, this is a sad state of affairs. On the other hand, who >> are we without it? This failure is the upwelling current that brings >> nutrients from the ocean floor to our arctic habitat. This is the >> solar wind of quantum bits we float from planet to planet on. This is >> the brief touch of a child's hand on the belly of the Buddha. This is >> truth in the way that we know it. >> >> -dave >> ---- >> Resources: >> https://blog.forcesunseen.com/a-primer-for-testing-the-security-of-graphql-… >> https://medium.com/csg-govtech/closing-the-loop-practical-attacks-and-defen… >> _______________________________________________ >> Dailydave mailing list -- dailydave(a)lists.aitelfoundation.org >> To unsubscribe send an email to dailydave-leave(a)lists.aitelfoundation.org

1 0

GraphQL
by Dave Aitel 05 Mar '22

05 Mar '22

One of the best ways to get more performance out of your networked system is to trust the client more. This is always a bad idea from a security perspective, as everyone on this list knows, but it's fun to see it reincarnated a thousand times in different bodies. So for example if your web application has endless structured data always changing and you're sick of writing REST APIs and middleware you start thinking - what if instead, I had a flexible Javascript API in the client that just grabbed data right from the database, and that database did the user-authorization? Anyways, GraphQL is interesting and makes the hacker in me, and probably all of you, hungry. In general, from a security perspective, "Let the user talk directly to the database, but we FILTER it a bit" is always a hilarious losing perspective, like trying to outswim a shark, or having just one more drink of Goldschlager. Any filter or translation layer starts introducing protocol desynchronization vulnerabilities, of course, but also you have to worry about timing oracles, denial of service via resource exhaustion, authorization mistakes, and a whole host of nightmares that hackers at this point can pull out of endless old Bugtraq posts whenever they feel like they need a conference talk at your expense. People often make the mistake of correlating "No plugin exists in BURP for this attack surface" with "this new technology is more secure than the last one!" What confuses me is when people deploy huge web applications based on this sort of thing you would think they would at least ask the giant, VC funded companies, "Which security team looked at and gave you a review of this tech? What if the whole thing is a bad idea?" Like in five years are we going to realize that you can't give users the ability to run arbitrary regular expressions on your extremely complicated database without so many checks and balances that it ruins the whole point of having them connect to the database in the first place? Yes, yes we are. On one hand, this is a sad state of affairs. On the other hand, who are we without it? This failure is the upwelling current that brings nutrients from the ocean floor to our arctic habitat. This is the solar wind of quantum bits we float from planet to planet on. This is the brief touch of a child's hand on the belly of the Buddha. This is truth in the way that we know it. -dave ---- Resources: https://blog.forcesunseen.com/a-primer-for-testing-the-security-of-graphql-… https://medium.com/csg-govtech/closing-the-loop-practical-attacks-and-defen…

1 0

General Relativity is Not Evenly Distributed
by Dave Aitel 11 Feb '22

11 Feb '22

[image: image.png] If cities were 100% accurately represented by video games, Miami would of course be *GTA: Vice City*, a story of simplistic corruption garishly lit and stuck in 2002 forever. It's traditional to hate on Miami, right until you make some crypto money and decide to move there into a condominium with a stunning view and an equally stunning lack of maintenance or foresight around rising water tables. Seattle, on the other hand, is *Cyberpunk 2077*, a city run by cybernetically enhanced corpos who get to work by walking past endless discarded refuse and homeless tent cities heated with literal barrel campfires - on my way to the airport yesterday we drove through some thick fog, which the Uber driver explained to me was just "a fire under the bridge" with the same level of casual interest he would apply to a sale at a JC Penny's. Traveling between these two cities imposes arbitrage costs on your consciousness itself, extracting profit from your inability to look away from what seems like an obvious oncoming disaster. What happens when the ocean goes up another foot, and nobody can get flood insurance? you ask yourself, as people around you wave you off. How come such a progressive city can't serve its people's needs, or at the very least pick up their trash? you wonder, while running past a well worn armchair next to the freeway that, rain or shine, serves as someone's impromptu throne. While the humanity in you rages against the system, the hacker in you realizes that knowing the past and processing it to produce the future can be as useless and predictable as an earthworm's digestion. Hackers live in a realm between spaces and times, looking at the hidden connections and occasionally playing a chord on the threads. -dave

1 0

Cyber Threat Intelligence vs Megafauna
by Dave Aitel 08 Feb '22

08 Feb '22

https://twitter.com/SecurePeacock/status/1486156096259637250?s=20 [image: image.png] So I wanted to respond to this post which starts "If someone exploits an 0day they still have to setup C2 - this is where TTPs are generated that Blue Teams can win against". And I think for the past year I've gone on a huge journey of discovery, annoying my Cyber Threat Intelligence friends to no end as I ask annoying questions like "After you put some random non-googlable name up, like PLATINUM, can you just add a little flag so I know what country you're talking about?"" [image: image.png] (Argh. The whole point of codenames is they are UNIQUE and easy to search for. This is like naming your OS "Windows" I guess.) Anyways, imagine if seventeenth century biologists were reporting to the newly established Royal Society and they were talking about counting all the animals and doing studies on animals and of course what they used to do that were the various animals that kings and whatnot had gotten stuffed and sent to them. I feel like you would find out that almost all animals had fur and were easily shot by muskets or stabbed with spears! I guess my point here being: Cyber Threat Intelligence is in a very hard place right now, despite soaring revenues and many exciting trophies on the wall. What you hear, over and over again, is that yes, detecting exploitation is hard, but you will be able to detect "lateral movement" and see the command and control traffic, and when attackers need to "accomplish their mission" they will therefore be detectable. And this is true - for some missions, and for some operational concepts <https://cybersecpolitics.blogspot.com/2020/05/asynchronous-command-and-cont…> that accomplish those missions. But we fail when we don't consider other operational concepts and other missions. Apparently we call the many reasons we fail to turn data into warnings and then into action: "pathologies". Good marketing from XDR companies is a pathology in this space. And that pathology goes to the highest levels - when we have leaders in govt say "We don't see any serious Log4J exploitation" we have to think "Wait, we have almost no visibility for Unix targets though". Even when we have the right telemetry, we don't have the right analysis. I like to probe our pathologies with annoying questions: - What percentage of worms do we see? - What happens when people don't use a C2 but just drop an implant? - Who are the hacker groups focusing only on Unix? - What percentage of 0day do we really even find? - Are we looking only at our adversary's actions, or also our own to make trendlines? But more than that, we are not self-conscious in the way that we should be about our own analytical pathologies. This is because our academic structure for peer review and everything else in this space is pretty busted. Anyways, there's more to the world out there than just lions and antelope and espionage RATs. To see the really interesting things you need a microscope, and the kind of eyes that want to squint through the lenses of microscopes we haven't even built yet. -dave

2 1

RootedCON 2022 Call For Papers is open!
by omarbv＠riseup.net 17 Dec '21

17 Dec '21

______ _ _ ____ ___ _ _ / / _ \ ___ ___ | |_ ___ __| |/ ___/ _ \| \ | | / /| |_) / _ \ / _ \| __/ _ \/ _` | | | | | | \| | / / | _ < (_) | (_) | || __/ (_| | |__| |_| | |\ | /_/ |_| \_\___/ \___/ \__\___|\__,_|\____\___/|_| \_| *** /RootedCON'2022 - Main activity *** -=] About RootedCON RootedCON is a technology congress that will be developed in Madrid (Spain) from 10 - 12 of march 2022. With an estimated seating from 2.500 to 3.000 people, is the most relevant specialized congress that is held in the country, and one of the most relevant in Europe, with attendee profiles ranging from students, Law Enforcenment Agencies to professionals in the technology and information security market and, even, just passionate people. This is our XII edition, after the restrictions pause. And as in every edition, we want it to make it special :) -=] Talk types We will mostly accept two kind of talks: - Fast talks: 20 minutes. - Standard talks: 50 minutes. There will exist a limited number of talks of both types having, even, the possibility of working with the schedule to extend a talk beyond the 20 minutes limit, or to reduce a 50 minutes one. We encourage you to BE ORIGINAL with your proposals. We accept *rare* talks and thematic, on culture or politics (always orbiting around the concepts technological or Information Security). -=] International speakers There is simultaneous Spanish-English and English-Spanish translation on all tracks, so please do not hesitate to inscribe a talk, wherever you are from :) Be sure to indicate the language in which you will give it: [ES] - Spanish [EN] - English =] Topics we are looking for Any interesting topic related to TECHNOLOGY, having examples below and not limited to: - ANY original topic that contributes content to our audience! - APT, botnets and malware. - Obviously, ransomware! - BIO Hacking and alternative disciplines - Any hacking topic in any environment: IP, OT, IoT, Cloud, EDGE, Satellites, Mobiles... - Reverse engineering, debugging, hooking, fuzzing, exploiting, DFIR,... - Financial Tech (FinTech) - Hardware Hacking, Jtag, SWJ, Dap, consoles,... - Videogames, cheats... - Cryptography, steganography, covert channels,... - DEV/SEC/OPS. - DEV: MQTT, AMQP, development patterns, distributed development, CI/CD... - OPS: puppet, jenkins, orchestration, virtualization and containers, artifacts,... - Culture, philosophy and ethics, future, innovation ... the world! -=] Talk submission procedure We will only accept talks submitted throught the official speaker form: https://cfp.rootedcon.com/ (both english and spanish) Any other talk submission will be considered "unofficial" and will not have any guarantee in being selected. -=] Speaker benefits and privileges Every speaker will get these benefits and privileges: - ONE extra ticket for a partner (1 ticket) to attend the event. - Diner with all the speakers, RootedLABS trainees, sponsors and the RootedCON team. - Accommodation (RootedCON carries with the costs, even the partner) - Travelling (RootedCON carries with the speaker's costs) - Full access to all congress areas all the event long. - The possibility of repeating the speech up to three times, one in every track (depending of the final rating). - Some free drinks in the party :) - Potential job offers management. - A gift from the organization. -=] Obligations and duties of the speaker All speakers that inscribed a talk and get selected must: a) Confirm that the talk is TECHNICAL and it is supported with Proof of Concepts (PoC). If PoC are not available, it should be justified.

1 0

2025

2024

2023

2022

2021

2020

Dailydave