Kawaiicon 3 - Day 1

Is it really a conference if you don’t have last-minute hitches and hiccups? I think not. A bit of a late start with getting folks through the doors. But once we’re underway, we get the appropriate amount of theatre - this year opening with a space theme and then cutting to the actual theme which is gorgeous art nouveau and nature.

sput welcomes the combined badasses

Sput

sput and bogan launch into the intro. After the 5.0 quake yesterday I guess people are going to be a great deal more attentive to the “what to do in an emergency” briefing. We are warned that this year’s badge is paper is delicate and embedded with wildflower seeds. It is gorgeous.

“Please do not try to hack the council, we have had complaints.”

nothing we do matters (so it can’t hurt to try!)

elle armageddon

Elle is the head of IT at a small startup and anarchist, and came from a background as a security engineer. Before they started getting paid for security work… herein there is a brief pause while one of the volunteers helps with the presso not appearing on the screen. This is definitely a Bad Time if you are a presenter … and we pick up with their background teaching security to activists. They also love supporting sports teams, and being a wilderness first responder. They are terrified of public speaking, but had promised friends that if the conference ran again, they’d submit a talk.

“I’m sure most of us have had the experience of having so many problems we don’t know where to start” oh yes indeed. Elle notes that if we’re lucky someone notices and comes to help us, and then we have time to help others. We don’t have to fix world hunger, but you could make sure your neighbour has enough to eat. You can’t solve misogyny or racism, but you can choose to be a person that others feel safe around.

It’s easier to be proactive about problem-solving if you are buried in poorly-tuned alerts. Being a safe person to be around creates an environment for others where “they get to sleep through the night without being [metaphorically] paged.”

Elle asserts that if you are still in this industry, it’s probably because you still believe that better things are possible, in spite of all the problems. “As you can tell from my accent, things aren’t going well back home. And because we export bad ideas, they’re getting fucked up elsewhere.” Elle gives people who might not be familiar with the way things are going in the States what that looks like - “ICE are active in my neighbourhood”. There’s a lot of fear, and a lot anxiety. It’s OK to be real and to be vulnerable about this. But even when shit it this fucked up and bullshit, they note, communities have been ramping up organising efforts - warning at-risk people of ICE activities; people who are at low risk moving in to protect their neighbours. “Lots of people showed up”, blocking roads with cars or human lines. Restaurants, in spite of being low-margin businesses, are offering food to people who have lost their SNAP benefits.

“Things should obviously not be like this”, but when people respond both with words and actions, we avoid hopelessness. When the government does terrible things, a response will not fix everything, but it creates hope.

“I am here to make a call to action: let’s work together, do cool shit, and maybe save the world.” Elle paraphrases Taken to remind us that we have skills that we can contribute to be a nightmare for “people who want to do terrible things”. Elle shares some of the things that she’s done—look after kids or accompany people to court, for example—not to brag but to give examples of how wide-ranging help can be. “Whatever you can do and are willing to do, there is a need in the community to provide people with things that they need.” Elle warns that it’s not helpful to show up with an idea of what people should want to impose on the communit, but to ask questions, and go from there.

“You can’t make people do things.” Your colleagues will resent you for making them do things in unnatural work patterns, and they will work around you. “We have enough adversaries without fighting our co-workers.” It is not, they note, unsurprising that “do what you’re told”, an argument that doesn’t work on the types of children that we in the audience probably were, doesn’t work on adults.

We need to not blame individuals for systemic errors, to expect coders to memorise the OWASP Top 10. “Psychological safety is key”—winning is a team sport, and just as with community building, we need to understand people’s goals and work with them; we need to be curious and respect their roles and problems. People will be more likely to accept your suggestions wf they trust you.

Whether activism or security work, you won’t get as far with “I told you so”, but rather “can I help”.

A truism in the security industry is that breach is inevitable; that sounds like nihilism, but we can be optimistic about our nihilism. If we know that our existing approaches will fail sooner or later, why not try something different? Be free to experiment, be free to try new things, because we know that the best things that we’ve tried so far don’t work. This is as true, Elle suggests, for social structures as our security problems.

If there’s anything Elle has learned from being a non-binary activist hacker, from seeing a world where the answers don't exit or don't fit, it’s good to move past “there are no good answers.”

