You can listen to the podcast and read the show notes here
Michael: Welcome back to the show. I'm here with Pete Frietag, or Freitag. How do you say your name Pete?
Pete: In German, I mean, it's Freitag, so probably if you want to go with that pronunciation, it'd be Freitag.
Michael: Freitag. In America, we say …
Pete: You say Freitag.
Michael: Freitag. All right. He's the founder of Foundeo, that sounds very whatever, founder of Foundeo. He is a ColdFusion security expert. He's the creator of FuseGuard and HackMyCF. Not surprising to me, we're gonna be talking about secrets of high security ColdFusion code today on the CF Alive podcast. We're alive here at Into the Box, which is why we're on the same piece of video real estate here. Coming up in this episode, we're going to be looking at why you should even care about securing your ColdFusion code, and what the common misconception is about website security. How long does it typically take between a site being hacked and discovering the hack? How you should get started securing your CF code, and are some versions of ColdFusion more [inaudible 00:01:11] than others, and why is that the case.
We'll also look at how the eval a IIf functions may be letting hackers into your site, how file uploads can be dangerous, why storing API keys in your code is a terrible idea, and I think some of the CMA have done that, so I know I'm gonna learn more why not to do that, ColdFusion session hijacking, and isn't it a bad idea to document all these security holds on the public web, how ColdFusion security compares to Ruby on Rails, PHP and Java security, and other ways other than new ColdFusion code that people may be hacking into your server. We'll also, if we have time, touch on all the modern things being done in SSL, and have a look FuseGuard and HackMyCF, which Pete's company makes. Welcome Pete.
Pete: Thank you. Thank you Michael.
Michael: Let's just start right at the top. Why should someone even care about the security in their ColdFusion code?
Pete: It's something that's a very important topic. If you've got security vulnerabilities within your code base, eventually at some point if you don't address them, you might find out the hard way, which is a really horrible thing to have to go through having somebody hack your server, and all the potential things that they might be able to do. It could be deleting important assets that are difficult to recover, corrupting databases that might be very difficult to restore back to a reasonable state. There's just all sorts of things that a attacker could potentially do to your applications and they can really be a costly problem for you to recover from.
It's something that's really important to take a look at, the difficult thing about security though it's one of those kind of features that's hidden. Your users can't see that the code's more secure, but it's something that can sometimes be a tough sell to maybe a manager or whoever's paying the bill for the work to be done to actually spend some time doing security, cross security review, and improving the security of your server as to your code base.
Michael: It's a bit like buying car insurance. Until you actually need it, it seems a waste of money. Then tens of thousands or millions of dollars in cost later, it seemed like an incredibly good idea.
Pete: Yeah, exactly.
Michael: They not only may destroy your data, that might take confidential information. They might hold your site to ransom, could be all crazy stuff. In fact, maybe they even put wares or pornography on your site and cause a reputation problem.
Pete: Yeah, there's almost limit to what kind of harm can be done with security vulnerabilities these days.
Michael: What's the most common misconceptions people have about website security?
Pete: I think maybe that there's and absolute security, that you can be at a point where, okay if I just do 1, 2, 3, I'm secure. For example if I put a SSL certificate on my website, all right now we're secure. Security is just constantly changing, so there's always new practices that you need to do to make sure you're secure. It can be difficult to stay on top of that, so one thing to make sure you're doing is just constantly learning about security, seeking advice of other people that know about security, and trying to stay up-to-date as much as possible about security. I think that can be a tough problem or misconception that, okay I did what I think I know is gonna make me secure, so now I'm secure. There's almost always something else that you could be or should be doing.
Michael: Do you mean to say that hackers don't stand still? They're always improving?
Pete: Exactly, they're always looking for a different way in. As soon as something gets patched, they're already looking or maybe already have another vulnerability that they're able to exploit for a different purpose. Yeah, it's a constantly changing, evolving problem that always need attention.
Michael: It's like a competition between security side of things and the hacker side of things. I'm kind of curious, you've looked at thousands of site yourself and through all the tools you have. Typically how long does it take between a site being hacked and people discovering the site has been hacked? I'm interested in that because I think some of the people listening may think, oh yeah, I've never been hacked. In reality some of our listeners have been hacked and haven't discovered it yet.
Pete: Yeah, so I run a process from time to time where I have a client that maybe they've just realized that they had an attack for one reason or another but the exploit that the attacker was using was maybe a file that was placed on the server one or two years ago, or even-
Michael: One or two years?
Pete: Yeah, it could be something that's been there for a long time that they hadn't realized was there, and has been opened for exploit. Especially one in particular is like that CFIDE h.cfm file that servers were kind of mass hacked all around at the same point of time. A lot people were able to react to that quickly and get it taken care of, but then I still come across people that didn't realize they had I on their server, and they might still have it on their server. It really depends on the situation. In some cases you'll know right away depending on what the attackers doing. In other cases maybe something just gets placed on your server that is there for the attacker to use whenever they want to at some point.
Michael: Wow.
Pete: It can depend quite a bit.
Michael: Then you only discover it when it has side effects.
Pete: Right, when it causes a problem you might notice. Like for example filling up the disk space of the server if they're uploading all kinds of stuff.
Michael: Yep, I've seen that one. How can people get started in securing their ColdFusion code?
Pete: This is kind of what my Into the Box talk is gonna be focused on tomorrow. When we work with ColdFusion code bases we find that most of them aren't brand new code, or green code they sometimes call it that was just written. A lot of it's been around for a few years. It's not uncommon for ColdFusion code bases to be around for 15 or more years. You'll find that those code bases have been worked on by dozens of developers. There could be 10,000, 20,000 ColdFusion files. If this is your code base that you're working on, it can be kind of like one of those tasks where you're like, I don't even know where to start. What am I gonna do to improve the security? If I fix one thing here or there, it's not gonna make an overall difference.
That's kind of how do you decide where to start? Basically you've got to start somewhere, so I like to prioritize what vulnerabilities I'd like to focus on. I can start with ones that are maybe more critical, ones that are gonna compromise the server itself. For example, I might look at all the file upload code within the application and make sure that, that doesn't have any gaping holes in it that might allow the hacker to upload a cfm file or something like that.
Michael: Just to clarify that again, if you allow file uploads, that could let someone upload any ColdFusion file if you it in code form?
Pete: If you haven't coded it properly. Yeah, so I'll go into a little more detail on that. I kind of have three core rules when it comes to file uploads and my first one is, don't trust the MIME type. The MIME type is what you might find in accept the tribute of the cffile tag, so it might say, “Accept image/jpeg.” If you're looking at versions of ColdFusion prior to ColdFusion 10, that was used as a … Look, a lot of people thought it was a security check but it's really just looking at what the browser has sent to the server, so it's not at all a security check. It's just-
Michael: A trust thing. If they're being good guys it would the be the file type, but if they have hackers, it could be anything.
Pete: It could be anything. If that was your only security check, then right there the attacker could just simply upload a CFM file and then-
Michael: Do anything, really.
Pete: Yeah full ColdFusion access.
Michael: Delete files, read your data.
Pete: Yeah, anything that a ColdFusion user could do. That's where it comes into the lockdown guide, where locking down servers is a important as well because you can restrict what ColdFusion can do. That can also restrict what an attacker the might have had the ability to upload a file onto the server what they can do. If you can limit them to only maybe messing with your database instead of completely taking over the server itself, that might be a good thing. That's one rule is the MIME type, pay attention to that.
The other problem I've seen a lot is that if your destination of your upload is under the web group, and then you're doing your validation check. Maybe you're aware that the MIME type isn't enough and you're checking file extensions as well. If you've uploaded to the destination, but then you check the file extension, there's a small, maybe a few milliseconds of time where that file's actually under your web root before it gets deleted. That's a window for attackers to be able to hack you.
Michael: That's sneaky.
Pete: Yep, and that's one that actually has been exploited out there in the wild.
Michael: Because they have some software that uploads it and then immediately goes that [inaudible 00:12:05] file.
Pete: Yeah, in my presentation I'll show you an example. It's super easy to do. Just a loop basically, and having two loops, one that uploads the file, one that hits where the attacker expects it to be.
Michael: Hits where the file would be.
Pete: Then they've executed code. Then the third rule is to always check the file extension as well. Those are the kind of the three core rules. There's more you can do beyond that then, as far as file uploads are what I focus on.
Michael: Does it really make any difference what version of ColdFusion you're running, whether it's the current version of Adobe ColdFusion or an earlier version, or an open source version?
Pete: Yeah, so it can make a big difference in terms of what problems are out there. For one if you're running ColdFusion 9 or below, that's been end of life for quite some time.
Michael: 18 months, nearly.
Pete: Yeah, so there's no more security patches.
Michael: What does that mean no more security patches?
Pete: That means there's vulnerabilities in it that are publicly known that are not patched.
Michael: They're never gonna be patched.
Pete: They're not gonna be patched by Adobe. Then we've got ColdFusion 10 is gonna reach that point next month, May 2017.
Michael: Yep, yep.
Pete: That's also reaching what they call end of core support. I believe there's an extended support period that if you've got some sort of contract with Adobe, an extended support contract, I think they'll help you migrate to a more recent version. I don't think there's any guarantee of security patches even for those running extended support. It might be something that they would provide if it's easy enough for them to do.
It's really important in terms of just security patching to make sure you've updated ColdFusion. Also another one along with that is-
Michael: Maybe people think no one runs ColdFusion 9 and 10, but our recent state of the union survey showed nearly half of the people are running 9 and 10. It's amazing.
Pete: Yeah, that's a big number that are probably, hopefully looking at upgrading to a more recent version. Because what will happen is at some point if there's some sort of zero day vulnerability in ColdFusion 10 or below, you're gonna be stuck with a server that's exploitable. You don't know if that's gonna happen for sure or not, but it's a little bit risky I think to continue running those versions.
Michael: I would say it's more. I mean how often does a secure hot patch come out for ColdFusion, once every three months maybe?
Pete: Yeah. Roughly quarterly, like that.
Michael: I mean there's a lot of them.
Pete: Yeah.
Michael: Which is a good thing that they patch it, but if you're on an older version, you're not getting those patches any more.
Pete: Exactly. Also the version of Java that you're using can also affect the security of your code. Going back, this is something that was patched in I forget the exact version, Java 1.7. something, where if you're doing patch reversals vulnerabilities within ColdFusion, if you had a null byte character, it basically opened up the range of what an attacker could do with that type of vulnerability to even more types of files. There's certain patches that happen within Java itself. A lot of them tend to be focused around like https connection, things like that, but that's a nice thing that's good to keep up on.
Michael: Generally patching all your software is a good idea. Let's have a look at some of the code stuff. You mentioned the eval function is a window for people to hack in.
Pete: Yeah, the evaluate function in ColdFusion is something that you want to pay attention to in your code. Most cases I find that you don't need it. It was used a lot back in say ColdFusion 3 and 4. The reason for that was the scopes weren't structures at that point. If you wanted it kind of dynamically have form variables passed in, ugc value function through some sort of loop. I see a lot of that in old code bases. The problem with that is the evaluate functions basically executes CFML statements.
Michael: CFML.
Pete: Yeah, not tags, but basically anything that could be in a CFSET tag, it can execute.
Michael: Any script for variables.
Pete: Yes. You call [inaudible 00:17:02].
Michael: That would be handy if you were trying to [inaudible 00:17:04] someone's machine.
Pete: Besides evaluate, any function you could think of basically could be-
Michael: Creating fresh files with new or key code in 'em.
Pete: Yeah, exactly. Any use of the evaluate function, you want to look in your code. That's one of the high priority ones I'll look for when I do a code review is, are you using evaluate function. In a lot of cases it's real easy to fix too because you can just use the square bracket notation instead. If it's the forms code, you say Form[the name of the value], and then it's not actually evaluating it as an expression, it's just-
Michael: Well this makes sense. I understand why you don't want to use Evaluate, but what about the IIf function?
Pete: Yeah, so the IIf function does the same ting in the second and third arguments. It evaluates as an expression.
Michael: Oh, sneaky.
Pete: Yeah. The work around for that is if you've got ColdFusion 9 and up, which again, hopefully you do, because it's-
Michael: ‘Cause you listened to the earlier point that it's a bad idea to have old versions?
Pete: Yep, yep. There's the Ternary Operator, which is like the question mark. You'd have the condition ?, and then if it's true you pop into this : if it's false, you output that. There's other ways to work around the IIf function, but Ternary Operator is one that kind of matches the syntax I think, most directly.
Michael: Wow. What about we have a lot of people use APIs in their code. Why is it a terrible idea to store your APIs directly in your keys?
Pete: That's what's something you'll see a lot is API keys, passwords, encryption keys used for encrypting data found directly in the code itself. There's a number of reasons it's not a good idea. One reason is that the code probably is maybe hopefully stored on version control which puts those API keys onto some other third party potentially if you're using HUB, or something like that. If somebody's able to read files on your ColdFusion server, they're able to grab those keys. There's a number of different ways you could protect those secrets. One I like is Amazon Web Services has a key management service; Azure, the Microsoft Azure platform has another one and I forget what it's called, key something, another key management service.
These, they use hardware security modules which are very high end hardware that do encryption for you and they store their key directly in the hardware where they're not accessible to the software at all. Any access to a hardware security module prior to some of these new services that even are pretty new within the last year or two, I would say, was pretty costly, like thousands of dollars just to have access to a hardware security module. Then you need two of them for redundancy. They've made these cheap. It's like a dollar a month basically to leverage Amazon's key management service, plus there's some usage fees like a penny per 10,000 calls or something like that. It becomes a relatively cheap way to improve the security of our secret management.
Then there's software you can utilize as well. One of 'em that comes to mind is called Vault from HashiCorp. There's one called Confident, Keywhiz, there's a bunch of software out there that you can use that provide an API to get your keys out of and store them securely for you.
Michael: What about ColdFusion sessions? You know those can be hijacked?
Pete: Yeah.
Michael: Why is that a bad idea?
Pete: Session hijacking basically means that the attacker was able to figure out what the session ID values for a particular user. When you think about the session ID, if somebody has a session ID for a user, they're essentially logged in as that user. You gotta think about protecting those session IDs as much as possible. That's really what defending session hijacking is all about protecting the session ID as much as possible. There's a number of things you can do mitigate that issue. One thing would be to call SessionRotate when a user logs in. What that does is rotates a new session identifier, and it's a way to get to session hijacking. It's called session fixation. The way that works is let's say I give you my laptop and say, here do you want to login to your bank account. I might know what the session ID is already because I had the browser open, and then that would allow me to take it.
A more practical way that might work would be somebody sending you a link with the session IDs in it. When you rotate the session IDs a valid login, that prevents that type of attack. Then invalidating the session IDs when somebody logs out is another good practice. You can use sessionInvalidate function to do that, and then the SessionRotate function handles rotating. Then in terms of protecting such identifiers, really the best way is to probably use the cookies. Don't pass them around in URLs because probably the biggest problem is that users will copy and paste URLs and stuff. They'll send them to co-workers, and then their co-worker's logged in as the wrong person.
Michael: I can't help thinking that if we just got rid of the users, everything would be a lot more secure.
Pete: Exactly.
Michael: Just joking guys. I know on your site you document thousands of different security holes, and what to do about them. Isn't it a bad idea to put this stuff on a public web?
Pete: I am cautious about when I post something, but I think as a developer, especially for a coding security thing, if you don't know about it, how are you gonna fix it in your code. At some point you need to be able to make sure your code is protected against these things that the attackers are gonna figure out.
Michael: They already know. The attackers already have this stuff figured out.
Pete: Yes, exactly.
Michael: They're not the ones. It's the developers that need to find this out.
Pete: It's important to be able to find this stuff and know what to protect against, because if you don't know what a session fixation attack is, how are you gonna defend against it. You gotta have some knowledge about what the different types of attacks are as a developer, so that you can think about it while you're coding in order to defend against them.
Michael: How does ColdFusion stack up against other languages like Ruby, or PHP, or Java for security?
Pete: Yeah, I was at the Adobe ColdFusion Government Summit last week and they were comparing on one of their slides in the keynote that, I don't have the exact numbers, but what they were showing is the number of vulnerabilities in something like Ruby on Rails, over the last few years has been increasing a lot, whereas Adobe ColdFusion vulnerabilities in the server platform itself has been improving and decreasing the number of vulnerabilities.
I think a lot of these issues that I talk about in my secure coding presentations, they're all issues that you'd have to defend against no matter what language you're using. There's still a possibility of session hijacking, skill injection, file upload issues in no matter what language you're writing it in. I think from a developer standpoint, ColdFusion's got a lot of builtin tools they can utilize to defend against some of these things.
Michael: Cool. That's good news that ColdFusion stacks up good against other languages for security. I know Adobe's always focused on releasing more fixes, and dealing with and publicizing security issues.
Pete: Yeah, and they do have a good process when it comes to security hot fixes. They make sure everything gets reviewed and addressed which is a good thing. I don't know if you necessarily always have the same guarantee when you're using a different platform that doesn't have as disciplined of a security team working with it.
Michael: Suppose you've made your code a secure as you can, what other ways might people hack into your CF server with?
Pete: Once you've done everything you can possibly do to secure the code, then you gotta think about the actual server setup and configuration itself. That's where things like following lockdown guide is good to do. The approach of the lockdown guide is really to just is really just to try to reduce the attack surface as much as possible. If you're not using a feature, make sure it's turned off, disabled. A lot of the URIs that ColdFusion might listen to by default, making sure that those are blocked on the web server level before getting the ColdFusion running using minimal user permissions, and things like that. Yeah, those are some of the different ways that-
Michael: Do you need to lockdown IIS, and Sequel Server, or MySQL, and Windows.
Pete: Yeah, each thing is gonna have its own process to go through. IIS starting with version seven has a lot of good security features I think. I like the way that they turn everything into a little module, so you only have to install what you're actually going to use, and you can leave a lot of the stuff turned off in IIS, so that's a good thing. Yeah, keeping your Sequel Server setup properly with user permissions and all that, the Windows server itself, using things like two factor authentication is great too, because that can protect against certain things like social engineering attacks where somebody might give out a password or something inadvertently.
Michael: I've heard that possibly users write passwords down on little yellow stickies and put them by their computer, and then will give them out over the phone to somebody who pretends to be from the IT department.
Pete: Yeah, I've gotten phone calls from Microsoft support.
Michael: Mm-hmm (affirmative), where they ask for your password.
Pete: It's a scam, yeah. I told them that I didn't have any-
Michael: Let alone phishing emails. Yeah, probably one of the weakest links is the human element here.
Pete: Definitely. That's something to keep in mind, I think two factor authentication's a good solution for that. Not always the perfect solution for every problem but it can help one of those situations.
Michael: What about SSL? You mentioned earlier that sometimes people think that, that's enough but it isn't. What's good about SSL these days? What's changed in that?
Pete: I think SSL is basically something that there's not a lot of reasons to not use it any more these days, because for one you can get certificates for free at letsencrypt.org, you can get a certificate that works in all the major browsers. That's no longer a roadblock. The other roadblock people have a lot of times is that when you're running https, you kind of needed a dedicated IP address. That's not necessarily the case any more either due to the server name indication, the SNI is one of the TLS extensions, or SL extensions that has been part of browsers I think since I forget what version first supports it, but probably like seven, or something like that. It's not really something that is a roadblock any more because I think a very, very high percentage of users are gonna be able to support server name indications.
You don't even need a dedicated IP address any more necessarily to do SSL. Even in some cases there's a site you can check out. I think it's httpvshttps.org, but I'll get you the link to put in your notes, but I'll get you the link to put in your notes, that shows kind of an example of loading around 150 images first over http, and then they do it over https using http version two. Because of some of the features in that new protocol where it can pipeline requests and save it [inaudible 00:31:17] repeating, sending headers and things like that. You'll see that the https is actually faster than the http version.
Michael: Oh wow.
Pete: In these cases.
Michael: Is there any hardware acceleration on-
Pete: Yes.
Michael: On SSL now.
Pete: Yeah, a lot of the processors have builtin AES support in the process.
Michael: That's the encryption method used in it.
Pete: Yeah, for some of the ciphers used in SSL.
Michael: You run a product called called FuseGuard, but why should someone be using that?
Pete: Let me explain first kind of what it does. FuseGuard is a product that it's a web application firewall. It's written in ColdFusion and then it sits in your application.cfc or CFM file. Think of it basically on request start before your code gets executed, FuseGuard runs and looks at the request coming in and looks for various malicious patterns, and then can log or block the request. You might think, well I do a pretty good job coding. I don't need something like that. Where it's good is it provides an additional layer of defense that can protect you maybe from something you didn't know existed. It's good in that regard. Then HackMyCF is a product that makes requests to your ColdFusion server looking for various configuration vulnerabilities and issues.
It can determine if you're missing certain patches, and then there's even a file you can place on your server which will give you even more detail into it to show what version of Java the person's running, and whether it needs to be updated. It'll give you a lot of information to help you keep updated on the security of your ColdFusion server.
Michael: Let me just ask this different question here Pete. Why are you proud to use ColdFusion?
Pete: ColdFusion's this great language for building web application websites. I've been using it I don't know, I think since '98 maybe. Coming up on-
Michael: 19 years, wow.
Pete: Yeah, so I've been using it for quite a while and it's always got the job done for me. I've found it to be a very productive language. It's a language that I feel like has gotten better over the years. The scripting support I'm enjoying using full script CFCs these days. Yeah, I'm enjoying using these things. I still find it productive.
Michael: Great. What will it take to make ColdFusion even more alive this year?
Pete: I think more modules written in ColdFusion that people can utilize to do certain things would be a good step forward for ColdFusion. Having used other Lexi NodeJS that has a very robust ecosystem impact that you can easily utilize. I think that's something that ColdFusion could use a little bit more of that type of thing to help move them forward.
Michael: What are you looking forward to Into the Box?
Pete: I've been learning a lot already. I went to a ColdBox modules session which I thought was really good. I learned about PresideCMS which I did a lot of things I didn't know it could do, and also learned some stuff about WebSocket so far. There's a lot of great presenters. Ortus has done a great job innovating ColdFusion and pushing the language forward with things like CommandBox. I think even if you're not a ColdBox developer, there's a lot you can get out of this conference.
Michael: Oh, it's far more than ColdBox. I mean just CommandBox itself is like a whole new way of doing things, and that's totally free. I mean it must be great for the code you have where you need to test against different versions.
Pete: Exactly.
Michael: Just spinoff the server in seconds.
Pete: Yep, I can set up different versions of the servers and test code. I can do that in continuous deployment environments as well and have it automatically run it in like six different servers. I don't know if you saw the CFScriptMe website I built recently that will convert database CFCs into CFScript. On the plane ride over here, I wrote a CommandBox command that will convert, you can give it a whole directory and it'll convert all the CFCs over to CFML script.
Michael: Wow.
Pete: I'm still working on a few kinks in that but hopefully I'll have that published this week.
Michael: Wow. That's amazing. If people wanted to find out more about you Pete, how could they find you?
Pete: My company Foundeo.com, my blog is PeteFreitag.com, I'm also on Twitter @PeteFreitag. Those are probably the three places you could reach out. I'm also on the CFML slack channel, amazing fun day on there. Feel free to reach out to me in any of those channels.
Michael: Great, well thanks so much for being on the podcast.
Pete: Oh thank you Michael.
