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,854 other subscribers

Archive for the ‘Security’ Category

Hornbach has some very “special” limitations to “special characters” in passwords. I wonder why.

Posted by jpluimers on 2022/02/01

[Wayback] Jeroen Wiert Pluimers on Twitter: “”Too special” password character password woos at @HORNBACH_NL : [ Het wachtwoord moet minstens acht tekens lang zijn, en minstens een getal en een letter (a-zA-Z) bevatten. De volgende speciale tekens zijn toegestaan: !”#$%&'()*+,.:;?@_|} ] 1/”

I wonder what kind of parser they use, as these printable special ASCII characters are forbidden:

  • \-/[\]^`{~
  • space (0x20)
  • tab (0x9)
  • line feed (0xa)
  • carriage return (0xb
  • vertical tab (0xb)
  • form feed (0xc)

Seems no JSON or SQL to me: there I would expect other limitations.

What would break if you use them in other fields or pass them in an HTML POST-request?

I mean: these passwords should be salted and hashed immediately when the HTML-POST request is received, so certainly they would not be stored somewhere or passed many layers into code, right?

Oh, in order to activate an account there, you need to accept some 40+ A4 sized pages of legal stuff. Brave Dutch judge that will put these all in favour of Hornbach.

–jeroen

Read the rest of this entry »

Posted in Development, LifeHacker, Power User, Security, Software Development, Web Development | Leave a Comment »

Some links on using and updating Let’s Encrypt certificates for internal servers

Posted by jpluimers on 2022/02/01

Sometimes it is easier to have current and public CA signed TLS certificates for internal servers than to setup and maintain an internal CA and register it on all affected browsers (including mobile phones).

One of my reasons to investigate this is that Chrome refuses to save credentials on servers that have no verifiable TLS certificate, see my post Some links on Chrome not prompting to save passwords (when Firefox and Safari do) about a week ago.

Below are some links for my link archive that hopefully will allow me to do this with Let’s Encrypt (msot via [Wayback/Archive] letsencrypt for internal servers – Google Search):

Read the rest of this entry »

Posted in Cloud, Cloudflare, Development, Encryption, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Fritz!, Fritz!Box, Fritz!WLAN, Infrastructure, Internet, Let's Encrypt (letsencrypt/certbot), Power User, Security, Software Development, Virtualization, VMware, VMware ESXi, Web Development | Leave a Comment »

Some links on Chrome not prompting to save passwords (when Firefox and Safari do)

Posted by jpluimers on 2022/01/20

For quite some time now, Chrome (think years) refuses to prompt for saving passwords whereas Firefox and Safari do prompt and save them, even for site types that it used to save passwords for in the past.

It has been annoying enough for too long now that I tried to do better than the Google searches I used back when I saw this happen first.

Below are some links based on new searches (starting with [Wayback] adding a password in chrome settings – Google Search); hopefully I can try them after I made a list of sites that Chrome does not show the password save prompt for.

Solutions I tried that failed (but maybe useful for others):

Solutions still to try:

Read the rest of this entry »

Posted in Chrome, Chrome, Communications Development, Development, Encryption, ESXi6, ESXi6.5, ESXi6.7, Firefox, Fritz!, Fritz!Box, Fritz!WLAN, Google, https, HTTPS/TLS security, Internet, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, routers, Safari, Security, TCP, TLS, Virtualization, VMware, VMware ESXi, Web Browsers, Web Development | Leave a Comment »

Security questions are evil because of social media “games” phishing for them

Posted by jpluimers on 2022/01/11

Via [Archive.is] Jilles Groenendijk on Twitter: “what @AppSecBloke said… “, from:

I don’t normally do this but here goes:

First job STOP
Current job SENDING
Dream Job YOUR
Favorite food POTENTIAL
Favorite dog PASSWORDS
Favorite footwear OR
Favorite Chocolate bar MEMORABLE
Favorite Ice Cream DATA
Your Vehicle color TO
Favorite Holiday PEOPLE
Night owl or earlybird WHO
Favorite day of the week COLLECT
Tattoos THIS
Favourite colour INFORMATION
Do you like vegetables FOR
Do you wear glasses SOCIAL
Favourite season ENGINEERING

Read the rest of this entry »

Posted in Facebook, Instagram, LifeHacker, Pen Testing, Power User, Security, SocialMedia | Leave a Comment »

SVB PGB and DigiD security suddenly logged you out every 15 minutes despite the count down counter indicating otherwise.

Posted by jpluimers on 2021/12/14

From a while back, so I hope it has been fixed by now on the SVB PGB site.

The Dutch SVB (sociale verzekeringsbank, the [WayBack] organisation that implements social security schemes in The Netherlands) has a web-site to submit declarations for PGB ([Wayback] individualised subsidy for care, or personal care budget).

Authentication for the site goes through DigiD, the identity provider through which government related web-sites can verify the identity of Dutch residents on the internet.

In from somewhere in the mid 2010s until somewhere in 2020, the SVB PGB site would log you out when the 15-minute inactivity count-down in the lower right of the screen would reach zero.

After that, the behaviour changed: you would be logged out 15 minutes after logon, forcing one to login way more often. Each logoff/logon cycle had these effets:

  1. loosing the data you entered on the current page
  2. a cost to SVB of about EUR 0.15 excluding VAT for the logon
  3. loss of time and convenience for the end-user

Note that due to site stability reasons in the years before, I already printed each web-page to PDF before submitting, as there was no way to use the “back” button to see what information you had entered.

That way at least I had the information at hand when re-entering the same information. It also provided me of a “paper” trail of site navigation and entered data.

That’s why I reported it early March 2021:

Read the rest of this entry »

Posted in Authentication, Development, DigiD, Power User, Security, Software Development, Web Development | Leave a Comment »

Jan Schaumann: “The secret language of coders, part N of many. Today: “risk acceptance”… “

Posted by jpluimers on 2021/12/08

From a while back, but more relevant than ever:

[Archive.is] Jan Schaumann on Twitter: “The secret language of coders, part N of many. Today: “risk acceptance”… “

Obligatory video below the fold.

–jeroen

Read the rest of this entry »

Posted in Development, DevOps, Infrastructure, LifeHacker, Power User, Security, Software Development | Leave a Comment »

OWASP top rated security “feature” A01:2021 – Broken Access Control

Posted by jpluimers on 2021/11/24

An important [Wayback/Archive] A01:2021 – Broken Access Control, in German, is a pre-amble for a future post about getting a feel how to counter the vulnerabilities that OWASP tracks and documents.

Basically remember that Broken Access Control is by far the most vulnerable feature in applications:

Broken Access Control war 2017 auf Platz 5 und ist jetzt Problem #1. 94 % der getesteten Anwendungen hatten irgendeine Form von defekter Zugangskontrolle. Der ehemalige #1 Dauerbrenner Injection ist nur noch auf Platz 3.

Basically the top 3 changed dramatically between 2017 and 2021. The new top-3 is below. Please get acquainted with it.

  1. [Wayback/Archive] A01 Broken Access Control – OWASP Top 10:2021

    Moving up from the fifth position, 94% of applications were tested for some form of broken access control with the average incidence rate of 3.81%, and has the most occurrences in the contributed dataset with over 318k. Notable Common Weakness Enumerations (CWEs) included are CWE-200: Exposure of Sensitive Information to an Unauthorized ActorCWE-201: Exposure of Sensitive Information Through Sent Data, and CWE-352: Cross-Site Request Forgery.

  2. [Wayback/Archive] A02 Cryptographic Failures – OWASP Top 10:2021
    Shifting up one position to #2, previously known as Sensitive Data Exposure, which is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof). Which often lead to exposure of sensitive data. Notable Common Weakness Enumerations (CWEs) included are CWE-259: Use of Hard-coded PasswordCWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy .
  3. [Wayback/Archive] A03 Injection – OWASP Top 10:2021

    Injection slides down to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and 274k occurances. Notable Common Weakness Enumerations (CWEs) included are CWE-79: Cross-site ScriptingCWE-89: SQL Injection, and CWE-73: External Control of File Name or Path.

Via; [Archive] Kristian Köhntopp on Twitter: “Vieles aus diesem Thread ist nun geordneter in … zu finden.… “

Very much related as A01 was the basic cause of GitHub’s commitment to npm ecosystem security | The GitHub Blog – no npm package can historically ben tracked to be authentic.

We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.

–jeroen

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

To bypass a Chrome certificate/HSTS error, you can type ‘badidea’ (previously ‘thisisunsafe’) without quotes (this might change in the future)

Posted by jpluimers on 2021/11/11

For expired or self-signed certificates with an untrusted chain, you might want to by base the Chrome certificate/HSTS error message.

Instead of clicking a few times, you can also type ‘badidea’ (this used to be ‘thisisunsafe’ and might change again someday).

Based on: [WayBack] security – Does using ‘badidea’ or ‘thisisunsafe’ to bypass a Chrome certificate/HSTS error only apply for the current site? – Stack Overflow

Found via [WayBack] KPN-klanten kunnen Experiabox V10A niet benaderen door verlopen certificaat – Computer – Nieuws – Tweakers

Source code that handles this: [WayBack] components/security_interstitials/core/browser/resources/interstitial_v2.js – chromium/src – Git at Google

/**
 * This allows errors to be skippped by typing a secret phrase into the page.
 * @param {string} e The key that was just pressed.
 */
function handleKeypress(e) {
  var BYPASS_SEQUENCE = 'badidea';
  if (BYPASS_SEQUENCE.charCodeAt(keyPressState) == e.keyCode) {
    keyPressState++;
    if (keyPressState == BYPASS_SEQUENCE.length) {
      sendCommand(SecurityInterstitialCommandId.CMD_PROCEED);
      keyPressState = 0;
    }
  } else {
    keyPressState = 0;
  }
}

–jeroen

Posted in Chrome, Development, Encryption, https, HTTPS/TLS security, Power User, Security, Web Browsers, Web Development | Leave a Comment »

Shodan (via SCADA systems accessible through the internet)

Posted by jpluimers on 2021/10/27

Just 2 years ago I bumped into shodan.io through [Wayback] Onderzoekers: zestig slecht beveiligde Nederlandse scada-systemen op internet – Computer – Nieuws – Tweakers and saved the entry [Wayback] Shodan (website) – Wikipedia:

Shodan is a search engine that lets the user find specific types of computers (webcamsroutersservers, etc.) connected to the internet using a variety of filters. Some have also described it as a search engine of service banners, which are metadata that the server sends back to the client.[1] This can be information about the server software, what options the service supports, a welcome message or anything else that the client can find out before interacting with the server.

Shodan collects data mostly on web servers (HTTP/HTTPS – ports 80, 8080, 443, 8443), as well as FTP (port 21), SSH (port 22), Telnet (port 23), SNMP (port 161), IMAP (ports 143, or (encrypted) 993), SMTP (port 25), SIP (port 5060),[2] and Real Time Streaming Protocol (RTSP, port 554). The latter can be used to access webcams and their video stream.[3]

It was launched in 2009 by computer programmer John Matherly, who, in 2003,[4] conceived the idea of searching devices linked to the Internet.

It looked promising, but I was really pressed for time (having impromptu arrange all care for my mom, and became even more so when I got diagnosed with rectum cancer later that year), so did not pay much attention apart from registering.

Last year in the midst of my chemos I noted [Archive.is] Nate Warfield on Twitter: “https://t.co/16969jRfuL The latest Citrix vulnerability looks bad but there might be time to fix them before PoC comes out. The @shodanhq query above might help. (support.citrix.com/article/CTX269106 has more details)… “ (I think via @jilles_com) , so put it on my list of things to look into a bit further.

Since then, I found out a lot of people dislike Shodan and want to blacklist it because they see it as a threat. It feels like people think the internet is like the [Wayback] Ravenous Bugblatter Beast of Traal | Hitchhikers | Fandom

The Ravenous Bugblatter Beast of Traal is a vicious wild animal from the planet of [Wayback] Traal, known for its never-ending hunger and its mind-boggling stupidity. One of the main features of the Beast is that if you can’t see it, it assumes it can’t see you.

(This by the way is one of the reasons for Towel Day – Wikipedia)

Anyway: a few lists of Shodan IPv4 addresses and hostnames, and means to maintain them for the ones interested:

Reality is that the internet is much smarter, so if you block Shodan from seeing you, others from the internet still will and if you have vulnerable services, one day they will be abused. For instance, this personal anecdote:

I forgot I had a port redirection on my router for RDP access a non longer existing Windows system any more. I forgot that this Windows machine had no fixed DHCP-lease while in use (it kept it’s lease as it was always on).

When that machine was long gone, another temporary Windows machine obtained the same internal machine (the router had been rebooted and after reboot hands out previously handed out IP address), and boom: the new Windows machine was bombarded with RDP logon requests.

In the end, the new Windows machine was not compromised, so I was lucky as it could have been.

Back when registering, shodan.io sent SMTP mail via sky.census.shodan.io, so you might want to not blacklist it if you blacklist at all (incidentally, when writing the IP address  servicing that hostname was hosted in The Netherlands: [Wayback] 80.82.77.33 – sky.census.shodan.io – Netherlands – IP Volume inc – IP address geolocation).

It is good to think of you use Shodan, as not all usage might be legal where you live or where you travel to.

Some discussion in Dutch on the risks of using Shodan are in the above Tweakers.net link. It boils down to:

  • Searching should be OK
  • Accessing the devices found can be totally illegal

That’s basically with anything you find on the internet, for instance by Googling, so nothing new here.

I mainly use Shodan to see if I have any known vulnerabilities exposed. There are not that many ports open, but given the anecdote above, I might screw up again and not be so lucky.

This article has a balanced explanation of Shodan, how you use it, and how to stay safe: [Wayback] How to remove your device from the Shodan IoT search engine.

jeroen

 

Posted in Development, IoT Internet of Things, Network-and-equipment, Power User, Security, Software Development, Web Development | Leave a Comment »

The hard part of a crypto specification: make it safe and misuse resistant.

Posted by jpluimers on 2021/10/19

Great quote from a while back:

[WayBack] Filippo Valsorda on Twitter: “Here’s a secret: it’s not that hard to put together a crypto specification. What’s hard is to make it safe and misuse resistant. What needs to be “battle tested” is the security devex, not the narrow happy path, and blaming the developer when it breaks is not battle testing.”

From the same thread:

–jeroen

Read the rest of this entry »

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