January 22, 2019 • 21 mins
Does your application give away details about it server, framework, or other components? How is this information used by an attacker? Check out this episode to learn more.
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.
For more info go to https://www.developsec.com or follow us on X (@developsec).
The DevelopSec podcast is brought to you by Jardine Software Inc.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:04):
On this episode, James talks about application fingerprintingand 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?
(00:40):
Hey everyone, welcome to Episode 112 of the DevelopSecpodcast. I am your host, James Jardine. And today I want to talk
about fingerprinting and no I'm not talking about Fingerprinting where youactually use your actual fingers to place them in some ink and set
them on something and have your fingerprints taken instead I'm talkingabout the identifying or identification
(01:03):
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 determinewhether you're running IIS or whether you're running Apache, whether you're
running PHP versus ASP.NET versusRuby, even down to the type of
(01:28):
application level. So are you running something likeWordPress or some other CMS like Joomla or
Drupal? So we have this way ofidentifying this information that may not
be readily just thrown out there for us. And the reasonthis came up is I had a question asked to me in my Slack channel
(01:50):
asking about cookie names and really theirend goal was they've got an application that
is installed for multiple clients I guess if youwill 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 Joomlaor Drupal. Something that's pre-built out there for you
(02:16):
that you can stand up and run. And their concernwas basically really around their cookie names.
And more importantly, around the ability forsome 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.
(02:38):
And you know, what if, I mean, it's a good concern, becausewhat happens if there's a vulnerability in that application,
somebody identifies it. And then all of a sudden, they just go out and theydo these quick searches and are like, hey, show me all the, you know, applications
that use this version of this application. And if we canimmediately pull that back, then we can immediately go out and try to
(03:01):
exploit that vulnerability on all those sites. So of course the concernthere is, hey, I want to be able to stop this from happening. That yeah,
maybe there's, we may have vulnerabilities in our sites, butwe 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 howmany times have we seen a breach where something like
(03:23):
a MongoDB database was sitting out thereexposed 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.
(03:45):
When we see those type of breaches occur, it's really justsomebody going out there and doing this search. Think about things like your baby
monitors, your security cameras. We see these all the time in thenews 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 catalogall of this. So that way if there's something specific you're looking for I'm
(04:12):
looking for all web servers that are runningIIS 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 orsomething else, and that gets catalogued, then if I fold
the vulnerability in that server, then I can quickly go andsearch and identify all those servers and then attempt my
(04:34):
exploit against those to see if it works. So it was agreat 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 whenwe're thinking about what we're talking about with fingerprinting
within our applications. And there's lots of ways that we canidentify what a site may be running
(04:57):
for the application. And again, that goes back to What type of server, whattype of frameworks you have, all that stuff. So here's a
couple different things that we typically will identify. And someof these things we may identify during a penetration test or
vulnerability assessment. Some things we don't, which is kind ofinteresting, where we kind of pick and choose which ones
(05:19):
typically will get flagged and which ones don't. So some exampleswe have response headers. This is very common and when you're
having an assessment done a lot of times this may belisted not as fingerprinting but just
information leakage in that we send downresponse headers that include things like server name or it'll just say
(05:41):
server right and it lets us know that it's Apache or it's IIS. Youhave the framework so ASP.NET versions
come down with response headers, and it gives you a lot of information. Ittells you the exact version that is running on the
server that's out there. So response headerscan give us a lot of information about what's happening on our site. We also
(06:03):
have the file extension. That's kind of a funny 1. I remember doing an assessmentyears ago working with somebody else and they're
like, you know, I think this is a .NET app butI'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 headerthat's coming down saying it's running on IIS? Or is it the
(06:26):
extension of .aspx that's giving you awaythat this is a Microsoft-based application? But the file
extension will give us information right whether it's a PHP app whetherit'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 dotdo There's all kinds of info that comes from just that
(06:48):
extension that we see. Now we do see a lot of applications nowthat use routing and we don't actually see the extension, but I mean
I still see applications every single day that still have extensions onthem that let us know, hey here's the technology that we're using. You
also have cookie names. A lot of frameworks havedefault cookie names for things like their session ID, so
(07:10):
PHP session ID, or, you know, with authenticationin .NET, you know, you have the .aspxauth
cookie that comes down, right? These default names give us thatinformation about what type of system you have going
on. We also have things like file paths. And, you know, aclassic example of a file path is
(07:34):
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 aspart of a lot of the paths in there. And that immediately
gives it away that, hey, we've got a WordPress site. And othersites may do this as well across the board, right? They have something
(07:56):
that's commonly set that we can attribute it tothat type of site, especially sites where we're going to deploy them in
multiple locations. You know, less your custombuilt 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
(08:18):
soon as somebody identifies and says, oh yeah, this path belongsto XYZ site, now we know anytime I
see that, oh, this is this type of site. So filepaths 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
(08:40):
help provide that as well. And then you also have comments. Sometimesif you look at the comments, I feel like .NET Nuke did
this. We could look at comments and actually see some info inthere 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
(09:03):
way for us to be able to identify, hey, what typeof application am I dealing with
here? And is there something thatI could do with that information? Now, of course,
there's 2 schools of thought when we talk aboutthe fingerprinting of an application or a
(09:25):
server or whatever it is. And usuallythe first thing that you hear when people say, oh, you're returning
the server header and it tells me that it's IIS8.5. And it's like, okay, but I can't
necessarily do anything directly with that information, right? Ineed something else Because just having that info, I mean, it is an
(09:47):
information leakage. I know something about that site. Soas 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 ishelpful in that case and so you'll hear a lot of people say well you
(10:09):
have to remove that because if there's a vulnerability in thatversion of that system then somebody
could just write a script that runs out and says, oh, let me check theresponse header. The server says I is 8.5. Let me go ahead and
run my payload. Okay, well, I mean, that is possible, right? Andsomebody could script that out for sure and let that run
(10:31):
and all of a sudden just hit all the sites, bam, it's 8.5. Even ifyou catalog it using something like Shodan, oh, I know that's
that, I'm gonna go ahead and I'll run my exploit against allthose. And that is 1 avenue of potential attack.
But the other side of that is so manyplaces or so many scripts out there actually
(10:53):
don't care what version it is. You know you've got somany 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. Itsays, 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 whenwe do that, then obviously that other information
(11:15):
becomes less important because we'renot 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 thatinformation 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
(11:36):
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 thatbecause 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
(11:58):
that just benignly goes out there looking for a specificthing 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'mgonna run both sets of exploits and see if it goes anywhere
so doing the obscurity thing might not bethe best thing and to be honest even if you're doing that and
(12:20):
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 goingthrough, 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,
(12:43):
right? Some of the things that we want to think about is don'treturn unneeded response headers. So things like
your server header, your frameworks, those type of things, Xruntime. 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'tworry about obfuscating it, just don't return it. Don't return
(13:09):
the ASP.NET MVC versionor anything like that, just remove those headers. It's good cyber
hygiene, and it just reduces that attack surface alittle bit because we're providing less information that's easy to
gain. We also have things like don't change your defaultor do change your default cookie name. So instead of using .aspx
(13:31):
auth, change it to something else so that way it's notblatantly giving away that, hey, this is an ASPX application.
Now, in a moment, I'm going to talk that that's not necessarilythe most difficult thing to figure out afterwards.
Change your don't use your app name or identifiers inyour paths. You know, don't put identifying information in your
(13:53):
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 pickthose up and do that. But even if we do all
that, even if we make all those changes, it doesn't necessarily meanthat we still can't fingerprint the application and find out
(14:15):
some information about it. And that's because serversact in different ways even without responding with those type of response
header. So IIS may returnother 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 gonnaautomate that and will that show up on Shodan?
(14:41):
Probably not, but there is still that capabilitythat even everything you add on there, if I'm a dedicated
attacker, and especially if I'm doing like manual techniques, I may identifythis and I may be able to find it and see it and
be able to use that information. So we're nottotally killing everything that we see there. But if
(15:03):
we're following those best practices, then we're reducingthe chance of any type of automated script or simple searching for our
stuff being out there. And we're helping protect our app alittle bit more. I mean, to be honest, the best way we're going to
protect our app is by having that secure design whilewe're building everything out, building up good security requirements.
(15:27):
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 mightbe at risk for our application. Right? And
that's our end goal. So we want to make sure that we're going in andprotecting against all these different things. And then on top of that, because a
(15:49):
lot of this stuff is specific toour servers and all that, and really less about
against our specific code, unless you're talking about something that'sdeployed out multiple times across different sites, right, like a
WordPress instance or something like that. A lot of theseinformation that's coming out is application or server
(16:11):
specific, meaning more like the framework. So, oh, I seeyou'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 ableto identify that, hey, this is an IIS server. But
again, it doesn't really matter how much we try to trimthat down. What we're doing is we're creating a higher barrier
(16:33):
of entry to make it more difficult to identify thisstuff. Can I still identify your app as an ASP.NET
application? And you know, we'll talk before core. So we'lltalk ASP.NET, maybe 4.7, or, you
know, Web Forms, MVC, whichever it is, even if youuse routes, and I can't see the extension, even if I don't see the server
(16:55):
header even if I don't see ASPX headers maybe you change the cookieinformation so it's not dot ASPX off and you know
there's nothing in that app that is telling me Hey, this is a .NETapplication and you know, unfortunately with .NET apps There's a lot of
information oftentimes that will give it away that it's .NETBut what about when I try to submit a cross-site scripting attack and it
(17:17):
kicks off validate request and throws an exception for that.
Even without giving me the error message back there's achance I can still determine, hey wait if I do this specific
character set it will act this way and ifI 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 offfor this, because I know exactly how it works. So I know, oh, hey, they're
(17:43):
using ASP.NET in the background. So there are stillways 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 likethat? And you know, I mean, I think it's something that
(18:05):
is a good consideration within your app. You know, do you have a way thatif you have multiple installs to be able to let users
set their cookie names? Or do you generate arandom 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 identifythat. That's a great consideration to have within
(18:27):
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 differentwhen 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
(18:49):
and that you know we already do things like hey you have to setup you know a default username and password for your
site when you configure your site. Alright we're not gonna giveyou 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,
(19:15):
because I think it was interesting. When I talked about it, when we were talkingthrough 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 doyou 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 applicationsand our web apps. And are you for
(19:42):
removing this stuff? Are you for trying to do this? Do you have any storiesthat talk about when you've had this situation come up and it's caused
you some sort of issue? You know, anything like that isbeneficial 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
(20:04):
learn more about ways we've seen it. If you've got cooltricks to be able to identify the OS or
the server, whatever it is, send it over. There are tools out therelike HTTP print that'll do stuff like fingerprinting
your applications or at least your servers but are there other tools thatyou use what are your thoughts on this I'd love to hear them so
(20:27):
send them my way and I appreciate everybody listening and we'll catch you on thenext episode.
You have been listening to the DevelopSec Podcast with JamesJardim. 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.
(20:54):
upbeat music
On this episode, James talks about application fingerprintingand 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?
(00:40):
Hey everyone, welcome to Episode 112 of the DevelopSecpodcast. I am your host, James Jardine. And today I want to talk
about fingerprinting and no I'm not talking about Fingerprinting where youactually use your actual fingers to place them in some ink and set
them on something and have your fingerprints taken instead I'm talkingabout the identifying or identification
(01:03):
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 determinewhether you're running IIS or whether you're running Apache, whether you're
running PHP versus ASP.NET versusRuby, even down to the type of
(01:28):
application level. So are you running something likeWordPress or some other CMS like Joomla or
Drupal? So we have this way ofidentifying this information that may not
be readily just thrown out there for us. And the reasonthis came up is I had a question asked to me in my Slack channel
(01:50):
asking about cookie names and really theirend goal was they've got an application that
is installed for multiple clients I guess if youwill 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 Joomlaor Drupal. Something that's pre-built out there for you
(02:16):
that you can stand up and run. And their concernwas basically really around their cookie names.
And more importantly, around the ability forsome 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.
(02:38):
And you know, what if, I mean, it's a good concern, becausewhat happens if there's a vulnerability in that application,
somebody identifies it. And then all of a sudden, they just go out and theydo these quick searches and are like, hey, show me all the, you know, applications
that use this version of this application. And if we canimmediately pull that back, then we can immediately go out and try to
(03:01):
exploit that vulnerability on all those sites. So of course the concernthere is, hey, I want to be able to stop this from happening. That yeah,
maybe there's, we may have vulnerabilities in our sites, butwe 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 howmany times have we seen a breach where something like
(03:23):
a MongoDB database was sitting out thereexposed 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.
(03:45):
When we see those type of breaches occur, it's really justsomebody going out there and doing this search. Think about things like your baby
monitors, your security cameras. We see these all the time in thenews 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 catalogall of this. So that way if there's something specific you're looking for I'm
(04:12):
looking for all web servers that are runningIIS 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 orsomething else, and that gets catalogued, then if I fold
the vulnerability in that server, then I can quickly go andsearch and identify all those servers and then attempt my
(04:34):
exploit against those to see if it works. So it was agreat 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 whenwe're thinking about what we're talking about with fingerprinting
within our applications. And there's lots of ways that we canidentify what a site may be running
(04:57):
for the application. And again, that goes back to What type of server, whattype of frameworks you have, all that stuff. So here's a
couple different things that we typically will identify. And someof these things we may identify during a penetration test or
vulnerability assessment. Some things we don't, which is kind ofinteresting, where we kind of pick and choose which ones
(05:19):
typically will get flagged and which ones don't. So some exampleswe have response headers. This is very common and when you're
having an assessment done a lot of times this may belisted not as fingerprinting but just
information leakage in that we send downresponse headers that include things like server name or it'll just say
(05:41):
server right and it lets us know that it's Apache or it's IIS. Youhave the framework so ASP.NET versions
come down with response headers, and it gives you a lot of information. Ittells you the exact version that is running on the
server that's out there. So response headerscan give us a lot of information about what's happening on our site. We also
(06:03):
have the file extension. That's kind of a funny 1. I remember doing an assessmentyears ago working with somebody else and they're
like, you know, I think this is a .NET app butI'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 headerthat's coming down saying it's running on IIS? Or is it the
(06:26):
extension of .aspx that's giving you awaythat this is a Microsoft-based application? But the file
extension will give us information right whether it's a PHP app whetherit'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 dotdo There's all kinds of info that comes from just that
(06:48):
extension that we see. Now we do see a lot of applications nowthat use routing and we don't actually see the extension, but I mean
I still see applications every single day that still have extensions onthem that let us know, hey here's the technology that we're using. You
also have cookie names. A lot of frameworks havedefault cookie names for things like their session ID, so
(07:10):
PHP session ID, or, you know, with authenticationin .NET, you know, you have the .aspxauth
cookie that comes down, right? These default names give us thatinformation about what type of system you have going
on. We also have things like file paths. And, you know, aclassic example of a file path is
(07:34):
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 aspart of a lot of the paths in there. And that immediately
gives it away that, hey, we've got a WordPress site. And othersites may do this as well across the board, right? They have something
(07:56):
that's commonly set that we can attribute it tothat type of site, especially sites where we're going to deploy them in
multiple locations. You know, less your custombuilt 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
(08:18):
soon as somebody identifies and says, oh yeah, this path belongsto XYZ site, now we know anytime I
see that, oh, this is this type of site. So filepaths 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
(08:40):
help provide that as well. And then you also have comments. Sometimesif you look at the comments, I feel like .NET Nuke did
this. We could look at comments and actually see some info inthere 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
(09:03):
way for us to be able to identify, hey, what typeof application am I dealing with
here? And is there something thatI could do with that information? Now, of course,
there's 2 schools of thought when we talk aboutthe fingerprinting of an application or a
(09:25):
server or whatever it is. And usuallythe first thing that you hear when people say, oh, you're returning
the server header and it tells me that it's IIS8.5. And it's like, okay, but I can't
necessarily do anything directly with that information, right? Ineed something else Because just having that info, I mean, it is an
(09:47):
information leakage. I know something about that site. Soas 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 ishelpful in that case and so you'll hear a lot of people say well you
(10:09):
have to remove that because if there's a vulnerability in thatversion of that system then somebody
could just write a script that runs out and says, oh, let me check theresponse header. The server says I is 8.5. Let me go ahead and
run my payload. Okay, well, I mean, that is possible, right? Andsomebody could script that out for sure and let that run
(10:31):
and all of a sudden just hit all the sites, bam, it's 8.5. Even ifyou catalog it using something like Shodan, oh, I know that's
that, I'm gonna go ahead and I'll run my exploit against allthose. And that is 1 avenue of potential attack.
But the other side of that is so manyplaces or so many scripts out there actually
(10:53):
don't care what version it is. You know you've got somany 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. Itsays, 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 whenwe do that, then obviously that other information
(11:15):
becomes less important because we'renot 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 thatinformation 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
(11:36):
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 thatbecause 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
(11:58):
that just benignly goes out there looking for a specificthing 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'mgonna run both sets of exploits and see if it goes anywhere
so doing the obscurity thing might not bethe best thing and to be honest even if you're doing that and
(12:20):
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 goingthrough, 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,
(12:43):
right? Some of the things that we want to think about is don'treturn unneeded response headers. So things like
your server header, your frameworks, those type of things, Xruntime. 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'tworry about obfuscating it, just don't return it. Don't return
(13:09):
the ASP.NET MVC versionor anything like that, just remove those headers. It's good cyber
hygiene, and it just reduces that attack surface alittle bit because we're providing less information that's easy to
gain. We also have things like don't change your defaultor do change your default cookie name. So instead of using .aspx
(13:31):
auth, change it to something else so that way it's notblatantly giving away that, hey, this is an ASPX application.
Now, in a moment, I'm going to talk that that's not necessarilythe most difficult thing to figure out afterwards.
Change your don't use your app name or identifiers inyour paths. You know, don't put identifying information in your
(13:53):
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 pickthose up and do that. But even if we do all
that, even if we make all those changes, it doesn't necessarily meanthat we still can't fingerprint the application and find out
(14:15):
some information about it. And that's because serversact in different ways even without responding with those type of response
header. So IIS may returnother 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 gonnaautomate that and will that show up on Shodan?
(14:41):
Probably not, but there is still that capabilitythat even everything you add on there, if I'm a dedicated
attacker, and especially if I'm doing like manual techniques, I may identifythis and I may be able to find it and see it and
be able to use that information. So we're nottotally killing everything that we see there. But if
(15:03):
we're following those best practices, then we're reducingthe chance of any type of automated script or simple searching for our
stuff being out there. And we're helping protect our app alittle bit more. I mean, to be honest, the best way we're going to
protect our app is by having that secure design whilewe're building everything out, building up good security requirements.
(15:27):
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 mightbe at risk for our application. Right? And
that's our end goal. So we want to make sure that we're going in andprotecting against all these different things. And then on top of that, because a
(15:49):
lot of this stuff is specific toour servers and all that, and really less about
against our specific code, unless you're talking about something that'sdeployed out multiple times across different sites, right, like a
WordPress instance or something like that. A lot of theseinformation that's coming out is application or server
(16:11):
specific, meaning more like the framework. So, oh, I seeyou'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 ableto identify that, hey, this is an IIS server. But
again, it doesn't really matter how much we try to trimthat down. What we're doing is we're creating a higher barrier
(16:33):
of entry to make it more difficult to identify thisstuff. Can I still identify your app as an ASP.NET
application? And you know, we'll talk before core. So we'lltalk ASP.NET, maybe 4.7, or, you
know, Web Forms, MVC, whichever it is, even if youuse routes, and I can't see the extension, even if I don't see the server
(16:55):
header even if I don't see ASPX headers maybe you change the cookieinformation so it's not dot ASPX off and you know
there's nothing in that app that is telling me Hey, this is a .NETapplication and you know, unfortunately with .NET apps There's a lot of
information oftentimes that will give it away that it's .NETBut what about when I try to submit a cross-site scripting attack and it
(17:17):
kicks off validate request and throws an exception for that.
Even without giving me the error message back there's achance I can still determine, hey wait if I do this specific
character set it will act this way and ifI 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 offfor this, because I know exactly how it works. So I know, oh, hey, they're
(17:43):
using ASP.NET in the background. So there are stillways 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 likethat? And you know, I mean, I think it's something that
(18:05):
is a good consideration within your app. You know, do you have a way thatif you have multiple installs to be able to let users
set their cookie names? Or do you generate arandom 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 identifythat. That's a great consideration to have within
(18:27):
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 differentwhen 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
(18:49):
and that you know we already do things like hey you have to setup you know a default username and password for your
site when you configure your site. Alright we're not gonna giveyou 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,
(19:15):
because I think it was interesting. When I talked about it, when we were talkingthrough 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 doyou 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 applicationsand our web apps. And are you for
(19:42):
removing this stuff? Are you for trying to do this? Do you have any storiesthat talk about when you've had this situation come up and it's caused
you some sort of issue? You know, anything like that isbeneficial 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
(20:04):
learn more about ways we've seen it. If you've got cooltricks to be able to identify the OS or
the server, whatever it is, send it over. There are tools out therelike HTTP print that'll do stuff like fingerprinting
your applications or at least your servers but are there other tools thatyou use what are your thoughts on this I'd love to hear them so
(20:27):
send them my way and I appreciate everybody listening and we'll catch you on thenext episode.
You have been listening to the DevelopSec Podcast with JamesJardim. 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.
(20:54):
upbeat music
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Betrayal Season 5
Saskia Inwood woke up one morning, knowing her life would never be the same. The night before, she learned the unimaginable – that the husband she knew in the light of day was a different person after dark. This season unpacks Saskia’s discovery of her husband’s secret life and her fight to bring him to justice. Along the way, we expose a crime that is just coming to light. This is also a story about the myth of the “perfect victim:” who gets believed, who gets doubted, and why. We follow Saskia as she works to reclaim her body, her voice, and her life. If you would like to reach out to the Betrayal Team, email us at betrayalpod@gmail.com. Follow us on Instagram @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com