Aug 22, 2021

Enable HTTP Basic Authentication in Spring Security

How to enable Spring Security in Java Web application? 

To enable Spring security in Java Web application, you need to configure three things -  (i)  declare a delegating proxy filter in web.xml, (ii) add the ContextLoaderListener in web.xml and (ii) provide actual security constraints on applicationContext-Security.xml file. 

This is also known as Spring's "security chain filter", which relies on web container for initialization of delegating filter proxy.

1) Declare DelegatingFilterProxy filter in web.xml

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>



2) Specify the Spring application context file to ContextLoaderListener

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      /WEB-INF/applicationContext.xml
        /WEB-INF/applicationContext-security.xml
    </param-value>
</context-param>

 

3) Specify Spring Security intercept URL pattern in the applicationContext-Security.xml file

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:security="http://www.springframework.org/schema/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/security
    http://www.springframework.org/schema/security/spring-security-3.1.xsd">
    <security:http auto-config="true">
        <security:intercept-url pattern="/admin"
            access="ROLE_ADMIN" />
    </security:http>
    <security:authentication-manager>
        <security:authentication-provider>
            <security:user-service>
                <security:user authorities="ROLE_ADMIN" name="admin"
                    password="admin" />
                <security:user authorities="ROLE_ADMIN" name="root"
                    password="root" />
            </security:user-service>
        </security:authentication-provider>
    </security:authentication-manager>
</beans>

By doing this simple configuration, all URLs ending with /admin to be only accessible with username and password. The two users who have access to this are now admin and root.


How to enable HTTP Basic Authentication in Spring Security using Java and XML Configuration?

Basic authentication is another common ways to authenticate a user in a web application WITHOUT using a form. This is common in the case of RESTful web services clients are not human but application.

In HTTP basic authentication, user login credentials are passed on the HTTP request header, precisely "Authorization" request header. This header sends username/password into request headers, using Base64 encoding.

Other authentication methods include digest authentication, OAuth 2.0, and form-based authentication.

 

To enable HTTP basic authentication using XML config, we use the  <http-basic /> configuration element in Java web app.

To use form login, just replace the <login-form> element in configuration file  applicationContext-security.xml with <http-basic />.

Here is a sample of Spring security configuration with HTTP basic authentication enabled (applicationContext-security.xml):

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.1.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">
 
<http pattern="/home" security="none"/>
<http use-expressions="true">
  <intercept-url pattern="/**" access="isAuthenticated()" />
  <http-basic />
</http>
 
 
<authentication-manager>
  <authentication-provider>
    <user-service>
      <user name="userId" password="passwd" authorities="ROLE_USER" />
    </user-service>
   </authentication-provider>
</authentication-manager>
 
</beans:beans>

1)The first line says that for /home we don't need any security so anyone can access it.

2)The second line <http> says that we are using Spring expression language and that's why we could have used the isAuthenticated() method for intercepting url.

3) The <intercept-url pattern="/**" access="isAuthenticated()" /> means all URLs need authentication and they will use HTTP basic authentication mechanisms.

4) The authentication manager is not in focus but here we are using in-memory authentication provider with just one user is configured whose username is "userId" and password is "passwd".

To enable HTTP basic autthentication using Java configuration, we configure security aspects of calling the httpBasic()  mehtods on the HttpSecurity object passed into configure() mehtod.

Here is a sample of Spring Security configuration to enable HTTP basic authentication using Java code:

@Configuration
@EnableWebSecurity
public class HttpBasicAuthenticationAdapter extends
    WebSecurityConfigurerAdapter {

  @Autowired
  public void configureGlobal(AuthenticationManagerBuilder auth)
      throws Exception {
    auth
    .inMemoryAuthentication()
    .withUser("userId").password("passwd")
    .authorities("ROLE_USER");
  }

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
    .authorizeRequests()
    .antMatchers("/securityNone").permitAll()
    .anyRequest().authenticated()
    .and()
    .httpBasic()
    .realmName("Your App");
  }
}

We can combine security constraint using joiner methods like and(). If you want to turn off HTTP basic authentication just remove the call to httpBasic() method and you are done.


