- Dailydave - mm4.emwd.com

do androids dream of electric sheep in JSON or XML?
by Dave Aitel 03 Apr '24

03 Apr '24

[image: image.png] Like everyone I know, I've been spending a lot of time neck deep in LLMs. As released, they are fascinating and useless toys. I feel like actually using an LLM to do anything real is your basic nightmare still. At the very minimum, you need structured output, and OpenAI has led the way in offering a JSON-based calling format which allows you to extend it with functions that cover the things an LLM can't really do (i.e. math, or access the web or your bash shell). In real life you are going to use this through LangChain or some similar library. You can do this sort of thing with Claude (a better model than GPT-4 in many respects for code), but it's janky as the model wasn't specifically fine tuned for this purpose yet. Your best bet, as you see everyone do, is to force it to start its reply with a curly bracket "{", but even then it's going to pontificate about its reply after it sends you the JSON object you want, if you're lucky and it uses your format at all. Claude is more based on XML than JSON, which, if you think about how LLMs work, makes a ton of sense. To an LLM, {' may be one token, or {{{{ may be a token. In fact, let's test that: >>> import tiktoken >>> encoding = tiktoken.encoding_for_model("gpt-4") >>> encoding.encode("{") [90] >>> encoding.encode("{{") [3052] >>> encoding.encode("{{{") [91791] #one token >>> encoding.encode("{{{{") [3052, 3052] #two tokens >>> encoding.encode("{{{{{") [3052, 91791] #two tokens >>> encoding.encode("{{{{{{") [3052, 3052, 3052] #three tokens >>> encoding.encode("{'") [13922] #{ ' is one token Yeah, so like, on one hand, that's great. Very optimized compression on token lengths. But on the other hand, it is very confusing for the model to train on and understand! You can see why XML would be much more natural! < SOME WORD > is more likely to be three tokens, which makes creating clean output much easier. Claude's focus on XML probably makes it "smarter" in some ways that are hard to prove with math. >>> encoding.encode("<high>") [10174, 1108, 29] >>> encoding.encode("<html>") [14063, 29] >>> encoding.encode("</html>") [524, 1580, 29] >>> encoding.encode("/html") [14056] >>> encoding.encode("</high>") [524, 12156, 29] >>> encoding.encode("high") [12156] Also, of course, I highly recommend Halvar's latest talk (which is highly relevant): https://www.youtube.com/watch?v=xA-ns0zi0k0&t=4s -dave

1 0

Bugdoor vs Backdoor
by Dave Aitel 02 Apr '24

02 Apr '24

[image: image.png] The security community (aka, all of us on this list) still rages with the impact of Jia Tan putting a sophisticated backdoor into the XV package, and all of the associated HUMINT effort that went into it. And I realized from talking to people, especially people in the cyber policy realm but also technical experts, about it that there's a pretty big gap when it comes to understanding why someone would put in a backdoor at all, instead of adding many bugdoors. Some Background: 1. A post <https://cybersecpolitics.blogspot.com/2019/05/hope-is-not-nobus-strategy.ht…> on what NOBUS means when it comes to backdoors. 2. Responsible offense from a bunch of Americans <https://www.lawfaremedia.org/article/responsible-cyber-offense> 3. Responsible offense from the UK <https://www.gov.uk/government/publications/responsible-cyber-power-in-pract…> 4. Responsible offense from the Germans <https://www.stiftung-nv.de/sites/default/files/snv_active_cyber_defense_tow…> 5. A university banned from Linux <https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minn…> for contributing backdoors as part of a research project So as with all areas of responsible offense, there is a tight connection and contention between good OPSEC and responsible operations. In particular, it is very easy to get yourself on a team for a big project, and add code that introduces exploitable conditions, perhaps handles input in a way that causes a memory corruption, or does authentication slightly wrong in certain circumstances. From an operational security standpoint, these bugdoors are easy to introduce, and I don't know of a serious hacking group that hasn't played with this - if for no other reason than to fix bugs that cause crashes while you are trying to exploit some other, better bug. Reading the original UMN paper, (which was under-appreciated for its time, despite getting them banned from Linux!) you can see that it is not really always about adding bugs, but often about adding enabling features for bugs that already exist in the codebase, making them more reachable. In some ways, attacking the open source community by hacking into developers or repositories has been the traditional way of ancient Unix 90's hackers, who understand a web of trust the way a Polynesian navigator understands the swells and currents between islands. From an opsec perspective though, bugdoors have limits. Fuzzers can find them, other hackers can find them, and once found, they can be used by anyone with the skill to write the exploit. Likewise, using them is risky: No memory corruption is 100% reliable, and when they fail, *they fail in the worst way, in the worst place, at the worst time*. Likewise, the traffic you may have to do to shape memory in the target host is likely to be anomalous, and easily signatured. And from a responsible offensive cyber operation perspective, bugdoors cannot mathematically demonstrate that they can protect the hosts you target from third parties. *Bugdoors are never a NOBUS capability.* Ideally a NOBUS capability would allow you and only you to get in and avoid replay attacks, but a close second is a simple asymmetric key of some kind where the target ID is used as part of the scheme. The XZ backdoor used an Elliptic Curve with a signature that included the target's SSH public key <https://github.com/amlweems/xzbot>. Thanks, Dave

1 0

t2'24: Last Dance
by Tomi Tuominen 28 Mar '24

28 Mar '24

Dear Daily Dave, For a hacker conference, twenty years is a huge achievement — for a small conference, even more so. Over these years we’ve enjoyed speakers showcasing results from cutting-edge research, seen thought-provoking keynotes and bonded with other like-minded people from all over the world. If we had to summarize the experience with one word, it would be gratitude. The speakers, repeat speakers, first timers or regular attendees, and friends of t2 — you have made the event and its atmosphere. This was always a true community event – it’s organized for hackers, by hackers. The Advisory Board’s motivation and main driver was our love for the game. Creating a small event with a curated program, offering a backdrop for lobby bar and coffee break discussions was (and still is) our vision of a perfect infosec con. The chance to network with your industry peers was as integral part of t2, as the high quality content. It’s rare you get the same level of interaction with current/former speakers and attendees alike at any other conference. Tomi has fond memories of pretty much each and every year. Starting from the humble beginnings, when the legendary Phenoelit guys were kind enough to come and present at a conference that back then had no history nor reputation. How the Toolcrypt guys dominated the stage for years with their absolutely amazing research, and how Ivan Krstić (now Apple’s security samurai) shared his ideas on how modern security architectures should be built (iDevices anybody?), how the InversePath crew delivered some of the most enjoyable and hardcore research ever and well, you get the idea – the list just goes on and on – there are simply too many good memories to list here. Mikko remembers learning from Ludde (during a t2 coffee break) how he works at Spotify. Then Mikko explained how impressed he was with Spotify’s early beta version, especially how you could skip parts of a song and it would still continue streaming instantly. Ludde nodded…and said ‘yeah…I coded that’. Henri still reminisces how Halvar Flake took the time after his talk in 2010 to have a chat with him and Esa Etelävuori (RIP), despite Halvar feeling slightly under the weather in the midst of what later turned out to be the Zynamics acquisition by Google. In 2017 we enjoyed the late night/very early morning pizza in the hotel lobby bar with Dave Aitel, after proving him wrong. Instead of dropping a surprise announcement sometime next year, or silently disappearing into the crowd, we wanted to let everyone know before this year’s t2 infosec that 2024 will be our last dance. We have truly enjoyed the past two decades of world class cyber in Helsinki – all good things come to an end eventually. From the bottom of our hearts, a big thank you to all of you who made this happen. We are privileged to be able to call many of you out there our friends. This goes especially to Dave, thank you for treating us so well over the years. Tomi Tuominen Mikko Hyppönen Henri Lindberg

1 0

while True:
by Dave Aitel 25 Mar '24

25 Mar '24

There seem to be a lot of people who think the problem with cyber security is we aren't paying lawyers enough. This results in the current push for software liabilities, or the need to click accept on cookies before we use every website. It is natural for lawyers to want to feed the next generation of associates, by regurgitating legal koans into their mouths. These vomitous truisms pass for thought leadership when you go high enough into the cyber policy clouds. "We don't know what we don't know!", "You can't manage what you can't measure!" , "We need to be Secure to Market not First to Market!", "Crawl, Walk, Run!" These statements are the opposite of haikus, which when done right are one crystalized emotional moment. This is why I think maybe we should hire more poets to do cyber policy, instead of lawyers. What is "*i carry your heart with me(i carry it in*" other than the first line to an exploit written in a bash script we all forgot existed but our spirits remembered? When LSD-PL said: bn,a bn,a call did that not carry with it an emotive punch? When we hack, do we not reach within our internal well of hate to pull forth a tiny amount of darkness and then send it into the world on tiny flaxen wings? I cannot do a survey on this in any language that matters, but I look into the net and see all the ancient hackers I grew up with still crouched in full armor, their ocher swords smoldering. This week in between cyber policy calls at 0500, I sat for hours, choking on the byzantine syntax of LangChain attempting to wrestle an LLM into submission. I kept thinking, what would Horizon do? What would Shubs do? What would James Kettle do? What would Tiraniddo do? What would Chompie do? What would Skylar do? I told myself: They would *continue*, is what they would do. -dave

1 0

Value of the [leaked] Windows source
by Konrads Klints 07 Mar '24

07 Mar '24

Windows XP and Windows 2003 partial source code is out there on github. With such a rich corpus of known vulnerabilities in those OS'es and source code availability, surely there should be an amazing amount of SAST/semgrep/codeql rules that take as input existing known exploits and then do rules that find similar things, yet I don't seem to be able to find such projects Surely, these two code bases should be the foundation of most good CS/cyber courses - like students finding new bugs, etc. Is source code junk?

2 1

0xC15A: Secure By Design and Secure by Default
by Dave Aitel 24 Jan '24

24 Jan '24

So I have a ton of thoughts on the CISA Secure by Design and Secure by Default push that is ongoing, as I am sure many of you do. And the first thought is: This is not a bad way to go about business as a government agency in general. I think it's easy to ignore how fast the USG has changed its business practices, showing an agility that few large organizations can match. In particular using Secure By Design as a case example. 1. Massive outreach to garner feedback (including at defcon, but also via email, etc.) 2. Multiple rounds of editing of proposals 3. Actual people you could call and talk to about the proposal, with their faces and positions listed right in the papers and blogs and lawfare podcasts. If you were in DC today you could probably hit one of them up for drinks or lunch or whatever. 4. Interaction across multiple stakeholder groups, including internationally 5. The "right people" involved - and you can tell their backgrounds from what they are annoyed about during their podcasts and other presentations. (i.e. Bob Lord is very annoyed about XSS and obsessed with car safety, which I'll dig into later). But also Jack Cable, Lauren Zabierek and Grant Dasher are all worth listening to. 6. Clear executive support So that's all good stuff. I thought I would post it as its own note because it's rare to spend a moment to look at the government process, and not see literally sausage being made. :) -dave

