Als gebruikers via een proxy werken, lopen ze dan ook gevaar? Ja ik denk dat de exploit erop kan komen. Maar kunnen "aanvallers" dan via de proxy op de client komen?

Proxy of niet maakt niets uit, tenzij daar nog wat IDS functionaliteit in zit.

Een proxy houdt op zich dit soort dingen niet tegen, maar je kunt in je proxy wel rules instellen die dit soort problemen kunnen beperken.
Als je bijvoorbeeld het downloaden van .exe bestanden verbiedt voor je gebruikers dan zullen veel exploits niet meer werken.
Uiteraard kan daar omheen gewerkt worden, bijvoorbeeld door de exploit te hosten op een https site, maar die moeite wordt veelal niet genomen.

Of de exploit ook werkt via een proxy dat is een andere verhaal. Op zich is het triviaal om dit te regelen, kwestie van de juiste library calls gebruiken voor je uitgaande verbindingen naar de C&C. Maar er zullen vast wel exploits zijn die dit niet gedaan hebben en dus niet werken in combinatie met een proxy.
Ook kun je in je proxy beperkende rules instellen die de kans groter maken dat een exploit er niet doorheen komt, bijvoorbeeld door het beperken van de portnummers die geCONNECT kunnen worden tot 443 en evt 1935.
Dat betekent dan dat een C&C server die een willekeurig poortnummer gebruikt niet meer geCONNECT kan worden via de proxy.
Je kunt dit ook doen voor GET/POST/etc requests maar dan heb je meer impact op de dagelijkse werkzaamheden omdat een enkele website nog wel eens een rare poort gebruikt voor een of ander onderdeel van de pagina.

(we hebben op het werk ook een proxy, en een heel enkele keer kom je amateuristisch geprogrammeerde applicaties tegen die het niet doen omdat ze geen proxy supporten, maar meestal is het totaal geen probleem en worden de proxy instellingen van internet explorer automatisch overgenomen door de applicatie. deze applicaties doen het dus "goed", en dat kan een exploit ook doen)

Als je op een bedrijfsnetwerk dit soort dingen wilt beperken denk dan meer in de richting van het beperken van de rechten van de gebruiker (gebruiker is geen admin) en het instellen van een Software Restriction Policy (of Applocker heet dag geloof ik tegenwoordig) die verbiedt dat programma's worden uitgevoerd die in de gebruiker zijn profieldirectory staan.
(waar de TEMP directory en de Tijdelijke Internet bestanden directory een onderdeel van zijn).
Hiermee voorkom je dat de gedownloade exploit wordt uitgevoerd. En omdat de meeste exploits draaien met de rechten van de gebruiker beperk je de schade als die een User is en geen Administrator.

De gebruiker verbind na de exploit zelf naar de "hacker" toe. Dus als de de betreffende poort die de "hacker" gebruikt als toegestane poort gedefineerd heeft staan zal de exploit gewoon werken.

Ik heb het zelf getest door de proxy van mijn werk heen (isa) en dat gaat gewoon goed. Ik heb het ook met door mij beheerde Websense proxy's getest en deze blokkeren zelf realtime de exploit. Het hangt dus vooral af van de implementatie van de proxy...

Hmmm,
Ik zie dat op de Fix it pagina de Enable en Disable Fix it mogelijk zijn omgewisseld.
http://support.microsoft.com/kb/2757760

Normaal gesproken heeft de Enable Fix it het laagste volgnummer (evenals de bijbehorende link) en de Disable Fix it het hoogste volgnummer, maar ik zie dat dat nu omgekeerd is.

Zo'n omwisseling van de Enable en Disable Fix it daarvan was sprake bij een eerdere Fix it. In eerste instantie bij alle taalweergaven, en later was het gecorrigeerd op de Engelstalige pagina maar nog niet op de anderstalige pagina's. Ik heb Microsoft daar toen nog nadrukkelijk op gewezen.

Ik heb de huidige Fix it niet getest, zoals Beveiligingsonderzoeker H.D. Moore, maar zijn/haar bevindingen samen met de weergave op de Fix it pagina doen me vermoeden dat er mogelijk opnieuw sprake zou kunnen zijn van omwisseling van de Enable en Disable Fix it.


Aanvulling 21-9:

Nee, er was in dit geval nu blijkbaar toch GEEN sprake van een omwisseling.

Ook in de "More information on Security Advisory 2757760's Fix It"
http://blogs.technet.com/b/srd/archive/2012/09/19/more-information-on-security-advisory-2757760-s-fix-it.aspx
heeft de url voor de Enable Fix it het hoogste 'volgnummer' en die voor de de Disable Fix it het laagste, zo zie ik nu.

Dat zal dan wel kloppen, maar logisch is het niet, en gezien een eerdere fout met een Fix it oplossing waarbij de Enable en Disable wél omgewisseld waren, schept dit voor alerte en logisch ingestelde gebruikers ten minste verwarring!

Tijd om IE vooorgoed vaarwel te zeggen.Microsoft wil of kan haar browser niet veilig krijgen.Nu komen ze zometeen met IE 10 maar die is alleen voor Windows 8.Windows Vista en Windows 7 klanten staan dus in de kou.

Nee, er was in dit geval nu blijkbaar toch GEEN sprake van een omwisseling.

Ook in de "More information on Security Advisory 2757760's Fix It"
http://blogs.technet.com/b/srd/archive/2012/09/19/more-information-on-security-advisory-2757760-s-fix-it.aspx
heeft de url voor de Enable Fix it het hoogste 'volgnummer' en die voor de de Disable Fix it het laagste, zo zie ik nu.

Dat zal dan wel kloppen, maar logisch is het niet, en gezien een eerdere fout met een Fix it oplossing waarbij de Enable en Disable wél omgewisseld waren, schept dit voor alerte en logisch ingestelde gebruikers ten minste verwarring!