Hacking the web: Breakpoints and making a “watcher” all in console. (Carefully) [level adv]
WARNING:
BE CAREFUL WITH THIS . IT IS POWERFUL AND IF THIS IS UNKNOWN (THE TOPIC) THEN ITS COMPLETELY UNKNOWN HOW IT WILL AFFECT RUNTIME ON A PRODUCTION REMOTE SITE —
With the “disclaimer” out of the way, I cant stress enough that you need to practice, read alot and know your JS to pull this off effectively on a production env, for a real pentest or bounty. The point of doing the break point this way, is just for convienence and automation — the normal way is to right click the line in Inspect and set break point. It would be a good idea to know how to do both.
Why do we need breakspoints at all?
If you need to look this up or dont know, I would not proceed with any of the JS on a live site. To answer the question — the best way I could describe the way in a general sence how a webpage continunes to “work’ even while the page is loaded and looks idle. The “state” of the DOM / VM (inside the browser is virtualized env. you will notice it called VM. its constantly running monitoring the state of what keys are being pressed on the page, mouse movements, etc. Setting a break point can assist the developer and/or pentester identify the value of various variables (both declared by you in your code, or by dependencies) or predefined built in’s — can be a excellent source of informatoin and it is somewhat complex which (if you master the topic) will set you apart, and will get you the high paid bounties.
Definitions:
Breakpoint: (in terms of this situation) A point in time of the Java Runtime and loading of the DOM (Document Object Model) that stops and the user/developer can check values at certain times of execution.
Watcher: A snippet of code you paste into console, which will identify where to stop the script (page) on next load
Web Runtime Environment: The Java Virtual Machine is running all the time on the page rendered while you are in console, so you can stop it at different interesting points in memory.
If those 3 definitions have you scratcing your head, do not continue with this article, read up deeply on javascript. then come back.
Contining on. Implementing a watcher inconsole (without manually setting it or manually setting it) could be called “Breaking Execution” — Normally you have to goto Elements and find the line to right click add breakpoint. We will identify points in memory and write a short snip. of code paste it it run the debugger and analyze the memory.
Lets jump right, youll thank me and know a ninja trick Open incogito chrome tab to hxxps://npmjs.com — Right click/ Inspect
On npmjs.js they are using highlight.js — (After clicking inspect/console):
Start out with a quick test — to validate we are not blocking alert()’s
Pasting in to the “console” tab:
alert(1); // You should see a popup on the page:
Sometimes you have to type: allow pasting (in order to type in console)
(After clicking OK on alert) → Paste in:
javascript:(function() { if (window.Highlighter) { debugger; } else { console.log(“highlighter.js not detected”); } })();
For breaking execution when a specific script like highlight.js (assuming you mean a syntax highlighting library or any script with a similar name) is loaded, you would typically follow a similar approach to the jQuery example, but with a condition that checks for something unique to highlighter.js. This could be a global object or function that the script creates. However, if highlighter.js doesn't expose a clearly identifiable object or function globally, detecting its load might be trickier and would require a more generic approach, such as monitoring changes to the DOM or script elements.
Regarding making such breakpoint one-liners “global” in the sense that they apply across multiple pages or sessions without needing to paste them each time, there isn’t a built-in feature in browsers that persistently applies such custom JavaScript across different pages or sessions for obvious security and performance reasons. However, there are a few strategies you could consider:
- Extensions: Developing a small Chrome extension that injects your specific code into every page you visit. Extensions can have persistent scripts that run according to your specifications.
2. Bookmarklets: Convert your script into a bookmarklet that you can click whenever you need to apply the breakpoint. This isn’t fully automatic but is a quick way to reapply the script.
3. User Scripts: Use a userscript manager like Tampermonkey or Greasemonkey. These tools allow you to write scripts that automatically run on pages you define, acting similarly to a self-made extensio
Example Bookmarklet for highlighter.js
Assuming highlighter.js sets a global variable or object named Highlighter when loaded, here's how you could make a bookmarklet. Note that this is just an illustrative example; you'd need to adjust it based on the actual global identifiers highlighter.js uses.
- {level: ‘warn’, message: ‘[websockets] Overwriting existing handler without silencing. This may indicate a race condition.’}
level: “warn”, message: “[websockets] Overwriting existing handler without silencing. This may indicate a race condition.”
[[Prototype]] : Object
[ Console Breakpoint JS memory watcher ]
[*] Runtime Example paste in the following to start watching:
var debugWatcher = setInterval(() => { console.trace(‘Watcher Trace’); console.log(‘Variable:’, variableName); }, 5000);
[*] Clear the watcher runtime from memory
clearInterval(debugWatcher);]
This will display every 5000ms (5s) on the console. various objects and data depending on what you set it to. Observe headers, the values of the headers and cookies, etc, etc, this can give you an idea of where you in terms of pivoting — in these complex cloud env’s we are dealing with now. I have found its good to attempt to diagrm out your target and learning Visio is always helpful.
Warning:
Even with the best of “hacker tools” and debuggers you have no idea what is actaully happening in the back end, espicially if processes are spawned on various other unseen backend servers.
[ Example output ]
This is initially what I got when I just tried that example on chatGPT:
20:29:22.400 Failed to load resource: the server responded with a status of 403 ()
20:29:22.700 [Intercom] Launcher is disabled in settings or current page does not match display conditions
20:29:22.719 /backend-api/compliance/cookie_consent:1
20:29:22.734 API error https://chat.openai.com/backend-api/compliance/cookie_consent Cannot update user’s compliance settings
29:23.233 _app-20<snip>63.js:1 Uncaught (in promise) FatalServerError: Cannot update user’s compliance settings
20:46:31.459 Error with Permissions-Policy header: Unrecognized feature: ‘document-domain’.
20:29:46.515 react-scroll-to-bottom: Please set “behavior” when calling “scrollToBottom”. In future versions,
the default behavior will be changed from smooth scrolling to discrete scrolling to align with HTML Standard.
— — — After 5 minutes — seeing *extensive* amounts of errors and msgs: [This is after “unloading” it)
mous) @ VM304:1
20:47:53.710 VM304:1 Uncaught ReferenceError: variableName is not defined
at <anonymous>:1:97
If anyone is interested, I closed the tab and reloaded ChatGPT and it was fine, but here is the stacktrace
/ error log that I got prior to closing window → https://pastebin.com/raw/MEVjUBJJ
— — — — — A more complex example / less potential for odd behavior, but more potential for finding vulnerabilities
This new console script is going to have multiple phases:
Definitions:
Watcher — our script we paste into console
Detection Phase: — initial phase, the watcher identifies custom objects, prototypes, and global variables that might be vulnerable.
Techniques like heuristic analysis or pattern matching against known vulnerable structures can be employed.
The goal is to pinpoint elements in the code that warrant closer scrutiny.
Monitoring Phase:
Once potential vulnerabilities are detected, the system focuses on monitoring these elements more closely.
It logs their states or any changes at regular intervals or in response to specific events.
By doing so, it keeps a watchful eye on variables that could pose security risks.
Analysis and Reporting Phase:
Collected data undergoes analysis to identify suspicious or anomalous behaviors.
These behaviors may indicate exploitation or vulnerability.
The system can generate reports or alerts for further investigation.
Implementing the Detection Phase: To expand beyond the original one-liner, consider the following approaches:
Listing Custom Defined Prototypes and Objects:
Begin by listing all custom-defined prototypes and objects.
While challenging in a global scope due to the abundance of built-in objects and variables, focus on identifying objects not part of the standard JavaScript environment.
— — — — More complex example — — — -
Creating a more advanced debug watcher that “learns” about potentially vulnerable variables, objects, or prototypes
and then focuses on monitoring them is an intriguing idea. This concept involves dynamically identifying and
tracking parts of the code that could be susceptible to common web vulnerabilities like prototype pollution, XSS,
or other injection attacks. Implementing such a system in JavaScript, particularly in a browser environment,
involves several steps and considerations
Detection Phase:
The watcher would need an initial phase to detect custom objects, prototypes, and global variables that
could potentially be vulnerable. This might involve heuristic analysis or pattern matching against known
vulnerable patterns or structures.
Monitoring Phase:
Once identified, these elements would be monitored more closely than others, logging their states or any
changes to them at regular intervals or upon specific events.
Analysis and Reporting Phase:
The system should analyze the collected data, potentially identifying suspicious or anomalous behaviors
that could indicate exploitation or vulnerability.
Implementing the Detection Phase
To expand the original one-liner into something capable of identifying potentially vulnerable variables or
objects, consider the following approaches:
Listing Custom Defined Prototypes and Objects
Start by listing all custom-defined prototypes and objects. This can be tricky in a global scope due to the sheer number of built-in objects and variables, but you can look for objects that are not part of the standard JavaScript environment.
javascript
Copy code
Object.getOwnPropertyNames(window).forEach(prop => {
if (typeof window[prop] === ‘object’ || typeof window[prop] === ‘function’) {
console.log(prop, window[prop]);
}
});
Detecting Commonly Exploited Objects
For commonly exploited objects, such as those susceptible to prototype pollution, you could monitor modifications to prototype chains or unexpected property additions. Monitoring all property changes on all objects is not feasible for performance reasons, but you can focus on critical objects known to be targets of such attacks.
Implementing the Monitoring Phase
For the variables or objects identified as potentially vulnerable, use Object.observe (deprecated but illustrative for this example) or Proxy objects to monitor changes to their properties or behaviors.
javascript
Copy code
// Example using Proxy to monitor an object for changes
const monitoredObjects = {}; // Placeholder for objects identified as vulnerable
Object.keys(monitoredObjects).forEach(key => {
monitoredObjects[key] = new Proxy(monitoredObjects[key], {
set(target, property, value) {
console.log(`Change detected in ${key}: property ${property} set to`, value);
// Original set operation
target[property] = value;
return true; // Indicate success
}
});
});
Analysis and Reporting Phase
The data collected by the watcher would be analyzed to identify patterns indicative of exploitation or vulnerability. This could involve checking for unexpected changes, accesses from suspicious sources, or other anomalies.
Integrating Machine Learning
To make the watcher “learn” over time, you could integrate machine learning algorithms that analyze the behavior and evolution of the monitored objects and variables. The learning component could adjust its focus based on detected patterns, improving its ability to identify potential vulnerabilities.
This approach would require a backend capable of processing and analyzing the data collected by the debug watcher, along with a model trained to recognize patterns associated with common vulnerabilities.
Performance: Constantly monitoring and analyzing variables and objects can significantly impact performance, especially if done in the main thread of a web application.
Security: There’s a fine line between detecting vulnerabilities and inadvertently creating new ones by exposing sensitive information through the watcher itself.
Lastly, remember type: undebug (or undebugger(); ) depending on what populates while you type it. Do not leave your modifications to any prototypes and debuggers running. Always verify the site is working fine after testing , incognito obviously.
Tll next time
substance
