Welcome back, this is a simple demo to show why you don’t use administrator rights with normal everyday accounts you use for email and web browsing. It’s something you may hear all the time, but it’s not easy to understand what the big deal is if you don’t know.
In the video we have the attacker on the left and the victim on the right.
We have used the metasploit framework to create a simple malicious .exe (we will cover creating this in a separate video), which we have uploaded to our web server which hosts the malicious file. We then start our metasploit framework listener which, when the malware is clicked will, connect to the victim machine.
The victim machine is running server 2008R2 and is a simple RDP server which is used by multiple users in our fake organisation for various different tasks.
What you will see is that when the victim user is NOT a member of the administrators group when the malware is clicked and the user clicks past the warning, it still fails to run as they do not have sufficient rights. We then run the same test with the same malware, but this time we add the user to the administrators group, and of course the malware runs and we get full access to the victim server. We will cover some of the things we can do once we have a foothold on the machine in the next video.
The Meterpreter commands we run in this video are:
sysinfo; this gives us the info of the infected system we are connected to.
shell; this launches a hidden Windows command prompt which allows you to run native Windows commands. Which we use to launch “notepad.exe” as a demonstration.
load kiwi; mimikatz (if you don’t know what this is go have a look online) has been ported into Metasploit and when you load the extension you can use it straight from the meterpreter session.
getuid; shows who we are currently running as on the victim server. This video shows us moving from Guest to SYSTEM.
getsystem; meterpreter tries a built in script of techniques to attempt to get SYSTEM level access. This means your malicious actions will now be run as SYSTEM.
Come back for the next video where we dump the hashed passwords of all the logged in users
A quick video showing why you need both server and client side input validation. Here we bypass client side validation using Burp Suite browser proxy to change our input from our valid credentials for the site to get logged in as admin with a simple SQL injection statement. Server side validation would prevent this attack. This method gets us admin in less than a minute, leaving us free to do whatever we want. Here we right a blog entry however we could obviously do a lot more with admin for the website.
This is a very basic demo to keep it simple, however it clearly shows the principles behind this type of attack. Filtering dangerous characters in the browser is not enough, you must perform server side checks as well.
If you have been following the previous QGR’s and the past few posts we have shown how to install LEMP on Ubuntu, and make sure we have carried out some basic hardening of the OS.
We can verify this internally by checking versions on the server but how do we get the external view and see what an attacker would see? Again, this does not need to be extremely expensive. Let’s dive in and look at some great, freely available tools.
Below is a list of free resources we are going to use in this guide.
OK, now you have all the links, let’s get started.
nmap is a free network scanner and we can use this to verify that our firewall is set correctly, and the exposed applications are running the latest versions. Let’s fire it up and scan our site.
This performs a basic scan of our webserver and the top 1000 ports. (we will cover more advanced scanning in a later post) The results are shown below.
This shows that as expected our server has only 3 ports exposed to the internet. Now let’s do a version check on those services by adding the “-sV” flag.
nmap -sV info.2code-monte.co.uk
We can now see the versions, a quick google shows we are on the latest versions, so we can move on.
If you want to scan all ports then add the “-p” flag, and port range as below
nmap -p 0-65535 info.2code-monte.co.uk
Right let’s go to immuniwebs site and using the free web scanner let’s scan our site by selecting “community Edition”, and “Website Security Test”.
After around 10 minutes you will get a report as shown below
This report will provide remediation advice if an issues are found so have a good read through. We will come back to these reports in later posts to show best practice configuration, and other tips.
Security headers are important for website security, not only for your site, but also for anyone who visits your site. Browse to the Security Headers website and start a scan. As before after a short while you will receive a report for your site as shown below.
This also has some great resources for helping you to understand what each finding means and how to remediate any issues. As with the other tests, we will come back to these in the next post.
If you are using WordPress, and making use of themes and plugins it is vital you ensure you are keeping everything up to date. That means the version of WordPress itself, the current live theme, and all plugins you have installed.
Luckily there are free tools for this as well, so lets head over to the wpsec website and launch the scan.
Simply pop in your website URL , tick the box and off we go.
If there are any issues it will tell you on this page,and you can sign up for a free account to receive a more in-depth report.
In the past few weeks we have gone through setting up a LEMP stack on Ubuntu to run our WordPress site.
As this is a web server and will be exposed to the internet we need to make sure we do some additional configuration regardless of if it sits behind a Next-Gen Firewall, or Web App Firewall. Perimeter security is no longer sufficient, we need to harden the operating system to provide some strength in depth.
Now you shouldn’t look at this as an all or nothing situation, or that hardening the operating system is something you do once and that’s it. You can start with the basics which greatly reduces your exposure, but it needs to be monitored and maintained over time.
I start with the basics and then dependent on the resources available and the value of the server/data I make improvements over time, this is a great way to learn.
Below are some resources for further information on hardening Ubuntu.
Enable ufw. This is a built in host-based firewall.
Install fail2ban. This is an intrusion prevention system (IPS) which looks for patterns to identify attacks and block the offending IP addresses.
Secure shared memory. Shared memory can be used to attack running services so we need to secure it.
Create a non-root user, and grant sudo privileges.
Enable key pair SSH login.
Disable SSH password authentication and root ssh login.
Disable any graphical User interface. (X11 Forwarding)
Disconnect idle sessions.
Make a back up
Make a back up, now we can continue.
This configuration is based on the assumption we are using port 22 for SSH, and have ports 80 and 443 open for web services.
ufw is installed by default so you can just enable without the need to install.
sudo ufw enable
And open the 2 ports we need for connecting to it
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
You can check status using the below
sudo ufw status
First up, let’s install.
sudo apt-get install fail2ban
fail2ban will work right out of the box, but we can make some small adjustments. Rather than make changes directly to the default config file located at “/etc/fail2ban/jail.conf” we can create a new file named jail.local using the following command.
This monitors for brute force login attempts on port 22, now just save and close the file then restart fail2ban
sudo systemctl restart fail2ban
Remember that this will also block YOUR IP if you fail 5 login attempts. You can adjust the time out settings in the “/etc/fail2ban/jail.conf” file.
Protect shared memory space
We need to edit the /etc/fstab file and make a settings change.
sudo nano /etc/fstab
Now we add the following line to the bottom of the file, before saving and closing.
tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0
This will require a restart which is a simple command.
Create non-root user with sudo privileges
Logging into your Linux box as root and using it as your everyday account is the same as just using the domain admin or local administrator account as a normal user account. If you don’t understand how bad this is you should go find out!
We will create a standard user account but grant them sudo privileges so you do not have to log out each time you need root. You will able to use the ‘sudo’ command enter a password to elevate to the needed permission level. Let’s get started.
Log in as root and run the following commands picking your own username
Choose a strong password, and then answering the other questions are optional. Next we assign sudo to the new user.
usermod -aG sudo newuser
That’s it. If you want to change user just use (replace newuser with the desired username)
Enable key pair ssh login.
This is much more secure than password authentication, and again if you do not understand why, I really encourage you to go and find out. As most of you will be connecting to your server via Windows machine I’ll cover setting this up using an ssh gui client, however if you are connecting from a Linux box follow the link in the resources section for a quick way to perform this process via command line.
I’m a fan of Bitvise ssh (link in resource section above) and from here we can easily create our key pair from the login tab and selecting “Client key manager”.
Generate new as shown
Make note of the profile number, and choose a strong passphrase. You can choose a larger key size if you wish but do not go lower.
Now below we can see our new key, and the export button to create a file of our public key.
Export as shown below and remember where you have saved it.
Now login to your Ubuntu machine using your new account and check for the ssh directory, and if we don’t have one we need to create it. The following command will create the directory if it does not exist and do nothing if it does.
mkdir -p ~/.ssh
Now browse here using cd and locate the “authorized_keys” file.
If “authorized_keys” file is not there then create it
sudo nano authorized_keys
No go back to your exported file on your local machine and paste the contents into the new file on your Ubuntu machine. This file should start with “ssh-rsa”, then save and close the file.
Now we set permissions making sure you replace “newuser” with your own username
chmod -R go= ~/.ssh
chown -R newuser:newuser ~/.ssh
Now we need to test that this works, so disconnect from the remote session and attempt to login using public key authentication instead of a password. In Bitvise select the correct profile, and pubkey as shown. Obviously you will need the username and host address to connect.
The first time you connect you will receive a warning about key verification, but as long as you are sure you are sure you connecting to the correct host you can accept this the first time you connect. Should you ever see this error again when connecting to this machine you should verify the keys to ensure you are not a victim of malicious activity.
You will then be prompted for the key pair passphrase (not your login password), enter this and you should be logged in. Well done now we need to disable password authentication, and root ssh login.
Disable password authentication and root ssh login
This is a quick and simple one, we just need to edit the sshd_config file and set the options to no.
sudo nano /etc/ssh/sshd_config
Disable any graphical User interface. (X11 Forwarding)
This is set in the same file, find the option and set to no
Disconnect idle sessions
Again, in the same file change the following settings
This setting will check once after 15 minutes of inactivity and close the connection. If you want a longer interval just increase the setting which is in seconds.
Again in the same file we can provide an allow list of users who are permitted to remotely connect over ssh to the machine. You will need to add this manually to the bottom of the file.
Make sure there are no typos and you have added everyone you need to as once this is set if not on the list you will not be able to login via ssh and may be completely locked out of your server. Double check before loading the new config.
To load the new settings we need run the following commands.
If you receive an error go back and check you changes as you have made a mistake somewhere. If not then restart the service to apply the changes.
sudo service sshd restart
Well done, in the future we will look at more advanced hardening techniques.
Believe it or not if you install nginx on Ubuntu 18.04 using the default repositories then you get nginx version 14! This version is not even maintained anymore, it’s like installing Office 2003 on you new Windows 10 machine, crazy right?
If you have used our quick guide for installing WordPress on the LEMP stack then this is the version you will have installed.
Let’s show how to fix it then….
First up, let’s add the repository by adding a new .list file
sudo nano /etc/apt/sources.list.d/nginx.list
Then add the following lines to tell our install where to go to get the latest version
deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ bionic nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ bionic nginx
CTRL X to exit, then Y to confirm changes and hit enter.
Next we need the nginx public key, so run the following to download it
Then add the key
sudo apt-key add nginx_signing.key
You should get an “OK” message in the console.
This is where it gets scary, so if you haven’t backed up, do it now. NO……. do it now.!
We remove all the current version components, but first we make a copy of our config file, just in case.
If you have reinstalled version 14, then you did not run “sudo apt-get update” after adding the keys and the new resources list, doh!. (not that I’ve ever done that!)
We are not quite there yet, especially if you have a website already running on the server.
There are 2 additions we need to make if we are using the standard config. (If you have used guides on this site then you will need to do this)
We need to make two changes in the nginx.conf file
sudo nano /etc/nginx/nginx.conf
in this file we need to change “user nginx;” to “user www-data;” which is right at the top.
Then we need to add the following to the bottom of the file “include /etc/nginx/sites-enabled/*;”
Both shown below
Then we reload nginx and we’re done.
sudo systemctl reload nginx
Well done. If it all breaks then I really encourage you to retrace your steps and try and resolve the issue. It’s already broken so who cares if you break it more right? And if it’s that bad, that’s why we made a back-up? You did make a back-up………right?
This is gonna be the first of a “quick guide with resource links” series where I’ll pick a subject and just post quick links to guides, warn of pitfalls you may encounter, or things you still need to do. (this is for my own future reference as well!)
Hello there…..so…..recently I had to migrate this site to the cloud after years of being hosted in my home lab, and thought I’d do a quick write up while I am at it. Previously I have posted step by step guides for installing my fave stack, but there are so many really good guides I’m just gonna direct you to the best one’s out there for the initial install.
Digital Ocean have some great guides online and are generally where I look first for anything LEMP related. I did have a look at Apache, but I do still prefer nginx as my webserver. There is a good article here; https://kinsta.com/blog/nginx-vs-apache/ if you want to delve into comparisons.
Don’t just follow these word for word, you will need a little bit knowledge to tailor to your instance if not using Digital Ocean hosting. If you have followed previous guides on my site you will have enough knowledge to follow these. Not to say these aren’t good enough for absolute beginners but if you follow blindly with no basic concept of LEMP, Ubuntu or Linux you will come unstuck.
Links To Resources
The list of articles below are in order of install;
Make sure you note any user account names or passwords you create.
Double check, then check again before you disable SSH root login, or password authentication. (You’ll only do it once if you lock yourself out of your own server!)
Make a backup before each step. You will mess up, or something will go wrong, just make sure you do not have to start from scratch!
If you publish a WordPress site on the internet, then within minutes it will be scanned and you will see brute for login attempts. (Even if it is just to blog about the progress of mold on your shower curtain)
There is still more to do to ensure your site has a decent level of protection
If you create a private key, (for anything) make, make, make sure you keep this private. Don’t make loads of copies and forget to delete them.
In the next of our short videos we show why download warnings should not be ignored. We are using a Windows 7 machine just for ease, this will also work in Windows 10 (I haven’t gotten around to updating all my test victim machines yet!)
When you are browsing the internet and trying to find what you are looking for; one thing you can guarantee is that there will be thousands of malicious sites pretending to be the website you need.
Here our user is looking for some free software to play a video file, after a google search goes to a site they think will have what they want. The site prompts that they need to update their browser, how responsible of them to make sure I am up to date. The update is downloaded, and the browser warns there is an issue with this. However the user is impatient and just wants the software, ignores the warning and installs it. That’s why they have anti-virus right? If it is malicious that what it’s there for.
They continue with the download and run the file. and in the left hand side machine you will see (as you have seen in previous videos) just how quickly this happens, and just how quickly the cyber criminal can take screenshots, pop messages on the screen, and control the machine which we show by launching Windows programs such as calculator and notepad.
Another quick video to show just how quickly a server can be compromised and taken over completely by an attacker.
In this video we have a server running an out of date and un-patched application, which gives the attacker a way onto the server. Then the attacker dumps and cracks the password hashes, which gives persistent remote (using ssh) access to the system. The attacker can then continue to access the server for whatever purpose they wish
Then the attacker changes the root (admin) password potentially resulting in no one else having admin access to the system. Allowing them to hold the system to ransom or threatening to take it off line to disrupt the business function, or continue to search and remove data unhindered.
This all happens in under 4 minutes. Always stay as up to date with versions and patches as possible.
This is a quick video which shows in a very basic way how important encryption is. It is important to practice defense in depth, so even if an attacker manages to gain persistence on your network and is able to “man-in-the -middle” your network connections, encryption gives another layer of protection meaning communication is not in clear text, preventing login credentials being captured.
It’s important remember, that just because an attacker has gained a foothold, does not mean they can stay there or actually do anything. It standard user permissions are well controlled, then the attacker will need to elevate their privileges. One way of doing this is capturing passwords.
The more steps an attacker needs to take to carry out their intended actions to more chance you will have to hopefully detect them on the netywork.
Here we simulate an IT engineer logging in a server terminal session, and showing how encryption protects the connection compared to telnet which communicates in clear text.
We are going to quickly touch on something which frustrated me for a short while and it is related to the default configuration used by “WECUTIL” when setting up WEF (Windows Event Forwarding).
Previously I had always forwarded logs from my endpoints into Graylog using either nxlog/syslog or OSSEC so had never had this issue before. I noticed after setting up WEF that my logs in Graylog did not contain the full message field which it always had previously. At this point I’d like to point out that I do not need this field in all my logs however it is nice to have in some cases so I wanted to look at why.
It was due to the default setting of WECUTIL when setting up WEF. It is set to “RenderedText”. When this is set the messages for our test domain appear as below.
To enable us to get the full message we need to run the following command on the Event Log Server from an elevated Powershell Window. (Make sure to replace “name of subscription” with the name of your own subscription. You can run the command without specifying a subscription name but I don’t recommend doing this as it may create a hell of a lot of traffic and crash your network. Do a test first if you want to enable this, create a new subscription for a single eventID then apply this change and monitor. Only if you are happy should you roll this out to all machines.
wecutil ss "name of subscription" /cf:Events
If this causes issues you can roll back using the command below;
wecutil ss "name of subscription" /cf:RenderedText
Let’s assume all is OK after it is enabled and take a look at the differences in the forwarded messages in Graylog.
As I said previously, this is useful in some cases depending on your setup, and if you are sending them to a SIEM or not. I just thought I’d show that this can be configured natively in Windows if required. It was something I did not know about so it might help someone else.