Maybe you're right. I just find it confusing. The language is all-encompassing, doesn't read opt-in to me if taken literally: "By submitting any vulnerabilities to Microsoft". And I found no other pages describing "report in such and such way to have these terms apply instead". But I always have problems with this stuff, perhaps taking it too seriously.
Obviously they can write whatever they want in their policy documents. The thing is, sometimes this is about larger sums of money, or someones reputation, which may or may not actually lead to steps. That is in contrast with whatever TOS/EULA in account signups for some service or whatever, this feels more serious. I've seen some people getting harried after publishing something that fell _outside_ the servicing boundaries. Getting tangled up in whatever is already a loss in my book, even if you "win" in the end.
Note that that policy is also where they set out the safe-harbor conditions, which, according to my read, is tied to the bounty policy and not RD/CVD policy. The RD/CVD page itself specifies no such thing, so I relate them.
> The Microsoft Bug Bounty Programs Terms and Conditions ("Terms") cover your participation in the Microsoft Bug Bounty Program (the "Program"). These Terms are between you and Microsoft Corporation ("Microsoft," "us" or "we"). By submitting any vulnerabilities to Microsoft or otherwise participating in the Program in any manner, you accept these Terms.
Microsoft's policy is: "if you contact us with a vulnerability, you automatically agree to the terms of our responsible disclosure policy", which includes waiting 30 days after patch was created, and says nothing about how long that process takes.
There is actually no way to give them a friendly heads up, and then do your own thing. The only way not to be bound is by not sending them any notification at all...
You can imagine a pipeline that looks at individual source files or functions. And first "extracts" what is going on. You ask the model:
- "Is the code doing arithmetic in this file/function?"
- "Is the code allocating and freeing memory in this file/function?"
- "Is the code the code doing X/Y/Z? etc etc"
For each question, you design the follow-up vulnerability searchers.
For a function you see doing arithmetic, you ask:
- "Does this code look like integer overflow could take place?",
For memory:
- "Do all the pointers end up being freed?"
_or_
- "Do all pointers only get freed once?"
I think that's the harness part in terms of generating the "bug reports". From there on, you'll need a bunch of tools for the model to interact with the code. I'd imagine you'll want to build a harness/template for the file/code/function to be loaded into, and executed under ASAN.
If you have an agent that thinks it found a bug: "Yes file xyz looks like it could have integer overflow in function abc at line 123, because...", you force another agent to load it in the harness under ASAN and call it. If ASAN reports a bug, great, you can move the bug to the next stage, some sort of taint analysis or reach-ability analysis.
So at this point you're running a pipeline to:
1) Extract "what this code does" at the file, function or even line level.
2) Put code you suspect of being vulnerable in a harness to verify agent output.
3) Put code you confirmed is vulnerable into a queue to perform taint analysis on, to see if it can be reached by attackers.
Traditionally, I guess a fuzzer approached this from 3 -> 2, and there was no "stage 1". Because LLMs "understand" code, you can invert this system, and work if up from "understanding", i.e. approach it from the other side. You ask, given this code, is there a bug, and if so can we reach it?, instead of asking: given this public interface and a bunch of data we can stuff in it, does something happen we consider exploitable?
Hey jstsch, would you mind answering some questions?
- Did you need/use an electrician to set this up?
- How much KWh capacity do your batteries have?
- What about fire safety? Did you install outside, or inside?
- I assume dec/jan are the months you're not fully self-sufficient, are you allowed to charge from grid to do arbitrage over time, or is that another can of worms?
> 1) Are there any reliable open-source PAM alternatives or privilege elevation tools for Windows that handle this "per-app" scenario effectively?
I would look into:
- creating an account to run the apps you need, giving the user the password to this account, or create a shortcut to execute the browser with "runas"
Now here my ideas break down, but I think you could get far with:
- For that account, (log in as it, open IE), and configure the "secure zone" / "internet zone" as "insecure". Allow all active X components to load.
- As an admin:
1) Start/go into "Component services" (run: "DCOMCNFG")
2) Right-click "my computer" -> properties:
3) "Edit default" for both activation and access permissions and for both default and limits:
3.1) Give the new user basically all privileges.
3.2) Review if the process now works with the lower privileged user.
3.3) Reduce privileges as far as possible until the process breaks. Stop there.
4) Consider that "Remote launch" and to a lesser extent "remote access", exposes the computer to remote control _if_ the credentials for the user with those privileges are leaked.
5) Consider if this is worth the risk, if yes, leave the configuration. You're done :)
Some unconnected suggestions:
- The page that loads the active X will have a number of GUIDs in them, those are the COM classes that back the active X objects (just DCOM objects). You can look those up in the registry to find the implementing .dll files, paths, etc. etc.
- You _can_ whitelist / safelist individual COM / ActiveX packages if you need to but I've forgotten the exact way to do this, and also what exactly it allows you to do ;). You may find: https://github.com/tyranid/oleviewdotnet useful to research this, it has a tab for "pre approved objects", I think if you get your ActiveX's in that list they'd be able to run under the user you need to. If you can access the HTML page you need to open which loads the ActiveX components, you can search for the CLSIDs in that tool, and perhaps figure out where they are. I'm 90% you can move the CLSIDs to a registry key to put them on the safe list, perhaps that's already enough to bypass the "local admin required".
You may be able to do the launch permissions per com object in `DCOMCNFG`.
> 2) When dealing with hostile ActiveX components, are there specific legacy behaviors (beyond obvious file/registry Access Denied) I should be looking for in my Procmon captures?
If you mean, _abused_ ActiveX components, not much you can do. Obviously yes, access to registry, etc. But if the attacker gets to a point they can load _arbitrary_ dcom objects and talk to them, it's game over, that's RCE.
If you mean, how to find which COM objects I need to allow. Better luck with `oleviewdotnet` I think. And open that page and look for the CLSIDs to know where to start. You can search in the registry and oleview to find them once you have the CLSIDs (guids).
> 3) How do you isolate this kind of hardcoded legacy requirement when there is zero budget for commercial enterprise tools?
I assume you are on a much older version of windows? Xp? 2000?, Then I'm not sure.
The bar to ingest unstructured data into something usable was lowered, causing more people to start doing it.
Used to be you needed to implement some papers to do sentiment analysis. Reasonably high bar to entry. Now anyone can do it, the result: more people doing scraping (in less competent scrapers too).
> Your company can scream to anyone that listens that all the competition is AI SLOP, but when hundreds of companies are pitching the same solution, your one voice will get lost.
If you cannot out compete "AI SLOP" on merit over time (uptime? accuracy? dataloss?), then the AI SLOP is not actually sloppy...
If your runway runs out before you can prove your merit over that timeframe, but you are convinced that the AI is slop, then you should ship the slop first and pivot onec you get $$ but before you get overwhelmed with tech depth.
Personally, I love that I can finally out compete companies with reams of developer teams. Unlike many posters here, I was limited by the time (and mental space) it takes to do the actual writing.
IMO it's shoddy. Anybody can get hacked, that's true. But a modern corp that has tried to defend itself should have multiple layers of defenses against complete pwnage.
If you've paid attention in the last 10 (or even 5) years as a company, and did some pentests and redteams, you've seen how you could be breached, and you took appropriate steps years ago.
A non-shoddy company will have:
- hardened their user endpoints with some sort of modern EDR/detection suite.
- Removed credentials from the network shares (really).
- Made sure random employees are not highly privileged.
- Made sure admin privileges are scoped to admin business
roles (DBA admin is not admin on webservers, and vice-versa).
- Made sure everyone is using MFA for truly critical actions and resource access.
- Patched their servers.
- Done some pentests.
This won't stop the random tier 2 breach on some workstation or forgotten server still hooked up on prod/testing, but it will stop the compromise _after_ that first step. So sure, hackers will still shitpost some slack channel dumps, but they won't ransomware your whole workstation fleet...
SS7 which is used to route calls, sms, can be spoofed. Any person with access to a cell tower (hop over a fence, break the padlock, plug your laptop in) or access to the Telecom backbone (hack a Telecom provider, buy a link). Can hijcak any number.
Well if you want to start reverse engineering, I'd think you'd need a very deep understanding of C.
When reversing it doesn't help you if you know what a single instruction is doing. You need to be able to recompile the program in your head, and translate it back to high-level logic. You need far more knowledge of C than just the 'learn C in 21 days' stuff if you really want to start reverse engineering.
Obviously they can write whatever they want in their policy documents. The thing is, sometimes this is about larger sums of money, or someones reputation, which may or may not actually lead to steps. That is in contrast with whatever TOS/EULA in account signups for some service or whatever, this feels more serious. I've seen some people getting harried after publishing something that fell _outside_ the servicing boundaries. Getting tangled up in whatever is already a loss in my book, even if you "win" in the end.
Note that that policy is also where they set out the safe-harbor conditions, which, according to my read, is tied to the bounty policy and not RD/CVD policy. The RD/CVD page itself specifies no such thing, so I relate them.