TechShizz | All posts by rich

Login CSRF Exploit

Login CSRF is a type of attack where the attacker can force the user to log in to the attacker’s account on a website and thus reveal information about what the user is doing while logged in.

What can happen?

The risk varies depending on the application and is hard to evaluate from a black-box perspective.

PayPal was once vulnerable to login CSRF and the attacker could make a user log in to the attacker’s PayPal account. When the user later on paid for something online, they unknowingly added their credit card to the attacker's account.

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

If public registration for the application exists, the risk of attacks drastically increases as it’s very easy for the attacker to create an account and thus know the credentials for it.


    if (isset($_POST["user"], $_POST["pass"]){
        // Make sure the token from the login form is the same as in the cookie
        if (isset($_POST["CSRFtoken"], $_COOKIE["CSRFtoken"])){
            if ($_POST["CSRFtoken"] == $_COOKIE["CSRFtoken"]){
                // code for checking the user and password
    } else {
        $token = bin2hex(openssl_random_pseudo_bytes(16));
        setcookie("CSRFtoken", $token, time() + 60 * 60 * 24);
        echo '
            <form method="post">
                <input name="user">
                <input name="pass" type="password">
                <input name="CSRFtoken" type="hidden" value="' . $token . '">
                <input type="submit">


Disable Autodiscover for Office 365 Migration

When migrating to Office 365 the internal outlook users are not able to use autodiscover.

This is because the internal exchange server also uses autodiscover in IIS.

Use this description to remove the internal AutodiscoverVirtualDirectory

Be sure that this is the proper migration plan for you’re organization!

1. Open an elevated command prompt and back-up the IIS configuration (Just in case !):

cd %windir%system32inetsrvappcmd.exe add backup “Before Removing Autodiscover”

2. Open an elevated Exchange Management Shell and retrieve the current autodiscover virtual directory:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

Copy the Identity value to the clipboard.

3. In the Exchange Management Shell, remove the autodiscover virtual directory:

Remove-AutodiscoverVirtualDirectory -Identity “ALPHAAutodiscover (Default Web Site)”

When you’re identity contains a space, use the quotation marks ”

You will have to confirm by typing a “Y”.

4. Check that the autodiscover virtual directory is gone:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

This should now return nothing.

5. Now, with Outlook running on a desktop, hold the Ctrl button, right-click on the Outlook icon in the system tray, and select Test E-mail AutoConfiguration. Enter your email address and password and click the Test button. The results should come from the Office 365 server.

DNS | TLSA Records to ensure the validity of SSL certificates

TLSA Records are a new feature which adds an additional layer of security for checking the validity of server certificates. The TLSA record is placed in DNS, which can be queried by a client to verify the SHA hash the domain holds against the certificate a server has presented the client. If the Key matches DNS has "agreed" that the certificate does indeed match. This security protects against the wrongful issuing of certificates by CA's and also the theft of certificates. 

#Add a TLSA DNS Record
Add-DNSServerResourceRecord -CertificateAssociationData 2a8f2d8af0eb123898f74c866ac3fa669054e23c17bc7a95bd0234192dc635d0 -CertificateUsage DomainIssuedCertificate -MatchType Sha256Hash -Selector SubjectPublicKeyInfo -TLSA -ZoneName -Name _443._tcp.www

This record combines with DNSSEC provides a robust security system to protect agains man in the middle attacks. Due to the need to DNSSEC, and a provider who offers TLSA, it's going to be a premium service if used on the internet. It does come with server 2016 for internal usage on the corporate infrastructure. 

DNS Time Based Policy

We can configure DNS in server 2016 to DENY, IGNORE or ALLOW the response of DNS requests. Here are the commands required to configure this. 

#Get current server time
Get-Date -DisplayHint Time

#Get current DNS Policies
Get-DnsServerQueryResolutionPolicy -ZoneName

#Add a new Policy called "Time-Policy" to deny dns requests between 4AM and 11PM.
Add-DnsServerQueryResolutionPolicy -zoneName -Name "Time-Policy" -Action DENY -TimeOfDay "eq,04:00-23:00" -ProcessingOrder 2

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName

#Change Processing order (1 takes precedence)
Set-DnsServerQueryResolutionPolicy -ZoneName -Name "Time-Policy" -ProcessingOrder 1

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName

#Remove the time policy
Remove-DnsServerQueryResolutionPolicy -zoneName -Name "Time-Policy" -Force

#Re-add the time policy but with IGNORE request instead
Add-DnsServerQueryResolutionPolicy -zoneName -Name "Time-Policy" -Action IGNORE -TimeOfDay "eq,04:00-23:00" -ProcessingOrder 1

#Remove Time policy again
Remove-DnsServerQueryResolutionPolicy -zoneName -Name "Time-Policy" -Force

#Add time policy to DENY between 11PM and Midnight, Order 1
Add-DnsServerQueryResolutionPolicy -zoneName -Name "Time-Policy" -Action DENY -TimeOfDay "eq,23:00-23:59" -ProcessingOrder 1 

#Check Result
Get-DnsServerQueryResolutionPolicy -ZoneName

#Change Policy order to 3
Set-DnsServerQueryResolutionPolicy -ZoneName -Name "Time-Policy" -ProcessingOrder 3

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName


DNS Policy by Client Source Address

If we have various subnets we can create a DNS policy so that our DNS server responds differently to clients on different subnets. Here's how:

#Add a new Demo DNS Zone
Add-DNSServerPrimaryZone -Name -Replication Domain

#Add two Client Subnets
Add-DNSServerClientSubnet -Name SubnetA -IPv4Subnet ""
Add-DNSServerClientSubnet -Name SubnetB -IPv4Subnet ""

#Add Zone Scopes for Subnets
Add-DNSServerZoneScope -ZoneName -Name "0_Scope"
Add-DNSServerZoneScope -ZoneName -Name "64_Scope"

#Add some A records
Add-DNSServerResourceRecord -ZoneName -A -Name App1 -IPv4Address "" -ZoneScope "0_Scope"
Add-DNSServerResourceRecord -ZoneName -A -Name App1 -IPv4Address "" -ZoneScope "64_Scope"

#Create the DNS Client Based Policy
Add-DNSServerQueryResolutionPolicy -Name "0_Policy" -Action ALLOW -ClientSubnet "eq,SubnetA" -ZoneScope "0_Scope,1" -ZoneName
Add-DNSServerQueryResolutionPolicy -Name "64_Policy" -Action ALLOW -ClientSubnet "eq,SubnetB" -ZoneScope "64_Scope,1" -ZoneName