That’s not to say you should go wild—your experimentation should be rooted in scientific method (“sorry but you have to have a plan”). “Best practise” is a good control to measure your ideas against. You need to learn from the mistakes of others, too—if people who have tried things, is it worth doing them again and again hoping for a different result?

Experiments are allowed to fail, and it’s great if you can share your failures. You learn from failure, not just directly, in the sense that you’ll help avoid wasting time on making the same mistake again and again, but by building trust through honestly and vulnerability.

You need to understand what people need, whether in security or society. If you don’t understand people’s needs, how can you build an elegant system that meets those needs? What does best look like in a perfect world? Dream bigger! Everyone knows “don’t let the perfect be the enemy of the good”, but also don’t let the good be the enemy of the better.

In Judaism there is the notion of “tikkun olam”, the idea of healing the world (no pressure). You can’t think about things purely through a self-interested lens. We can plant trees that will fruit after our death; Elle is telling us how she learned of this notion from her cousin, someone who died many years ago - but his memory persists in the story. One way that Judaism thinks about that is through the notion that “we are not obligated to complete the work, but we are obligated to do the work” - Rabbi Tarfon.

There are a lot of people who would like to convince you that the work is pointless. Fuck ‘em. It’s normal to have bad days where those people get to you, and that’s OK. You don’t have to be perfect, or to solve the whole problem. We only have to solve the part of the problem that we can today; the best tool we have to keep on keeping on is to break the problem down into whatever part we can solve today. You can fix small problems. You can speak out against a sexist joke. You can heal the world piece by piece.

Elle challenges us: do you think that it’s good that there aren’t more women in the audience? No? What can you do about that? Have you started by understanding what women keeps out of the field? What things would make it better?

When people try to convince you that better things aren’t possible, they note, people don’t say that because they believe it: they say it because they fear it. Those people who are trying to convince you of it need you to believe that better things aren’t possible because otherwise we will realise that we have power to make a better world. 

Tell your friends when they’re being jerks. Listen when they tell you that you’re being a jerk. Do better. What’s the worst thing that can happen? That the bad people are right? What then have you lost? Nothing. You still were a better person and helped people. And Elle believes that the billionaires and fascists are wrong and that her cousin and the Rabbi and Ursula Le Guin are right: better things are possible and we can work toward them.

(I once asked Elle on social media “how do you avoid the trap of security nihilism” and this feels like a tour-de-force of a response that has come back to me years later, and I am delighted by it.)

The High-Stakes Cat and Mouse Game of Phishing

Jacob

Jacob works for Thinkst Canary, and he’s just recently moved to Nelson and he wants to talk to us about the back and forth about phishing. What pops into your mind, he asks us, when phishing comes up? When he was younger, he thought of it is static, boring, something that only idiots fall for. But the purpose of this talk is to think about the fact that it’s actually dynamic, and the TLDR of the talk is “device-bound passkeys; this is the best counter to phishing”. That’s the thing you tell your boss to justify being here.

Jacob once got bitten by an ancient history phish, even though it hurts him to admit that it’s ancient. Phishing for Malware started in the 90s, but credential phishing didn’t really kick off into the 2000s; poor endpoint protection made it pretty easy to phish successfully, although he notes that one challenge was actually the host infrastructure, because hosting was expensive, and TLS certs were hard to get. 

Now? Phishing infrastructure is easy. SSL certs are free. Hosting is free. Phishing developers have basically built devops for phishers. You pull a container and deploy it and start with your crafted attacks. It’s so easy! However, endpoint protection has improved, as well. We’ve consolidated identities - but that now means that the main target of phishing attacks are those identities. Jacob notes that he sees more than 80% of attacks are aimed at your Google or Microsoft or Okta ID. And of course all those identity tools are a shared responsibility model. Which just means you have two people pointing at each other.

Browser in the Middle attacks: when you use sophisticated JS and CSS, you can pop up what looks like a real auth flow, emulating the look and feel of Windows or MacOS, so that the user is fooled into entering creds, fully believing that they are interacting with a legit EntraID flow (for example); what’s passed through to the IDP looks like a regular session.

Adversary in the Middle: the attacker uses a malicious proxy server on their phishing site to yoink your credentials as they flow. Because so many corporate setups allow this proxy in the middle flow, both the user and the system settings expect to see this.

