Se dovessi dimostrare un'architettura .NET Remoting vulnerabilità con un attacco pratico, quale sceglieresti?
Ho letto J. Il white paper di Forshaw su Breaking .NET Through Serialization (PDF) , google a fondo, e ora voglio implementare un exploit di lavoro di un servizio .NET Remoting. Non importa dove è ospitato il servizio. Può essere ASP, IIS, servizio di Windows o qualsiasi altra cosa.
Attacchi DoS - Data la natura trasversale della tecnologia di questi framework (essi C # -VB-C ...) in genere sono difficili da proteggere con le "porte" della connessione. Quindi se riesci a enumerare e trovare i punti di connessione puoi spesso inondarli o semplicemente tenerli occupati e creare un attacco DoS affamando la fine "ricevente" del framework. In genere non è difficile da fare e, a meno che un sacco di cura sia stato inserito nell'architettura e assicurato correttamente, allora questo è un frutto a basso impatto.
Attacchi per carenza di risorse:
a. Attacco di risorse proxy: in genere, dati gli schemi di schemi proxy implementati da questi framework, in genere è necessario un proxy approssimativo che non viene distrutto esplicitamente quando le risorse vengono impostate e disattivate. Ciò consente ai modi in cui un utente malintenzionato può creare modalità per far esplodere le risorse proxy creando scenari di fame.
b. Attacchi alle risorse fisiche - I meccanismi di serializzazione utilizzati per gonfiare / sgonfiare gli oggetti possono in diversi punti creare attacchi alle risorse fisiche. È possibile creare oggetti-bombe: oggetti di grandi dimensioni che consumano risorse che si arrestano in modo estensivo o che affamano il sistema; o nel caso della serializzazione xml ricorsiva è possibile creare sia il consumo di risorse del processore e della memoria con l'elaborazione xml che lega il sistema.
a. Mutazione: qui si modifica il codice o gli oggetti originali, ma si inserisce il nuovo codice. Ogni lingua ha i suoi modi e le sue guardie da superare, ma generalmente fattibili.
b. Collateral - Qui è dove si muta o si inietta il codice in lingue secondarie, come ad esempio iniettare nuove SQL nelle interazioni di database o spingere nuovi Javascript negli scenari web.