The Wiert Corner – irregular stream of stuff

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

  • My badges

  • Twitter Updates

  • Pages

  • All categories

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

    Join 1,854 other subscribers

Archive for the ‘Security’ Category

Use TLS 1.2 or higher, as TLS 1.1 is phased out on many sites, after TLS 1.0/SLL has been disabled by most for a while now

Posted by jpluimers on 2018/07/23

If you get an error like this in one of your tools

OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

it means you are using a tool not yet properly supporting TLS 1.2 or higher.

Or in other words: update your tool set.

The reason is that – after turning off TLS 1.0 a while ago – more and more sites do the same for TLS 1.1.

A prime example of a site that warned on this in a clear way very early on is github:

Others have done this too, for instance:

TLS 1.0 is vulnerable to many attacks, and certain configurations of TLS 1.1 as well (see for instance [WayBack] What are the main vulnerabilities of TLS v1.1? – Information Security Stack Exchange), which means that properly configuring the non-vulnerable TLS 1.1 over times gets more and more complex. An important reason to say goodbye to that as well, as TLS 1.2 (from 2008) is readily available for a long time. The much more recent TLS 1.3 (from 2018) will take a while to proliferate.

I ran in the above error because on one of my systems, an old version of wget was luring around, so I dug up the easiest place to download recent Windows binaries for both win32 (x86) and win64 (x86_64):

[WayBack] eternallybored.org: GNU Wget for Windows having a table indicating the OpenSSL version for each wget build.

–jeroen

Reference: Transport Layer Security – Wikipedia: History and development

Posted in *nix, https, HTTPS/TLS security, OpenSSL, Power User, Security, wget | Leave a Comment »

CVE-2017-11509: Firebird fbudf Module Authenticated Remote Code Execution – Firebird News

Posted by jpluimers on 2018/05/31

Ouch (despite one needs authenticated access): [WayBack] Firebird fbudf Module Authenticated Remote Code Execution – Firebird News

Here is the description for CVE-2017-11509

An authenticated remote attacker can execute arbitrary code in Firebird SQL
Server versions 2.5.7 and 3.0.2 by executing a malformed SQL statement. The
only known solution is to disable external UDF libraries from being loaded. In
order to achieve this, the default configuration has changed to UdfAccess=None.

This will prevent the fbudf module from being loaded, but may also break other
functionality relying on modules.

Here is the Debian security page with the issue : CVE-2017-11509

The thing I am really not happy about is that the 90 day limit has been overdrawn by about 180 days (see https://www.tenable.com/security/research/tra-2017-36)

Related:

Via:

–jeroen

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

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 »

Cracking xkcd Passwords in little time, breaking 12 character passwords in more time… hashing algorithms…

Posted by jpluimers on 2018/03/29

via [WayBack] Cracking xkcd Passwords in 20 Seconds, breaking 12 character passwords and other cyber “I hope I’ve demonstrated that you need unique words, digits and … – Kristian Köhntopp – Google+

Some interesting reads:

–jeroen

Posted in Power User, Security | Leave a Comment »

A beginner’s guide to beefing up your privacy and security online

Posted by jpluimers on 2018/03/19

Want to protect your security and privacy? Here are some places to start:

via: [WayBackI think I’ll keep this article somewhere where I can easily share it with the famz the coming days :) – Roderick Gadellaa – Google+

–jeroen

 

 

Posted in Power User, Security | Leave a Comment »

Packet Sender is a good tool when debugging protocols: free utility to send & receive network packets. TCP, UDP, SSL

Posted by jpluimers on 2018/03/07

It was fitting to bump into [WayBack] Packet Sender is a good tool when debugging protocols…” Written by Dan Nagle… – Lars Fosdal – Google+ on the day presenting [WayBack] Conferences/Network-Protocol-Security.rst at master · jpluimers/Conferences · GitHub

It also means that libssh2-delphi is getting a bit more love soon and will move to github as well after a conversion from mercurial.

Some of the things I learned or got confirmed teaching the session (I love learning by teaching):

Here is some more info:

–jeroen

Read the rest of this entry »

Posted in Communications Development, Delphi, Development, Encryption, Hardware, Harman Kardon, Home Audio/Video, HTTP, https, HTTPS/TLS security, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), OpenSSL, Power User, Security, Software Development, TCP, TLS | Leave a Comment »