Monthly Archives: June 2014

WEES KEYLOGGERS TE SLIM AF MET KEYSCRAMBLER!

OMERTA INFORMATION SECURITY – Rotterdam 4 Juni 2014

cropped-logo.png

 

 

 

 

 

Privacygevoelige gegevens invoeren op je pc houdt altijd wel risico in. Er kan een keylogger op de loer liggen. Met Keyscrambler blijf je die een stap voor.

Data invoeren houdt altijd wel een zeker risico in. Immers, je weet nooit helemaal zeker dat je systeem niet geïnfecteerd is door een of andere keylogger die heimelijk al je toetsaanslagen vastlegt en naar de maker of verspreider doorstuurt. Keyscrambler verhindert dat door alle toetsaanslagen te versleutelen.

Voor alle duidelijkheid: de gratis versie van Keyscrambler werkt alleen in je browser. Het programma ondersteunt naar eigen zeggen maar liefst 33 verschillende browsers.

Wanneer de tool is geactiveerd en je start een browser op, wordt standaard alles wat je intikt versleuteld, ook URL’s of trefwoorden in de adres- of zoekbalk. Dat gebeurt met behulp van zowel symmetrische (Blowfish 128-bit) als asymmetrische (RSA 1024-bit) encryptie-algoritmes.

Deze versleuteling kan je ‘afleiden’ uit een klein, verplaatsbaar balkje waar je de ingetikte toetsen scrambled ziet passeren – een gimmick die je trouwens kunt uitschakelen. Deze versleuteling zou volgens de makers op het niveau van de toetsenborddriver in de kernel gebeuren, wat zou moeten volstaan om de meest hardnekkige keyloggers te slim af te zijn. Houd er wel rekening mee dat alleen wat je zelf intikt in je browser(s) wordt versleuteld, en dus niet (noodzakelijk de inhoud die de webservers retourneren)

Download

dit artikel verscheen eerder op zdnet.be

KOM ERACHTER WELKE WINDOWS PROGRAMMA’S JOUW WEBCAM GEBRUIKEN!

OMERTA INFORMATION SECURITY -Rotterdam 3 Juni 2014

We zijn allemaal ondertussen op de hoogte dat je jouw webcam maar beter kunt afplakken om je privacy te bewaren. Maar hoe kom je er überhaupt achter dat jouw webcam wordt misbruikt?

Hieronder een mooie tool die je kan helpen :

Find Out What Windows Program Is Using Your Webcam

Find Out What Windows Program Is Using Your Webcam

If you’re worried you might have some malware using your webcam to spy on you, MakeUseOf has a list of steps you can follow to find out which Windows program is the culprit.

To do this you’ll need Process Explorer, the awesome Windows Sysinternal tool developed by Mark Russinovich for IT work. You can download the installer here if you like, or you can just run the application from their server (which is faster).

With Process Explorer running, follow these steps:

  1. Figure out what your camera’s object name is by finding it in Device Manager. For Windows 7: search “Device Manager” in the start menu. For Windows 8.1: search the same thing in the Charms bar.
  2. Once you locate it in the Device Manager, double-click and go to the “Details” tab. Open the property drop-down and select “Physical device object name”, then right-click to copy the name.
  3. Return to the Process Explorer, or get it started if you haven’t yet. Then hit Ctrl+F and paste the camera’s object name into the search field and click “Search.” You should see whatever processes are currently using your webcam.

If the program using your webcam is something you recognized, there’s no need to worry (but you may need to quit it if you don’t want it running)! If you don’t recognize the program, right-click it in Process Explorer and select “Kill Process”, then uninstall it from your machine. After the program has been removed, run a full-system virus scan to ensure your machine is safe to use again.

Oh ja en hier nog een link naar een PDF file van een onderzoek dat 2 studenten ooit deden naar het gebruik van de MAC webcam.

OPEN REDIRECTORS EN MISBRUIK VAN ACCESS TOKENS

OMERTA INFORMATION SECURITY – Rotterdam 3 Juni 2014

Hoe bescherm jij jezelf tegen slechte implementaties van open redirectors en Access Tokens?

In het stuk dat je hier kunt lezen vindt je een aantal zaken die je gaan helpen de problematiek te begrijpen en maatregelen te nemen. Echter……….

Eigenlijk is de vraag hier hoe voorkom je nu dat je slachtoffer wordt van slecht geïmplementeerde redirections en misbruik van je gegevens van bijvoorbeeld een facebook of Google + account ?

Simpel gewoon niet meer klikken op “LOG IN met Facebook ” of “LOGIN met Google+” maak gewoon een nieuw account aan. Je gebruikte immers al een password SAFE toch?

 

OpenID_Auth_Flow

 

 

 

 

 

 

 

 

 

 

 

 

 

 

En nog wat uitleg :

Open Redirectors


   The authorization server, authorization endpoint, and client
   redirection endpoint can be improperly configured and operate as open
   redirectors.  An open redirector is an endpoint using a parameter to
   automatically redirect a user-agent to the location specified by the
   parameter value without any validation.

   Open redirectors can be used in phishing attacks, or by an attacker
   to get end-users to visit malicious sites by using the URI authority
   component of a familiar and trusted destination.  In addition, if the
   authorization server allows the client to register only part of the
   redirection URI, an attacker can use an open redirector operated by



Hardt                        Standards Track                   [Page 60]

RFC 6749                        OAuth 2.0                   October 2012


   the client to construct a redirection URI that will pass the
   authorization server validation but will send the authorization code
   or access token to an endpoint under the control of the attacker.

10.16. Misuse of Access Token to Impersonate Resource Owner in Implicit

Flow


   For public clients using implicit flows, this specification does not
   provide any method for the client to determine what client an access
   token was issued to.

   A resource owner may willingly delegate access to a resource by
   granting an access token to an attacker's malicious client.  This may
   be due to phishing or some other pretext.  An attacker may also steal
   a token via some other mechanism.  An attacker may then attempt to
   impersonate the resource owner by providing the access token to a
   legitimate public client.

   In the implicit flow (response_type=token), the attacker can easily
   switch the token in the response from the authorization server,
   replacing the real access token with the one previously issued to the
   attacker.

   Servers communicating with native applications that rely on being
   passed an access token in the back channel to identify the user of
   the client may be similarly compromised by an attacker creating a
   compromised application that can inject arbitrary stolen access
   tokens.

   Any public client that makes the assumption that only the resource
   owner can present it with a valid access token for the resource is
   vulnerable to this type of attack.

   This type of attack may expose information about the resource owner
   at the legitimate client to the attacker (malicious client).  This
   will also allow the attacker to perform operations at the legitimate
   client with the same permissions as the resource owner who originally
   granted the access token or authorization code.

   Authenticating resource owners to clients is out of scope for this
   specification.  Any specification that uses the authorization process
   as a form of delegated end-user authentication to the client (e.g.,
   third-party sign-in service) MUST NOT use the implicit flow without
   additional security mechanisms that would enable the client to
   determine if the access token was issued for its use (e.g., audience-
   restricting the access token).