Category: Security

XSS with CSP set to “self”

June 5, 2023 / / 0 Comments

Although initially one might think that the Content Security Policy(CSP) set to self will defeat XSS then depending on the web app, it might not be the case. Depending on how well the application is written there still might be ways to get around it.

When playing around on HTB I came across a machine where the initial foothold was designed to be gained via cross-site scripting(XSS) against a “bot user” on a website. I saw that when editing a field in a order form on my own user I could successfully ender a XSS payload, yet it got blocked by the CSP. As it was set to self, making the web browser reject inline Java Script. After looking around a bit on the page and discovering it’s features I noticed that I can actually upload a profile picture. After discovering that I decided to try and see if there are any restrictions on files that can be uploaded as my avatar. Lucky for me there weren’t any and I successfully uploaded a Java Script file as my profile image.

After having uploaded the malicious Java Script payload as my profile image I could get XSS to trigger on my own order forms. It was just a matter of pointing the inline Java Script to include its source from my profile image. 

<script src="http://ctftarget.htb/static/profile/1"></script>

After that it was just a matter of finding out how to feed that XSS to the bot user, which turned out to be easy – update the bots order form as permissions were broken.

So when you come across restrictive CSP look for other functionalities which might help you reach your goal. And like always use your skills wisely/legally/responsibly.

Notes on Pentesting/CTF “hacking” a gRPC application

May 25, 2023 / / 0 Comments

Things I describe here are only to be used in a “lab/ctf” environment or on systems you have actually permission to try things out on.

Discovery

When playing around on HTB I ran into a strange port/service I hadn’t seen before. My nmap scan showed that port 50051 was active but “unknown”. Just out of curiosity opened a connection to it by using telnet after a while it timed out stating that its a HTTP/2 based service:

A quick Google search later it seemed to be a gRPC server. You can read more about it on their website gRPC.

Tools to interact with gRPC

As I hadn’t played around with gRPC previously I spent some time looking at tools and ways to interact with gRPC applications.

The options I found were:

After a quick look I ruled out writing Python code, as it seemed too much for a “simple CTF machine” and my current use case.

Next I took a look at Postman/Insomnia, their interface was similar and they could easily interact with the gRPC service but they were lacking some functionality to conveniently pentest the application.

Yes they were able to show what “Symbols” are available in the gRPC app, it they didn’t return some descriptive info/reflections properly at least in the app I was “hacking” which ended up for me looking at other tools.

grpcurl looked like a nice command line tool and was able to explore the app nicely:

But it also didn’t reflect all the features/parameters of the application and was still lacking something I found that grpcui had!

Now we come to my favorite of the bunch and that got me past the finish line on my target machine – grpcui. What this tool does is give you a WebUI to access and interact with the backend gRPC application. Why this is good for “hacking and pentesting” is that this gives you the option of proxying the connection through BurpSuite and use other automation tools to interact with the gRPC service. The current version of grpcui had a “csrf token”, but it was a static value so you could indefinitely, so basically could be ignored.

Testing/”hacking” a gRPC application

So after having found a tool that seemed to suite my purpose I started poking and prodding at my target gRPC application using a web browser with the help of grpcui.

When starting grpcui it basically starts a little WebUI on localhost:”SomeRandomHighPort” which you should access via a web browser. Startup Example :

If you use the bind parameter to bind it to some IP address that differs from loopback(127.0.0.1) then your browser will gladly proxy your connections to Burp or ZAP. After that you can continue your “regular pentesting workflow” .

In my case after having poked and prodded at the app for a bit I found that it had a SQLi in it. So I opted to take the raw request from Burp and “unleashed” sqlmap on it and dumped the whole database. That contained a username and password combo in it I could use to access the box over SSH and “user flag claimed”.

HackTheBox don’t get stuck on the decoy’s

May 24, 2023 / / 0 Comments

Lately I’ve been doing a quite a lot of playing around on HackTheBox. I just love the “competitive mode/season” thing they are trying out, as it just gives you a target for the week. It does add a nice incentive to play around there and makes it harder to forget, as who doesn’t like getting higher on the “leader board”.

But what I’ve noticed over the past few weeks there is that there are some decoy hints on the machines. So if you seem stuck for a while and are quite sure you are doing the right thing.. Just take a step back and go through your notes again. The last decoy I found my self stuck on for a while was an app returning “username” in the header. Of course that was the value for username I used in all the following exploitation steps instead of my own username that I used to register. Wasted a bit of time because of that. It was there purely to throw people off! But hey lesson learned!

Also although nmap might say that some software version is vulnerable then usually that’s not the way in. It still tends to be some web application vulnerability that gives you the initial foothold not “vulnerable ssh daemon” (don’t waste time guessing usernames for scp exploitation). Most likely there is either a path traversal issue which allows you to see get access to something you shouldn’t or SQL injection.

Oh and before I forget, -p- flag for scanning is quite a good idea, as there have been quite a few hosts there where the actually vulnerable service doesn’t show up in the default port selection. And if you feel stuck then surely visit HackTheBox forums/discord servers to get a nudge/do a sanity check on your progress. Really nice and active community there with quite a few people willing to share ideas with out actually spoiling the challenge.

Tenable.SC plugin/feed updates failing & disk full

February 3, 2023 / / 0 Comments

Today I was called to help with a Tenable.SC instance that failed updating it’s plugins. It turned out that that had its “/opt” filled 100%.. A little investigation into where the space had gone led me to see that “/opt/sc/data/” folder was full of “feed.XXXX” folders each being 2.4GB in size. (~130+ GB in total..)

When looking at the logs I could see that as of December 6th updating the feed had failed (/opt/sc/admin/logs/sc-error.log).

PHP Fatal error: Allowed memory size of 1782579200 bytes exhausted (tried to allocate 20480 bytes) in /opt/sc/src/lib/FeedLib.php on line 2769

So in order to get the SC updating itself normally again I removed all unneeded feed folders, except the “latest feed update attempt” by running the following command:

find /opt/sc -name "feed.*" -ctime +1 | xargs rm -rf

And next in order to fix the “feed update failing” & prevent it from filling up the disk again within a month had to increase the PHP memory parameters. Todo that I edited “/opt/sc/support/etc/php.ini” and turned the memory limit up to 1900M, its default value was 1700m. After that restarted the SC by running :

service SecurityCenter stop && service SecurityCenter start

Additional thoughts on SC disk cleanup can be found in these 2 posts on tenables website:

Kali ticket_converter.py issue fix

October 3, 2022 / / 0 Comments

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

March 1, 2022 / / 0 Comments

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.

Nessus Essentials activation email issue

August 28, 2021 / / 0 Comments

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

August 24, 2021 / / 0 Comments

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

August 23, 2021 / / 0 Comments

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:"192.168.90.1"
* Rebuilt URL to: http://google.com/
*   Trying 216.58.210.174...
* TCP_NODELAY set
* Connected to google.com (216.58.210.174) port 80 (#0)
> GET / HTTP/1.1
> host:192.168.90.1
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://192.168.90.1/
< 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..”.