Talking everything Information Security, from Penetration Testing, System Hardening to Information Assurance.
Author: ACouch
For me, Information Security, Computing and understanding how things work is a mindset, a hobby and a profession. As you may have guessed my name is Adam Couch. I currently work as Cyber Security Consultant specialising in penetration testing. A Cyber Scheme Team Member, performing penetration tests, ITHC for PSN, CHECK tests, server/workstation/Switch/Router and Firewall build reviews/security hardening and web application testing.
Using sed to add text to the end of each line in Linux.
In this example we are going to use sed to add text to the end of each line in Linux. More specifically in a text file in Linux using a bash one liner! Why would we want to do this? Multiple reasons if your penetration tester. Creating user name lists or adding ports to the end of IP addresses for example. Sed is used to perform basic text transformations you can read more about it here.
So for example if we wanted to add ‘:80’ to the end of each line for a list of IP address we would do the following:
Or if we found we wanted to add ‘adm’ to the end of each line in a list of user names we would also use sed.
~$cat admins.txt
adam
bob
bill
james
jane
~$sed 's/$/adm/' admins.txt > new_admins.txt
~$cat new_admins.txt
adamadm
bobadm
billadm
jamesadm
janeadm
~$
Having these small bash commands to hand is super useful. As a penetration tester I am always find that I need to script something in Bash or PowerShell or needing to produce one liners. Having these commands to ready and waiting saves time looking them up. Hopefully you will also find them useful. Don’t forget the man pages for bash commands. Practice, practice and more practice.
Just a quick post regarding creating username lists.
Often during an engagement if you have discovered a service that is brute-force able such as smb then it would be advantageous to create a semi-valid username list. We can do this fairly easily with the harvester. Once we have this list we probably want to manipulate the forname and surname to create a valid username to suit our target. I came across this python script which quickly gives us the output we need. Full props to Harold Rodriguezsuperkojiman for his code: https://gist.github.com/superkojiman/11076951. I have found that just removing the various outputs that you don’t want works best if you know the target username combination, and if you don’t run with all options. I’ve found the password/username spraying technique with a single password works best and is the smart option to avoid account lockouts.
#!/usr/bin/env python
import sys
if __name__ == "__main__":
if len(sys.argv) != 2:
print "usage: %s names.txt" % (sys.argv[0])
sys.exit(0)
for line in open(sys.argv[1]):
name = ''.join([c for c in line if c == " " or c.isalpha()])
tokens = name.lower().split()
fname = tokens[0]
lname = tokens[-1]
print fname + lname # johndoe
print lname + fname # doejohn
print fname + "." + lname # john.doe
print lname + "." + fname # doe.john
print lname + fname[0] # doej
print fname[0] + lname # jdoe
print lname[0] + fname # djoe
print fname[0] + "." + lname # j.doe
print lname[0] + "." + fname # d.john
print fname # john
print lname # joe
I came across a need to expand the hdd on Linux virtual machine, as I had run out of space. I thought I would share my experience by walking through the steps I took in resizing a VirtualBox Linux disk for the Debian based OS that I had. The process involves expanding the virtual image file then using GParted to expand the partition. This is actually relatively painless. My particular disk image was in VMDK that I needed to increase by an additional 10Gb. I actually tested this out for a non trivial virtual machine first, this is how I got on:
First like me if your using a VMDK you will need to convert the disk image to either a VDI or VHD file. This can be done at the command line (with Admin privs) like below. If you try to expand the a VMDK with VirtualBox you get a nice error as below:
The next stage is optional: Take the new VDI file and create a new virtual machine using the new HDD file. I personally would then boot the machine just to check it boots and everything is in order however this is optional, while I was there I took a quick snip of the HDD space. /dev/sda1 is 29Gb we will increase to 40Gb.
Resize the VDI file at the command line (with Admin privs) like below:
At this point the vm will still boot just fine, however the hdd partition won’t have increased. We will need to extend the partition using a program like Gparted. So we mount the GParted ISO into the guest CD drive. You will also need to enable EFI from the system page in order to boot into the latest GParted GUI, this will need to be unchecked after we have finished to boot back into our Debian os.
Start the vm, allow GParted to boot. Select the first option and allow GParted to continue to load, accept the default settings pressing ‘enter’ three times.
Once booted into GParted you will be presented with the following screen:
We need to remove ‘/dev/sda2’ (the swap file and recreate it later) in order to extend the partition into the unallocated space. Once this is complete we can then select ‘/dev/sda1’ select ‘Resize/Move’ from the menu, drag the slider bar all the way to the right hand side like below and select ‘Resize/Move’.
Select ‘Apply’ from the menu, and after a short pause we can see all operations were successful. Once this is complete close the ‘Apply pending operations’ and shutdown.
Remember to disable the EFI option in the VirtualBox machine settings for our Debian based system. Boot the machine up and recheck the size; voila, we can see our /dev/sda1 is now 39Gb!
In this post I’m going to be talking about LLMNR and NBT-NS. That’s Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS). They are backup name resolution processes that take place by default in windows networking to help your PC resolve names it requests. However are they really helping you or actually causing you more harm! I’l talk about why its bad, and why we should look to disable it.
Ok so what is LLMNR and NBT-NS, whats it all about?
Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are processes that take place by default in windows networking to help your PC resolve names it requests. When you PC needs to resolve the name or a server for example to an IP address it firstly uses the DNS server it has been assigned. If the DNS Server doesn’t have the record you requested, your PC will use LLMNR and then NBT-NS. With LLMNR your PC will broadcast across the local subnet and ask other machines if they have a record for the name you are trying to resolve. If no-one answers, your PC will then try NBT-NS in the same manner.
Lets see it in action, in the below wireshark we can see 10.0.2.2 (Windows 7 domain joined machine) querying 10.0.2.10 ( Windows Active Directory DNS Server) for the record of DC2. DC2 doesn’t exist, and as we can see the DNS server responds ‘No such name..’. The PC then proceeds to use LLMNR and broadcasts across the subnet. No response is given. The PC then tries NBT-NS and again broadcasts across the subnet, no response is given. No response is given as no-one on the subnet has that record, I just made it up to demonstrate LLMNR and NBT-NS.
Ok so why is this bad, surely its a good thing right..?
Well yes and no, more no these days. Ordinary and back some 10 years ago LLMNR and NBT-NS were used in helping resolve names. If the DNS Server was unavailable local hosts on the same subnet would help resolve names. However lets face it if your PC can’t use DNS its pretty much not going to be doing alot in terms of network connectivity and services. LLMNR and NBT-NS are just not needed anymore (usually). Attackers can take advantage of the LLMNR and NBT-NS broadcasts by replying to them with poisoned responses. The poisoned response can essentially trick the PC into thinking that it knows where the resource is. The PC then attampts to setup an SMB challenge response, in doing so sends its credentials along to the attackers machine. An attacker is able to capture the username and LM, NTLMv1 or NTLMv2 hash of the user making the request. This can then be subject to an offline brute force attack using several different programs such as John the Ripper or OCLhashcat. Or be reused in a PassTheHash or SMB relay attack.
Lets see it in action from wireshark.
We can see our usual DNS request, then an LLMNR broadcast goes out, as the DNS server has no record. Our attacker on 10.0.2.3 (a kali linux machine using Responder) sends a response back to our PC ‘Standard query response, DC3 is at 10.0.2.3’ this is actually the attackers machine fooling the PC. NBT-NS request hasn’t gone out at this stage as a response is received to the LLMNR. The PC is fooled into thinking the resource is at 10.0.2.3 and starts to negotiate an SMB session, passing along its credentials to the attackers machine.
What can we do to fix it?
LLMNR and NBT-NS are old methods for name resolution. You may have legacy applications in your environment that may potentially still use LLMNR and NBT-NS for broadcast name resolution. Due to this thorough testing should be carried out first. If this is the case get onto the vendor for some answers as to why! Otherwise we can disable both via GPO and DHCP options. For LLMNR there is native GPO setting. For NBT-NS there is no native setting however it can be set in the registry. The registry key references an interface name which has its own unique GUID so can’t be changed in GPO via a registry key change (as the key will be different every time), however we can use powershell and do a ‘catch all’ on that key and thus script and then run via GPO. I’ll demonstrate below.
You can disable LLMNR via Group Policy in your domain or locally, go to:
The process for disabling both are in the below video:
It obviously goes without saying the appropriate testing, change control and usual roll out procedures should apply especially with a change like this.
This is just a short write up on unquoted service paths, what they are, why they are bad and how we can fix them. A vulnerabilty scanner will often find these on an ‘Authenticated’ type of scan. However we can search for them via WMI (Windows Managment Interface) query or by manually looking through the services one by one. So what is an unquoted service path? It is the path/file location of the service-exe for a given service that isn’t wrapped in quotes, like in the picture.
OK, so what? Why are these bad?
The problem with unquoted service paths is that as windows starts up or as the service is started Windows needs to locate the service-exe for that service. (I keep saying ‘service-exe’, well we’ll come on to that in a sec!). It looks for the service-exe in the path specified in the ‘Path to executable:’ field of the service. If the path is quoted and contains white space in the path windows knows to go directly to the location. If the path is unquoted and contains white space, Windows will essentially query the different locations in the path until the service-exe is found.
Where the service path contains white space and is unquoted, an attacker can use this to escalate privileges from a standard user account. For example if the service is running as SYSTEM, an attacker can create a service-exe to say create an account and drop it in the local administrators group. The attacker would also need to have ntfs permissions as the standard user in the location in the path so ‘C:\’ might not be viable however further down the path might be. The attacker then restarts the service and the new service-exe will be executed by the service running as SYSTEM.
The service-exe I keep refereing to is special type of executable file that is used by services, its not any old exe you can’t just drop cmd.exe in the path unfortunatly…
If I can’t do an Authenticated Vulnerability Scan how can I find them..?
We can use two methods, we can either use WMI query or manually open up each service and check each one, then check the ntfs permissions of each location. We can use the follwoing WMI command from Common Exploits; this will filter out the automatic service and also look for unquoted service paths:
wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """
Running the above wmi query will display something like the the following if present:
As we can see large mainstream manufactures still implment unquoted service paths!
I’ve found one, how do I fix it?
This is relatively straight forward however this should be tested before being rolled out into production (goes without saying). We need to add the quotes to our service path so windows know where to go for the service-exe directly immediatly, rather than searching each directory. We can do this through the registry.
Fire up the registry and navigate to the service as below:
Open up the ImagePath string and simple add the quotes as below:
Restart the service and ensure the service starts properly. We can also open up the service and also re run the WMI query to ensure our affected service now has quotes. This will ensure any attackers should they manage to compromise the machine as a standard user, stop them being able to escalte privileges in this manner!
Hopefully this post will help you resolve the uquoted service path issue.
Cisco, AAA, Radius, Active Directory, Windows Server 2012 R2, NAP role, NPS its all going on!
Just a quick note to reference the following video on YouTube. This video demonstrates setting up Active Directory Authentication for Cisco Devices, such as Routers and Switches etc. This is using AAA on the router and RADIUS through the Network Access Policy (NAP) role in Windows Server 2012 R2, this in turn enables a Network Policy Server (NPS). The Windows server (the Radius Server) is registered in Active Directory which allows it to query the domain it is connected too for authenticating users in Active Directory to the Cisco IOS devices. You can control who has access to various network devices through rules created on the NPS. This can in turn be achieved in Active Directory via groups, binding those groups to privilege levels to pass through to deifferent devices.
For example you could have a group in AD called Network Admins which is tied to a prilivelge level 15 group rule in the NPS configuration. This rule would pass through the privilege level 15 setting through to the IOS configuration. Members of this AD group upon succesful authentication would then be granted privilege level 15 access on the router or switch.
Running MBSA on remote machine that is in a workgroup or different domain.
I thought I would share my findings on using MBSA (Microsoft Baseline Security Analyser) for targeting remote machines that are not part of the same domain or in a workgroup. This really is a great tool for enumerating OS patch levels.
We have two scenarios to run through; the first, running MBSA on remote machine that is in a different domain from the machine that it is installed on. The second, running MBSA on a machine that is in a workgroup. Ok no problem. Here is what we do.
First Scenario
In the first scenario our target machine is a Windows Server 2012 R2 machine that is in a different domain to our MBSA host (Windows 7 Pro 64bit). Fire up a cmd prompt with admin privileges from the machine that you are running MBSA from, and run the following syntax:
A second command prompt will pop up and run, running the syntax as above:
If you wait a short while the MBSA command prompt will disappear when finished, from here you can open up MBSA and view the report:
In this example the target machine was in my virtualbox lab, in a domain called ‘Test’. The machine I ran MBSA from was a Windows 7 Pro machine in a workgroup (no relationship) other than IP connectivity. The cli syntax I used here was used to speed up the check, clearly only use this if you have the latest scan catalogue:
/wi – Show all updates even if not approved by wsus.
/nvc – Do not check for a new version of MBSA.
/nd – Do not download any files from MS update site when scanning.
Additional options:
/target <Target-IP>
/listfile C:\tmp\targets.txt
/catalog C:\tmp\wsusscn2.cab
Add: ‘>C:\tmp\MBSADC1.txt’ to the end of the syntax for a handy output to a text file.
The second scenarios is a Windows Server 2003 machine that is in workgroup. The syntax is actually the same however your specifying the local machine name rather than the domain name. I have mixed this one up a little here by not using the cli, by just specifying MBSA the command simple fires up MBSA GUI as the account specified. The only thing to remember here is to add the IP address into the GUI.
runas /netonly /user:test\administrator mbsa
And again after the scan has finished the results can be view in the GUI.
I haven’t successfully managed to do this from a Windows 10 client yet, various forums would suggest it isn’t supposed to work with 10 however if you know please feel free to drop me an email or comment.
Securing Remote Desktop with Certificates from your Internal CA.
In this post I’m going to be following on from Part 1 located here, talking about further hardening the Windows Remote Desktop Protocol (RDP) with a certificate based system. The certificate is generated and signed by an internal Active Directory Certificate Authority (CA). The issue here being that you have no way of verifying the server or PC that you are trying to connect to via RDP. The machine that you are supposedly connecting to usually presents you with a certificate that is signed by itself, funnily enough known as a ‘self signed certificate’.
The Attack…
The play by an attacker here being that should they have exploited a vulnerability and been able to access your internal network (not for this discussion, however..), they could essentially respond to ARP request by modifying responses sent by an attackers machine. This is done by flooding the network with bad ARP responses, known as ARP poising, the whole attack is known as a Man In The Middle (MITM). There are many ways of carrying out a MITM attack, this just one of them. Once a MITM attack is in play and your arp cache is then poisoned you would essentially be connecting to an attackers machine. The attacker can then sniff the network traffic and all sorts of other rather bad things can happen, like stealing credentials.
A typical self signed certificate presented through RDP looks like the picture above, and clearly states the certificate is not from a trusted certificate authority. If your PC can trust the certificate that is presented by the machine you are connecting too, through the use of a bonafide signed certificate from your internal CA you would know whether or not the machine you are connecting to is genuine. More importantly, through the use of Group Policy you can specify that you are not able to connect to it unless you trust it. Thus preventing any bad MITM rdp sessions.
How do we fix it…
Carlos Perez has written up an excellent ‘how to’ guide from start to finish on how to setup this up. He walks through the certificate templates required for the RDP service. Also setting up group policy to deploy the certificate. This is a great guide so I’m not going to re-regurgitate his excellent work going through all the various screen shots, you can view it here at http://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo .
A quick and simple Ubuntu 14.04 Syslog Server with rsyslog for Network Devices.
In this post I going to run through creating a quick a simple Ubuntu 14.04 Syslog Server. Logging events is an important part of secure network configuration. The messages provided by devices such as switches, routers, firewalls and number of other devices provide a huge amount of information to systems administrators when a specific event has occurred and steps need to be traced. This could be for diagnosing a problem or looking at the activity of a potential attacker. When syslogging is setup it allows system administrators to respond better to incidents due to having the information readily available. Shipping the logs off to a remote server allows them to be safely stored without fear of them being deleted due to an attacker compromising the device but also the device being restricted due to small amount of storage space usually allocated.
In this post we are going to setup a syslog server on Ubuntu 14.04. Ubuntu uses rsyslog for its logging you can read all about this here, I’m just going to cover some of the basics to get you up and running, the idea here being that you have something to work on and take to the next level.
The below network diagram whilst may seem overly complicated, serves us well for this scenario and gives us our network and devices that we want to collect data from. In this scenario we want to collect logs from the routers. The platform we are going to test this out in is GNS3, truth be told it was a lab I had machines active for so though, meh… why not drop a syslog server in.
There are essentially three steps I’m going to walk you through:
1. Configure the /etc/rsyslog.conf to accept remote incoming UDP syslog messages
2. Create and configure a conf file in /etc/rsyslog.d/30-cisco.conf. This is a new file we are going to create which specifies some rules on what we want to do with our messages if they come from different devices. You can add the rules to the rsyslog.conf file however creating a seperate conf file is the neater option in my opinion.
3. Change permissions of the /var/log/ directory so syslog user can make changes, create files etc.
4. Restart rsyslog with : sudo service rsyslog restart.
5. Test with our Cisco devices.
So taking our completely standard Ubuntu 14.04 install find our rsyslog.conf file in /etc/ and uncomment the following lines with our favourite text editor in my case ‘nano’:
$ModLoad imudp
$UDPServerRun 514
If you scroll down towards the bottom of the file we can see that it references to use all ‘conf’ files under /etc/rsyslog.d/ including where the default rules are kept in 50-default.conf.
Create/touch a new file calling it ’30-cisco.conf’, since we are only collecting syslog info for cisco devices on this occasion we shall chose this name. Append the file with the following lines of code:
# This rule runs in FRONT of the local/regular rules
# The below line sets a variable for the hostname and Cisco directory.
$template HostBasedLog,"/var/log/cisco/%HOSTNAME%.log"
# This creates a separate log file for each device
if $fromhost-ip == ‘192.168.0.1’ then -?HostBasedLog
& ~
if $fromhost-ip == ‘10.0.0.2’ then -?HostBasedLog
& ~
The above code sets up a template which creates the ‘cisco’ directory and also a log file using the hostname of the device the messages have come from.
From here we set the permsisions of the log directory for syslog service with ‘cd /var && sudo chown syslog:syslog log’
Restart the rsyslog service: ‘service rsyslog restart’
All that is left to do is configure our cisco devices to ship logs off to our syslog server. For a typical cisco router or switch we can simple do this from a conf t prompt with ‘logging x.x.x.x’ also setting desired trap levels with: ‘logging trap debugging’ for example.
There it is, a simple syslog server, as said previously this is just something to get you started with. The next level to think about is rotation of log files, backups secure transfer of the log files through TLS which rsyslog supports.
Check your Egress Filtering with a PowerShell port scan script
This is just a quick post so I can refer to myself more than anything regarding conducting a Powershell Port Scan! However this is a useful couple of lines to to conduct a port scan from a windows device with PowerShell. This can be used in a number of situations however is especially ideal to check your egress filtering out to a server on the internet or to a segmented network. In the below few lines we are testing the first 1000 ports this can be bumped up to 65535 if wanted and the server that you are port scanning is listed as X.X.X.X.
This particular script has been pulled from Black Hills Information Security page here. An alternative from Microsoft’s ‘Hey, Scripting Guy! Blog’ can be found here.
The Common Problem
Often organisations lack adequate egress filtering, by this I mean outbound connects that can be established on a number of ports from within the heart of the network. Client machines and typical internal application servers don’t need to access a range of services out on the Internet. Once a nasty exploit has got an attacker onto a network they will look to get a foothold within the network lateral move and phone home to command and control server. Having a range of ports open to clients and servers allows attackers to make an outbound connects from whole host of tools, including PowerShell for that matter.
The Solution
Check you egress filtering and lock down any unwanted open ports out to the internet, your perimeter firewalls should not allow these outbound connections. Obviously certain services are going to need to make outbound connections such as web proxy and email gateways and these rules should be appropriately provisioned. To take this one step further enable your outbound firewall rules on your local hosts, ‘hang on a sec, you must be crazy’ I hear you say, however by doing this you will be help prevent the lateral movement of attackers through your network as well as being able to get off your network back out to the Internet.
In this example we are going to use sed to add text to the end of each line in Linux. More specifically in a text file in Linux using a bash one liner! Why would we want to do this? Multiple reasons if your penetration tester. Creating user name lists or adding ports to the end of IP addresses for example. Sed is used to perform basic text transformations you can read more about it here.
Just a quick note to reference the following video on YouTube. This video demonstrates setting up Active Directory Authentication for Cisco Devices, such as Routers and Switches etc. This is using AAA on the router and RADIUS through the Network Access Policy (NAP) role in Windows Server 2012 R2, this in turn enables a Network Policy Server (NPS). The Windows server (the Radius Server) is registered in Active Directory which allows it to query the domain it is connected too for authenticating users in Active Directory to the Cisco IOS devices. You can control who has access to various network devices through rules created on the NPS. This can in turn be achieved in Active Directory via groups, binding those groups to privilege levels to pass through to deifferent devices.
