Qual è il rischio di modificare le autorizzazioni della chiave del registro di EventLog di sicurezza nelle operazioni IT?

6

Sfondo

Molti sviluppatori stanno riducendo inutilmente la sicurezza del registro eventi o richiedono l'esecuzione di applicazioni in modalità amministratore solo per poter utilizzare il registro eventi con questo codice C # o VB:

  EventLog.[WriteEntry][1]("MyBadApp", "This will cause an exception for ASP.NET and non admins", EventLogEntryType.Error, 10);

.. e quindi non creare un programma di installazione che crei le chiavi di registro necessarie per "MyBadApp"

Ulteriori informazioni

Se viene eseguito in Network Service , ASP.NET, WCF, un account di servizio e sta utilizzando un account non amministratore, si verificherà la seguente eccezione ... ma chissà se o dove verrà registrato (Incollare per il bene di Google)

System.Security.SecurityException: The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.
   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
   at System.Diagnostics.EventLog.SourceExists(String source, String machineName)
   at System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, String currentMachineName)
   at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID)
   at **YOUR.CUSTOM.BROKEN.CODE.HERE(ResolvedMessageEventSource source, QueuedMessageEventArgs e) in c:\test2\YourProjectHere\Class1.cs:line 116**

 ----  SNIP Possibly more stuff here --
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
The Zone of the assembly that failed was:
MyComputer

Microsoft è a conoscenza di questo problema, ma è in base alla progettazione per un accesso EventLog rapido e sporco. Ogni volta che viene chiamato WriteEntry , il sistema enumera il registro e cerca "Sourcename" l'applicazione specificata . Se non esiste, verrà creato.

Il problema è che durante l'enumerazione, il registro di sicurezza viene colpito e viene generata un'eccezione. Gli sviluppatori che non creano un programma di installazione o che altrimenti creano una chiave di registro per "MyBadApp" ricadranno nella creazione di eventi dinamici vedranno questo problema.

Questo è di progettazione e influenza WriteEntry e meno frequentemente WriteEvent (Gli sviluppatori WriteEvent di solito creano un programma di installazione)

Soluzione

Ci sono 3 soluzioni di cui sono a conoscenza:

  1. Rendi l'applicazione eseguita come amministratore (non valido)

  2. Modifica le autorizzazioni sulle chiavi di registro

  3. Creare un programma di installazione che renda la chiave di registro per l'applicazione (soluzione migliore)

Domanda

Qual è la cosa peggiore che può accadere per un'applicazione che modifica le autorizzazioni della chiave del Registro di sicurezza?

  • Può leggere il registro degli eventi di sicurezza?

  • Può modificare o modificare le voci del registro eventi di sicurezza?

  • Può spoofare eventi di sicurezza che non sono propri?

  • Può portare a un tentativo?

posta random65537 09.06.2012 - 00:58
fonte

1 risposta

3

NON MODIFICARE I PERMESSI SUL REGISTRO EVENTI DI SICUREZZA.

Se si modificano le autorizzazioni su di esso, qualsiasi applicazione in esecuzione come utente con autorizzazioni può leggerla e possibilmente scrivere su di essa se gli si sono concesse dette autorizzazioni. Se ricordo che la chiave del Registro di sistema utilizza un formato SDDL, è molto facile da configurare in modo errato.

Non puoi modificare le voci con permessi di lettura o scrittura, a meno che tu non abbia accesso al file di log degli eventi sottostante, ma è bloccato dal sistema.

Sì, può falsificare gli eventi di sicurezza.

Assolutamente può portare a un DoS se il log è impostato per causare un panico del kernel una volta colpito è la sua dimensione massima.

In ogni caso, non dovresti modificare direttamente la chiave di registro. Dovrebbe essere fatto tramite WMI o tramite la riga di comando con wevtutil.

Un programma di installazione (utente amministratore) deve creare la sorgente del registro prima dell'esecuzione dell'applicazione, oppure l'applicazione deve scaricare i suoi eventi in un'origine predefinita. È molto semplice controllare se esiste la fonte:

if (EventLog.SourceExists("YourSource")) { /* do your stuff */ }

Puoi anche creare facilmente la fonte chiamando questo:

EventLog.CreateEventSource("YourSource", "YourLogName");
    
risposta data 11.06.2012 - 20:26
fonte

Leggi altre domande sui tag