Links:

Aug 14, 2021

Glowworm Attack

Here comes the new class of optical TEMPEST attacks: recovering sound by analyzing optical emanations from a LED power indicator.

There are 2 classes of optical TEMPEST attacks against the confidentiality. 1) recovering content from monitors, 2) recovering keystrokes from keyboards.

By analyzing the response of the power indicator LED of various devices to sound and show that there is an optical correlation between the sound that is played by connected speakers and the intensity of their power indicator LED due to the facts that: 
(1) the power indicator LED of various devices is connected directly to the power line, 
(2) the intensity of a device's power indicator LED is correlative to the power consumption, and 
(3) many devices lack a dedicated means of countering this phenomenon. 
Based on these, here comes the Glowworm attack, an optical TEMPEST attack that can be used by eavesdroppers to recover sound by analyzing optical measurements obtained via an electro-optical sensor directed at the power indicator LED of various devices (e.g., speakers, USB hub splitters, and microcontrollers).

 

 

This is a very interesting attack, and you can read the full article at https://www.nassiben.com/glowworm-attack.

 

 

Aug 9, 2021

Microsoft OMI

OMI is an open source project to further the development of a production quality implementation of the DMTF CIM/WBEM standards. OMI is also designed to be inherently portable. It builds and runs today on most versions of UNIX(r) and Linux. In addition to OMI's small footprint, it also demonstrates very high performance.

OMI's primary goal is to provide a rich, high-performance, standards-based management stack that is suitable for a wide range of management applications. This includes cloud management, storage management, server hardware management, device management, and network management, on both large and small systems (embedded and mobility). To support this goal, OMI implements DMTF CIM/WBEM standards with the following characteristics:

  • A very small footprint
  • A provider generator model which makes the task of creating providers very easy
  • High portability to a wide variety of hardware and software
  • High performance
  • Support for WS-Management

The availability of OMI means that we can now easily compile and implement a standards-based management service into any device or platform from a free open-source package. The goals are to remove all obstacles that stand in the way of implementing standards-based management so that every device in the world can be managed in a clear, consistent, coherent way and to nurture spur a rich ecosystem of standards-based management products. 

In addition, the growth of cloud-based computing is driving demand for more automation, which, in turn, will require the existence of a solid foundation built upon management standards. For standards-based management to satisfy today’s cloud management demands, it must be sophisticated enough to support the diverse set of devices that are required and it must be easy to implement by hardware and platform vendors alike.  The DMTF CIM and WSMAN standards are up to the task, but implementing them effectively has been a challenge.  Open Management Infrastructure (OMI) addresses this problem.

Background context (History)

  • WMI was first introduced in Windows NT 4.0.
  • WMI used DCOM for remote management.
  • In Windows Server 20212, Microsoft synching WMI with DMTF standards and protocols.
  • Microsoft works with The Open Group to built a highly portable, small footprint, high performance CIM Object Manager called OMI.

Acronyms:

  • OMI - Open Management Infrastructure
  • CIM -  Common Information Model
  • DMTF - Distributed Management Task Force
  • WBEM - Web-Based Enterprise Management
  • WMI - Windows Management Infrastructure

 

Links:

Aug 2, 2021

AD Security Administration Best Practices

Secure AD Administration

  • Separate accounts for each administrative tier
    • Tier 2: workstations
    • Tier 1: servers
    • Tier 0: AD/DC, PKI, ADFS, AAD connect, etc.
  • AD admins only use admin workstations
  • AD admins only logon to admin servers/DC
  • Block AD admin groups from logging on to workstations & servers via Group Policy
  • Limit DC management protocols (RDP, WMI, WinRM) to AD admin systems/subnets
  • Limit service accounts with privileged AD rights

