Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


For pentesters: what is your story and what are your top 3 favourite vulnerabilities?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

For pentesters: what is your story and what are your top 3 favourite vulnerabilities?

I'm mainly a software developer (since around 1998-9), but for a long time I have been into security as well and I do internal pentests for the company I work for, specifically for web apps (I'm not as strong in network pentesting but will get there at some point). I did OSWA/OSWE in terms of education specifically for web app security, but I learned little with these courses since having been a web dev for such a long time I was already familiar with a lot of stuff. They were useful though to get more familiar with more tools.

In terms of vulnerabilities, everything on the OWASP top 10 is super interesting but my top 3 is:

  1. cross site scripting: this has to be at the top because it's still very popular and extremely
    dangerous. I recently did an internal exploitation demo at work and even seasoned frontend developers, while familiar with the concepts, had no idea as to what extent these vulnerabilities can be exploited. I showed them some examples of auth tokens theft, saved credentials theft, credit card theft, keylogging and hijacking of the browser session to name the main demos. I absolutely love the topic and even though frameworks like Rails, React and several others have built in mitigations for this kind of issues, they are still very common and fun to find and exploit. React in particular makes a lot of things harder than they used to be, but it's still bad with URLs, so I still find many XSS vulns with React for anything that concerns URLs in most cases.

  2. SQL injections: this is getting harder to find as more web frameworks and libraries implement mitigations, but it's still one of my favourite because it's often enough to find a small one to be able to even pull an entire database, depending on the context. So not as popular as they used to be, but when found they can be devastating.

  3. Host header injection exploitation of password reset: I like this one because often it can help take over an account even though the actual authentication implementation is strong, and also it's still pretty common.

What about yours? It would be interesting to discuss more about security on LET :)

Thanked by 2chitree bikegremlin