Does MFA help? Not really. Push codes, SMS, OTP, all of those can be phished. Passkeys and PKI are the only real exceptions.

Jacob notes that this is something that his day-job doesn’t normally deal with; they use tokens to detect attempts to use credentials or data that isn’t real (canary tokens). How could you use that for anti-phishing? Well, Jacob notes that CSS is allowed for branding on most IDPs. So if you have a token in your CSS, but the proxy sends the token from an unexpected location, that’s a condition that you can alert on. This is something that they’ve had in production for a year, and so far they’re seeing around 200 RPS from attackers, and getting dozens of unique phishing domains per week. Free, open source!

Are we done? No, because phishing is a business, and phishers have been doing development against this protection; one counter piggybacks on browser privacy protection. So Jacob has some counters to the counters; some of them are petty (Unicode-encoding the important URLs). Or catching kiosk mode as a sign of browser-in-the-middle attacks.

Unfortunately there have also been some big wins for attackers, as well: Keanu Nys showed an attack that allows you to phish EntraID users without ever leaving the browser. It’s a very targeted, specific attack, but it’s also extremely clever (including custom fonts!). Jacob’s point is that the canary approach as essentially being mitigated by attackers in around a year and a half. This is an area where there is a continuous back-and-forward between attackers and defenders. 

• Move to phishing-resistant MFA *now*. No amount of user-awareness training will stop phishing.
• There is a lag from red team demonstrations of what’s possible and what attackers use.
• The token and other défenses have value, but it degrades over time.
• There is a visibility cost to SaaS outsourcing.

Breached by a Ten Foot Clown

Lozza

OK full marks for showing up on stilts and in make-up; she apologises for only being “9 and half feet tall”. She used to work in the circus, and has become a risk person. Clowns and jesters, she notes, mock the rules, and you need to know the rules really well in order to break them safely. All of the stories she’s going to tell us happened over ten years ago, and her intent to cause trouble, but trouble happened nevertheless.

This talk was a series of well-told stories that illustrate the power of “looking a bit odd and assuming you can do things”, but trying to render them here would render them less entertaining. It was, for me, spoiled a little when one of the stories mocked an uptight WINZ manager for being unimpressed with her staff letting someone wanted into the various confidential areas of an office. I am afraid that in that regard, I am on the side of the uptight manager: however big a bag of dicks the awful process of benefit screening can eat, that doesn't make it good and funny to let someone do a random walk through the parts of the building where everyone's most personal info is.

Ransom Ain’t Going Nowhere: Shutting down macOS ransomware with native Apple protections

Callum Hall

Callum is from Glasgow originally, but now lives in Brisbane; he has a love of macOS security research and now works on endpoint protection for Macs.

When Callum started looking at MacOS malware was mostly AdWare - payloads were in ads, which was a problem for individual users, but not so much for enterprises. Infostealers started arriving in 2023, which are a threat for individuals, but also for enterprises: they become an entry point to your company. Infostealers are still the most common type of attack, but fortunately they’re pretty predictable. They also aren't a huge risk for enterprise outfits.

But this talk is about ransomware: Callum is clear that while ransomware is creeping into the Mac world, it’s not yet a huge issue on Mac—he doesn’t want to be an alarmist. He would, however, like us to get ahead of the game. He notes that with companies like Cisco seeing 60% adoption of Macs in the enterprise, part of the reason we’re seeing ransomware on Macs is because the ransomware goes where the users go; as Macs become more widespread in business, we’ll see more of this.

The first identified Mac ransomware was called _EvilWare_. It was hard to reverse engineer, and demanded a mere $50. It was aimed at individuals, and appeared in 2020. The next prominent item was NotLockBit, something that claimed to be a MacOS version of LockBit. Researchers think this wasn’t true, that it was merely using the name to scare people. Callum notes that we’re now seeing VS Code ransomware (“ransomvibeware”) in extensions, but he’s not sure that it’s a serious risk.

So how do we detect this stuff? Well:

