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.
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.
Assuming you mean to remove the access from the AppPool's set identity, not sure that is favorable to remove the worker process's identity from the decryption needs.
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.
Ok, so if you are using the default provider (RsaProtectedConfigurationProvider) and the default container (NetFrameworkConfigurationKey)
which is defined in the machine.config, how could it be possible to pull that key and decrypt? Yes, I am questioning whether indeed the attacker has at least the same rights as the AppPool of the exploited app. He would have to somehow execute code that would
give him the RSA key, no? Doesn't the POET vs DNN video show them guessing the machine key from the padding oracle, then using that to gain access to files on the server?
DNN does somethin very risky - it stores the machine key unencrypted in the web.config, so the POET demo shows that key being taken from the web.config and not the machine.config, which is proteted because it is outside the application root.
Is there available a script or batch file that I can run from the command line that would
indicate whether a given web site, web page or web app is in some way based on or using
ASP.NET. I just want to find out whether my bank, credit card, etc access is safe, and I can
say from experience, trying to get any information to or from the IT department of any financial
organisation is as good as impossible. So is there a smart person amongst you that can quickly
write up such a script and make it available, so that I can decide whether or not to use a
particular website for the time being.
Yes, I am naive, because only naive people can ask understandable questions.
(If I can't see as far as anyone else here, it's only because I am standing on the shoulder of a
dwarf, and the giants standing on my shoulders don't help either.)
Your information is safe at a financial institution because they use layers of safety including firewall and application layer gateways that inpect the network packets going in and out of their networks to ensure this attack can't even reach the web server.
A script is not necessary, and if you actually had one, you'd probably end up being arrested for trying to hack your financial institution. If you want to know if your bank is using ASP.NET, simply look for .aspx or .asmx at the end of the URL. Tomcat and
Java will generally have something like .jsp or .do at the end of the URL.
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
Like most people, you are falsely assuming that Microsoft's recommendation is actually a "fix". It does nothing to protect you from the vulnerability, it only slows down the currently published POET attack. Once that is modified to inspect the response
to look for the YSOD, the attack will work again. Force a 500 error on your site and compare it to a 404 and see if they are different and then decide if you are protected by Microsoft's recommendation. The best protection is to detect the attack by monitoring
for event ID 3005 and blocking the IP address at your default gateway.
DNN does somethin very risky - it stores the machine key unencrypted in the web.config, so the POET demo shows that key being taken from the web.config and not the machine.config, which is proteted because it is outside the application root.
I take issue with that, I would say it is best practice in general is to have seperate machine key for each application/site.
If you just have the machinekey in the machine.config then if that is broken then all sites are vulernable.
I would say it is more risky to have one machine key for hundreds of sites.
The biggest problem here is ASP.NET has access to display the web.config to the world and override the settings that IIS tells it to. There any idiot dev can make a box vulnerable.
Like most people, you are falsely assuming that Microsoft's recommendation is actually a "fix". It does nothing to protect you from the vulnerability, it only slows down the currently published POET attack. Once that is modified to inspect the response
to look for the YSOD, the attack will work again. Force a 500 error on your site and compare it to a 404 and see if they are different and then decide if you are protected by Microsoft's recommendation. The best protection is to detect the attack by monitoring
for event ID 3005 and blocking the IP address at your default gateway.
Have you even read the workaround?!?!
What the workaround forces all error pages to goto a *single custom error page* not the default YSOD page. So if the pages and http response are exactly the same (all http traffic is the same if you really wanted to check) then I am confused about what you/the
hacker is comparing it too?!?
Also your solution doesn't help really for a decent attacker. A decent attacker will use multiple machine/bot net to try and attack your site so a static IP block is pointless. And the is no non-complex automated way that you can block the IP address based
on multiple event ID entries. A) some can be valid padding errors and b) once an attacker has got the key then blocking the IP address will make no difference at all.
No Joshua, I am not "assuming" this fixes the issue forever. It is a stop gap until the ASP.NET team releases the proper fix. "It does nothing to protect you" - that is a bit draconian, don't you think? Let's be realistic here, it is a preventative measure.
That is why
I posted some other information on securing other parts of your site.
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
Ok, so if you are using the default provider (RsaProtectedConfigurationProvider)
and the default container (NetFrameworkConfigurationKey) which is defined in the machine.config, how could it be possible to pull that key and decrypt? Yes, I am questioning whether indeed the attacker has at least the same rights as the AppPool of the exploited
app. He would have to somehow execute code that would give him the RSA key, no? Doesn't the POET vs DNN video show them guessing the machine key from the padding oracle, then using that to gain access to files on the server?
That is possibly a scenario that is "safer" - I don't think anyone outside of the Microsoft ASP.NET team can speak to whether that is a truly safe configuration. According to the ASP.NET team, it is still a high recommendation to encrypt those sections in
your config files, so I would take that advice and heed it.
But, I would still caution/stress that the only part of the exploit that we know about is that information can be read out of your web site files. I for one would not want to take the chance that there is more that we don't know about. The way that this
exploit was handled by the attackers was in the most unprofessional way. I would rather take as many other precautions as possible in the meantime.
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
None
0 Points
2 Posts
Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 11:26 AM|SamJonesIII|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!!
All-Star
47060 Points
5884 Posts
MVP
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 04:58 PM|HeartattacK|LINK
True.
Using the workaround on Gu's blog should keep you safe. A permanent fix is being developed and should be available soon.
twitter: @ashic
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 19, 2010 07:37 PM|davidpenton|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"
None
0 Points
2 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 05:37 AM|darkthread|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.
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 05:50 AM|davidpenton|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"
Member
10 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 04:17 PM|joshuaperry|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.
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 20, 2010 04:23 PM|davidpenton|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"
Member
10 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 12:32 PM|joshuaperry|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.
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 12:45 PM|davidpenton|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"
None
0 Points
3 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 04:42 PM|Garf.Leonard|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.
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 04:51 PM|davidpenton|LINK
Assuming you mean to remove the access from the AppPool's set identity, not sure that is favorable to remove the worker process's identity from the decryption needs.
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
None
0 Points
3 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 05:57 PM|Garf.Leonard|LINK
Ok, so if you are using the default provider (RsaProtectedConfigurationProvider) and the default container (NetFrameworkConfigurationKey) which is defined in the machine.config, how could it be possible to pull that key and decrypt? Yes, I am questioning whether indeed the attacker has at least the same rights as the AppPool of the exploited app. He would have to somehow execute code that would give him the RSA key, no? Doesn't the POET vs DNN video show them guessing the machine key from the padding oracle, then using that to gain access to files on the server?
None
0 Points
1 Post
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 22, 2010 06:43 PM|OOGOOBAAA|LINK
Is there available a script or batch file that I can run from the command line that would
indicate whether a given web site, web page or web app is in some way based on or using
ASP.NET. I just want to find out whether my bank, credit card, etc access is safe, and I can
say from experience, trying to get any information to or from the IT department of any financial
organisation is as good as impossible. So is there a smart person amongst you that can quickly
write up such a script and make it available, so that I can decide whether or not to use a
particular website for the time being.
Yes, I am naive, because only naive people can ask understandable questions.
(If I can't see as far as anyone else here, it's only because I am standing on the shoulder of a
dwarf, and the giants standing on my shoulders don't help either.)
ASP.net Vulnerability - how can I find out which website uses it ?
Member
10 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 08:06 AM|joshuaperry|LINK
DNN does somethin very risky - it stores the machine key unencrypted in the web.config, so the POET demo shows that key being taken from the web.config and not the machine.config, which is proteted because it is outside the application root.
Member
10 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 08:12 AM|joshuaperry|LINK
Your information is safe at a financial institution because they use layers of safety including firewall and application layer gateways that inpect the network packets going in and out of their networks to ensure this attack can't even reach the web server. A script is not necessary, and if you actually had one, you'd probably end up being arrested for trying to hack your financial institution. If you want to know if your bank is using ASP.NET, simply look for .aspx or .asmx at the end of the URL. Tomcat and Java will generally have something like .jsp or .do at the end of the URL.
Member
10 Points
7 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 08:17 AM|joshuaperry|LINK
Like most people, you are falsely assuming that Microsoft's recommendation is actually a "fix". It does nothing to protect you from the vulnerability, it only slows down the currently published POET attack. Once that is modified to inspect the response to look for the YSOD, the attack will work again. Force a 500 error on your site and compare it to a 404 and see if they are different and then decide if you are protected by Microsoft's recommendation. The best protection is to detect the attack by monitoring for event ID 3005 and blocking the IP address at your default gateway.
Member
1 Points
11 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 09:23 AM|Abshr|LINK
How do you do this "monitoring for event ID 3005 and blocking the IP address at your default gateway"
Where can i monitor the evenID?
Thanks
Member
120 Points
83 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 09:44 AM|Rovastar|LINK
I take issue with that, I would say it is best practice in general is to have seperate machine key for each application/site.
If you just have the machinekey in the machine.config then if that is broken then all sites are vulernable.
I would say it is more risky to have one machine key for hundreds of sites.
The biggest problem here is ASP.NET has access to display the web.config to the world and override the settings that IIS tells it to. There any idiot dev can make a box vulnerable.
Member
120 Points
83 Posts
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 09:49 AM|Rovastar|LINK
Have you even read the workaround?!?!
What the workaround forces all error pages to goto a *single custom error page* not the default YSOD page. So if the pages and http response are exactly the same (all http traffic is the same if you really wanted to check) then I am confused about what you/the hacker is comparing it too?!?
Also your solution doesn't help really for a decent attacker. A decent attacker will use multiple machine/bot net to try and attack your site so a static IP block is pointless. And the is no non-complex automated way that you can block the IP address based on multiple event ID entries. A) some can be valid padding errors and b) once an attacker has got the key then blocking the IP address will make no difference at all.
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 10:25 AM|davidpenton|LINK
No Joshua, I am not "assuming" this fixes the issue forever. It is a stop gap until the ASP.NET team releases the proper fix. "It does nothing to protect you" - that is a bit draconian, don't you think? Let's be realistic here, it is a preventative measure. That is why I posted some other information on securing other parts of your site.
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
Member
340 Points
91 Posts
ASPInsiders
Re: Question: An encrypted web.config is not actually useful: True or False?
Sep 23, 2010 11:08 AM|davidpenton|LINK
That is possibly a scenario that is "safer" - I don't think anyone outside of the Microsoft ASP.NET team can speak to whether that is a truly safe configuration. According to the ASP.NET team, it is still a high recommendation to encrypt those sections in your config files, so I would take that advice and heed it.
But, I would still caution/stress that the only part of the exploit that we know about is that information can be read out of your web site files. I for one would not want to take the chance that there is more that we don't know about. The way that this exploit was handled by the attackers was in the most unprofessional way. I would rather take as many other precautions as possible in the meantime.
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"