Showing posts with label mitm. Show all posts
Showing posts with label mitm. Show all posts

Sep 26, 2022

HTTP Security

Here are a few commonly seen HTTP security features.


Content Security Policy (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate Cross-Site Scripting (XSS) and data injection attacks.  

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header.  If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy. 

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes).

Examples:

Content-Security-Policy: default-src 'self'

Content-Security-Policy: default-src 'self' example.com *.example.com

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

Content-Security-Policy: default-src https://onlinebanking.example.com

Content-Security-Policy: default-src 'self' *.example.com; img-src *

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi


Using HTTP cookies

An HTTP cookie is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is used to tell if two requests come from the same browser—keeping a user logged in.

Cookies are mainly used for three purposes: Session management, User preferences, and Tracking.

Instead of using cookies, modern APIs for client storage are the Web Storage API (localStorage and sessionStorage) and IndexedDB. 

Example (set cookies) on sending cookie to client browser.

Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

Set-Cookie: mykey=myvalue; SameSite=Strict

Example () on sending stored cookies to web server.

Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Additional ways to mitigate attacjs involving cookies:

  • Use the HttpOnly attribute to prevent access to cookie values via JavaScript.
  • Use the Secure attribute to prevent MiTM attack and ensure its never sent with unsecured HTTP.
  • Use short lifetime, with SameSite attributes to protect sensitive info.

 

Same-origin policy (web security)

The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.  

"Same origin" means the protocol, port (if specified), and host are the same for both. It is referenced as the "scheme/host/port tuple".

For example, an URL at http://store.company.com/dir/page.html will give origin comparison as below:

URLReasonOutcome
http://store.company.com/dir2/other.html Only the path differs Same origin
http://store.company.com/dir/inner/another.html Only the path differs Same origin
https://store.company.com/page.html Protocol different Fail
http://store.company.com:81/dir/page.html Port different Fail
http://news.company.com/dir/page.html Host different Fail

Other schemes or URL, such as javascript: and about:blank, are inherited origins from the page. But data: scheme get a new security context. file:/// schema is treated as opaque origins. 

Use CORS to allow cross-origin access. CORS is a part of HTTP that lets servers specify any other hosts from which a browser should permit loading of content.

 

Strict-Transport-Security (HTTP header)

The HSTS or HTTP Strict-Transport-Security response header informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.

Example of all the present and future subdomains will be HTTPS for a max-age of 1 year:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Strict-Transport-Security: max-age=31536000; preload

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

To detect if a HTTPS server is supporting HSTS, check the post at When HTTPS is not Sufficient.

 

X-Content-Type-Options (HTTP header)

This is a web server HTTP header to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured. 

For example, it can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than text/html.

Site security testers usually expect this header to be set, such as:

X-Content-Type-Options: nosniff


X-Frame-Options (HTTP header)

This is a web server response header to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

If you specify DENY, the page cannot be displayed in a frame, regardless of the site attempting to do so.

If you specify SAMEORIGIN, the page can only be displayed if all ancestor frames are same origin to the page itself.


X-XSS-Protection (HTTP header)

This is a server response header sent to browser that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protection is unnecessary when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').

This feature is not a standard feature for all browsers. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

Directives:

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

Examples:

X-XSS-Protection: 1; mode=block

Apache (.htaccess):

<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>

Nginx:

add_header "X-XSS-Protection" "1; mode=block";


Links:

  1. Content Security Policy (CSP)
  2. Using HTTP cookies
  3. Same-origin policy (web security)
  4. Strict-Transport-Security (HTTP header)
  5. X-Content-Type-Options (HTTP header)
  6. X-Frame-Options (HTTP header)
  7. X-XSS-Protection (HTTP header)
  8. HTTP Request Methods 

Jun 22, 2022

New Attack Vector PetitPotam

Still remember PetitPotam attack?

PetitPotam is an NTLM Relay Attack tracked as CVE-2021-36942 that French security researcher GILLES Lionel discovered, aka Topotam, in July 2021. 