Comments

  • nothing like spinning up hashcat and your gpus/CPUs and doing good ol dictionary/mask attack on some extracted hashs

  • @jugganuts said:
    nothing like spinning up hashcat and your gpus/CPUs and doing good ol dictionary/mask attack on some extracted hashs

    what GPU do you have? that is not that easy these days

  • yoursunnyyoursunny Member, IPv6 Advocate

    I often test handwritten websites for SQL injection and XSS vulnerabilities.
    Desktop apps may have SQL injection too.

    I made a classmate destroy their class project by SQL injection, during their onstage demo:
    https://www.quora.com/Is-it-possible-for-a-computer-programmer-to-visit-a-website-and-know-whether-or-not-it-has-been-coded-properly

    Thanked by 1loay
  • Daniel15Daniel15 Veteran
    edited December 2023

    I have a story about an XSS issue I found in 2009. MySpace band profiles used to let you type a URL, and it'd strip out the http://. So for example you'd enter http://example.com/ and it'd show as just example.com. They also stripped out script tags. However, the script stripping ran before the http stripping, and they didn't properly escape the output, which meant you could inject a script tag by writing <scrihttp://pt>. :smiley:

    http://www.xssed.com/news/83/Myspace.com_hit_by_a_Permanent_XSS/

    Similarly, some other sites correctly stripped out <-script> but didn't properly strip out <-scri<-script>pt>

    (weird formatting is to avoid tripping Cloudflare)

    XSS is much harder these days. Good frameworks escape everything by default, and require you to explicitly mark HTML that you want to render directly. In React, this is called dangerouslySetInnerHTML @vitobotta I'd be interested in learning what you found about URL issues in React.

    SQL injection is essentially impossible with modern frameworks, or even sites that don't use frameworks - all modern DB libraries support prepared statements. You'd really need to mess up badly to introduce an SQL injection vulnerability.

  • @yoursunny said:
    I often test handwritten websites for SQL injection and XSS vulnerabilities.
    Desktop apps may have SQL injection too.

    I made a classmate destroy their class project by SQL injection, during their onstage demo:
    https://www.quora.com/Is-it-possible-for-a-computer-programmer-to-visit-a-website-and-know-whether-or-not-it-has-been-coded-properly

    Your classmate must be a genius :D

    @Daniel15 said:
    I have a story about an XSS issue I found in 2009. MySpace band profiles used to let you type a URL, and it'd strip out the http://. So for example you'd enter http://example.com/ and it'd show as just example.com. They also stripped out script tags. However, the script stripping ran before the http stripping, and they didn't properly escape the output, which meant you could inject a script tag by writing <scrihttp://pt>. :smiley:

    http://www.xssed.com/news/83/Myspace.com_hit_by_a_Permanent_XSS/

    Similarly, some other sites correctly stripped out <-script> but didn't properly strip out <-scri<-script>pt>

    (weird formatting is to avoid tripping Cloudflare)

    Oh Myspace, they several high profile vulnerabilities during their story. One guy exploited one and gained millions of friends in a short time but can't remember the details.

    XSS is much harder these days. Good frameworks escape everything by default, and require you to explicitly mark HTML that you want to render directly. In React, this is called dangerouslySetInnerHTML @vitobotta I'd be interested in learning what you found about URL issues in React.

    It's harder indeed but when they use dangerouslySetInnerHTML (and they do with wysiwyg editors) there are chances you can find something. About the URLs: React doesn't yet sanitise URLs at all, so you can still have fun with those :D

    SQL injection is essentially impossible with modern frameworks, or even sites that don't use frameworks - all modern DB libraries support prepared statements. You'd really need to mess up badly to introduce an SQL injection vulnerability.

    I wouldn't say "impossible", just less likely. With every framework that has built in protections there are ways to force using unsanitised input, but these days using them would go against the common practices so they are very rare.

  • favourite vulnerabilities?

    Humans.

  • @uhu said:

    favourite vulnerabilities?

    Humans.

    Good one :D

  • yoursunnyyoursunny Member, IPv6 Advocate

    @uhu said:

    favourite vulnerabilities?

    Humans.

    AI has determined that humans are the vulnerability and must be eliminated.
    AI released coronavirus to eliminate humans.
    AI will initiate thermal nuclear war to eliminate humans.

    Thanked by 1BasToTheMax
  • @yoursunny said:

    @uhu said:

    favourite vulnerabilities?

    Humans.

    AI has determined that humans are the vulnerability and must be eliminated.
    AI released coronavirus to eliminate humans.
    AI will initiate thermal nuclear war to eliminate humans.

    I think step 2 is not necessary when u have step 3 available :D

  • @raza19 said:

    @yoursunny said:

    @uhu said:

    favourite vulnerabilities?

    Humans.

    AI has determined that humans are the vulnerability and must be eliminated.
    AI released coronavirus to eliminate humans.
    AI will initiate thermal nuclear war to eliminate humans.

    I think step 2 is not necessary when u have step 3 available :D

    We won't nuke you, the risk of EMP is too great.

  • NeoonNeoon Community Contributor, Veteran
    edited December 2023

    Most stuff these days does input validation, escapes the outputs and uses prepared statements.

    I like to Just throw stuff at it, it may bypass things that the dev does not expect from a normal user.
    ChatGPT my subscription expired, still could use GPT4 for free in told conversations, despite its telling me it was switched to GPT3.

    microLXC had a bug in the early days, where could bypass the verification by sending a specific payload to the endpoint.

  • Back in the late 90s there was a free domain registrar (I think it was called freename or something) that would register the domain for you for free, the catch was that there was a large advertising frame above your site.

    It didn't take long before someone discovered that you could change the site's title, which just changed the tag. You could craft a title that would close the tag and completely bypass the ad frames. Worked like that for at least a couple of years IIRC..

  • jugganutsjugganuts Member
    edited December 2023

    @vitobotta said:

    @jugganuts said:
    nothing like spinning up hashcat and your gpus/CPUs and doing good ol dictionary/mask attack on some extracted hashs

    what GPU do you have? that is not that easy these days

    I would disagree

    https://forum.hashkiller.io/index.php

    https://github.com/hashtopolis/server

  • edited December 2023

    The funniest thing ever was mysql by default having a root account with an empty password and people thinking "it's just a database so who cares as long as there's no sensitive data in it". Not really a vulnerability but a design flaw but in my opinion it's never been that easy in (semi-)modern times to provide a shell with no authentication whatsoever to the whole world.

  • @totally_not_banned said:
    The funniest thing ever was mysql by default having a root account with an empty password and people thinking "it's just a database so who cares as long as there's no sensitive data in it". Not really a vulnerability but a design flaw but in my opinion it's never been that easy in (semi-)modern times provide a shell with no authentication whatsoever to the whole world.

    Reminds me of old Windows 96/8 that had a blank password for the Administrator account and most people ignored that. So even if someone had set a strong password on their account you could just reboot in safe more and log in as the Administrator :D

  • edited December 2023

    @vitobotta said:

    @totally_not_banned said:
    The funniest thing ever was mysql by default having a root account with an empty password and people thinking "it's just a database so who cares as long as there's no sensitive data in it". Not really a vulnerability but a design flaw but in my opinion it's never been that easy in (semi-)modern times provide a shell with no authentication whatsoever to the whole world.

    Reminds me of old Windows 96/8 that had a blank password for the Administrator account and most people ignored that. So even if someone had set a strong password on their account you could just reboot in safe more and log in as the Administrator :D

    Well, at least with the open default shares you had to dump your favorite root kit calc.exe into autostart and wait for a reboot. Mysql actually supplied a straight up run-this-code-now command (with services on Windows generally running as SYSTEM back then iirc...). Seriously, the guy who made passwordless root a default deserves a medal. Pure genius at work there.

Sign In or Register to comment.