Unfortunately for the version of myself writing this, this silly browser security finding that I released months ago is more than patched, so this post is just because I want to upload content to this blog and collect the mess of screenshots, written things and links that are my notes.

With that being said, I want to show a proof of concept whereby you could extract an NTLM hash via JavaScript. Actually it is not only with JavaScript, we cheat a bit, but it is interesting and it helps us to understand how the different components that make up the sanbos of the browser are related.

We are going to present the two concepts involved in this proof of concept, the file:// wrapper and the sourceMappingURL

sourceMappingURL is a directive that can be added to the end of a JavaScript or CSS file to specify the location of a source map file. A source map is a file that maps the code in a minified or compiled file back to the original source code.

For example, consider the following JavaScript file:

1
2
3
4
5
6
7
function add(a, b) {
  return a + b;
}

console.log(add(1, 2));

//# sourceMappingURL=app.js.map

The sourceMappingURL directive at the end of the file specifies the location of the source map file for this JavaScript code. The source map file contains information that allows a debugger or other tool to map the code in the minified file back to the original source code, making it easier to debug or understand the code.

Source maps are often used in conjunction with tools that minify or compile code, in order to make it easier to debug and work with the resulting code. They are an important tool for developers working with minified or compiled code.

Well, the second concept that we have to take into account is that of the wrappers that the browser uses when accessing different resources.

The file:// protocol is used to access files on the local file system, rather than on a remote server. When a web browser accesses a source with a file:// URL, it will retrieve the file from the local file system and treat it as if it were a web page.

There are a few security considerations to keep in mind when using file:// URLs:

  • Local files may have different permissions than files on a web server, which could potentially allow an attacker to access sensitive information.
  • Local files are not subject to the same security measures as files on a web server, such as content security policies (CSP) or the same-origin policy. This could potentially allow an attacker to inject malicious code into a web page or access sensitive information.
  • Some web browsers may block file:// URLs or restrict their access to certain features in order to protect against these risks.
  • It is generally not recommended to use file:// URLs to access sources on the local file system, especially in production environments. Instead, it is generally better to use a web server to serve files, and to use http:// or https:// URLs to access them. This will ensure that appropriate security measures are in place to protect against malicious activity.

It is possible to use a file:// URL to access a file on a remote server using the Server Message Block (SMB) protocol. However, this can be a security risk because it could potentially allow an attacker to capture the user’s NT LAN Manager (NTLM) hash, which is used to authenticate the user to the server.

NTLM hashes are vulnerable to attack, and an attacker who is able to capture an NTLM hash can potentially use it to gain unauthorized access to the server. This is why it is generally not recommended to use file:// URLs to access remote servers, especially in cases where sensitive information is stored on the server.

Instead of using a file:// URL to access a file on a remote server, it is generally better to use a network share or a web server to access the file. This will ensure that appropriate security measures are in place to protect against the capture of NTLM hashes and other types of malicious activity.

There are several HTML tags that can be used to reference a local resource using a file:// URL:

  • <a>: The <a> (anchor) tag can be used to create a link to a local resource. For example: <a href="file:///C:/path/to/file.html">Link to file</a>

  • <img>: The <img> (image) tag can be used to display an image from a local file. For example: <img src="file:///C:/path/to/image.jpg" alt="Local image">

  • <script>: The <script> tag can be used to include a JavaScript file from a local source. For example: <script src="file:///C:/path/to/script.js"></script>

  • <link>: The <link> tag can be used to include a stylesheet from a local file. For example: ```

It is generally not recommended to use file:// URLs to reference local resources in a production environment, because it can be a security risk. Instead, it is generally better to use a web server to serve files, and to use http:// or https:// URLs to access them. This will ensure that appropriate security measures are in place to protect against malicious activity.

So, if we call from a sourceMappingURL resource using a file:// wrapper, it will make a connection looking for the file, authenticating itself through NTLM, it will be on this server where we can intercept the hash.

poc

However, for the browser to make this request, you have to access the browser’s devtools, an action that cannot be forced from JavaScript, so we’re sad, it doesn’t matter anyway, the bug has been patched

A hug 4 all hackers ^^