Convalida di .NET Framework Assiemi

Question

Ho appena passato il nostro german VB.NET forums e c'era qualcosa di interessante che mi dava un po 'di mal di testa.

In realtà è possibile modificare gli assembly di .NET Framework che utilizzano ReflexIL o qualche altro editor IL. L'unica cosa che devi ignorare è la firma Strong Name dell'assembly. Dopo aver modificato l'assembly IL, è necessario eseguire sn.exe -Vr [assemblyname] in modo da saltare la convalida del nome sicuro. Dopodiché è necessario cancellare le immagini native memorizzate nella cache. Basta passare attraverso la directory C:\Windows\assembly ed eliminare tutte le immagini relative all'assieme. Quindi riavviare. Una volta effettuato l'accesso, eseguire ngen install [assemblyname]. Ora vengono generate le immagini native nuove.

Questo funziona. Ho verificato questa procedura nel mio ambiente virtuale (Windows XP x86). Ora la cosa che mi preoccupa di più è che puoi facilmente aggirare i metodi .NET VerifyHash o VerifyData dello RSACryptoServiceProvider. Anche questo funziona davvero. Un mio amico e io testati potrebbero verificare questo problema (see screenshots). E 'stato abbastanza facile.

Per esempio, se mi piacerebbe creare un sistema di licenze costruito sulle classi di crittografia di .NET Framework, potrebbe essere aggirato a livello di sistema perogni applicazione .NET sul sistema utilizzando il framework. Inoltre, tutti possono registro e modificare l'input di functios che chiamo solo agganciando i metodi.

Ora la mia domanda è: Poiché questo può essere un problema enorme, come posso fare qualcosa al riguardo? Ovviamente un utente malintenzionato potrebbe semplicemente modificare l'applicazione, ma non sarebbe così male come fare questo a livello di sistema. Stavo pensando ad una convalida del checksum del framework, ma poiché ci sono molti aggiornamenti diversi per .NET Framework, questo sembra impossibile.

Eventuali soluzioni o suggerimenti? Microsoft si prende cura di questo problema in qualche modo?

Answer 1

Se un utente malintenzionato ha accesso amministrativo al computer (necessario per l'attacco che hai descritto), hai praticamente perso. Qualsiasi cosa tu potessi fare potrebbe essere aggirata dall'attaccante.

Per questo motivo, penso che sia completamente inutile cercare di difendersi da questo tipo di attacco. Se hai a che fare con computer non affidabili e potenzialmente compromessi, non puoi semplicemente fidarti di loro per fare qualcosa di sensibile e devi farlo sul tuo server, o qualcosa del genere.