I have read all the material, and have a question.
I initially thought "Hey, if my web.config is encrypted, I am in pretty good shape."
However, I am concerned that the "default" documented method of encrypting the web.config is based on the same machine key that is compromised by the exploit.
I initially thought "Hey, if my web.config is encrypted, I am in pretty good shape."
There are two things to consider here. I outline a portion of this in this
post. The concept of encrypting your web.config is that in the situation that your server is compromised (depending on how it it is compromised), nothing of value can be gleamed without decrpyting the file. For this particular exploit, since the machineKey
is now known to the attacker, he/she can retrieve the sensitive information.
SamJonesIII
It appears that the system MachineKey is used to encrypt web.config
That is true. (update) with the supported methodology for encrpyting the web.config.
SamJonesIII
QUESTION: If the exploit path is open, an encrypted web.config can be both retrieved from a 3.5SP1 system AND decrypted.
True or false?
I would say yes to this.
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
According to my understanding, the encrypted section, like connectionStrings, in web.config is encrypted by RSA key and you can even assign different RSA key container for different web.config. I don't think it can be decripted directly with machine key.
According to my understanding, the encrypted section, like connectionStrings, in web.config is encrypted by RSA key and you can even assign different RSA key container for different web.config. I don't think it can be decripted directly with machine key.
Whatever files that the AppPool identity has access to, if your server is compromised the assumption is that now the attacker has [at least] the same level of access as the AppPool. This part of those instructions [Execute aspnet_regiis
-pa "SharedKeys" "NT AUTHORITY\NETWORK SERVICE" to grant access permission to ASP.NET web application.] implies that if the attacker has that level of access means that decryption could be possible.
Bottom line is that if you have a server that has been compromised, you cannot assume anything is secured.
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
If you were to store the key in a file location other than the machine.config that is outside the web directory, the attacker should have to guess the exact path to that file to obtain the key and decrypt the web.config file. Don't use the key stored in
the machine.config file to encrypt your web.config file.
If you were to store the key in a file location other than the machine.config that is outside the web directory, the attacker should have to guess the exact path to that file to obtain the key and decrypt the web.config file. Don't use the key stored in
the machine.config file to encrypt your web.config file.
Given the skill of these kinds of attacks, just putting the path "somewhere else" isn't good enough either. Obfuscation is easily beaten, "hidden" paths aren't really hidden. Basically if the server is attacked and your files are downloaded there is little
recourse to salvage that information. Security through obscurity isn't a fail-safe.
Thanks,
David
joshuaperry
If you were to store the key in a file location other than the machine.config that is outside the web directory, the attacker should have to guess the exact path to that file to obtain the key and decrypt the web.config file. Don't use the key stored in
the machine.config file to encrypt your web.config file.
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
I am not advocating "hidden" paths or obfuscation. Files that are outside of the application root do not have the same permissions and would not be vulnerable like a web.config that resides under the application root. Layered security like this is always
one of the best ways to protect information on your site. The best defense to keeping files from being downloaded is to store them outside the application root, especially things like encryption keys. I believe Scott Guthrie may have even mentioned in one
of his replies that only files that reside under the application root were vulnerable to being downloaded. This is also the reason that many of us follow the best practice of storing the root folder on a volume other than the system volume. That practive,
along with encryptiing connection strings and storing passwords in a separate encrypted XML file have kept us safe from many vulnerabilities over the years.
For this vulnerability, we aren't doing anything with changing web.config files. Instead we are simply notifying on event ID 3005 by monitoring our event logs and then automatically blocking the remote IP. This prevents the attack from being completed
in the first place. Making all of the changes suggested by Scott will not protect anything since the attack would still only need to check the suorce of the returned content to see if it is a YSOD versus a 404. you could probably also accomplish blocking
the remote IP from completing the attack using a layer 4 gateway. This is certainly the best way to ensure protection from this vulnerability if you manage thousands of customs sites.
I am not advocating "hidden" paths or obfuscation. Files that are outside of the application root do not have the same permissions and would not be vulnerable like a web.config that resides under the application root. Layered security like this is always
one of the best ways to protect information on your site. The best defense to keeping files from being downloaded is to store them outside the application root, especially things like encryption keys. I believe Scott Guthrie may have even mentioned in one
of his replies that only files that reside under the application root were vulnerable to being downloaded. This is also the reason that many of us follow the best practice of storing the root folder on a volume other than the system volume. That practive,
along with encryptiing connection strings and storing passwords in a separate encrypted XML file have kept us safe from many vulnerabilities over the years.
By "default" files outside of an application root do not have the same permissions. If your website is configured to view/parse/open/etc files that are outside of the web root, then you "do" have it configured to at least read outside of the web root. I
am glad that you have been safe over the years. I hope you continue to be safe.
joshuaperry
For this vulnerability, we aren't doing anything with changing web.config files. Instead we are simply notifying on event ID 3005 by monitoring our event logs and then automatically blocking the remote IP. This prevents the attack from being completed
in the first place. Making all of the changes suggested by Scott will not protect anything since the attack would still only need to check the suorce of the returned content to see if it is a YSOD versus a 404. you could probably also accomplish blocking
the remote IP from completing the attack using a layer 4 gateway. This is certainly the best way to ensure protection from this vulnerability if you manage thousands of customs sites.
That is your choice to not modify your web.config files. Given that the only publicly available "fix" to this is the adjustment of the customErrors element in the web.config, if you feel that you are safe with your solution, then good for you. I will continue
to push for people to update their web.config files under the guidance of Microsoft/ASP.NET team and through my
additional guidance.
Thanks,
David
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
According to my understanding, the encrypted section, like connectionStrings, in web.config is encrypted by RSA key and you can even assign different RSA key container for different web.config. I don't think it can be decripted directly with machine key.
Whatever files that the AppPool identity has access to, if your server is compromised the assumption is that now the attacker has [at least] the same level of access as the AppPool. This part of those instructions [Execute aspnet_regiis -pa
"SharedKeys" "NT AUTHORITY\NETWORK SERVICE" to grant access permission to ASP.NET web application.] implies that if the attacker has that level of access means that decryption could be possible.
Bottom line is that if you have a server that has been compromised, you cannot assume anything is secured.
Then use the command aspnet_regiis -pr "[KeyName]" "NT Authority\Network Service" to remove read access to that key. It's the web.config that is compromised, not the web server.
EDIT: nevermind, you do need read access to decrypt.
Pro Tip: make sure you are using the right AppPool identity when executing the aspnet_regiis commands.
SamJonesIII
0 Points
2 Posts
Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 03:26 PM|LINK
I have read all the material, and have a question.
I initially thought "Hey, if my web.config is encrypted, I am in pretty good shape."
However, I am concerned that the "default" documented method of encrypting the web.config is based on the same machine key that is compromised by the exploit.
For example, in : http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
It appears that the system MachineKey is used to encrypt web.config
QUESTION: If the exploit path is open, an encrypted web.config can be both retrieved from a 3.5SP1 system AND decrypted.
True or false?
Thank you!!
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 08:58 PM|LINK
True.
Using the workaround on Gu's blog should keep you safe. A permanent fix is being developed and should be available soon.
blog: www.heartysoft.com
twitter: @ashic
davidpenton
Member
595 Points
100 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 11:37 PM|LINK
There are two things to consider here. I outline a portion of this in this post. The concept of encrypting your web.config is that in the situation that your server is compromised (depending on how it it is compromised), nothing of value can be gleamed without decrpyting the file. For this particular exploit, since the machineKey is now known to the attacker, he/she can retrieve the sensitive information.
That is true. (update) with the supported methodology for encrpyting the web.config.
I would say yes to this.
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
darkthread
Member
2 Points
1 Post
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 09:37 AM|LINK
(Correct me if I am wrong...
)
According to my understanding, the encrypted section, like connectionStrings, in web.config is encrypted by RSA key and you can even assign different RSA key container for different web.config. I don't think it can be decripted directly with machine key.
Here are some supplementary explanations about web.config encryption.
davidpenton
Member
595 Points
100 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 09:50 AM|LINK
Whatever files that the AppPool identity has access to, if your server is compromised the assumption is that now the attacker has [at least] the same level of access as the AppPool. This part of those instructions [Execute aspnet_regiis -pa "SharedKeys" "NT AUTHORITY\NETWORK SERVICE" to grant access permission to ASP.NET web application.] implies that if the attacker has that level of access means that decryption could be possible.
Bottom line is that if you have a server that has been compromised, you cannot assume anything is secured.
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
joshuaperry
Member
24 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 08:17 PM|LINK
If you were to store the key in a file location other than the machine.config that is outside the web directory, the attacker should have to guess the exact path to that file to obtain the key and decrypt the web.config file. Don't use the key stored in the machine.config file to encrypt your web.config file.
davidpenton
Member
595 Points
100 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 08:23 PM|LINK
Given the skill of these kinds of attacks, just putting the path "somewhere else" isn't good enough either. Obfuscation is easily beaten, "hidden" paths aren't really hidden. Basically if the server is attacked and your files are downloaded there is little recourse to salvage that information. Security through obscurity isn't a fail-safe.
Thanks,
David
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
joshuaperry
Member
24 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 04:32 PM|LINK
I am not advocating "hidden" paths or obfuscation. Files that are outside of the application root do not have the same permissions and would not be vulnerable like a web.config that resides under the application root. Layered security like this is always one of the best ways to protect information on your site. The best defense to keeping files from being downloaded is to store them outside the application root, especially things like encryption keys. I believe Scott Guthrie may have even mentioned in one of his replies that only files that reside under the application root were vulnerable to being downloaded. This is also the reason that many of us follow the best practice of storing the root folder on a volume other than the system volume. That practive, along with encryptiing connection strings and storing passwords in a separate encrypted XML file have kept us safe from many vulnerabilities over the years.
For this vulnerability, we aren't doing anything with changing web.config files. Instead we are simply notifying on event ID 3005 by monitoring our event logs and then automatically blocking the remote IP. This prevents the attack from being completed in the first place. Making all of the changes suggested by Scott will not protect anything since the attack would still only need to check the suorce of the returned content to see if it is a YSOD versus a 404. you could probably also accomplish blocking the remote IP from completing the attack using a layer 4 gateway. This is certainly the best way to ensure protection from this vulnerability if you manage thousands of customs sites.
davidpenton
Member
595 Points
100 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 04:45 PM|LINK
By "default" files outside of an application root do not have the same permissions. If your website is configured to view/parse/open/etc files that are outside of the web root, then you "do" have it configured to at least read outside of the web root. I am glad that you have been safe over the years. I hope you continue to be safe.
That is your choice to not modify your web.config files. Given that the only publicly available "fix" to this is the adjustment of the customErrors element in the web.config, if you feel that you are safe with your solution, then good for you. I will continue to push for people to update their web.config files under the guidance of Microsoft/ASP.NET team and through my additional guidance.
Thanks,
David
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
Garf.Leonard
Member
6 Points
3 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 08:42 PM|LINK
Then use the command aspnet_regiis -pr "[KeyName]" "NT Authority\Network Service" to remove read access to that key. It's the web.config that is compromised, not the web server.EDIT: nevermind, you do need read access to decrypt.
Pro Tip: make sure you are using the right AppPool identity when executing the aspnet_regiis commands.