"Ask, and Ye Shall Receive"

#1

A crazy thing happened at work - I’ve been interested in Application Securty
and pentesting for almost 2 years now, but only recently have I started to become
more active in order to gain knowledge.

They knew this at work, so I called for a 1:1 with my supervisor, and asked

What if I’d take ownership of our application’s security?

I’ve prepared some notes why I want to do this (self development, motivation),
or why is it good for the product & company (big customers will be interested to know where
and how their data is stored and retained at the very least), but to my surprise,
before I could even start vouching for myself, the answer was

Yes, we’d love that to happen

I was quite surprised by the answer, but their reasons were very similar to what I was about to say.
Win-win, right?

After some internal celebration (while keeping a straight face), I started to make plans
on what I’d like to do in my new position.

The Pentest

As the 0th step, I started to pentest our application - I didn’t expect
any mind blowing results, since I’m biased by knowing the internals and I’m
not that good yet to find non-obvious issues. For the record, and without giving away too much:
the application is using Angular on the client and Django on the server, all on AWS.

With this in mind, I still went ahead and did it, and I was quite pleased, because:

  • I could run my first ever brute-force attempt on a real site - I didn’t get a password
    for the account I was using, but that won’t make it any less of an issue.
    The command I used is hydra -l [email protected] -P ~/Downloads/rockyou.txt xxx.xxx.xxx.xxx http-post-form '/oauth/token:username=^USER^&grant_type=password&password=^PASS^:Unauthorized' -V
  • I did implement a CSRF and a Clickjacking PoC - CSRF couldn’t be exploited, but due to a missing X-Frame-Options header, the latter PoC worked, YAY! Also made a note that the original site is sub.domain.com, and sub-domain.com is available, so it’d be easy to fool someone.
  • Every single user input field I’ve found I tested for XSS - with all the wonky characters you can imagine (and even :crazy_face: emojis) - I must say I was impressed when nothing I tried has worked. I’ve also tried uploading avatars with names like -1.jpg" onerror="alert(1)", but again, it was all sanitized.
  • SQL Injection didn’t work - but I wasn’t expecting it anyway
  • I’ve found 3 CVEs for our dependencies, but they all relied on certain configurations, which
    we didn’t have - lucky us I guess?
  • I did find a couple of misconfiguration issues, and a way of triggering an Internal Server Error
    with a file upload, which sounds interesting, maybe I could do something with it.

You know what they say:

If you failed a pentest, you know where your biggest vulnerabilities are, if you passed one, it doesn’t mean you’re secure, but instead it means you don’t know what are your weaknesses

While I really enjoyed doing the above, and will carry on doing it for a couple of days to see if I can find anything
meaningful, I’d like to involve an external pentester team at some point.

What’s next?

The next step is to write my first ever pentest report - which I’m looking forward to, there are a couple of
good templates in this repo that I plan
to borrow some inspiration from.

I received some advice as well, one of them I think is probably the most important:

… Which means first you need to build solid relationships with your development teams. You want them to feel comfortable. You want them to feel they won’t be slowed down coming to you. It needs to be a clean /good process for both sides.

By Jordan Ligas on Twitter

Since I’m still part of the development team, I think this one is going to be relatively easy, but I think this is a very crucial part of one’s success as a security enthusiast.

The other is not much of an advice, but a good starting point, the “Your code”, “Your application”,
and “Your product users” sections in the SaaS CTO Checklist will help you come up with the basics, and will point you to things you should learn about.

Summary

If you want to be involved with the security aspect of the software you’re working on,
try to make the first step! I was surprised this was all it took, but yet here I am - and I think you can do this too!
Especially if you’re working at a smaller firm, I think security is more important, since if they lose
the trust of their users, it can mean the end of their company, whereas larger companies (ever heard of Equifax?)
can survive breaches, either because they have the money to endure while they rebuild trust, or
have something else that’ll make them resilient to losing customers.

As I’m celebrating this new position, please accept my virtual :beer: or a :tumbler_glass: (even a :tropical_drink: if that’s your game)!

And as always, thanks for reading :smiling_face_with_three_hearts:

11 Likes

(Leader & Offsec Engineer & Forum Daddy) #2

This is awesome! Congrats man!

I usually find that when I test angular and react apps I can’t find much in the way of old school application vulnerabilities.

If I was you, I’d look hard on logic issues, can you delete somebody else’s files just being authenticated?

I’d hope you’re using Burpsuite, so capture the request to add or delete a certain item, authenticate as a lower priv or different user, and try the same request. You might find that the application is just checking that somebody is authenticated at all, and not that you own the asset etc.

The fact you’ve not found very much is really good because it means you’ve done a quick sweep. Some 14 year old script kiddie isn’t going to find something if you can’t (unlikely).

Anyway - keep up the awesome work man, I love these types of posts!

3 Likes

#3

Yep, that’s what I gathered - the app (and infrastructure) should be safe from automated attacks, at least the most basic ones. The app is simple enough that there are no different authorisation levels - I did manage to bypass the password policy though, and I could set “a” as a valid password. Not a big issue, but it goes into the report for sure :wink:

2 Likes

#4

Great stuff! Just as @pry0cc said, React, Angular and most other modern web frameworks implement input sanitation out of the box. XSS of any kind is a no-go.
But definitely attack the logic, use BurpSuite and capture requests. Mess around with parameters, yada yada.
Another thing I can recommend is implementing basic web security testing in your DevOps pipeline (if you’re using one). You’ll definitely see some false positives, but it’s good to have nonetheless.

Good luck! <3

2 Likes

#5

Congrats on the new position, its good to see companies taking it seriously when someone stands up to be counted.

As you are on AWS, I would suggest that you look to that infra as a secondary test, look at your instance profiles, assigned roles etc. harden the infra that your app sits on in parralel to your app itself. (Assuming that you manage the AWS infra alongside your app as part of your DevOps pipeline ofc).

pacu from Rhino Security labs is a good tool for AWS testing, (https://github.com/RhinoSecurityLabs/pacu).

All the best.

2 Likes

(Leader & Offsec Engineer & Forum Daddy) #6

I second this, you can automated authenticated scans with OWASP ZAP in docker. I spent a lot time researching this and have some code to get JSON from ZAP (to do with whatever you like!).

2 Likes

#7

Thanks for the advice @pry0cc @Nekiruy & @icyphox - I’ll be working on making a proper CI/CD pipeline in the near future with SAST + I’ll also be more firm on adding logging (pretty much non-existent at the moment, but the app is just starting to evolve)

I’ve looked at Pacu, but haven’t tested it yet, but looking forward to it!

3 Likes