AAA – What is the difference between Authentication, Authorization, and Accounting?

Authentication, Authorization, and Accounting or AAA is an framework that allows access to a computer network/resource,

Authentication

Authentication identifies the user. It’s from the Greek authentikos “real, genuine”. We can think of it as proving the identity of the user. Bob sits down at the computer and types in his password (Something he knows) and confirms that he is in fact Bob.

Authorization

Authorization is the privileges that the user has to the system. For instance, Bob is now authenticated to the computer, but he may only be authorized to access email and a web browser.

Authorization and Authentication can get confusing. In simple terms

  • Authentication – Who are you?
  • Authorization – What you have access to.

Accounting

Accounting is the auditing or logging arm of AAA. It is for answering the 5 Ws Who did what, when, where, and how. For instance, accounting could log that Bob checked his email at 9:30AM, Improved his mind by reading posts on incredigeek.com for a couple hours, then checked email again before shutting the computer down.

Hopefully that is a short helpful explanation of AAA. For more information, check out the following links.

https://afteracademy.com/blog/authentication-vs-authorization/

https://en.wikipedia.org/wiki/AAA_(computer_security)

Install NetworkMiner on Kali Linux

The Network Miner tool is a handy little utility that works great on Windows. It sorta works on Linux. Doesn’t appear to be able to read the traffic coming off the interface, but you can drag and drop a pcap file on it. You can export a pcap file from wireshark, but it needs to be a pcap, not the newer default pcap Wireshark defaults to. Can change it in the “Save as:”

Install Prerequisites

sudo apt install mono-devel

Download and Configure

wget https://www.netresec.com/?download=NetworkMiner -O /tmp/NetworkMiner.zip
sudo unzip /tmp/NetworkMiner.zip -d /opt/
cd /opt/NetworkMiner*
sudo chmod +x NetworkMiner.exe
sudo chmod -R go+w AssembledFiles/
sudo chmod -R go+w Captures/

Should be ready to launch.

Launch Network Miner

mono /opt/NetworkMiner*/NetworkMiner.exe
Network Miner on Kali Linux

Further Thoughts and Reading

You could potentially get a live view of what is going on by using the “Receive Pcap over IP”

Maybe use something like

tcpdump -i wlan0 | nc localhost 57014

The following links should help and provide more information.

https://www.netresec.com/?page=Blog&month=2014-02&post=HowTo-install-NetworkMiner-in-Ubuntu-Fedora-and-Arch-Linux

https://www.netresec.com/?page=Blog&month=2011-09&post=Pcap-over-IP-in-NetworkMiner

How to Verify Signal APK

These steps are for Windows, but they should be very similar on macOS or Linux.

Prerequisites

  1. Android Studio installed
  2. Install the latest SDK

Locate apksigner

Apksigner is part of the Android build tools should be in the SDK directory.

%APPDATA%..\Local\Android\Sdk\build-tools\30.0.0

Lets open up a terminal and navigate to the build-tools. Replace 30.0.0 with the actual SDK version you have installed.

cd .\AppData\Local\Android\Sdk\build-tools\30.0.0

Alternatively use the full path (Replace username and 30.0.0 with actual username and SDK number)

cd C:\User\username\AppData\Local\Android\Sdk\build-tools\30.0.0\

Verify Signal APK

We can now verify the Signal APK with the following. Replace username with your username.

.\apksigner.bat verify --print-certs C:\User\username\Downloads\Signal-Android-website-prod-universal-release-6.0.6.apk

Scroll up to the top part and look for the part that says

Signer #1 certificate SHA-256 digest:

Check the signature against the signature on Signal’s website/

https://signal.org/android/apk/

You may see a bunch of

WARNING: META-INF/xxx.version not protected by signature...

Sounds like this can be expected and is a common thing. The certificate is stored in META-INF which means that other files stored in META-INF are not protected. Most of the files in that directory are only version numbers of libraries the app depends on. There shouldn’t be anything important so shouldn’t be a security concern.

https://stackoverflow.com/questions/52122546/apk-metainfo-warning

Directory Traversal – Burp Suite

Here are a couple different ways to do directory traversal.

More detailed information is available at the following site.
https://portswigger.net/web-security/file-path-traversal

  1. Normal directory traversal
  2. URL Encoding
  3. Getting around applications that strip directory traversal sequences
  4. Using a null byte

Directory Traversal

What exactly is directory traversal anyway? Well, it is pretty much exactly what it sounds like. We traverse directories by manipulate the file path, for something like an image, to get something more valuable like the passwd file.

In it’s most basic form, we can add ../../../../../etc/passwd to a file path and instead of pulling an image, we get the passwd file.

For instance, if we load an image on a website, it’s file path on the server may be something like /var/www/html/image.png. If we right click on an image and open in a new tab and inspect the URL, we can see this path. “Note: Web servers have a root directory for all the website files. Generally web files’ root starts there not / root of the machine.”

Now if we remove image.png and replace it with ../ (../ on Linux/macOS or ..\ on Windows) we’ll go backwards one directory. String them together and we can go back to the root of the drive. Then we can add /etc/passwd (Or replace with whatever file we want) and load the contents of that file.

Most web applications should have some sort of protections in place to guard against directory traversal. Let’s go over a few ways to get around it.

URL Encoding

URL encoding sometimes can work and is simple to do. In Burp, select the file path, right click, Convert selection -> URL -> URL-encode all characters.

You can also try double encoding. Encode once, select the encoded text and encode again.

In the above screenshots, ../../etc/passwd becomes “%25%32%65%25%32%65%25%32%66%25%32%65%25%32%65%25%32%66%25%36%35%25%37%34%25%36%33%25%32%66%25%37%30%25%36%31%25%37%33%25%37%33%25%37%37%25%36%34”

Getting around applications that strip directory traversal sequences

Sometimes the web app can strip out text that it knows is directory traversal characters/sequences. For instance, it sees ../ in the requested url and just strips it out.

We can do something like the following sequence to get around it.

....//....//etc/passwd

That is 4 periods, followed by 2 slashes. What happens is the web app reads the URL, goes hey ../ is not allowed, bye bye! Removes the two instances of ../ and forwards the URL on. Which ends up being

../../etc/passwd

Which is just perfect for our use case.

Using a Null Byte

If the application is using the file extension to validate that an image or other file is loaded, instead of say passwd, we can try using a null byte. A null byte is used to terminate a string.

../../etc/passwd%00.png

What can end up happening is the web application sees the .png or .jpg at the end and goes “oh that is a valid extension, carry on” and then the system reads the line and sees the null byte and says “Oh null byte! end of file path, here is your file.”

Install and Configure Fail2ban on Fedora/CentOS/RedHat

The following is a very basic guide for setting up Fail2ban for SSH.

Install and basic config

Install Fail2ban

sudo dnf install fail2ban

You may need to install the epel repo

sudo yum install epel-release

Configure to run on system boot

sudo systemctl enable fail2ban

Start Fail2ban service

sudo systemctl start fail2ban

Copy config file with

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Modify the config file

nano /etc/fail2ban/jail.local

Uncomment the following line and add any IPs that need to be whitelisted

ignoreip = 127.0.0.1/8 ::1 192.168.1.20

Save the file and restart Fail2Ban

sudo systemctl restart fail2ban

Configuring Fail2Ban for SSH

Create a new jail file in /etc/fail2ban/jail.d/ called sshd.local

nano /etc/fail2ban/fail.d/sshd.local

Add the following. Note: if you are using a custom ssh port, change “port = ssh” to “port = portnumber”

[sshd]
enabled = true
port = ssh
action = iptables-multiport
logpath = /var/log/secure
maxretry = 5
bantime = 300

Restart Fail2ban

sudo systemctl restart Fail2ban

You can list the firewall rules to verify that an IP gets banned.

iptables -S | grep ipaddress

Unbanning an IP Address

You can unban an IP address with the following command.

sudo fail2ban-client set sshd unbanip 192.168.1.100

You can check out the following link for more information

https://www.redhat.com/sysadmin/protect-systems-fail2ban

Troubleshooting SSH “No Matching Key Exchange/Host Key Method/Type Found” errors

It can be common for older devices to throw errors like the following when trying to ssh into them.

Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

or

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa

There can also be a No Matching Cipher Found error. We have talked about that in the past.

The issue is that your version of SSH does not support those older, and most likely insecure, Key Exchange and Host Key algorithms types. The errors do give us enough info to add the right options to connect to the device.

No Matching Key Exchange Method Found

For the “no matching key exchange method found.” we need to manually add the KexAlgorithms option. KexAlgorithms means Key Exchange Algorithm.

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 username@192.168.1.1

Change out “diffie-hellman-group14-sha1” for a supported Key Exchange algorithm.

No Matching Host Key Type Found

This issue is with the Host Key algorithm type. We’ll use the -o option with the HostKeyAlgorithms option.

ssh -o HostKeyAlgorithms=+ssh-rsa admin@192.168.1.1

Change our ssh-rsa with a supported “Their offer:” Host Key.

Putting it all together

You can combine the options if needed.

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa admin@192.168.1.1

We have covered some of these topics before. Be sure to check them out.

no matching cipher found. Their offer: aes128-cbc,3des-cbc…

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

no matching host key type found. Their offer: ssh-dss

Enable Logging for firewalld

Enabling logging on firewall rules can be beneficial for tracking why a certain rule is not behaving as you intended.

Enabling logging is relatively straight forward.

  • Enable Firewall Logging
  • Check Logs
  • Disable Firewall Logging (Optional)

