HSTS - HTTP Strict Transport Security

[toc]

---

HSTS - HTTP Strict Transport Security

• The HTTP Strict Transport Security (HSTS) header
• a web security policy mechanism
• web sites communicate to browsers that all traffic exchanged with a given domain must always be sent over https
  • protect the information from being passed over unencrypted requests.
  • ensure that all the data travels encrypted from the web browser to the server.
• The HSTS Policy is communicated by the server to the user agent via a HTTP response header field named "Strict-Transport-Security".
  • HSTS Policy specifies a period of time during which the user agent shall access the server in only secure fashion.
  • The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP. Instead it should automatically establish all connection requests to access the site through HTTPS.

The HSTS header uses two directives:

• -max-age:
  • the number of seconds that the browser should automatically convert all HTTP requests to HTTPS.
• includeSubDomains:
  • all web application’s sub-domains must use HTTPS.
  • If this parameter is set, then the HSTS policy applies to the visited domain and all the subdomains as well.
  • If not it only applies to the exact domain that the user has visited.

This header by web applications must be checked,

When a web application issues HSTS Policy to user agents, avoid following:

1. Attackers sniffing the network traffic and accessing the information transferred through an unencrypted channel.
2. Attackers exploiting a man in the middle attack because of the problem of accepting certificates that are not trusted.
3. user clicks on HTTP links or even if the user type an HTTP link.
   • Users mistakenly entered an address put HTTP instead of HTTPS
   • users click on a link which mistakenly indicated the http protocol
4. prevents an user from accepting self-signed or abnormally signed certificates, since remember the certification authority (CA) that signed the previous seen certificate.

$ curl --silent --head https://us.com/ | grep -i strict
strict-transport-security: max-age=7776000000;
includeSubDomains

---

Remediation

Configure webserver to redirect HTTP requests to HTTPS.

• i.e. for Apache, you should have modification in the httpd.conf.

# load module
LoadModule headers_module modules/mod_headers.so

# redirect all HTTP to HTTPS (optional)
<VirtualHost *:80>
       ServerAlias *
       RewriteEngine On
       RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>

# HTTPS-Host-Configuration
<VirtualHost *:443>
      # Use HTTP Strict Transport Security to force client to use secure connections only
      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

      # Further Configuration goes here
      [...]
</VirtualHost>

---

Classifications

PCI v3.1-6.5.4,
CAPEC-217,
CWE-523,
ISO27001-A.14.1.2,
WASC-4,
OWASP 2013-A6,
OWASP 2017-A3

---

Test HSTS HTTP Strict Transport Security (OTG-CONFIG-007)

$ curl --silent --head https://us.com/ | grep -i strict
strict-transport-security: max-age=7776000000;
includeSubDomains

bypass

NETWORK TIME PROTOCOL (NTP)

• The Operating Systems use the Internet for a big amount of internal tasks. One of those features is the Time Synchronization.
• By default, almost all the desktop operating systems automatically synchronize its time with Internet Servers usually owned by the operating system provider
  • for example ’time.windows.com’ for Microsoft operating systems
  • All of them use different versions (v3 or v4) of the Network Time Protocol (NTP) which provide time synchronization between computers.

NTP messages are sent via UDP packets (123/UDP).

• The message format is the same for both requests and responses,
• but each peer use a different set of fields and ignore the rest of them.

Most important fields are:

• Leap (LI):
  • a warning indicator
  • should be usually set to zero.
  • Clients often set this value to 3 (clock unsynchronized) when request time synchronization.
• Version (VN): NTPv3 or NTPv4.
• Mode:
  • Usually client (3) or server (4) depending if it is a request or a response.
  • Other values are also possible but they are not used in by default NTP configuration
• Stratum:
  • Usually from 2 to 15.
  • Values 0 and 1 are used by reference clocks and primary servers and shouldn’t be used by NTP servers.
• Precision:
  • Usually -18 or -20 (microseconds).
  • Precision of the system clock.
  • Value in log2 seconds.
• Root delay & dispersion:
  • Total round-trip and dispersion from de reference clock. Value in NTP short format.
• Reference identifier:
  • Server identifier, usually his IP Address.
• Timestamps:
  • Different values that are used by the client in order to calculate the current date and time. Values in NTP format

NTPv4 supports authentication based on asymmetric cryptography.

• The server signs NTP messages using his own private key.
• soclients can verify messages integrity, so Manin-the-Middle techniques shouldn’t be possible.
• However, none operating system use authentication, so all of them would be vulnerable to Main-in-the-Middle attacks.

---

Delorean.py: AN NTP MITM TOOL

• to perform NTP Man-in-the-Middle attacks,
• a python script based on the kimifly’s tool ’ntpserver’ [11] but adding some additional options for onthe-fly manipulation.

Delorean can be used in five different modes:

• Automatic:
  • If not other mode is selected, Delorean works in an automatic mode.
  • find a date at least 1000 days in the future with the same month day and weekday than the current one.
  • It makes harder for the user to detect that something happened on his computer clock.
