Horrendous Security Flaws I've encountered while working on a legacy SaaS app

[burroughs]

1. Guess the database id on a page with no access checks:

Code: [Select]

/loaddoc.php?id=123
Let's get ALL OF THE DOCS

Code: [Select]

/loaddoc.php?id=124
/loaddoc.php?id=125
....
/loaddoc.php?id=9001

2. Load a file by name from a request parameter with no sanitizing:
 

Code: [Select]

/loaddoc.php?filename=order.pdf

Code: [Select]

/loaddoc.php?filename=/../../../IWonderWhereIamNow/nudes.zip
3. Upload arbitary files to a web directory with script execution enabled, don't check file extensions:

Code: [Select]

/uploads/uploaddoc.php?name=lolz.php
Unintentional and free web hosting!

Code: [Select]

/uploads/lolz.php
Do share yours.

[Lanny]

I once worked on an app that had a long form where they shipped the (md5) hashed password and salt to the client after the first failed login so they could validate the password client side before sending it to the server. I was just surprised that whoever implemented it originally knew enough to salt and hash passwords but not enough to know not to send the digest to clients.

[burroughs]

I once worked on an app that had a long form where they shipped the (md5) hashed password and salt to the client after the first failed login so they could validate the password client side before sending it to the server. I was just surprised that whoever implemented it originally knew enough to salt and hash passwords but not enough to know not to send the digest to clients.

Goddamn, that is fucking awful.

Well, the app I work on doesn't even hash the password client side before sending it to the server. And there's no lockout on login attempts. The only solace is that the amount of requests needed to brute force a password would take down the server long before any progress was made.

[aldra]

lolol

proprietary software, A++

I distance myself from the company's developers as much as possible lately. most of the old applications were written in Clarion, but considering how old and locked down it is, they've been forced to start using another language... and they've gone with Java.

my favourite security issue in their last application was/is the upgrade system simply connects via ftp to a download server, grabs the file in the patch folder with the highest number at the end, then downloads and runs it.

being ftp, it's trivial to extract the credentials from the data files, or failing that just sniff traffic when it tries for an update. the password it uses has full read and write access on the ftp server... meaning you could grab the password from the client, then upload whatever malware or botnet code you like to the patches folder, and it'd automatically download itself to 700+ franchises without them knowing.

what's more, because the application is incredibly poorly written and the devs refuse to submit signatures to AV companies, it routinely triggers antivirus programs... so the installation instructions include a suggestion to disable AV protection on the application folder.

[Prometheus]

I was fixing someone's computer and was shocked to see that it had full disc encryption, because I knew this girl, and that was way beyond her. Then I found out that her password was LOVE. I cringed so hard I think I hurt myself.

[LiquidIce]

From a recent meeting:

Well, let's just chmod it to 777, what's the worst that could happen? I dont see any way anyone could exploit this

This was about a wordpress installation. I work with smart people, but I'm surprised at the amount of trust (or blindness) people place in the predictability of software. I mean fuck, there's so many possible inputs, saying something like "I dont know how this can be exploited, so it cant" seems so far fetched and funny, it's almost unreal.

But to be honest, let's think about it from the business side ie. the side that pays programmer's salaries: whether an application is exploitable, if it has a test suite, if it's updated, if it's meant to endure infrastructure failures (fucking 3rd party api going down or stalling on request = blocking the whole fucking application) doesn't matter at fucking all. This is what kills me at my job. Nobody cares if the code you sling is a 1000 line long procedural pool of diarrhea if if-else block nested 7 levels deep - as long as the css transitions look nice and the html adheres to the psd, and it's delivered on time - you're the fucking man.
Sorry for the slight rant, but I've the had the opportunity... no, wait, the joy of working with code from a senior developer whom everyone praises and I shit you not, this guy loaded a ton of logic into views (in an MVC based web app). Really, he couldn't take 30 minutes to refactor that out into a separate module that could be shared instead of duplicated?
That's when my enthusiasm for my current job broke - I wanted to do things the right way, to think of the next programmer on the project to make his/her life easier, but now I see that the only objective is pushing out eye-pleasing pages on time and fuck everything else. Well, then, fuck them too, I can ship shitty code too and I won't be anxious about barely meeting deadlines now.

[Lanny]

From a recent meeting:

Well, let's just chmod it to 777, what's the worst that could happen? I dont see any way anyone could exploit this

This was about a wordpress installation. I work with smart people, but I'm surprised at the amount of trust (or blindness) people place in the predictability of software. I mean fuck, there's so many possible inputs, saying something like "I dont know how this can be exploited, so it cant" seems so far fetched and funny, it's almost unreal.

To be honest I'm only slightly bothered by the "777 methodology" of security. A lot depends on context but I think there's a real issue when you have a bunch of people trained as developers but not really security specifically trying to assess how much of a security issue something is. Some things just radiate an air of perceived security, like "permissions". Nothing sounds like security as much as "permissions" does but like, you could 777 everything and it's honestly not that big of a deal. I had this come up at work once, like almost every account has sudo, at least two have passwordless sudo, and www-data has like three elevated services running at all times and I had an extended discussion with my coworker on whether or not to set the group read bit on a server conf file. Like the reality is that at that point the OS's FS permissions don't mean much, no one is going to start revoking permissions. So in some ways I think it would be better to give up the false sense of security and just accept that anything with a shell is effectively root, and work on making sure nothing untrusted ever gets that far. IDK, it's not a very popular opinion but I'm sticking to it.

The shitty code to meet deadlines thing kills me though. Particularly since it usually ends up being a net loss in the not-so-long run.

[Prometheus]

Goddamn I wish I understood more of this stuff. I'm following about 3/4 of what you guys are saying, but the other 1/4 is leaving me standing here scratching my hairy ass and going "wha?"

[Lanny]

Goddamn I wish I understood more of this stuff. I'm following about 3/4 of what you guys are saying, but the other 1/4 is leaving me standing here scratching my hairy ass and going "wha?"

Feel free to ask about anything you don't understand. The tech forms are always slow, I don't think anyone minds answering questions.

[burroughs]

But to be honest, let's think about it from the business side ie. the side that pays programmer's salaries: whether an application is exploitable, if it has a test suite, if it's updated, if it's meant to endure infrastructure failures (fucking 3rd party api going down or stalling on request = blocking the whole fucking application) doesn't matter at fucking all. This is what kills me at my job. Nobody cares if the code you sling is a 1000 line long procedural pool of diarrhea if if-else block nested 7 levels deep - as long as the css transitions look nice and the html adheres to the psd, and it's delivered on time - you're the fucking man.

Sorry for the slight rant, but I've the had the opportunity... no, wait, the joy of working with code from a senior developer whom everyone praises and I shit you not, this guy loaded a ton of logic into views (in an MVC based web app). Really, he couldn't take 30 minutes to refactor that out into a separate module that could be shared instead of duplicated?

Man, do we work at the same place?

The sad part is that when shit breaks, management sees it as a weakness in the technology used vs. the quality of the developer who worked on it. So while we have a moderately successful legacy application that requires a ton of maintenance, the higher ups have deemed that our successor application must be written with a string of unproven technology buzzwords.

Feel free to ask about anything you don't understand. The tech forms are always slow, I don't think anyone minds answering questions.

^ This, man. This so hard.

[LiquidIce]

From a recent meeting:

Well, let's just chmod it to 777, what's the worst that could happen? I dont see any way anyone could exploit this

This was about a wordpress installation. I work with smart people, but I'm surprised at the amount of trust (or blindness) people place in the predictability of software. I mean fuck, there's so many possible inputs, saying something like "I dont know how this can be exploited, so it cant" seems so far fetched and funny, it's almost unreal.

To be honest I'm only slightly bothered by the "777 methodology" of security. A lot depends on context but I think there's a real issue when you have a bunch of people trained as developers but not really security specifically trying to assess how much of a security issue something is. Some things just radiate an air of perceived security, like "permissions". Nothing sounds like security as much as "permissions" does but like, you could 777 everything and it's honestly not that big of a deal. I had this come up at work once, like almost every account has sudo, at least two have passwordless sudo, and www-data has like three elevated services running at all times and I had an extended discussion with my coworker on whether or not to set the group read bit on a server conf file. Like the reality is that at that point the OS's FS permissions don't mean much, no one is going to start revoking permissions. So in some ways I think it would be better to give up the false sense of security and just accept that anything with a shell is effectively root, and work on making sure nothing untrusted ever gets that far. IDK, it's not a very popular opinion but I'm sticking to it.

The shitty code to meet deadlines thing kills me though. Particularly since it usually ends up being a net loss in the not-so-long run.

Yeah, permissions seem like one of the lesser evils at least - I'm just really paranoid when it comes to any php application and security - I can just see that day when some plugin allows file upload to the 777'ed directory and then some other plugin allows execution... but then, if you have backups, nothing will really happen.

Yeah, I've been trying to point out how tests decrease that net loss in the long run but people just look at me weird. And this is from people who have budgeted 30 hours to fix one javascript module after spending about 30 hours trying to even figure it out. Don't get me wrong, I like challenges, but I hate it when "it'll be a 30 minute fix" turns into a "gimme 2 days" because someone hid a bunch of nasty ass code just far enough so that you don't initially see it.

Goddamn I wish I understood more of this stuff. I'm following about 3/4 of what you guys are saying, but the other 1/4 is leaving me standing here scratching my hairy ass and going "wha?"

Yeah man, totally ask away about anything that's unclear.

But to be honest, let's think about it from the business side ie. the side that pays programmer's salaries: whether an application is exploitable, if it has a test suite, if it's updated, if it's meant to endure infrastructure failures (fucking 3rd party api going down or stalling on request = blocking the whole fucking application) doesn't matter at fucking all. This is what kills me at my job. Nobody cares if the code you sling is a 1000 line long procedural pool of diarrhea if if-else block nested 7 levels deep - as long as the css transitions look nice and the html adheres to the psd, and it's delivered on time - you're the fucking man.

Sorry for the slight rant, but I've the had the opportunity... no, wait, the joy of working with code from a senior developer whom everyone praises and I shit you not, this guy loaded a ton of logic into views (in an MVC based web app). Really, he couldn't take 30 minutes to refactor that out into a separate module that could be shared instead of duplicated?

Man, do we work at the same place?

The sad part is that when shit breaks, management sees it as a weakness in the technology used vs. the quality of the developer who worked on it. So while we have a moderately successful legacy application that requires a ton of maintenance, the higher ups have deemed that our successor application must be written with a string of unproven technology buzzwords.

Feel free to ask about anything you don't understand. The tech forms are always slow, I don't think anyone minds answering questions.

^ This, man. This so hard.

It would be funny if we did. Hearing this from both Lanny and you, I get the feeling that this is a systemic problem and that instead of fighting it, I should just adapt to it and next time around ask more specific questions during the interview.

Oh, also, in my case, the management stays away from the buzzwords, but on the other hand, the design department is king. I really mean it - if something is off by > 1 pixel, you will get a stern talking-to about how insulting this is to the designer. Lesson learned - don't look for design-lead companies, focus on engineer lead companies.

*Throws more wood into the fire*. Anyone else got more horror stories?

[Lanny]

Oh, also, in my case, the management stays away from the buzzwords, but on the other hand, the design department is king. I really mean it - if something is off by > 1 pixel, you will get a stern talking-to about how insulting this is to the designer. Lesson learned - don't look for design-lead companies, focus on engineer lead companies.

Ugh, I think turning psd's into markup is one of the most soul sucking things there is. I had a similar situation where the CEO didn't really know what he wanted ("make it pop" was his usual edict) and the designer didn't have any UX experience ("add a dropshadow" and "just reduce the font size to make it fit" were how the CEOs advice usually got translated). The designer would send me these rasters of the PSDs, but they were designed at like 1.3 of actual resolution so I always had to guess with sizes so we'd have this back and forth that could go on for weeks about "add more space here", "make that taller" but never with actual units because apparently she didn't know how to make any edits to the CSS so she couldn't quantify how much something needed to be changed. Here's some real life CSS that process produced:

Code: [Select]

    #inform-bubble {
      background-image: url('/static/assets/img/orange lines background.png');
      background-repeat: both;
      padding: 15px 3px 20px 10px;
      margin-top: 17px;
      margin-bottom: 12px;
      border-left: 5px solid transparent;
    }

notice how no margin/border/padding on any side is the same as any other.

Heh, trawling through that part of the code base I also found something that while isn't particularly good code isn't quite a horror story, but the comment illustrates one of javascripts many quirks:

Code: [Select]

  ...
  .on('mouseenter', function() {
    var $this = $(this)
    $this.popover('show')
    $('.popover').addClass('active')

    $this.find('.close').click(function() {
      // $this isn't actually $(this) in this case. That is to say this this is
      // not selected by this $this, but rather by this $(this) where this is
      // this this.
      $this.popover('hide')
    })
  }).click(function(){
[code]

[LiquidIce]

Whoa, that sounds like my first job - having to had worked with print designers turned web designers. Except asking designers questions was also seen as insulting because IT'S RIGHT THERE IN THE PSD. I guess it's something everyone has to go through just to see how low human beings can go.

If I saw that js code, I'd probably have to take a breather. Only two things from today come to mind:

Code: [Select]

# This is a HACK, fix this!
(doing git blame on this showed that this was committed 2 years ago)

The other thing would take up too much code but just the concept itself is hacky: part of the design exists outside the grid, me being somewhat unfamiliar in front-end tackled this by using a combination of position: relative and position: absolute. Everything seemed fine and dandy until the container overflowing the grid had to be decorated with some divs which followed the grid. So I reached into my closet for some trust javascript and set it up that way. Only problem is, these divs have to be positioned after the container acquires its size by another piece of javascript. So once in every 50 refreshes, these divs are way off. At this point I just wanna throw in the towel.

[Lanny]

Not a security issue, but at work we have this basically NAS server that's responsible for pulling backups periodically from our production servers. It's not supposed to be production or anything so it has some archaic OEM distro on it. I had to make an edit to the backup procedure so I login, open up a file to edit, make a typo and get this:



For those who haven't used vim 'u' is the undo command. The version of vi is so old (or more likely is a shitty clone) that it literally doesn't have an undo. Unlike everywhere else in the world `vi` isn't symlinked to `vim`, so invoking vim is a little better only... it doesn't keep a history stack so multiple undos just cycled between undo and redo. I don't think shit was this bad even in the 80s, god damn.

[aldra]

eh, I've never used undo in vi. if I fuck up hard enough that I can't fix it, :q! and reload