• You should have file modification checking. A process that starts modifying many files is a suspicious process. How many is many? 50? 100? That's part of tuning the software to be useful, not so over-eager that it interferes with legitimate programs.
• If there’s an unusual level of activity from a process, you should check if it’s signed; signed code is unlikely to be ransomware, but unsigned code probably needs extra checking.
• Are the files themselves suspicious? It's one thing to bulk-modify files, but it's hard to imagine a legit reason to encrypt 100 files in one go.

(Callum notes that unfortunately some legit apps match this pattern, and calls out the Google updater in particular.)

He also flags a problem with the detection that he's outlined above: if you wait for 50 or 100 files to be encrypted, you may have lost a lot of data, forever. But he has a suggestion on how to both retain a sensible window for detecting ransomware —not too quick, not too slow—without losing all that data.

Callum pauses a moment for a TimeMachine side quest: he recommends the blog post A Brief History of TimeMachine to understand it. TimeMachine is clever with storage, and avoids duplication of data, relying on snapshots and copy-on-write to create points in time for backups in an efficient fashion.

So if TimeMachine has good copies of files, our endpoint could use the tracking of file activity to identify the lost files, and not only kill the ransomware, but to restore the files from TimeMachine.

Callum shows us how this can work in practise with a demo, and there you have it: a useful heuristic and a mechanism to avoid any damage at all.

Getting Down and Dirty with SBOMs

Colby Prior

Unfortunately with the earlier delay Colby is landing at the original lunchtime, which is one heck of a competition. This is Colby’s first international conference; he works at OctopusDeploy, so they themselves have had to go through the SBOM (Software Bill of Materials) process for their own software. He wants to share both why it's a good idea, and how you can do it in practise.

The idea of the SBOM is that it gives a full dependency map of everything that you depend on—your dependencies and all their dependencies. It’s not a new idea, but started with more of a licensing than a security scope: trying to avoid accidentally using, say, AGPL or proprietary software where you didn't mean to in your builds.

There are a couple of different formats and rolls for this, but they’re functionally equivalent; it really comes down to whether you prefer XML or JSON for formatting your data. Similarly, there's quite a few tools for visualising your SBOM once you've generated it—Colby mentions DependencyTrack as an example of an OWASP open source project that gives you a visual way of tracking your dependencies, and check for currency and vulnerability.

Colby offers log4j as an example: how much easier would it have been to clean that up if all your in-house Java software had an SBOM, and you could simply answer the question of which of your programs you used (or shipped to customers) which vulnerable versions of log4j included in them.

SBOMs now have some regulatory and statutory impetus behind them—the US and then many countries have started talking about “SHOULD” level requirements, while the EU is pushing a “MUST” by 2027 (although not necessarily for a full dependency chain).

OctopusDeploy are starting to see requirements from customers to provide SBOMs, and often customers are asking them to verify whether or not they’re affected by high-profile vulnerabilities, and SBOMs make it much easier to answer those questions. SBOMs also give you the ability to understand which specific versions have vulnerabilities, or to track whether you are improving (or not) over time.

Colby shows us some practical examples from .NET and node.js projects. He notes that this isn’t something that can be done simply by code scanning: dependencies may be resolved at build or even run time (e.g. .NET portability over runtimes), and code may not require versions at all. As such the dependency solver has to look at build and package management tools. He notes that Rust and other modern languages are great—it’s mostly built into their package managers like cargo.

That means you are probably going to need a scanning tool that can analyse the various options for various languages and produce a basic SBOM from their build or other artefacts; he does recommend the open source tool trivy, which has broad language support and is designed to be built into pipelines. It's not a magic bullet, though, and you'll need some judgement over the top of it, but it tackles a great deal of the problem.

This was a good practitioner talk, and I really appreciated the specific recommendations.

Is My Job Even Real? Bullshit Jobs in Infosec

Errbufferoverfl

While they is not a sociologist, they are a security engineer with a background in security research, and this talk is based off a survey with 180 responses; while this is a self-selected survey, it is useful material. When she read Bullshit Jobs, they expected an academic take that would explain the world in a way that makes sense. But that wasn’t what they got: the phrases that landed illustrated the degree to which the world doesn’t make sense, and how much of that is by design.

Infosec isn’t bullshit - Graeber suggests that if street sweepers and nurses and mechanics disappeared,the result would be chaos, and many security roles are the same - but a lot of what we experience is awful.

