On this episode, James talks about application fingerprinting and why it matters to you. Tackling the challenge to integrate security into the development process? Looking for insights, answers and practical solutions to avoid getting overwhelmed? Hey everyone, welcome to Episode 112 of the DevelopSec podcast. I am your host, James Jardine. And today I want to talk about fingerprinting and no I'm not talking about Fingerprinting where you actually use your actual fingers to place them in some ink and set them on something and have your fingerprints taken instead I'm talking about the identifying or identification of your application server, its framework, the actual application itself. So we actually call this fingerprinting in the digital world. And it's a way for us to be able to determine whether you're running IIS or whether you're running Apache, whether you're running PHP versus ASP.NET versus Ruby, even down to the type of application level. So are you running something like WordPress or some other CMS like Joomla or Drupal? So we have this way of identifying this information that may not be readily just thrown out there for us. And the reason this came up is I had a question asked to me in my Slack channel asking about cookie names and really their end goal was they've got an application that is installed for multiple clients I guess if you will right it's an open source application anybody can go grab it download it install it on their servers and now they've got it up and running. I kind of think of it similar to something like a WordPress or Joomla or Drupal. Something that's pre-built out there for you that you can stand up and run. And their concern was basically really around their cookie names. And more importantly, around the ability for some of these sites like Shodan to be able to index the site. So that way, somebody could go in and just do a search and say, hey, show me all the websites out there that are running X. And you know, what if, I mean, it's a good concern, because what happens if there's a vulnerability in that application, somebody identifies it. And then all of a sudden, they just go out and they do these quick searches and are like, hey, show me all the, you know, applications that use this version of this application. And if we can immediately pull that back, then we can immediately go out and try to exploit that vulnerability on all those sites. So of course the concern there is, hey, I want to be able to stop this from happening. That yeah, maybe there's, we may have vulnerabilities in our sites, but we don't want to make it easy for somebody to go out and identify all of them. And to me, it's a great question because how many times have we seen a breach where something like a MongoDB database was sitting out there exposed to the internet with no authentication? Well, How do they find these? They use a search engine like Shodan and say, hey, show me all the MongoDBs out there. And then they can test them, see if they have authentication. If they don't, then they can gain access. So this is how a lot of stuff is actually found. When we see those type of breaches occur, it's really just somebody going out there and doing this search. Think about things like your baby monitors, your security cameras. We see these all the time in the news where somebody all of a sudden does a search for these. They find a few and now we're reporting on them, hey, these are all exposed. We have these search engines that'll actually catalog all of this. So that way if there's something specific you're looking for I'm looking for all web servers that are running IIS 5.0 And if you've got something on your web server that's letting us know what that is, whether that's a response header or something else, and that gets catalogued, then if I fold the vulnerability in that server, then I can quickly go and search and identify all those servers and then attempt my exploit against those to see if it works. So it was a great question to come out and I thought, you know, I haven't talked about fingerprinting and it's a great time to do it. So that's where we're starting at when we're thinking about what we're talking about with fingerprinting within our applications. And there's lots of ways that we can identify what a site may be running for the application. And again, that goes back to What type of server, what type of frameworks you have, all that stuff. So here's a couple different things that we typically will identify. And some of these things we may identify during a penetration test or vulnerability assessment. Some things we don't, which is kind of interesting, where we kind of pick and choose which ones typically will get flagged and which ones don't. So some examples we have response headers. This is very common and when you're having an assessment done a lot of times this may be listed not as fingerprinting but just information leakage in that we send down response headers that include things like server name or it'll just say server right and it lets us know that it's Apache or it's IIS. You have the framework so ASP.NET versions come down with response headers, and it gives you a lot of information. It tells you the exact version that is running on the server that's out there. So response headers can give us a lot of information about what's happening on our site. We also have the file extension. That's kind of a funny 1. I remember doing an assessment years ago working with somebody else and they're like, you know, I think this is a .NET app but I'm not sure why I'm thinking that. And a couple of others joked kind of about it. We're like, is it the server header that's coming down saying it's running on IIS? Or is it the extension of .aspx that's giving you away that this is a Microsoft-based application? But the file extension will give us information right whether it's a PHP app whether it's ASP net whether it's classic ASP if we even see those very much anymore. I mean we do You know whether it's a dot do There's all kinds of info that comes from just that extension that we see. Now we do see a lot of applications now that use routing and we don't actually see the extension, but I mean I still see applications every single day that still have extensions on them that let us know, hey here's the technology that we're using. You also have cookie names. A lot of frameworks have default cookie names for things like their session ID, so PHP session ID, or, you know, with authentication in .NET, you know, you have the .aspxauth cookie that comes down, right? These default names give us that information about what type of system you have going on. We also have things like file paths. And, you know, a classic example of a file path is really, you know, if you look at WordPress, you know, WordPress, if you just right click on the site, view source, most likely you're going to see wp dash content as part of a lot of the paths in there. And that immediately gives it away that, hey, we've got a WordPress site. And other sites may do this as well across the board, right? They have something that's commonly set that we can attribute it to that type of site, especially sites where we're going to deploy them in multiple locations. You know, less your custom built site for a specific organization. But when I have something that, you know, is meant to be installed multiple times, Oftentimes those things don't change. So whatever you name something, as soon as somebody identifies and says, oh yeah, this path belongs to XYZ site, now we know anytime I see that, oh, this is this type of site. So file paths can help with that as well. Also, if you include the name of the app in the file path, sometimes when you're creating your apps, you put it in a directory that's the name of the app, that stuff can help provide that as well. And then you also have comments. Sometimes if you look at the comments, I feel like .NET Nuke did this. We could look at comments and actually see some info in there about, you know, it would say .NET Nuke, sometimes it'll say the version. Now we've seen a lot of those type of sites remove that information, But it is something that could be out there. That is another way for us to be able to identify, hey, what type of application am I dealing with here? And is there something that I could do with that information? Now, of course, there's 2 schools of thought when we talk about the fingerprinting of an application or a server or whatever it is. And usually the first thing that you hear when people say, oh, you're returning the server header and it tells me that it's IIS 8.5. And it's like, okay, but I can't necessarily do anything directly with that information, right? I need something else Because just having that info, I mean, it is an information leakage. I know something about that site. So as I'm planning further attacks and down the road, I've got that information. I say, okay, I know I'm dealing with IAS. You know, I'm looking for those type of flaws or this type of information. I go forward with that and it is helpful in that case and so you'll hear a lot of people say well you have to remove that because if there's a vulnerability in that version of that system then somebody could just write a script that runs out and says, oh, let me check the response header. The server says I is 8.5. Let me go ahead and run my payload. Okay, well, I mean, that is possible, right? And somebody could script that out for sure and let that run and all of a sudden just hit all the sites, bam, it's 8.5. Even if you catalog it using something like Shodan, oh, I know that's that, I'm gonna go ahead and I'll run my exploit against all those. And that is 1 avenue of potential attack. But the other side of that is so many places or so many scripts out there actually don't care what version it is. You know you've got so many tools, all the DAS tools, a lot of this stuff that it's not really checking to say, oh, I'm only gonna run my specific exploit here. It says, you know what, I'm gonna run everything. I'm just gonna spray everything I can at your app and I'm gonna see what sticks. And when we do that, then obviously that other information becomes less important because we're not using it, we're just throwing everything we can. Now you get a little bit more targeted and now we're not doing that and that information becomes a little bit better. Now some people will say, oh well you can obscure that information, although I recommend just don't even return it, but you could obscure it. So if I'm running IIS, set my server header to Apache. And we've said for a long time, security by obscurity, not really the best way to do anything. Actually, don't do it that way at all. We don't really want to do that because yeah, it might work a little bit, but that's not a real good solution to be honest. People are going to figure that out and, you know, they'll get around it. Again, you've got either you're going to stop something that just benignly goes out there looking for a specific thing or you've got all the rest of them that are just you know I don't care if it says IIS I don't care if it says Apache I'm gonna run both sets of exploits and see if it goes anywhere so doing the obscurity thing might not be the best thing and to be honest even if you're doing that and even if you're doing everything you should be, doesn't mean that we still can't figure out what type of server you're running. So even if you're going through, and let's list out some recommendations that I jotted down real quick here. And these are common that, you know, I mean, we give, even during when we do an assessment, when we talk about designing our applications, right? Some of the things that we want to think about is don't return unneeded response headers. So things like your server header, your frameworks, those type of things, X runtime. Response headers that aren't needed, don't return them, and it's just less information that we're providing back. So if I don't return at all what the server is, don't worry about obfuscating it, just don't return it. Don't return the ASP.NET MVC version or anything like that, just remove those headers. It's good cyber hygiene, and it just reduces that attack surface a little bit because we're providing less information that's easy to gain. We also have things like don't change your default or do change your default cookie name. So instead of using .aspx auth, change it to something else so that way it's not blatantly giving away that, hey, this is an ASPX application. Now, in a moment, I'm going to talk that that's not necessarily the most difficult thing to figure out afterwards. Change your don't use your app name or identifiers in your paths. You know, don't put identifying information in your comments. You know, don't create comments that say, hey, this is, you know, ASP.NET version 5.3.6 and we're waiting to update to 5.3.7. Those type of things, right? We can pick those up and do that. But even if we do all that, even if we make all those changes, it doesn't necessarily mean that we still can't fingerprint the application and find out some information about it. And that's because servers act in different ways even without responding with those type of response header. So IIS may return other response headers like content types, dates, all that stuff in a different order than an Apache system. And when it does that, we still have this capability. Now, are we gonna automate that and will that show up on Shodan? Probably not, but there is still that capability that even everything you add on there, if I'm a dedicated attacker, and especially if I'm doing like manual techniques, I may identify this and I may be able to find it and see it and be able to use that information. So we're not totally killing everything that we see there. But if we're following those best practices, then we're reducing the chance of any type of automated script or simple searching for our stuff being out there. And we're helping protect our app a little bit more. I mean, to be honest, the best way we're going to protect our app is by having that secure design while we're building everything out, building up good security requirements. And then as we're going in and doing our coding and our implementation, we are actually making sure that we're protecting against the types of vulnerabilities that we think might be at risk for our application. Right? And that's our end goal. So we want to make sure that we're going in and protecting against all these different things. And then on top of that, because a lot of this stuff is specific to our servers and all that, and really less about against our specific code, unless you're talking about something that's deployed out multiple times across different sites, right, like a WordPress instance or something like that. A lot of these information that's coming out is application or server specific, meaning more like the framework. So, oh, I see you're running IIS and I have an exploit for that, that's what I'm gonna try to target. We'll make that more difficult to be able to identify that, hey, this is an IIS server. But again, it doesn't really matter how much we try to trim that down. What we're doing is we're creating a higher barrier of entry to make it more difficult to identify this stuff. Can I still identify your app as an ASP.NET application? And you know, we'll talk before core. So we'll talk ASP.NET, maybe 4.7, or, you know, Web Forms, MVC, whichever it is, even if you use routes, and I can't see the extension, even if I don't see the server header even if I don't see ASPX headers maybe you change the cookie information so it's not dot ASPX off and you know there's nothing in that app that is telling me Hey, this is a .NET application and you know, unfortunately with .NET apps There's a lot of information oftentimes that will give it away that it's .NET But what about when I try to submit a cross-site scripting attack and it kicks off validate request and throws an exception for that. Even without giving me the error message back there's a chance I can still determine, hey wait if I do this specific character set it will act this way and if I do something else it acts a different way. And something like a validate request is pretty easy to identify, to say, yep, that's a validate request kicking off for this, because I know exactly how it works. So I know, oh, hey, they're using ASP.NET in the background. So there are still ways to be able to identify, but in this case, and you know, the question that was asked to me, you know, was really more of a, hey, should we be changing this stuff so that way things like search engines can't find us or identify us quickly like that? And you know, I mean, I think it's something that is a good consideration within your app. You know, do you have a way that if you have multiple installs to be able to let users set their cookie names? Or do you generate a random cookie name every time a new install is done? So that way, all the sites don't use the same cookie names and we can identify that. That's a great consideration to have within your application. And when you're designing it, thinking about that. Same thing with your response headers. And again, it's not really obfuscating. I don't think when you're doing that with the cookie names, it's a little different when you try to do the server names. And for server names, like I said, I would just not return server headers and some of those other headers, but obviously you have to return the cookie header. So cookies are kind of interesting and that you know we already do things like hey you have to set up you know a default username and password for your site when you configure your site. Alright we're not gonna give you an admin admin anymore. You have to set up a user and password when you install the site. Do we add configuration, things like that? I think it just depends on your application, to be honest, but something to consider. I'm curious your thoughts on this, because I think it was interesting. When I talked about it, when we were talking through this in Slack, I thought it was a great conversation and something we really don't talk about a lot. So I'm curious about your thoughts. What do you think? Send them to me at developsec on Twitter, or, you know, shoot me an email. James at developsec.com. I'm curious to hear your thoughts on things like fingerprinting with our applications and our web apps. And are you for removing this stuff? Are you for trying to do this? Do you have any stories that talk about when you've had this situation come up and it's caused you some sort of issue? You know, anything like that is beneficial for us all to hear. So hopefully this has been educational and If you've got stuff to share about it, please feel free to share it with us. I'm sure everybody would be interested to learn more about ways we've seen it. If you've got cool tricks to be able to identify the OS or the server, whatever it is, send it over. There are tools out there like HTTP print that'll do stuff like fingerprinting your applications or at least your servers but are there other tools that you use what are your thoughts on this I'd love to hear them so send them my way and I appreciate everybody listening and we'll catch you on the next episode. You have been listening to the DevelopSec Podcast with James Jardim. To find out more about how we can help you with application security, follow us on Twitter at DevelopSec, or check out our website at www.developsec.com. upbeat music