The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,373 other followers

Archive for the ‘Security’ Category

kryo.se: iodine (IP-over-DNS, IPv4 over DNS tunnel)

Posted by jpluimers on 2018/05/18

iodine is a free (ISC licensed) tunnel application to forward IPv4 traffic through DNS servers (IP over DNS). Works on Linux, FreeBSD, NetBSD, OpenBSD and Mac OS X.

In light of

–jeroen

Posted in Power User, Security | Leave a Comment »

GitLeaks – Search Engine for exposed secrets on the web

Posted by jpluimers on 2018/05/03

via: [WayBack] Yet another reason to be very careful with what you put in version control: GitLeaks – Search Engine for exposed secrets on the web https://gitleaks.com/This is why I Code – Google+

[Archive.isGitLeaks – Search Engine for exposed secrets on the web

–jeroen

 

Posted in Development, Security, Software Development | Leave a Comment »

Client-Side Password Hashing – DelphiTools

Posted by jpluimers on 2018/05/03

Interesting thought on client-side password hashing: [Archive.isClient-Side Password Hashing – DelphiTools.

I’ve ambivalent feelings on it, especially since it will expose salt and other settings to the client.

On the other hand it tremendously helps when there are transparent proxies in between. Read the article for full details; here is just one quote below.

Maybe dual hashing would be in place: once at the client to prevent plain-text to go over MITM channels, and a second hash server side with different settings like salt to prevent brute force attacks.

I need to give this more thought.

The quote:

If you are using a regular Windows and a regular browser, access to HTTPS will go through the regular certificate chain, using regular certificate authority. You also benefit from extra security layers like Public Key Pinning.

But when a custom Root CA is installed, all that goes through the window: the custom Root CA allows the corporate proxies to issue “valid” certificates for any website (even google.com and the rest), and the public key pinning features are disabled:

How does key pinning interact with local proxies and filters?

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. 

A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

All the major browsers have a similar behavior… because it is required to allow transparent proxies. And transparent proxies are the means through which the legal logging requirements are fulfilled.

So besides introducing a major MITM opportunity, this also means that there are legally-required corporate logs somewhere of all that went through HTTPS… including plain text passwords, if you did not hash them on the client-side.

These logs will have varying degrees of security when in the corporate domain… and next to none if they are ever requested by the legal system for an investigation.

–jeroen

 

Posted in Algorithms, Design Patterns, Development, Hashing, Power User, Security, Software Development | Leave a Comment »

beep, patch and ed – The Isoblog.

Posted by jpluimers on 2018/04/11

So we are all doomed: on debian, beep was an issue leading into a CVE. The fix is an issue too, and also has a CVE.

Source: [WayBack] beep, patch and ed – The Isoblog.

Related:

–jeroen

Posted in *nix, *nix-tools, Debian, Linux, Power User, Security | Leave a Comment »

Urgent security advisory – MikroTik – upgrade to 6.41.3 if you can change your bridge implementation, ensure SMB and WWW are not WAN accessible

Posted by jpluimers on 2018/03/31

I both understand the [WayBack] Urgent security advisory – MikroTik and the users reluctant to upgrade: Mikrotik has a history of updates breaking existing behaviour and underdocumenting features and release notes.

The attack is over the www or www-ssl services which by default run on port 80 and 443. You can see on which networks they are bound using this example from the terminal:

> ip service print where name=www
Flags: X - disabled, I - invalid 
 #   NAME       PORT ADDRESS                                        CERTIFICATE   
 0   www          80 192.168.71.0/24                               
                     192.168.171.0/24                              
                     192.168.124.0/24
> ip service print where name=www-ssl
Flags: X - disabled, I - invalid 
 #   NAME       PORT ADDRESS                                        CERTIFICATE   
 0   www-ssl     443 192.168.71.0/24                               
                     192.168.171.0/24                              
                     192.168.124.0/24

Note that if your device was infected, not all upgrades will remove the infection on all machines (even though it is mentioned in the FAQ below!). This is one of the “underdocumenting” aspects I mentioned.

There is no way to officially check if your device is infected. If you suspect it is and cannot upgrade to 6.41.3 or more recent, then you need to use [WayBack] Manual:Netinstall – MikroTik Wiki to wipe clean your router and re-install.

Be careful which version you upgrade to:

Somewhere in the middle of page 2 of the above post [WayBack], this is slightly addressed:

1) Upgrade to 6.38.5 fixes the botnet scanner and removes it.
2) Upgrade to 6.41.3 fixes SMB vulnerability.

Later this morning further below on page 2 of the above post [WayBack] it was elaborated more:

I recommend that you re-read all the posts from “normis”. Seems that we are going into circles.

1) Winbox port is used only to find out that this is RouterOS powered device (Winbox is not affected by vulnerabilities that we know of);
2) WWW service (“/ip service”) is used in order to “hack” your router if Firewall did not drop connections to this port (affected service was Webfig which by default is running on port 80, but you can change port under “/ip service” menu and then this other port must be protected). For example, “/ip firewall filter add chain=input action=drop in-interface=WAN connection-state=new”;
3) Issue with SMB is completely another thing but the same rules apply. If device (in this case SMB port) is protected by firewall, then no one can use this issue in order to mess up with your router. Usually attacks come to your router from public Internet (not from LAN) and in normal situation SMB access is not open for public Internet;
4) There is not and will not be an official way to gain access to routers shell.

You will be safe from both of these issues if you upgrade your routers (6.38.5 for WWW issue and 6.41.3 for SMB). In order to upgrade many devices at the same time – you can use MikroTik tool called The Dude or use scripts.

From the above post, at least read the FAQ:

FAQ:

What is affected?

– Webfig with standard port 80 and no firewall rules
– Winbox has nothing to do with the vulnerability, Winbox port is only used by the scanners to identify MikroTik brand devices. Then it proceeds to exploit WEBFIG through port 80.

Am I safe? 

– If you upgraded your router in the last ~12 months, you are safe
– If you had “ip service” “www” disabled: you are safe
– If you had firewall configured for port “80”: you are safe
– If you only had Hotspot in your LAN, but Webfig was not available: you are safe.
– If you only had User Manager in your LAN, but Webfig was not available: you are safe.
– If you had other Winbox port before this: you are safe from the scan, but not from the infection.
– If you had “winbox” disabled, you are safe from the scan, not from the infection.

– If you had “ip service” “allowed-from” set to specific network: you are safe if that network was not infected.
– If you had “Webfig” visible to LAN network, you could be infected by an infected device in your LAN.

How to detect and cure?

– Upgrading to v6.38.5 or newer will remove the bad files, stop the infection and prevent anything similar in the future.
– If you upgrade device and you still see attempts to access Telnet from your network – run Tool/Torch and find out a source of the traffic. It will not be router itself, but another device in local network which also is affected and requires an upgrade.

–jeroen

Posted in Internet, MikroTik, Power User, Routers, Security | Leave a Comment »

 
%d bloggers like this: