Kali ticket_converter.py issue fix

When trying to convert Kerberos tickets I ran into a little issue with it being unable to import a name.. To be more exact the specific error is:

Traceback (most recent call last):
File "ticket_converter.py", line 30, in
from impacket.krb5.ccache import CCache, Header, Principal, Credential, KeyBlock, Times, CountedOctetString
ImportError: cannot import name 'KeyBlock' from 'impacket.krb5.ccache' (/usr/local/lib/python3.8/dist-packages/impacket-0.10.1.dev1-py3.8.egg/impacket/krb5/ccache.py)

Fortunately the fix was quite easy when looking into impacket file mentioned in the error. Namely it seems, they have changed the class names and added versioning.

grep -i keyblock /usr/lib/python3/dist-packages/impacket/krb5/ccache.py
class KeyBlockV3(Structure):
class KeyBlockV4(Structure):

When seeing that I realized that the fix is easy.. Just change all occurrences of the word KeyBlock to KeyBlockV4. Just open up ticket_converter.py in vim and type: “%s/KeyBlock/KeyBlockV4/”. That fixed it for me. Happy Hacking! 🙂

OWASP ZAP/ZED Attack Proxy missing after Kali upgrade

If you find your self looking in the menus and not finding OWASP ZAP in the menu’s any more after updating/upgrading your Kali instance. Even locate command returns former paths to zap files that don’t exist any more.. Fortunately the fix is easy just updatedb command as root/with sudo. That should fix the issue and ZAP should be back visible in menus. At least that worked for me.

Couldn’t create partition or locate an existing one in Windows 10

Over the weekend when my Windows 10 decided to completely go nuts. Ok it was my fault, as it happened after some exploitation attempts. But during the re-install I ran into a small issue. When trying to re-install on my NVME drive the setup kept stating that “Couldn’t create partition or locate an existing one in Windows 10“.

In regards to that error there were some hints out there about using diskpart to clean/”resetting the disk” which I didn’t want to do, as I had things I wanted to keep on other partitions.

Fortunately I got away with only deleting the all the Windows related partitions on that disk. Namely I deleted the windows partition itself & 2 recovery related partitions – so all I had left was the data partition. After doing that my windows installer stopped throwing that error and went on without any issues.

Nessus Essentials activation email issue

As it turns out that Nessus Essentials is having trouble sending out e-mails. Ran into it after installing Nessus on a Kali VM. Filled out the form and although Nessus stated, that e-mail sent successfully, no message arrived. Not even after a few more attempts. Fortunately there is a quick work around, I wish I just had turned to Tenable’s website a bit sooner. To activate Nessus Esstentials just use Tenable’s own website to request the activation code. Just go fill out the form at https://www.tenable.com/products/nessus/activation-code and don’t wait for the one from your own installer, as it probably will never arrive.. Happy Scanning!

Don’t add user editable scripts to root cron

In quite a few servers that I’ve managed to gain access to during pen-tests I have found issues in filesystem permissions. The type of permission issues that end up with me gaining root privileges, aka privilege escalation.

When you gain access to a server it always seems to be a good idea to check the crontab log’s. If you have access to them and you if you see any of the scripts running in with the root user permissions.

If you find any root/other useful user entries in the logs, then go and check scripts filesystem permissions. Quite often I have stumbled upon a root script that can be modified by the “service users”. I don’t exactly know why, put some people have scripts with “apache/ww-data” write permissions run by root.

That is just a bad idea on so many levels. How-come people don’t realize that having root run what ever normal user’s scripts gives instantly root privileges to that user.

Using Cisco WSA to bypass firewall and access networks you wouldn’t have access to

This is a short write up of a old flaw I reported to Cisco years ago to which they replied it’s that they see no issue there.

When doing a security audit at a client I stumbled upon a Cisco-WSA/11.5.2-020 appliance filtering HTTP traffic. As it’s the first encounter for me with sucha device, the first thing that came to my mind when seeing that header in HTTP responses was, how can I abuse this. As it turns out I actually could abuse it.