3 3

Secure By Default Part 2
by Dave Aitel 20 Jan '24

20 Jan '24

So I wrote a little draft essay on Secure By Default and opened it for comment. I think one thing that we maybe forget in our community is that some of the more fundamental basises of what we do never make it up to policy-world. Langsec being the primary example. But also there's a huge body of work in TAOSSA, Shellcoders, every offensive conference talk, etc. that never gets put into context anywhere but in our clique. Obviously feel free to just comment in-thread if you prefer, even if you work at CISA: https://mastodon.social/@dave_aitel/111779922142416342 Thanks, Dave

1 0

Leverage
by Dave Aitel 28 Dec '23

28 Dec '23

So we know a lot of people who've gone into Big Corpo or sold a company or just worked hard and gotten lucky and happen to be richer than the average bear. And while a lot of those people put their money into nice things, nothing wrong with that, a lot of them also try to use that money to change the world, and then they find out it's harder to change the world with money than it is with an exploit. And I know a lot of people who say this out of experience. I used to say, and I continue to say, that most cyber policy experts have never seen a real exploit. Yes, even the news reports of 0days are addictive. They have cool names, like a street drug, they have a shadowy underworld, they have a bodyguard of rumors and insinuations. Literally, as I write this, Kaspersky is at CCC doing a street barker presentation on how much someone thought they were a legitimate target worth throwing down an iOS 0day chain on, which frankly is not something I would brag about as a nominally defensive company. Part of the problem is we analyze exploits out of failures. Reverse engineering an exploit does not show you the exploit any more than dissecting a Humboldt squid can show you the terrors of the deep. Once you've seen an exploit change the world, you are forever stunned. It is impossible to go backwards to your previous life. It is like your first taste of sex or love or the feral inhuman joy of combat. For some people, it's probably better. But how exploits really work has shockingly little to do with the circus around exploits on social media or in the news, or press releases from endpoint security companies or government agencies. And the same is true with philanthropy. Here we have "Give Miami Day!" where some random billionaire will match your funds if you give to your school, which should be getting all the government funding it needs, but clearly isn't. I don't know if this is at all useful to be honest. It feels more like covering a hole your government put in your school budget on purpose. I tried buying MEL science kits for entire classes of my local grade school. It worked once, and one of the kids was like "I didn't even know I liked science". But it was largely impossible to get the kits USED by the teachers, who are under levels of logistical stress that would stymie a Marine platoon. So I ended up giving up on this effort. I supported Project Grapple, which worked well because they have a leader at the top who is focused on the success of a small set of kids in a very personal way. But those kinds of leaders are almost impossible to find. When you find them, it's the best investment you can make if you want to change the world one kid at a time, which might be the only way. And these leaders don't last forever. A lot of big donors focus on things like FIRST Robotics, which frankly has been a massive success and offers a lifeline for kids in schools where nothing else matters or meets with any success. It's prohibitively tricky to figure out which schools have a local leader that can take money and build a robotics club out of it. It's very much not important that the kids WIN the competitions - which at the top level are between Northrop Grumman, Raytheon, and Lockheed Martin engineering teams doing ad-hoc group apprenticeships. So again, finding these leaders is a constraining problem. Just like with exploits, what I find is that changing the world with philanthropy is targeted , personal, and more complicated than it looks. I have seen very smart people struggle with finding leverage in this space. Nonprofits are themselves often quite exploitative of their employees or just generally ineffective. Anyways, what I'd like to see is the Gulas and Syversons and Alperovitch's and Pollocks and so forth put a Slack channel together to build a bit of a body of work on how to do this correctly. A bugtraq for changing the world with dollars, if you will. -dave

