O ScottGu στο προσωπικό του blog, αναφέρει για ένα σοβαρό πρόβλημα (security threat-security vulnerability ) σχετικά με το ASP.Net.

Να σημειώσω ότι το πρόβλημα ασφάλειας αφορά όλες τις εκδόσεις του ASP.Net.

Ένας κακόβουλος χρήστης μπορεί , εκμεταλλευόμενος την αδυναμία αυτή να κατεβάσει αρχεία ( συμπεριλαμβανομένου και του web.config ) από ένα ASP.Net site.

Είναι αναγκαίο άμεσα να εφαρμόσετε τα workarounds που αναφέρονται στο ίδιο post για να προστατέψετε τις asp.net εφαρμογές σας.

Το workaround για τις εφαρμογές που έχουν υλοποιηθεί σε asp.net 1 έως το version 3.0 είναι πιο απλό. Για τα asp.net sites που είναι σε υλοποιημένα σε asp.net 3.5 SP1 και 4, υπάρχει μια
διαφορετική προσέγγιση για να λύσουμε το θέμα.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Δουλειές που μας άνοιξες νυχτιάτικα!! Προς Θεού, δε φταις εσύ! Το προηγούμενο είναι σχήμα λόγου. Μία ερώτηση μόνο...

Αν σε έναν server ένα site δεν εφαρμόσει τις οδηγίες, αυτό δε βάζει σε κίνδυνο και τα υπόλοιπα ακόμα κι αν έχουν υλοποιήσει το workaround; Εμένα, τουλάχιστον, έτσι μου φαίνεται. Αν ο attacker αποκρυπτογραφήσει τα μηνύματα από αυτό το ένα site γιατί τα υπόλοιπα να είναι ασφαλή;

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Τώρα φίλε Μάρκο τι να σου πω... και εγώ διαβάζω άλλα forums-blogs και προσπαθώ να ενημερωθώ και να καταλάβω την έκταση του προβλήματος.

Το vulnerability αυτό επηρεάζει τα sites υλοποιημένα και σε ASP.NET MVC και τα Sharepoint sites

Έχω αρχίσει ήδη να εφαρμόζω το workaround... 

Δες και αυτό εδώ

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Ήταν το πρώτο που είδα όταν διάβασα το post του Scott Guthrie. Αυτό το άρθρο είναι πιο ενδιαφέρον. Το ίδιο ενδιαφέρουσα είναι και η ημερομηνία του post (13/9/2010). Νομίζω ότι και το video θα το βρεις ενδιαφέρον. Υπάρχουν πολλοί εκεί έξω που παίζουν με το POET; Μπορούμε να κοιμόμαστε ανήσυχοι...

Και για να μην το ξεχάσω. Απάντηση από του Scott Gutrhie σε σχόλιο για το ίδιο θέμα:

@TheJet,

>>>>>>>>> How does this allow exposure of web.config?  This seems to enable decrypting of ViewState only, is there another related vulnerability that also allows the information disclosure?  Is there a whitepaper that details the attack for a better explanation of what's going on?

The attack that was shown in the public relies on a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application).  We will obviously release a patch for this - until then the above workaround closes the attack vector.

Hope this helps,

Scott

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Μάρκο πολύ ενδιαφέροντα είναι αυτά που έγραψες στο post σου. Αυτά κοιτάω. έχω ενημερώσει ήδη την εταιρεία που κάνω hosting. Το κοιτάνε και αυτοί.

Και εγώ κοιτάω τα σχόλια των επισκεπτών στο post του Scott για να δω ακριβώς τι συμβαίνει.

Μου αρέσει που ήθελα να κοιμηθώ νωρίς σήμερα.....:)

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Μπορείς να κουλάρεις λίγο. Αναπαράγω το tweet του Juliano Rizzo (13/9):

POET downloaded 500 times in the last hour. Dear users: 1.0 doesn't automatically work against ASP.NET Wait!!

Απ' ό,τι βλέπω, η έκδοση που υπάρχει για download αυτή τη στιμή εξακολουθεί να είναι η 1.0.

Άντε, και καλό μας ξενύχτι... Πάει και η Κυριακή. ΦΤΟΥ!!

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Μάρκο για δες σε παρακαλώ αυτό το post μήπως σε βοηθήσει σε αυτό που με ρώτησες παραπάνω.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Ρίχνοντας μια ματιά σε κάποια άλλα blog posts , και στο ειδικό forum που έχει συσταθεί για αυτό το συγκεκριμένο security threat περιμένουμε άμεσα το release patch το οποίο θα λύνει το πρόβλημα στην ρίζα του χωρίς να χρειάζεται το workaround.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Εναλλακτικά, μπορείς να χρησιμοποιήσεις και το Hyperguard (τουλάχιστον έτσι γράφουν...). Ρίξε μια ματιά και στο εταιρικό site.

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Το προώθησα στην hosting company που κάνω host τα sites και τους ρωτώ για το firewall software που έχουνε. Έχω τρέξει τα workarounds και όπου μπορώ κάνω encrypt τα <connectionStrings> και <machineKey> sections του web.config.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Καλησπέρα σας , 

---

Ensignic.com

Σύμφωνα με το blog post του scott , Ναι κινδυνεύεις.

Αντιγράφω από το blog post του Scott

To customError section πρέπει να είναι σαν και αυτό.

<configuration>        

   <system.web>

      <customErrors mode="On" defaultRedirect="~/error.html" />

   </system.web>        

</configuration

"Notes: The important things to note above is that customErrors is set to “on”, and that all errors are handled by the defaultRedirect error page.  There are not any per-status code error pages defined – which means that there are no <error> sub-elements within the <customErrors> section.  This avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure."

όλα τα πιθανά errors πρέπει να γίνονται Handle από την error.html page και καμία άλλη.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Ευχαριστώ, παρατήρησα ότι στο machine.config έχω ορίσει <deployment retail="true" />. Αυτό με προστατεύει περισσότερο;

---

Ensignic.com

Αυτό το οποίο κάνει το <deployment retail="true" />

για το website είναι να θέσει στο web.config τα

• debug set to false
• disable page output tracing
  
• custom error pages to be shown to the remote users instead of detailed error messages or the stack trace

ρίξε μια ματιά εδώ

το να έχεις όλα τα web sites στον IIS σε release mode δεν αλλάζει κάτι. Το πρόβλημα παραμένει. Επιμένω στο workaround που δημοσίευσε ο Scott.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Δεν ξέρω αν πέρασε ήδη (με τόσα links έχασα τη μπάλα), αλλά ο Guthrie δημοσίευσε ένα updated FAQ για το vulnerability: http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

---

Σωτήρης Φιλιππίδης

DotSee Web Services