Setup description

It is a small corporate network with a few different segments separated by a firewall with a really strict access policy. Client computers don’t have access to the management network only access to specific internal applications and the internet.

All internet bound HTTP requests are sent by the firewall to the Cisco WSA by using “policy based routing”. that client computers network from which all internet HTTP traffic gets redirected to the Cisco WSA by the firewall.

The Issue

The clients firewall was blocking access to their management network from the users segment as it should. But I was able to bypass the firewall rules by adding a extra header to HTTP requests and effectively map all the hosts in their management network. As it turned out they had too much trust in their Cisco appliance and firewall rule set and thought you don’t need to create “deny to internal” rules on the WSA. But that provided them with a false sense of security.

In the case of this setup, when you add a extra “Host: x.x.x.x” header the firewall wont know the true connection destination thus won’t be able to actually do it’s job. As it will see your computer connecting to the IP address of the original query destination. At the same time the Cisco WSA device ignores the connection that your firewall thinks you are opening actually establishes a connection to the secondary host header. That effectively bypasses your firewall policy giving and purely relies on what policies you have set in the WSA. An example from the notes I have from that time:

C:\>curl -kv http://google.com --header host:""
* Rebuilt URL to: http://google.com/
*   Trying
* Connected to google.com ( port 80 (#0)
> GET / HTTP/1.1
> host:
> User-Agent: curl/7.55.1
> Accept: */*
< HTTP/1.1 301 Moved Permanently
< Location:
< Transfer-Encoding: chunked
< Date: Mon, 23 Aug 2021 12:16:19 GMT
< Via: 1.1 wsa.ent.int:80 (Cisco-WSA/11.5.2-020)
< Connection: close
* Closing connection 0

As you can see, I originally queried google.com, but WSA actually returned to me the HTTP response from an internal host. In that case it was the management network where the WSA management interface resides. Using that “Host” header, I could map their whole network. When the IP address I chose didn’t have a listening tcp port 80, then the connection was closed, when it existed it returned the HTTP page/response from the hidden server or when the host didn’t exist it timed out.

Although this looks bad, then it gets worse.. At least for that client. In their case they actually had a switch that had it’s web management over HTTP open and with default credentials. It turned out it was the same switch I was connected to, so I was able to reconfigure the port where I was connected to be directly in the management network.

Final thoughts

Although most of the things that I reported to the client probably could have been avoided by having changed their switch admin password and having also a strict “deny all inbound HTTP” traffic from that specific user segment rule on the WSA (not sure, if it would have triggered). Then still in my honest opinion the fact that the WSA device actually connects to the added host header, while all other devices in the connection chain see that the client is going to some innocent place is just wrong. Probably a lot of implementations can fall victim to this oversight in the policy as normal policy testing will never find such a loop hole.. When directly trying hidden/internal hosts you get time outs, when you add them to the header “voila it works..”.

Why enabling Zabbix remote command feature can be bad – chink in the armor of your servers

Today I was reminded of a little Pen-Test I did last year, which reminded me that I should write why for me that feature seems like a bad idea most of the times.

Zabbix is a popular monitoring solution which is agent based and it has the ability to run remote commands on the agents. While it may be nice to have your monitoring system try and auto restart things, etc. Enabling that feature also has other consequences, that people fail to take into account or just ignore.

Namely that it opens up a whole new nice attack vector to easily gain foothold in your servers. One issue is that usually the monitoring service instances are not that well protected. In a lot of cases the reasoning behind that is that “it’s just monitoring, there nothing sensitive there”. Although I disagree on that part, not going to rant about that. That statement becomes completely wrong as soon as you enable the remote command ability on the agents.

So what harm can come from the remote command feature? Why is it bad? In one of my Pen-test engagements I used it to take over the client’s whole infrastructure. Although it’s “just a monitoring solution”, gaining access to it was enough to compromise all of their servers thanks to the remote command feature. How I got access to their monitoring system is one thing, they had multiple setup failures there, but that’s besides the point. Never have devices with admin access to any system lying around unprotected in your office.. IE monitoring dashboard meant to show your service status in the reception area in your office..

Not to be too technical, but here is a short description of what happened. Basically after having gained access to the monitoring dashboard and noticing it had Zabbix admin privileges I did the following:
* Tested whether remote command execution was enabled on some hosts, that turned out to be YES.
* Using that figured out which of their servers had outbound unrestricted internet access.
* Activated a simple remote shell on the internet capable devices, just to make my life easier
* Found out their systems patch levels via Zabbix and abused a existing sudo vulnerability to gain root privileges

Long story short.. Just think twice about activating that feature and maybe there is some better way to do what You need. Oh yeah and patch your systems, as that sudo vulnerability at that time was already quite old.

Apache TLS auth restriction based on custom OID value using PeerExtList

A client was concerned that Apache/OpenSSL combo was not respecting certificate key usage values out of the box. They demonstrated how they logged into a web-service using certificates that didn’t have the “TLS Web Client Authentication” extended key usage set. Because of that were asking if they had some config error and how would it be possible to require those extensions to be set.

They had messed about with different hints they got from the web, but none worked properly. After a bit of reading manuals/researching the web and tinkering around I managed to get it working the way they wanted it to. So I thought I’d share the brief config snippet to help out anyone else who was running into the same problem.

<Directory /var/www/html/test.site/tls_test>
  SSLVerifyClient require
  SSLVerifyDepth 2
  SSLOptions +StdEnvVars          
  Require expr "TLS Web Client Authentication, E-mail Protection" in PeerExtList('extendedKeyUsage')

Kali apt-get update fails with signature error

When booting up a older Kali VM I hadn’t used for a while, I wanted to update it & ran into a small issue. Namely whilst trying to update I ran into the following error message:

root@kali:~/Documents# apt-get update
Get:1 http://kali.koyanet.lv/kali kali-rolling InRelease [30.5 kB]
Err:1 http://kali.koyanet.lv/kali kali-rolling InRelease
The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository devel@kali.org
Reading package lists… Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://kali.koyanet.lv/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository devel@kali.org
W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository devel@kali.org
W: Some index files failed to download. They have been ignored, or old ones used instead.

As it seems, the GPG key had been changed. Fortunately the fix is easy, just do the following:

  • Check which is the most current key-s file at https://http.kali.org/kali/pool/main/k/kali-archive-keyring/ and download it. For example today it was “ kali-archive-keyring_2020.2_all.deb “.
  • Download it using the wget command or via browser:
    wget https://http.kali.org/kali/pool/main/k/kali-archive-keyring/kali-archive-keyring_2020.2_all.deb
  • Install it by running “pkg -i kali-archive-keyring_2020.2_all.deb”
    root@kali:~/Documents# dpkg -i kali-archive-keyring_2020.2_all.deb
    (Reading database … 528672 files and directories currently installed.)
    Preparing to unpack kali-archive-keyring_2020.2_all.deb …
    Unpacking kali-archive-keyring (2020.2) over (2018.2) …
    Setting up kali-archive-keyring (2020.2) …
    Installed kali-archive-keyring as a trusted APT keyring.
  • Now updating should work again.
    root@kali:~/Documents# apt-get update
    Get:1 http://kali.koyanet.lv/kali kali-rolling InRelease [30.5 kB]
    Get:2 http://kali.koyanet.lv/kali kali-rolling/main i386 Packages [17.5 MB]
    Get:3 http://kali.koyanet.lv/kali kali-rolling/non-free i386 Packages [167 kB]
    Get:4 http://kali.koyanet.lv/kali kali-rolling/contrib i386 Packages [97.7 kB]
    Fetched 17.8 MB in 3s (5,676 kB/s)
    Reading package lists… Done