2 1

A holiday reflection on: Training.
by Dave Aitel 20 Dec '23

20 Dec '23

I think one thing this community does really well, better than almost any other community I've found, is training. It's amazing, in a way, because this is a community of professional secret holders. And yet everywhere you look, a hacker is putting their heart and soul into iterating on lab exercises for their class in whatever sub-field they are an expert in. And giving training is hard. It's hard in the way consulting is hard, but with even more social activity. On one hand: It's lucrative? But hour for hour, you're probably better off financially by finding a new bug or doing consulting work, or any number of other activities than building, marketing, and running a training class. When I left my last position, one of the first things I did was pay for and take Amy Burnette's browser exploitation class. And that's paid off to this day, really. And there's so many good classes, taught by all the specialists in our various sub-niches. It's spectacular that in this world of auto-didacts, we are gifted in the quantity and quality of training available in our field in a way that is basically unheard of in any other field. Of course, there's a lot of things you can't learn from training, and I was reflecting on this while sitting down and reading the labyrinthine specifications of some huge protocol for one of my current projects. A lot of the best bugs I've ever seen hackers find have been from doing exactly that: They sit and hit page down on some extensively huge and boring documentation with the steady, persistent rhythm of a neurodivergent woodpecker pecking at a tree, each tap bringing them closer to the elusive kernel of truth. Like, I know people who have various protocol RFCs printed out for long airplane rides. I've seen hackers read through a book on an operating system design and then just circle an LPE in the book with a yellow highlighter. On the flip side, there are times when you dive headfirst into a colossal specification, emerging as a veritable guru on an esoteric legacy mail transfer mess like X.400. Yet, despite this newfound expertise, you find yourself no more enlightened or advantaged than before, as if you've scaled a mountain only to find the summit shrouded in the same thick fog that cloaked its base. Anyways, happy holidays everyone. Hopefully you had a year of worthy discoveries. -dave