Secure AD Admin OU

  • Create a new top-level OU in the domain
    • Eg.: Management, AD Management, Administrative, etc
  • Modify security so Authenticated Users don't have view access
    • Remove Authenticated Users from OU permissions.
  • Block GPO Inheritance. Create, apply & link Admin OU specifics GPOs.
  • Create child OUs
    • Admin Servers
    • Admin Workstations
    • Admin Accounts
    • Admin Groups
  •  Place all AD Admin related objects (users/groups) in this OU structure
  • Only AD Admin have:
    • Modify rights to this OU structure
    • Modify/Owner rights to GPOs linked to this OU

 Securing AD: Level 1

  • Randomize computer local Administrator account passwords. (MS LAPS)
  • Minimize groups/users with DC admin/logon scripts.
  • Separate user and admin accounts
  • No user accounts in admin groups
  • Admin accounts = "sensitive and cannot be delegated"
  • All AD Admin accounts added to "Protected Users" group
  • Long and complex (> 25 characters) passwords for SA
  • Set GPO to prevent local accounts from connecting over network to computers.

 Securing AD: Level 2

  • Service Accounts (SA):
    • Leverage "(Group) Managed Service Accounts"
    • Implement Fine-Grained Password Policies (DFL > 2008)
    • Limit SA to systems of the same security tier, not shared between workstations and servers.
    • Ensure passwords are >25 char
  • Ensure all computers are talking NTLMv2 & Kerberos, deny LM/NTLMv1
  • Disable SMBv1
  • Separate Admin workstations for administrators (locked-down and no Internet)
  • No Domain Admin service account on non-DCs
  • Limit management protocol access on DC to admin subnets
    • RDP, WMI, WinRM, etc.

Securing AD: Level 3

  • Complete separation of administration
  • AD Admin never logon to other security tier
  • AD Admin should only logo to a DC (or admin workstation or admin server)
  • Time-based, temporary group membership
  • Restrict workstation to workstation communication with host firewalls
    • AD clients don't need special rules, default Block All Inbound works (add exceptions for authorized management systems)
  • Implement network segmentation
    • Start by reserving IP ranges/VLAN by device type (routers, switches, DC, servers, workstations, printers,etc).

Protect Admin Creds

  • Ensure all admin only log onto approaved admin workstations and servers.
  • Add all admin accounts to Protected Users group (requires Windows 2012 R2 DC).
  • Admin workstation and server:
    • Control and limit access to admin workstations and servers.
    • Remove NetBIOS over TCP/IP.
    • Disable LLMNR.
    • Disable WPAD. 

Additional Mitigations

  • Enable NTLM Auditing on DC.
  • Enable SMB Auditing on DC and file servers.
  • Enable PowerShell logging everywhere and send to SIEM.
  • Monitor scheduled tasks on sensitive systems (DC, etc)
  • Block Internet access to DC and servers.
  • Change the KRBTGT account password (twice) every year and when an AD admin leaves
  • Use Invoke-TrimarcADChecks (https://trimarc.co/ADCheckScript) to help identify problematic AD configurations. 

Aug 1, 2021

Trimarc Security Assessment: Protecting AD Administration



Compromise mgmt system for access:

  • Microsoft SCCM admin account - push packages
  • Microsoft SCOM admin account - run commands
  • Splunk server - run scripts on system (Splunk Universal Forwarder)
  • Vuln Scanners - extract stored credential.
  • Endpoint Detection/Response (EDR) - run scripts/commands/code
  • Microsoft Intune - run scripts on Azure AD.

Notes:

  1. DON'T run management tools on local workstations.
  2. Smart card PIN is cached and can be extracted by Mimikatz.
  3. Hijack Jump-server with tscon.exe (as SYSTEM).
  4. MFA is only as good as its configuration.
  5. MFA can be subverted. (self-service/SMS)
  6. MFA may be configured to be fail-open.
  7. Password vault becomes part of the AD security posture.
  8. Password vault: vulnerable to keylogger.
  9. Password vault: RDP Proxy (browser extension)
  10. Admin Deployment: AD admins, Virtual Infra admins, Cloud admins, Server admins, workstation admins.
  11. Admin Forest = Red Forest (ESAE)
  12. Admin Forest doesn't fix production AD security issues.
  13. Agents on DC will be the target.
  14. Modern Admin Forest = "Cloud" Admin Forest / ESAE
  15. Quick lockdown via Microsoft Intune by leveraging policies.