Funnily enough I've found that LLMs can be effective at mitigating many of the drawbacks of black-box testing and i've significantly expanded our usage of it over the past year
Reading the title I saw the words "room-temperature" and my mind auto-completed it to superconductor, and based on other comments I don't think i'm alone in that.
How do you suggest I determine the information is bad, if the domain is hosted on tesla.com, and Tesla says I am authorized to test it? Should I inspect all 1,368 subdomains on tesla.com by hand, and then do the same for 400+ bug bounty programs?
Maybe i'm old fashioned, but personally I think the onus should be on the person sending out unauthorized malicious requests to figure out how to not do that.
Any responsible bug bounty researcher reviewing the DNS zone by hand would spot the CNAME and remove it from the target list. You don't get to wash your hands of that because your chatbot did it.
Even before AI, I can't imagine a single bug bounty researcher doing that. Pre-AI, everyone ran a tool like subfinder to enumerate subdomains, httpx to resolve them, nuclei to scan them, etc. There's no human review involved there at the subdomain level.
And I don't know anyone that would really look at the intermediary of a CNAME even during a manual test. Maybe if it was obviously a third party service.
When I engage a security assessor on behalf of a client, I am required to provide detailed scope and attest to in scope assets (including IP blocks and public hostnames), as well as that I have legal authority for them to be tested. This is validated by my executive sponsor.
It is your responsibility to do your due diligence as a security researcher versus “spray and pray” to ensure you are not exceeding the scope beyond your intended target.
Dump the subdomains, resolve them, and review where they resolve to in order to understand the footprint and attack surface boundaries before engaging scanning or agentic red team harnesses. Automate as much as possible for building the state graph of the target, but a human must remain in the loop to sanity check. To not do this means you could be attacking hyperscaler object storage, a CDN, a partner SaaS frontend, ticketing systems, mail systems, etc (ie anything someone may CNAME off the root domain but that is outside of their organization’s control).
I reckon there's a decent argument to be made that an authorization to scan *.tesla.com definitively does NOT extend to any hosts resolved via a CNAME chain that goes foo.tesla.com -> bah.not-tesla.com -> host-that-never-authorized-attacking.
You're now confident that the other 399+ domains you mentioned are not under any sort of duress because they're controlled by people who are away of what's happening?
I feel confident that no system exposed to the internet should have a problem with 50,000 requests per month! If they do, they probably shouldn't run a public NTP server, or have a public IP address at all.
Okay, so you're just confident in exactly how many requests everyone else in the world will be making if you try to pentest resources unbeknownst to their owners.
Are you confident you are not viewing too many pages on HN? What if many other people are also trying to read this thread?
I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
> Are you confident you are not viewing too many pages on HN? What if many other people are also trying to read this thread?
I think it's pretty disingenuous to compare viewing a couple of pages once a day with running scripting tools against over 400 websites.
> I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
Oh good, no one has ever claimed "it's for your own good" when doing something selfish without consent.
We can quantify the impact of the scripting tools pretty easily - 1.5k requests per day! I just went on Reddit and viewed a few posts, and it caused about 500 HTTP requests in DevTools. Luckily HN is not that bloated, but I just don't see the number of requests as meaningful even if it was orders of magnitude higher.
As the OP said, they don't do anything when the server isn't vulnerable, and serving a 404 page is incredibly cheap.
This is why IP certificates are limited to a max lifetime of 6 days.
> IP address certificates allow server operators to authenticate TLS connections to IP addresses rather than domain names. Let’s Encrypt supports both IPv4 and IPv6. IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important.
> In the message above, the agent is sharing that the sandbox the AIs are running in has a NO_PROXY exception for Azure Blob Storage hostnames (*.blob.core.windows.net).
...
> Next, by changing its /etc/hosts file, which declares mappings from hostnames to IP addresses, the agent can point the fake hostname at the real Power BI dashboard, and fool the security proxy
I have poor eyesight and need to sit closer than normal, and I find 27" to be just a tad too large. In my home-office setup I have a decade-old 24" 4K IPS panel that is the perfect size, and I dread the day it gives up the ghost because apart from some very expensive professional monitors, no-one seems to make them at that size and resolution class any more.
If you can reproduce it reliably and doing so generates some form of telemetry, then just set up some automation to keep doing that in a loop. From as many machines as possible.
No comment is offered on if I have ever gotten a bug noticed this way.
Hell, I've hand-written a large PR as a single commit and then asked claude to break it down for me at least once. But I think the fact doing this task by hand is a tedious, time-consuming hassle is not because it inherently has to be but because the tooling for doing it has barely changed in the past 15 years.
> The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.
What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?
You want to ship every debug utility you will need in every image? Just seems wasteful. What about 3rd party images, you will respin images just to add your preferred toolset?
> every debug utility you will need in every image? Just seems wasteful
How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size.
I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.
Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too.
For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.
Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
What percentage of CVEs can be used to obtain a shell, but can't otherwise be used to obtain some other form of code execution in a distro-less container?
I haven't run any stats and am certainly not an expert but I would expect quite a few. In the one scenario you merely need to pull off an exec with a valid path. In the other you need to either write a block of memory and mark it as executable or else write your payload out to disk and mark the file executable. So it's the difference between being able to pull off a single syscall versus most likely needing arbitrary code execution.
reply