Here's a list of guidelines to help developers create more secure web applications. This info was based around the OWASP WASS project and the app sec STIG.
The general idea is to set the expectation on what gets audited during a web application security assessment and help developers code things up better the first time around...
http://sites.google.com/site/rwninsecurity/webappsec_dev_guide
Feedback/suggestions welcome!
Monday, November 9, 2009
Monday, September 21, 2009
tiered architecture revisited
[background]
recently "bob" told me about a situation which seemed simple: a dmz web server with a back end db on the trusted network was being upgraded. the IT staff started loading the new db software on the web server, breaking the tiered architecture model.
bob and i initially agreed this was bad, but let's play devils advocate for a minute.
[the tiered model]
the tiered model separates presentation, app logic, and db roles onto different hosts, and *is often implemented as*:
if the exposed front-end web server suffers a host compromise, the business-logic and data aren't immediately compromised, and the attacker will have trouble attacking these systems further because of tight fw policies between the dmz and trusted zones. well, that's the theory...
[problems?]
so why is this maybe silly? ask a pen-tester how they feel when they get an external network assessment where webapp and soc-eng are off limits... they groan and cuss, because many/most organizations today have gotten pretty good at limiting inet facing services and keeping inet facing hosts patched and up to date.
but those same inet facing web apps have logical ties back to systems which often reside on the internal network. application layer attacks like sql injection tunnel through the firewall on the back of trusted application functionality.
the tiered model defends against host vulns, but not app vulns. and are host vulns really more prevelant than app vulns today?
plus, how much protection do you actual get from the tiered model if a host level compromise occurs? the web server can be defaced, credentials can be stolen, and all the back-end data presented to users flows back and forth through the presentation layer. so is there a substantial security gain here?
maybe one can look at apps and equate parameters to listening services on hosts? they accept input and process it, and are vulnerable to attack. if you equate parameters to listeners (i know it's not a perfect comparision) then the attack surface on a web application is larger and more vulnerable than host services on the average inet facing segment.
[well we have WAFs, right?]
srsly? rly? i donno... i haven't seen these devices work in real-world environments yet, so i don't have much faith. they are either 'self-learning' models which prevent mainly simplistic automated attacks, or they are manually configured models which are nearly impossible to keep properly tuned. maybe some orgs have highly effective WAF deployments, but i haven't seen or heard about it...
[sooooo?]
isolating a presentation server in a high-security zone but letting it connect back to other machines in the trusted zone just isn't a good idea. there are at least a couple ways to improve this model.
if the tiered model is used, then all of the tiers should reside in their own DMZs. that way, when the database server gets owned via sqli and the attacker is pivoting to the next target, he'll be isolated in the db DMZ. maybe this is what the tiered model was always intended to be, but it isn't something i've seen very often on real-world networks. plus, an org willing to put in the time and effort to run 2 or 3 DMZs, they will probably also parameterize their queries, validate their inputs, encode their outputs, and make sure that the db app user isn't over-privileged.
a simplier alternative for some applications is to abandon the overhead of running multiple tiers and go back to a single-machine model. the machine can be isolated on a DMZ, and the content served by the application can be managed through a one-way push from the trusted network (trust -> DMZ only). this model has an advantage that the exposed machine has no connection back to the internal network. plus you have an on-site backup on your trusted network.
but if the apps gets a lot of input from users which is stored to be used in near-real-time by other applications or processes, the isolated push model fails because that data needs to be read back into the trusted network and the same injection vulns apply.
[anywho]
is there something obvious i'm missing? there's nothing amazing here, but it seems like the common implementation of the tiered model buys you very little in terms of security...?
recently "bob" told me about a situation which seemed simple: a dmz web server with a back end db on the trusted network was being upgraded. the IT staff started loading the new db software on the web server, breaking the tiered architecture model.
bob and i initially agreed this was bad, but let's play devils advocate for a minute.
[the tiered model]
the tiered model separates presentation, app logic, and db roles onto different hosts, and *is often implemented as*:
if the exposed front-end web server suffers a host compromise, the business-logic and data aren't immediately compromised, and the attacker will have trouble attacking these systems further because of tight fw policies between the dmz and trusted zones. well, that's the theory...
[problems?]
so why is this maybe silly? ask a pen-tester how they feel when they get an external network assessment where webapp and soc-eng are off limits... they groan and cuss, because many/most organizations today have gotten pretty good at limiting inet facing services and keeping inet facing hosts patched and up to date.
but those same inet facing web apps have logical ties back to systems which often reside on the internal network. application layer attacks like sql injection tunnel through the firewall on the back of trusted application functionality.
the tiered model defends against host vulns, but not app vulns. and are host vulns really more prevelant than app vulns today?
plus, how much protection do you actual get from the tiered model if a host level compromise occurs? the web server can be defaced, credentials can be stolen, and all the back-end data presented to users flows back and forth through the presentation layer. so is there a substantial security gain here?
maybe one can look at apps and equate parameters to listening services on hosts? they accept input and process it, and are vulnerable to attack. if you equate parameters to listeners (i know it's not a perfect comparision) then the attack surface on a web application is larger and more vulnerable than host services on the average inet facing segment.
[well we have WAFs, right?]
srsly? rly? i donno... i haven't seen these devices work in real-world environments yet, so i don't have much faith. they are either 'self-learning' models which prevent mainly simplistic automated attacks, or they are manually configured models which are nearly impossible to keep properly tuned. maybe some orgs have highly effective WAF deployments, but i haven't seen or heard about it...
[sooooo?]
isolating a presentation server in a high-security zone but letting it connect back to other machines in the trusted zone just isn't a good idea. there are at least a couple ways to improve this model.
if the tiered model is used, then all of the tiers should reside in their own DMZs. that way, when the database server gets owned via sqli and the attacker is pivoting to the next target, he'll be isolated in the db DMZ. maybe this is what the tiered model was always intended to be, but it isn't something i've seen very often on real-world networks. plus, an org willing to put in the time and effort to run 2 or 3 DMZs, they will probably also parameterize their queries, validate their inputs, encode their outputs, and make sure that the db app user isn't over-privileged.
a simplier alternative for some applications is to abandon the overhead of running multiple tiers and go back to a single-machine model. the machine can be isolated on a DMZ, and the content served by the application can be managed through a one-way push from the trusted network (trust -> DMZ only). this model has an advantage that the exposed machine has no connection back to the internal network. plus you have an on-site backup on your trusted network.
but if the apps gets a lot of input from users which is stored to be used in near-real-time by other applications or processes, the isolated push model fails because that data needs to be read back into the trusted network and the same injection vulns apply.
[anywho]
is there something obvious i'm missing? there's nothing amazing here, but it seems like the common implementation of the tiered model buys you very little in terms of security...?
Saturday, September 19, 2009
looking in the mirror
just came across a tidbit of info that i'd forgotten, and it got me thinking about my op-sec
i use my handle for fun, and there are a few places where i choose to tie it to my IRL info. at cons i tell people my real name and my handle, and there are obvious places where my IRL geogrophy is publicly revealed. i'm not out there commiting crimes or tryin to be an uber-reet hax0r, so i'm not too worried about that.
but i recently started re-doing my home network, and although i do a lot of good defensive foo, there's definately some stuff i noticed that wasn't right. some things pointing to my home network that didn't really need to be there. there were gaps in visibility and logs. some files and directories that i dropped on my box but never moved into the right cryptographic containers. tracking down inet accounts that aren't often used, i realized there are a number of passwords which aren't strong enough and/or haven't been rotated recently enough. machines which were not hardened.
it's easy to let things slip when you're doin sec from 9-5 and just wanna hang out w/ the fam and/or veg-out w/ hulu when you get home. it's not always easy step up and take the extra steps that need to be done to track down the details and stay on top of your environment.
i've got friends who have awesome op-sec and go the extra mile. i need to keep them in mind when i make decisions about my environment...
yea, i've seen people get popped who made bigger mistakes than me. but that doesn't matter if it's my mailspool and / or my filesystem.
a buddy of mine commented that it sux there are ppl out there makin us scared of teh pwnage. i agreed at the time, but really i donno. attackers are a reminder... a buzz in our ear, the angel and the devil on our shoulders reminding us that we do this stuff full time. if we can't run our own houses, why should anyone trust us to help them?
sometimes it's tough to look deeply in the mirror, but ultimately it only helps. it's painful to see the truth with warts and all, but you can't make something better until you understand what it really is.
i use my handle for fun, and there are a few places where i choose to tie it to my IRL info. at cons i tell people my real name and my handle, and there are obvious places where my IRL geogrophy is publicly revealed. i'm not out there commiting crimes or tryin to be an uber-reet hax0r, so i'm not too worried about that.
but i recently started re-doing my home network, and although i do a lot of good defensive foo, there's definately some stuff i noticed that wasn't right. some things pointing to my home network that didn't really need to be there. there were gaps in visibility and logs. some files and directories that i dropped on my box but never moved into the right cryptographic containers. tracking down inet accounts that aren't often used, i realized there are a number of passwords which aren't strong enough and/or haven't been rotated recently enough. machines which were not hardened.
it's easy to let things slip when you're doin sec from 9-5 and just wanna hang out w/ the fam and/or veg-out w/ hulu when you get home. it's not always easy step up and take the extra steps that need to be done to track down the details and stay on top of your environment.
i've got friends who have awesome op-sec and go the extra mile. i need to keep them in mind when i make decisions about my environment...
yea, i've seen people get popped who made bigger mistakes than me. but that doesn't matter if it's my mailspool and / or my filesystem.
a buddy of mine commented that it sux there are ppl out there makin us scared of teh pwnage. i agreed at the time, but really i donno. attackers are a reminder... a buzz in our ear, the angel and the devil on our shoulders reminding us that we do this stuff full time. if we can't run our own houses, why should anyone trust us to help them?
sometimes it's tough to look deeply in the mirror, but ultimately it only helps. it's painful to see the truth with warts and all, but you can't make something better until you understand what it really is.
Thursday, August 13, 2009
quick vmware perf foo (lameeee non sec post)
i was sick of my win VM running sooo slowwwww, so i defragged the 'drive' using the windows defrag utility. then every time i booted my win vm my lptp hdd thrashed and thrashed and performance was worse than before...
so i found out there's a defrag util for VMs... anyway, after a few pitfalls here's a concise description of the tasks:
so i ended up w/ a free 30 gig of space after shrinking the disk, and everything is running pretty snappy again. you need at least as much free space on your disk as the size of your vmdk in order to perform the shrink and defrag operations...
time to go write some reports... >sigh<
so i found out there's a defrag util for VMs... anyway, after a few pitfalls here's a concise description of the tasks:
vmware-mount /path/to/file.vmdk /mnt/
vmware-vdiskmanager -p /mnt/
[kill some time while the vmdk preps]
vmware-mount -d /mnt/
vmware-vdiskmanager -k /path/to/file.vmdk
[kill some time while the vmdk shrinks]
vmware-vdiskmanager -d /path/to/file.vmdk
[kill some time while the vmdk is defragged]so i ended up w/ a free 30 gig of space after shrinking the disk, and everything is running pretty snappy again. you need at least as much free space on your disk as the size of your vmdk in order to perform the shrink and defrag operations...
time to go write some reports... >sigh<
Saturday, June 27, 2009
cloud security redux
short and sweet post.... tons of talk about the cloud over the last 6-12 months...
so the cloud is a bunch of boxes offering a service out there on inet. all the security discussion i've seen has focused basically on confidentiality of your data once it enters the cloud, but mb there's another way to look at it.
clouds are potentially massive environments of resources which are allocated and partitioned to paying customers. instead of focusing on the risk posed to cloud customers, why not look a little at the risk to the cloud operators?
clouds are big business networks, and big networks are often under-monitored. attacking cloud allocation schemes could result in resources being allocated to an attacker off-the-record. "ghost" resources in the cloud controlled by an attacker who isn't paying for service and isn't abiding by the ToS. these ghost resources could be used for all kinds of illegitimate purposes with significant value for the attacker who controls them.
if you are subtle, you could probably operate under the radar within the cloud for quite some time...
so the cloud is a bunch of boxes offering a service out there on inet. all the security discussion i've seen has focused basically on confidentiality of your data once it enters the cloud, but mb there's another way to look at it.
clouds are potentially massive environments of resources which are allocated and partitioned to paying customers. instead of focusing on the risk posed to cloud customers, why not look a little at the risk to the cloud operators?
clouds are big business networks, and big networks are often under-monitored. attacking cloud allocation schemes could result in resources being allocated to an attacker off-the-record. "ghost" resources in the cloud controlled by an attacker who isn't paying for service and isn't abiding by the ToS. these ghost resources could be used for all kinds of illegitimate purposes with significant value for the attacker who controls them.
if you are subtle, you could probably operate under the radar within the cloud for quite some time...
Friday, June 19, 2009
from the blackhat reject bin
so maybe this is obvious, i donno...
the talk started when i told my buddy (@zenfosec) that i had this password for the firewall for this big .com site... it was one of those "it's always been that" passwords... pure speculation, anyway...
so at the end of the gig while presenting my report, i suggested they rotate the password, since they gave it to an external party. the admin laughs, and he's like "you can only get to the box from inside once i pull the rule for you".
i'm a big advocate of dropping the whole "inside" / "outside" terminology for substantial networks. the fundamental protection measures are so cheap in true cost, and the risk/benefit is clear. anywho...
so my buddy says "yea, until you client side him" ;)
so that was the crux of the talk. when you get client-sided by xss or flash vulns or whatever, your internal network can be attacked.
this idea really built off the nifty modem csrf pointed out by nathan... so let's just extend it. what if there's auth required on the device? can we attack it when we're XSSing and/or CSRFing?
blah blah, slides about xss and csrf history, and traditional distinctions, etc...
so anyway, the hostile code can blindly assume gateways are .1 or .254 on the local /24 (re: the timely rsnake comments on the pervasive homogenous rfc 1918 networks) or you can do a little work and find them.
once found, gateways can be attacked w/ a csrf via the client-side. if the gateway requires auth, it can be brute forced. i didn't do much with forms based because i was really curious about http basic auth. this lead me to realize you can pass http basic auth creds to the gateway:
<img src="https://username:password@u.r.gate.way/known/path/img.gif">
***update*** - i thought this auth method was really nifty when i thought about it and tested it, and just two days ago realized that the gnucitizen crew used the same method in their AttackAPI.. mb others did before that too. anywho, just wanted to give credit
generate tons of code brute the passwords with known usernames and image paths for common gateway models. you are auth'd, you detect it and initiate a second stage which leaks out the creds and/or performs a csrf to enable wan management.
bruting will work because people feel like inside is safe and they don't take reasonable precautions like password rotation, password complexity, and human monitoring of interesting log events like days of failed password attempts on the firewall.
i haven't come across similar ramblings on the web yet, so i wanted to share :)
thanks for stickin w/ me if you read this far ;)
the talk started when i told my buddy (@zenfosec) that i had this password for the firewall for this big .com site... it was one of those "it's always been that" passwords... pure speculation, anyway...
so at the end of the gig while presenting my report, i suggested they rotate the password, since they gave it to an external party. the admin laughs, and he's like "you can only get to the box from inside once i pull the rule for you".
i'm a big advocate of dropping the whole "inside" / "outside" terminology for substantial networks. the fundamental protection measures are so cheap in true cost, and the risk/benefit is clear. anywho...
so my buddy says "yea, until you client side him" ;)
so that was the crux of the talk. when you get client-sided by xss or flash vulns or whatever, your internal network can be attacked.
this idea really built off the nifty modem csrf pointed out by nathan... so let's just extend it. what if there's auth required on the device? can we attack it when we're XSSing and/or CSRFing?
blah blah, slides about xss and csrf history, and traditional distinctions, etc...
so anyway, the hostile code can blindly assume gateways are .1 or .254 on the local /24 (re: the timely rsnake comments on the pervasive homogenous rfc 1918 networks) or you can do a little work and find them.
once found, gateways can be attacked w/ a csrf via the client-side. if the gateway requires auth, it can be brute forced. i didn't do much with forms based because i was really curious about http basic auth. this lead me to realize you can pass http basic auth creds to the gateway:
<img src="https://username:password@u.r.gate.way/known/path/img.gif">
***update*** - i thought this auth method was really nifty when i thought about it and tested it, and just two days ago realized that the gnucitizen crew used the same method in their AttackAPI.. mb others did before that too. anywho, just wanted to give credit
generate tons of code brute the passwords with known usernames and image paths for common gateway models. you are auth'd, you detect it and initiate a second stage which leaks out the creds and/or performs a csrf to enable wan management.
bruting will work because people feel like inside is safe and they don't take reasonable precautions like password rotation, password complexity, and human monitoring of interesting log events like days of failed password attempts on the firewall.
i haven't come across similar ramblings on the web yet, so i wanted to share :)
thanks for stickin w/ me if you read this far ;)
dr horrible ftw
okok, so i just heard that there are ppl who haven't enjoyed this yet. soooo:
enjoy :D
(ps - this is 1/3)
enjoy :D
(ps - this is 1/3)
Subscribe to:
Posts (Atom)