• Step mode (-s):
  • Using this mode you can choose how many seconds, hours, days, etc to jump to the future.
  • The base date and time are the local date and time in the host that runs Delorean.
• Date mode (-d):
  • choose the exact date and time when you want to jump to the future.
• Random mode (-r):
  • This mode makes Delorean to answer with different date and time on each response.
  • Useful for testing integer overflows and other similar issues in NTP implementations.
• Skimming Attack (-k & -t):
  • This mode makes Delorean work in a different way. It is compatible with all the previous modes but it jumps to the future in several steps (-k) instead of a single one. The flag ’t’ makes Delorean to jump that amount of time before the ’-k’ time.

Delorean can’t intercept communications itself, so it should be used with other tools such as arpspoof + iptables, metasploit’s fakedns, etc.

TIME SYNCHRONIZATION IN MAJOR OS

A. Ubuntu Linux

• It doesn’t run a NTP daemon itself but it is configured by default
• synchronized via ’ntpdate’ command each time a network interface goes up.
• It uses unauthenticated NTPv4 messages, so it is be vulnerable to MitM attacks.

attacker could control the physical medium (fake AP, switch controlling, deauthentication) he could force an interface down and up. When going up, the time would be synchronized, so it could be intercepted and manipulated by Delorean.

B. Fedora Linux

• Fedora runs a NTP daemon called ’chronyd’ that synchronizes each minute.
• It uses unauthenticated NTPv3 messages, so it is be vulnerable to MitM attacks.
• The default chrony configuration use the parameter ’rtcsync’ witch means that the system time is copied to the real time clock each 11 minutes.

Waiting up to one minute, an attacker could intercept and manipulate that communication with Delorean and control the desktop’s system time. After up to 11 minutes of intercepting those messages, the new time would be applied to the host.

C. Mac OS X Lion

• Mac OS X Lion (probably all pre-Mavericks versions) runs a NTP daemon called ’ntpd’ [12] that synchronizes each 9 minutes.
• It uses unauthenticated NTPv4 messages
• vulnerable to MitM attacks.
• Waiting up to 9 minutes, an attacker could intercept and manipulate that communication with Delorean and control the desktop’s system time.

D. Microsoft Windows

• Microsoft Windows is the securest NTP implementation from the major operating systems.
• It doesn’t use authentication (in a standalone configuration) but it implements some additional security features that make more difficult a reliable exploitation.
  • Windows by default only synchronizes once a week: Sunday at 02:00.
    • If the computer is not running then, the synchronization is made in the next boot (if it’s in the next three days).
  • the ’MaxPosPhaseCorrection’ and ’MinPosPhaseCorrection’
    • parameters set in the windows registry (HKEY LOCAL MACHINESYSTEM\CurrentControlSet\Services\W32Time\Config). These parameters specify the maximum and minimum amount of seconds that the clock can be adjusted by the time synchronization.
    • Any time update greater is automaticallyignored.
    • In windows desktop systems such as Windows 7 or 8, these parameters are set to 15 hours, while in servers such as Windows Server 2012 they are set to 48 hours [14].
• As a result, there is a narrow attack surface in a default configured windows computer. However, there are lots of non official articles in the Internet that recommend to synchronize the time more often, maybe each hour or even each 5 minutes.
• If the user set up his computer in order to synchronize more often than his own MaxPosPhaseCorretion time then his computer would become vulnerable to Time Skimming attacks.
• There is an exception in this process. When the user manually requests a time synchronization, when any security restriction is consider.

TIME SKIMMING ATTACK

• A Time Skimming Attack works in a similar way than a ’Stone Skimming’ effect.
• Perhaps the attacker can’t jump to the proper date in the future, but if he can jump a few seconds before the next time synchronization then he could reach the proper date by doing multiple jumps to the future.

Sent to 192.168.10.31:123 - Going to the future! 2014-09-27 01:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-27 13:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-28 01:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-28 13:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-29 01:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-29 13:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-30 01:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-30 13:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-01 01:32
Sent to 192.168.10.31:123 - Going to the future! 2014-09-01 13:32
[...]

Some Windows or Mac OS X configurations could be vulnerable to this kind of attacks.

BROWSERS & PRELOADED HSTS

Using the Delorean tool, under certain circumstances and configurations

• allow to manipulate the system time and force the HSTS policies to expire.
• However, there is an extra security feature in browsers: the preloaded HSTS.
• When reading its documentations it s eems that preloaded hosts are enforced by default so they wouldn’t be vulnerables to time manipulation attacks but the real truth is that those hosts are ’preloaded’ but not ’static’ on most browsers, so they would be vulnerable as well.
• For example
  • in Chrome, the enforced hosts in the ’Preloaded HSTS’ list are configured with a 1000 days policy.
  • These policies can be overwritten when the browser visits de host for the first time.
  • 
• Only one tested browser, Safari, seems to configure those preloaded hosts as a static values (’inf’/’-inf’), so hosts preloaded by Safari couldn’t be attacked using these techniques.

on certain systems and under certain circumstances, an NTP MitM attack is possible and it could be used in order to force HSTS policies to expire. Delorean could be used to perform the proposed attacks.

---

.

ref

• 1