Enable Firewall Logging

Quickest way to enable logging is to run

sudo firewall-cmd --set-log-denied=all

This changes the options in the /etc/firewalld/firewalld.conf config file. Options include all, unicast, broadcast, multicast, and off

Enable Log option for firewalld

The command also reloads the firewall so manually restarting the firewall is necessary.

Checking Logs

You can use dmesg to view the failed attempts or you can follow the messages log and filter to just show the rejects

sudo tail -f /var/log/messages | grep -i REJECT

You can now try to access the server or run a test to trigger a log event. In my case I tried initiating a SSH connection.

Oct  1 16:32:10 localhost kernel: FINAL_REJECT: IN=eno1 OUT= MAC=f8:ab:98:12:fe:11:a1:ec:a6:00:67:3e:97:00 SRC=192.168.1.1 DST=192.168.88.2 LEN=60 TOS=0x08 PREC=0x40 TTL=59 ID=43080 DF PROTO=TCP SPT=38192 DPT=22 WINDOW=52240 RES=0x00 SYN URGP=0

Interesting bits are bolded. Our destination port it 22 “ssh” and our source address is 192.168.1.1. If I want this IP to access the server, I’ll need to add the 192.168.1.1 IP range in the allowed IP ranges.

Disable Logging (Optional)

After you have finished troubleshooting your problem, you may want to turn the logging feature off so you don’t fill up the logs with failed entries.

You can turn it off with

sudo firewall-cmd --set-log-denied=off

We can verify that logging is off by running

sudo firewall-cmd --get-log-denied 

If the firewall logging option is off it will return “off”

The following site has some more information and alternative ways

https://www.cyberciti.biz/faq/enable-firewalld-logging-for-denied-packets-on-linux/

Troubleshooting DNS CPU Usage on Mikrotik Router

Problem : Lots of CPU utilization. Profile shows a good bit of it is DNS related.

DNS eating CPU on Router

The router is setup to allow DNS to pass through to web servers so rDNS and other records can be looked up and resolved. This is a specific IP block that gets it’s addresses from the router. The firewall rules explicitly allow this address range. We’ll say 192.168.88.0/24, and blocks everything else. This works for the web servers. But why are we still getting a bunch of CPU utilization with DNS?

As it turns out, the firewall rule that allows the server address range also includes routers own address! So we have unintentionally whitelisted DNS access to our router.

To resolve the issue we can add another firewall rule that explicitly blocks DNS traffic to the routers IP address. We are using two rules, one to block TCP and the other UDP.

ip firewall filter add chain=input dst-address=192.168.88.1 protocol=6 dst-port=53 in-interface-list=WAN action=drop
ip firewall filter add chain=input dst-address=192.168.88.1 protocol=17 dst-port=53 in-interface-list=WAN action=drop

Rules 6 & 7 are the two new rules we just applied. 14 & 15 block input to the router, however rules 8 & 9 inadvertently allowed access to the router’s public IP.

Firewall Rules for Router

The Result? Our CPU usage dropped!

CPU Usage dropped after adding DNS firewall rules.

Quite dramatically too as the following LibreNMS screenshot shows.

LibreNMS CPU graph showing the overall CPU utilization improvement

For more information about DNS Amplification attacks, refer to the following links.

https://ask.wireshark.org/question/6865/dns-amplification-attack/
https://security.stackexchange.com/questions/237127/why-would-hackers-attack-a-dns-server-with-a-dos

Email error – The certificate does not match the expected identity of the site that it was retrieved from.

The certificate does not match the expected identity of the site that it was retrieved from.
The server's identity does not match the identity in the certificate
Hostname in certificate didn't match

The reason for the above errors are due to the fact that the email client is trying to use mail.mydomain.com and the email server is mail.emailserver.com.

So the email client pulls the certificate for mail.emailserver.com and reads that this certificate is for mail.emailserver.com, NOT for mail.mydomain.com. Hence the conflict and it throws an error.

If you can, accepting the certificate should let everything work. It appears that on recent versions of iOS their may be some problems trusting it. The other work around is to use the actual mail server host. So mail.emailserver.com

Hydra – Socket error: Connection reset by peer

[VERBOSE] Disabled child 2 because of too many errors
[VERBOSE] Disabled child 6 because of too many errors
[ERROR] could not connect to target port 22: Socket error: Connection reset by peer
[ERROR] could not connect to target port 22: Socket error: Connection reset by peer
[ERROR] could not connect to target port 22: Socket error: Connection reset by peer
[ERROR] could not connect to target port 22: Socket error: Connection reset by peer
[ERROR] ssh protocol error

Looks like the issue can happen if you have too many threads going at once. Lower the amount of threads your using with -t. Recommended amount for ssh is 4.

hydra -L usernames.txt  -P "passwords.txt" 192.168.1.20 ssh -t4