It is an NTLM Relay attack that allows threat actors to force devices, even domain controllers, to authenticate against malicious servers they control. Once a device authenticates, the malicious server can impersonate the device and gain all of its privileges.

The PetitPotam attack allowed unauthenticated users to use the EfsRpcOpenFileRaw function of the MS-EFSRPC API to force a device to perform NTLM authentication against attacker-controlled servers.

In 2022 (Jan ~ Mar), a security researcher, Raphael John, says that he discovered that PetitPotam was still working when conducting pentests. However, when he disclosed it to Microsoft, they fixed it under a new CVE rather than the original one assigned to PetitPotam.

A PoC tool, from Topotam, to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw. 

The tool uses the LSARPC named pipe with inteface c681d488-d850-11d0-8c52-00c04fd90f7e because it's more prevalent. But it's possible to trigger with the EFSRPC named pipe and interface df1941c5-fe89-4e79-bf10-463657acf44d. It doesn't need credentials against Domain Controller. And disabling the EFS service seems not to mitigate the "feature".

 

During the May 2022 Patch Tuesday, Microsoft released a security update for an actively exploited NTLM Relay Attack labeled as a 'Windows LSA Spoofing Vulnerability' and tracked as CVE-2022-26925.

In June 2022, a new DFSCoerce Windows NTLM relay attack has been discovered that uses MS-DFSNM, Microsoft's Distributed File System, to completely take over a Windows domain.

A security researcher, Filip Dragovic, released a proof-of-concept script for a new NTLM relay attack called 'DFSCoerce' that uses Microsoft's Distributed File System (MS-DFSNM) protocol to relay authentication against an arbitrary server.

The DFSCoerce script is based on the PetitPotam exploit, but instead of using MS-EFSRPC, it uses MS-DFSNM, a protocol that allows the Windows Distributed File System (DFS) to be managed over an RPC interface.

To coerce a remote server to authenticate against a malicious NTLM relay, threat actors could use various methods, including the MS-RPRN, MS-EFSRPC (PetitPotam), and MS-FSRVP protocols.

These mitigations include disabling NTLM on domain controllers, disabling web services on Active Directory Certificate Services servers, and enabling Extended Protection for Authentication and signing features, such as SMB signing, to protect Windows credentials.


Links:

Apr 23, 2021

When HTTPS is not Sufficient

HSTS stands for HTTP Strict Transport Security.

HSTS is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. The HSTS Policy is communicated, from the server to the user agent, via an HTTPS response header field named "Strict-Transport-Security".

It specifies a period of time in which the user agent should only access the server in a secure fashion.[2] 

Note that the protection only applies after a user has visited the site at least once. It works by upgrade to HTTPS automatically, without making an HTTP request, to prevents the HTTP man-in-the-middle attack from occurring. 

To detect if a HTTPS server is supporting HSTS, just examine the HTTP response header if the following header exists.

Strict-Transport-Security: max-age=31536000; 

It is accepted in HTTPS communication only. The max-age parameter specifies how long to remember the rule in seconds (31536000 corresponds to a year). Append ; includeSubDomains at the end to apply the rule for all subdomains as well.

Here, I'm using my browser (MS Edge) to query if a website is supporting HSTS or not. Enter the "edge://net-internals/#hsts" or "chrome://net-internals/#hsts" at the URL, and put in the website for query.

support HSTS


Nowadays, it is hardly find a website that does not support HSTS, so I run a simple HTTP in my lab.

Not supporting HSTS

Benefits of HSTS:

  • Simple to implement at web server.
  • Helps in implementing HTTPS correctly.
  • Enabling HSTS helps to ensure that you remain compliant with privacy and data security regulations that require the use of HTTPS.

Links:

  • https://www.rapid7.com/blog/post/2011/05/03/strictly-https/
  • https://www.rapid7.com/db/vulnerabilities/hstsdetection-hstsattack-1/
  • https://www.rapid7.com/db/modules/auxiliary/scanner/http/http_hsts/