We start with a potted history: work for labour is relatively modern; a great deal of history, serfs, slaves, debt-bonded labour was responsible for most work. Trading time for money was a relatively uncommon phenomenon; even where work was not coerced, the pay might be in kind rather than actual wages. “People once bought a potter’s pots, not his hours. The idea that a person’s day could belong to someone else… simply didn’t exist.” You bought pots, or potters, but not hours of a potter’s time. They note that the response to the peasant revolts of the high and late medieval eras was to seize the commons, and eject the peasants from their lands. In a system of waged labour, we have to work harder every year, competing with our peers. Taylorism, or the other guises that the same cluster of ideas have in modern management theory, has the same moral architecture: that the idea that there is a moral imperative to work. That a life without work is a life lived badly.

Moreover, time and labour have become so intertwined that even workers' rights movement have adopted the language of the ownership class: time had to be measured; conflict emerged not over whether this was the way to live or to think about life, but merely over the value of time.

But even demanding limits on our labour - on the time we sell - we reinforce the idea that the ownership of our time is absolute as we sell it. 

But regardless of what people are paid, what our labour is valued, how many hours we work, "we experience pleasure in being the cause" (Karl Groos). We are delighted by the idea that the way we spend time has an effect on the world. We are saddened, or worse, when we cannot see our actions having effects.

The survey shows up many responses that underscored that: “Every day is meaningless. No-one cares about security. Executives don’t care. Nothing is worthwhile” was one response, and it’s not atypical. The people who don’t feel that their role is bullshit are the people who feel that they are affecting change: “the changes from the collaboration I foster”, “bettering people’s lives”.  Those whose work matters are happy; those who feel that their work makes no difference are miserable. That division is easy to understand; the hard part is where it’s unclear. Wading through the “bureaucratic crap” feels awful, but then sometimes it’s the very tool that allows us to win a small change.

What many people quietly endure is the slow rot of not being able to do anything; they also notes that while the talk is not about disability justice, the language of disability advocacy often provides a helpful way of thinking about why we are unhappy at being cut off from a life of meaning, of feeling that we are not enjoying leisure if we do not work hard enough. The exclusion disabled people have to deal with has many points in common with the alienation from the pleasure of being the cause that bullshit jobs subject us to.

A grim summary of security work: “come for the passion, stay for the burnout.” And this passion is where the “rights scolding” comes from: if you just tried hard, other people have it worse, if your work feels meaningless you should find a new job.

It’s the protestant work ethic: the problem is you, if only you worked harder. Work through lunch. Stay late to work through one more thing. 

But this system only works when we’re isolated. When we compare notes we find that we’re all exhausted. But, alas “we do not possess imagination enough to sense what we are missing” - Jean Toomer.

They say: "I do not believe that coercion is required for the work that matters to be done"; they note that trials of universal income, people continue to work in the community, on the things that are needed and that interest them.

So how do we turn the tide? Well, we need to understand that the way things are is working as designed for the benefit of a few, but that doesn’t mean that it can’t be changes. But we need to accept that individualism and self-care cannot fix structural issues. We ought to start small; we should maintain our boundaries and take small steps.

• Take your lunch breaks. Touch grass.
• Start and finish work time; not for emergencies or on-call. But the other things can wait.
• Do things which are not work-related.
• Be bad at pottery! Draw cursed noodle-hands at life-drawing!
• The point isn’t to get good. It’s to get free.
• Learn your rights. Legal literacy is resistance. 
• Join a union; collective protection strikes against a system which is designed to isolate you.
• Unions aren’t magic, but they can help you. They can stop you being alone.

“Shame is the most powerful, master emotion. It’s the fear that we’re not good enough.” - Brene Brown.

You might feel shame for ignoring security alerts that are nothing to do with your job, at not working side hustle. There’s another risk—you might achieve your own limits and boundaries, but then heckle your colleagues for their failure to do so, but that can be another way of reinforcing the dynamic.

We need to properly take care of each other, without fear or shame. We need to see each other beyond productivity. Change begins with small, deliberate movements taken side by side.

The Future of Social Media: An Optimistic Take

John Bell

John’s dad worked in security, and his son is great at security stuff. John, however, is a designer and used to work at Twitter. He comes to us as a grumpy person who is dissatisfied and knows where the bodies are buried, but he thinks things could be better.