1 0

t2'24: Call For Papers 2024 (Helsinki, Finland)
by Tomi Tuominen 18 Dec '23

18 Dec '23

Call for Papers 2024 t2 infosec has been pushing the boundaries of security research for two decades and it don't stop. We're back April 18-19, 2024 - Helsinki, Finland. CFP and registration are both open. This is an event for newcomers, established merchants of dual use computer code, beginners of vulndev, cyber vagabonds, retired or redacted, and hackers of all sorts. If you have new original security research targeting old, current or future technology, please submit: https://if.t2.fi/action/call_for_papers Got 99 problems but an 0day ain't one. Helsinki offers a Northern European mood, with the resilience built by using Linux on the desktop since 1991, fueled by IRC, demoscene, VHS tapes, invention of modern backpropagation, a lot of memes and sauna. This is the country, which exports Alan Wake 2, quantum computers, and solitude. As regularly as seasons change, new technology is introduced, vulnerabilities - old and new are discovered, lessons of tradecraft are learned and teachings of the old slowly forgotten.To foster the passion for advancement of (in)security and to keep that fire burning bright for future generations, we gather an intimate crowd of people every year to enjoy the advance of offensive research, share lessons of coming back from the edge, and build those valuable human connections. Whether your research tackles LLMs, qubits, Azure/AWS/GCP, iOS internals, the market leading or lagging EDR products, access control systems, SoC, BTLE, tipping ChatGPT or something else, which is surprising to either humans or computers, we'd like to hear about it. Security researchers, you know the rules and so do we. This is an event for the community, by the community. Our focus is on technical excellence, not politics or player hating. Come as you are. The advisory board will be reviewing submissions until 2024-02-04. Slide deck submission final deadline 2024-04-02 for accepted talks. First come, first served. Submissions will not be returned. Quick facts for speakers + presentation length 60-120 minutes, in English + complimentary travel and accommodation for one person[6] + decent speaker hospitality benefits + no marketing or product propaganda Still not sure if this is for you? Check out the blast from the past. !!LINK!! [0] hunter2 [6] except literally @nudehaberdasher and @0xcharlie Call for Paper submissions https://if.t2.fi/action/call_for_papers Buy a ticket to the conference https://if.t2.fi/action/register/attendees -- Tomi 'T' Tuominen | Founder @ t2 infosec conference | https://t2.fi

1 0

2026

2025

2024

2023

2022

2021

2020

Dailydave