Sticking to the \x1b[4X background color is probably safe as that can be tweaked by terminal color palettes. It’s when you use the 256 or RGB \x1b codes that it becomes an issue. Ok for foreground.
> constraining to invert is not sufficient in my opinion
Eh. Doing green/red text color with default background, maybe inverted works amazing for me. In fact, I'd say that every sensible colour scheme for a terminal should have as the default foreground/background colours something that is more or less contrasting against every other explicitly named colour, including black and white (I personally have #212121 on #EEEEEE).
> though this would be a much more sophisticated exploit and is maybe a bit of a reach.
Not necessarily. I have successfully exploited stack buffer overflows in major products despite stack canaries, ASLR, and DEP. It largely depends on context; if the vector is something that can be hit repeatedly, such a webform that that takes a cert or whatever, that simplifies things a lot versus something like a file format exploit, where you probably only get one chance. While I haven't analyzed this vulnerability, I would absolutely assume exploitability even if I couldn't see a way myself.
It depends on what mitigations are in place and the arrangement of the stack. Even with stack canaries, having an unfortunate value on the stack e.g. a function pointer can still be quite dangerous if it can be overwritten without hitting any of the stack canaries.
While there's some overlap in methodologies and back-and-forth with various escalations, so-called malware is distinct from software exploits. Malware can be delivered without an exploit and quite often is. Social engineering is highly effective.
I was hit by this. Could RDP into machines using the regular client, but could not access Dev Boxes via Windows App. Getting real sick of the low quality AI slop.
The reliance on LLMs is unfortunate. I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. The Wireshark dissectors are quite mature, SSH is covered fairly well.
> I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark.
For some people who are used to using Wireshark and who know what to look for, probably yes. For the vast majority of even technical people, probably not.
In my case, I did a packet capture of a single keystroke using tcpdump and imported it into Wireshark and I get just over 200 'Client: encrypted packet' and 'Server: encrypted packet' entries. Nothing useful there at all. If I tcpdump the entire SSH connection setup from scratch I get just as much useful information - nothing - but, oddly, fewer packets than my one keystroke triggered.
So yeah, I dislike LLMs entirely and dislike the reliance on LLMs that we see today, but in this case the author learned a lot of interesting stuff and shared it with us, whereas without LLMs he might have just shrugged and moved on.
And thats a huge downside when people howl about "Encryption everywhere! ".
Try debugging that shit. Thats right, debugging interfaces aren't safe, by some wellakshually security goon.
You want a real fun one to debug, is a SAML login to a webapp, with internal Oauth passthrough between multiple servers. Sure, I can decrypt client-server stuff with tools, but server-server is damn near impossible. The tools that work break SSL, and invalidate validation of the ssl.
I used to share that opinion but after decades in industrial automation I find myself coming down much more on the "yeah, encryption everywhere" because while many vendors do not provide good tools for debugging, that's really the problem, and we've been covering for them by being able to snoop the traffic.
Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted protocols from the 1970s within the limitations of a 6502 to operate life-safety equipment.
Problem is, security people don't want you to MITM connections, because it's insecure (mostly to business interests). Hence stuff like certificate pinning, HSTS, DoH...
If you're debugging your own equipment you should have the certificates or keys to make it work. I'm not saying that's easy in a lot of scenarios, in fact it's frequently tedious as hell. But for example there are debug tools for like DNP3 or RPC over TLS, etc that can watch the whole exchange if provided the keys and parse the SCADA traffic or JSON objects as if it was plaintext.
But this goes back to the vendors not providing better tools in the first place. We shouldn't NEED to be picking apart packet streams to prove to some jackass tech support ticket that their code is FUBAR. They're basically outsourcing support to their customer or userbase and we tolerated it because it was more expedient.
This really does not need to be that hard. For TLS, many tools support setting the SSLKEYLOGFILE environment variable to log the session keys used in connections. Wireshark can import those to decrypt everything. [1]
Unfortunately, nothing exists for SSH (yet?). [2]
I do agree that if you design a protocol that enforces encryption, you should include some debugging interface. It is much more straightforward to do this by logging the session secrets on the endpoints rather than trying to break it through a man-in-the-middle, the main thing the protocol is protecting you against.
Sounds like blaming a tool on a problem it did not cause. Either way, solvable and encryption is important. Badly designed systems and or lack of tooling isn't really an encryption problem.
Anyway, VMs should not have authentication, it makes access sooo much easier. Also drop your IPs while you're at it. Might be useful for debugging later.
Unfortunately with SSH specifically, the dissectors aren't very mature - you only get valid parsing up to the KeX completion messages (NEWKEYS), and after that, even if the encryption is set to `none` via custom patches, the rest of the message flow is not parsed.
Seems because dumping the session keys is not at all a common thing. It's just a matter of effort though - if someone put in the time to improve the SSH story for dissectors, most of the groundwork is there.
Interesting, I thought it was possible to decrypt SSH in Wireshark a la TLS, but it seems I'm mistaken. It still would have been my first goto, likely with encryption patched out as you stated. With well documented protocols, it's generally not too difficult deciphering the raw interior bits as needed with the orientation provided by the dissected pieces. So let me revise my statement: this probably would have been a fairly easy task with protocol analysis guided code review (or simply CR alone).
It all depends on the key exchange mechanism (KEM) used at the start of the TLS session. Some KEM have a property called “perfect forward secrecy” (PFS) which means it’s not possible to decrypt the TLS session after the fact unless one of the nodes logs out the session key(s). Diffie Helman and ECDH are two KEM that provide a PFS guarantee.
* Yes, I clearly know what tcpdump is / how to capture network traffic
* It has been several years since I have looked at a pcap
* I don't have wireshark installed on this computer
* I've done the thing where you decrypt TLS with wireshark exactly once, years ago, and I found it frustrating for reasons I can't remember[1]. Wasn't sure if I could do this with ssh
* When I started investigating this, I didn't remotely think that ssh was the root cause. I thought it was a quirk of my game
* I *did* make a client that printed out all the data it was receiving, but it was useless because it was operating at the wrong layer (e.g. it connected over SSH and logged the bytes SSH handed it)
* I'm experimenting with Claude Code a lot because it has a lot of hype and I would like to form an opinion
* Looking up flags is annoying
* Being able to tell an agent "look at this pcap and tell me what you see" is *cool*
So idk. I'm sure that you would have solved this much more quickly than I did! I'm not sure that (for me) opening up the packet in Wireshark would have solved this faster. Maybe reading the SSH spec would have, but debugging also just didn't take that long.
And the big leap here was realizing that this was my SSH client and not a quirk of my game. The time at which I would have read the SSH spec was after I captured traffic from a regular SSH session and observed the same pattern; before that I was thinking about the problem wrong.
I don't think that this is unfortunate. In fact, I think I got what I wanted here (a better sense of Claude Code's strengths and weaknesses). You're right that an alternative approach would have taught me different things, and that's a worthy goal too.
[1] I suspect this is because I was doing it for an old job and I had to figure out how to run some application with keys I controlled? It would have been easier here. I don't remember.
Thanks for taking the time to respond, and apologies for the contentiousness. I'm a jaded old man suffering from severe LLM fatigue, so I may have come off a bit harsh. Your write-up was a good read, and while I might be critical of your methodology, what you did clearly worked, and that's what matters in the end. Best of luck with your project, especially the go lib fork.
obviously OPs empirical and analytical rigor are top notch. He applied LLMs in the best way possible: fill gaps with clumsy command line flags or protocol implementations. Those aren't things one needs to keep in their head all the time.
Not even remotely accurate. While the dissector is not as mature as I thought and there's no built-in decryption as there is for TLS, that doesn't matter much. Hint: every component of the system is attacker controlled in this scenario.
>Is that because wireshark can't do that just from packet captures?
Well, not quite. I think it's more that nobody has taken the time to implement it. That's not to say such an implementation would automatically decrypt the traffic from a capture with no extra leg work, of course. Wireshark dissectors have user configurable preferences, and presumably this would be where captured secrets could be set for use. This is how it handles TLS decryption [1], which works beautifully.
My thoughts exactly. The OP used AI to get a starting point to their investigation, then used their skills to improve their game, with actual (I guess according to the article itself) proof of that, as opposed to just approving changes from the LLM.
This looks like an actual productivity boost with AI.
Well, I spent a good part of my career reverse engineering network protocols for the purpose of developing exploits against closed source software, so I'm pretty sure I could do this quickly. Not that it matters unless you're going to pay me.
What are you even trying to say? I suppose I'll clarify for you: Yes, I'm confident I could have identified the cause of the mysterious packets quickly. No, I'm not going to go through the motions because I have no particular inclination toward the work outside of banter on the internet. And what's more, it would be contrived since the answer has already shared.
I think the point they're making is that "I, a seasoned network security and red-team-type person, could have done this in Wireshark without AI assistance" is neither surprising nor interesting.
That'd be like saying "I, an emergency room doctor, do not need AI assistance to interpret an EKG"
Sure, but that is aside from my original point. If somebody:
a) Has the knowledge to run tcpdump or similar from the command line
b) Has the ambition to document and publish their effort on the internet
c) Has the ability identify and patch the target behaviors in code
I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently, and would have learned more along the way. Forgive me for being so critical, but the LLM use here simply comes off as lazy. And not lazy in a good efficiency amplifying way, but lazy in a sloppy way. Ultimately this person achieved their goal, but this is a pattern I am seeing on a daily basis at this point, and I worry that heavy LLM users will see their skill sets stagnate and likely atrophy.
>I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently
Hard disagree. Asking an LLM is 1000% more efficient than reading docs, lots of which are poorly written and thus dense and time-consuming to wade through.
The problem is hallucinations. It's incredibly frustrating to have an LLM describe an API or piece of functionality that fulfills all requirements perfectly, only to find it was a hallucination. They are impressive sometimes though. Recently I had an issue with a regression in some of our test capabilities after a pivot to Microsoft Orleans. After trying everything I could think of, I asked Sonnet 4.5, and it came up with a solution to a problem I could not even find described on the internet, let alone solved. That was quite impressive, but I almost gave up on it because it hallucinated wildly before and after the workable solution.
The same stuff happens when summarizing documentation. In that regard, I would say that, at best, modern LLMs are only good for finding an entrypoint into the docs.
While my reply was snarky I am prepared to take a reasonable bet with a reasonable test case. And pay out.
Why I think I’d win the bet is I’m proficient with tcpdump and wireshark and I’m reasonably confident that running to a frontier model and dealing with any hallucinations is more efficient and faster than recalling the incantantions and parsing the output myself.
Oh come on, the fact that the author was able to pull this off is surely indicative of some expertise. If the story started had started off with, "I asked the LLM how to capture network traffic," then yeah, what I said would not be applicable. But that's not how this was presented. tcpdump was used, profiling tools were mentioned, etc. It is not a stretch to expect somebody who develops networked applications knows a thing or two about protocol analysis.
The specific point I was trying to make was along the lines of, "I, a seasoned network security and red-team-type person, could have done this in Wireshark without AI assistance. And yet, I’d probably lose a bet on a race against someone like me using an LLM."
I'm still waiting for a systems engineering tool that can log every layer, and handle SSL the whole pipe wide.
Im covering everything from strafe and ltrace on the machine, file reads, IO profiling, bandwidth profiling. Like, the whole thing, from beginning to end.
Real talk though, how much would such a tool be worth to you? Would you pay, say, $3,000/license/year for it? Or, after someone puts in the work to develop it, would you wait for someone else to duct tape something together approximately similar enough using regexps that open source but 10% as good, and then not pay for the good proprietary tool because we're all a bunch of cheap bastards?
We have only ourselves to blame that there aren't better tools (publicly) available. If I hypothetically (really!) had such a tool, it would be an advantage over every other SRE out there that could use it. Trying to sell it directly comes with more headaches than money, selling it to corporations has different headaches, open-sourcing it don't pay the bills, nevermind the burnout (people don't donate for shit). So the way to do it is make a pitch deck, get VC funding so you're able to pay rent until it gets acquired by Oracle/RedHat/IBM (aka the greatest hits for Linux tool acquisition), or try and charge money for it when you run out of VC funding, leading to accusations of "rug pull" and development of alternatives (see also: docker) just to spite you.
In the base case you sell Hashimoto and your bank account has two (three!) commas, but worst case you don't make rent and go homeless when instead you could've gone to a FAANG and made $250k/yr instead of getting paid $50k/yr as the founder and burning VC cash and eating ramen that you have to make yourself.
I agree, that would be an awesome tool! Best case scenario, a company pays for that tool to be developed internally, the company goes under, it gets sold as an asset and whomever buys it forms a compnay and tries to sell it directly and then that company goes under but that whomever finally open sources it because they don't want it to slip into obscurity but if falls into obscurity anyway because it only works on Linux 5.x kernels and can't be ported to the 6.x series that we're on now easily.
>Current tests suggest it is not likely related to any other known psychedelic compound. For one, the trips it produces are unusually long, commonly lasting 12 to 24 hours, and in some cases even causing hospital stays of up to a week.
Plenty of common psychedelics have durations in excess of 12 hours. Some even in excess of 24 e.g. high doses of 2C-P. This may be a novel compound, but the duration is not necessarily an indicator.
I read this merely as not likely corresponding to any psychedelic compound known to occur in nature, not that it isn't psychedelic. Of course, even that isn't a given, since there could be some interaction between a known compound and a second compound affecting the metabolism of the first one. Although the description of its effects doesn't really sound like any psychedelic I've tried either, and I've tried quite a few
I'm still open to it being psychedelic(primarily acting on the 5-HT-2 receptor family) though. It could just be that there's enough folklore surrounding these mushrooms in the local culture to explain the very specific effects. After all, cultural beliefs are a part of "set and setting".
Another example, this one deliriant and not psychedelic, is atropine/scopolamine, found in certain nightshades, such as deadly nightshade, mandrake, plants in the Datura genus, and trees in the Brugmansia genus. The chemical weapon QNB, also called BZ is another example of a long-acting deliriant.
As far as classic psychedelics go, I've read mescaline (3,4,5-trimethoxyphenethylamine) lasts really long.
My experiences with mescaline are that it has mostly wound down by 6-8 hours though I can tell that I am slightly "off" for a few hours after that. Shorter timeframe than LSD, though not by a whole lot.
I tried it during the summer between 8th and 9th grade after discovering a Datura Stramonium plant growing at a beach on Cape Cod. Fortunately the plant was growing in sand, and the alkaloid content of the plant was very low. I boiled an entire pod down in a soda can and gave it a try. In terms of effects, I did not become delirious, but my perception of gravity was greatly enhanced; I felt like I weighed 600lb. My eyes were also completely incapable of focusing on anything close-up for several days. I never tried Datura again, and I never will. I was lucky I didn't wind up dead, in jail, or in the hospital.
At risk of being called out for my ignorance (I am still new to GPU development and have only limited experience with CUDA), it seems to come down to how appropriate the execution model is to the work e.g. SIMT vs SIMD here.
That's the thing though, setting bg color opens up a lot of options, and constraining to invert is not sufficient in my opinion.