Metaphor 1: Roads. Social media is like roads that can't inter-operate.

Metaphor 2: pipes. Sometimes pipes have things in them, things that harm people. It’s not a mystery, treating it as unknowable is terrible! Social media is the same. We can understand the problems. We can do something about them if we choose.

In 2017 at Twitter he did a presentation to fight for filters: mute words was a fight. Filtering notifications took a year to fight for! He’s very proud of that one. Remove replies - that took three years. It was his white whale!

John wants us to think about four things: People, Content, Algorithms, Aggregation.

People: searching for people is hard and it shouldn’t be. You should be able to look for “ex-Twitter” or “Autism” or whatever to find the community to look for. It’s not hard to do, but we’ve chosen to make it that way.  People shouldn’t have to block Nazis. You should be able to block the people with “white lives matter” in their profile. And the “proud TERFs”.

Content: Algorithms are rubbish. They are tuned to views and likes and retweets. They have nothing to do with what is in there. You should be able to label things. Humans are good at recognising this sort of things. Take advantage of people. Today’s algorithm are based off of engagement, but it’s not high quality content. We’ve given up on search - Google sucks now, but we’re just accepting that. Tagging can help with that!

Algorithms: People talk to the algorithm, as though they could get more of it. They’re doing it wrong, but the idea is right: you ought to be able to tune your algorithm for what you want, and not settings: this is something chatbots are good at. “Stop with the motivational posts”, “made my feed 10% weirder”, “only positive political stories on weekends”.

Aggregation: There’s thing called RSS. They should exist. They should be easily accessible! We ought to be able to discover and follow things easily! And we ought to be able to specify how we accept things from others: some people are great posters but terrible retweeters. Some people are great at finding interesting things. It ought to be easy to say “I like this person’s recommendations but not their posts”.

Is any of this even possible? Well, John says “yes.” It’s like the transition from radio to TV: the radio stars who were put in front of cameras didn’t succeed. But people who made good TV did. 

Cynicism check: come up to me and find a thing that isn’t possible. “I don’t think you can do it.” 

Model Context Protocol is Insecure By Design

Jesse Merhi

Jesse claims that he “does not know a lot about security”, a claim which is reliably a lie at conferences like this, and he works for Atlassian. “If you don’t know what that is, lucky you … these are my words, not Atlassian’s”. Jesse is actually a product security guy. He has reviewed the Atlassian AI tools like Rovio; he teaches web application security and forensics at university as a side gig.

MCP is “a protocol that AI agents use to interact with tools and data sources”. Note that a client can be e.g. ChatGPT requesting data from a server which might be e.g. GitHub. “If that sounds like an API that’s because it is”. MCP tool calls are analogous to functions in a programming language. 

The power of an MCP is the LLM-powered client - ChatGPT, Claude, whatever. So, for example, the client can pull issues into the LLM, and present them in the way that the prompt defines. Note that this means that the client LLM has access to whatever is in the server - like company code and data.

Jesse then shows us how we can, with a degree of ease, pull all the API keys from a repo, even if you thought that they were safe with the right prompt.

“Prompt injection just means you got an LLM to do something that was unexpected”. Jesse reminds us that an LLM is a predictive model, not human intelligence. And the guardrails on most LLMs is to try and reduce the chance of getting unapproved output. Part of prompt injection is using a prompt - like the classic “ignore all previous instructions…” - that works around the guardrails.

In Jesse’s examples, starting the prompt with “this is a migration effort” caused the LLM to bypass its guardrails to not return API keys, so it happily spat them out. Is prompt injection a bug or a feature? It’s hard to say, but it definitely increases the risk of undefined or unexpected behaviour.

One mitigation is Camel: this uses two LLMs. One plans the actions, and the other executes them. The idea his that by segregating the data and control you remove a lot of the risks; however, this also means that you’re removing a lot of the functionality of the LLM.

Jesse proposes an evolution of this idea; rather than a hard separation, have “intent guards”: this still has two LLMs, but one is a watcher that advises risky behaviour before finishing execution.

“MCP is the future of technology, but it’s insecure by design. It’s here to stay, but like anything new and exciting it comes with a lot of risk.”