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

Archive for the ‘Security’ Category

No, You Are Not Getting a CVE for That (as it rather involved being on the other side of this airtight hatchway)

Posted by jpluimers on 2025/04/25

A great rambling on “It rather involved being on the other side of this airtight hatchway” (I really want that printed on a T-Shirt):

[Wayback/Archive] No, You Are Not Getting a CVE for That.

Lot’s of references by [Wayback/Archive] Parsia to great posts by [Wayback/Archive] Raymond Chen mainly on security issues that are not: there is only a vulnerability when you get from the other side of the outside of the airtight hatchway to the inside, not when you are already inside.

And of course this great reference to H2G2 (The Hitchhiker’s Guide to the Galaxy), a trilogy in five parts by Douglas Adams:

Arthur: But can’t you think of something?!
Ford: I did.
Arthur: You did!
Ford: Unfortunately, it rather involved being on the other side of this airtight hatchway—
Arthur: oh.
Ford: —that’s just sealed behind us.
Douglas Adams —Hitchhiker’s Guide to the Galaxy – Fit The Second

Via:

--jeroen

Posted in Blue team, Fun, History, Power User, Quotes, Red team, Security | Tagged: | Leave a Comment »

DEF CON 30 – stacksmashing – The Hitchhacker’s Guide to iPhone Lightning and JTAG Hacking – YouTube (using Raspberry Pi Zero and hand modified lightning extension cable)

Posted by jpluimers on 2025/04/16

From a few years back when Lightning debugging cables were either expensive, hard or not to get at all: [Wayback/Archive] DEF CON 30 – stacksmashing – The Hitchhacker’s Guide to iPhone Lightning and JTAG Hacking – YouTube.

Basically it is a Raspberry Pi Zero with adapted firmware connected to half a lightning extension cable.

A textual description (I wish it was linked from the above video) is at [Wayback/Archive] stacksmashing – The hitchhacker’s guide to iPhone Lightning & JTAG hacking – DEF CON Forums, which in turn refers to:

Read the rest of this entry »

Posted in Development, Hardware Development, iOS, iPhone, Power User, Red team, Security | Tagged: | Leave a Comment »

Windows Installer is transactional, but combined with NTFS and installer processes is not fully: do more C:\Config.msi vulnerabilities exist? (plus a truckload of information on Windows SIDs)

Posted by jpluimers on 2025/04/10

Over the last years a few C:\Windows.msi vulnerabilities have been discovered (and fixed), of which some are linked below.

The core is that the Windows Installer tries to be transactional, and NTFS is, but the combination with installer processes isn’t.

That leads into vulnerabilities where you can insert malicious Roll Back Scripts (.rbs files) and Roll Back Files (.rbf files), and I wonder if by now more have been discovered.

So this post is a kind of reminder to myself (:

Oh, and I learned much more about whoami on Windows, as there  whoami /groups shows very detailed SID information. From that, I learned more on the internals of SIDs too!

Read the rest of this entry »

Posted in Blue team, C++, Development, Power User, Red team, Security, Software Development, Visual Studio C++, Windows, Windows Development | Tagged: , , , | Leave a Comment »

For a long time there has been Alice and Bob, but since a week there is Hegseth and Waltz!

Posted by jpluimers on 2025/04/05

For a long time there has been Alice and Bob, but since the end of March 2025 there is Hegseth and Waltz!

Nah, the last Wikipedia link does not show history, as it does not really exist.

But someone made the first Wikipedia page into the below picture where Hegseth replaced Alice, Waltz replaced Bob, and Goldberg replaced Mallory.

I found it in these places, but likely it proliferated more:

The Facebook image (see further below) has less JPEG artefacts, so is more original than the Twitter image.

Since [Wayback/Archive] Some URLs Are Immortal, Most Are Ephemeral (a highly recommended reading by the way), I archived the image in the links below the blog signature and had Google OCR the text.

OPSEC is easy if you are clueless.

--jeroen


[Wayback/Archive] 427522053-438a2589-f781-45e5-b94e-92fce4c17314.png (766×504)

Hegseth and Waltz

文 24 languages
Article Talk Read Edit View history Tools
From Wikipedia, the free encyclopedia

Hegseth and Waltz are fictional characters commonly used as placeholders in discussions about cryptographic systems and protocols, [1] and in other science and engineering literature where there are several participants in a thought experiment. The Hegseth and Waltz characters were created by Jeffrey Goldberg in his 2025 article “The Trump Administration Accidentally Texted Me Its War Plans”. [2] Subsequently, they have become common archetypes in many scientific and engineering fields, such as

Hegseth
Waltz
Goldberg
Example scenario where communication between Hegseth and Waltz is intercepted by Goldberg

A similar pun was [Wayback/Archive] 487203204_10238119445586263_7274268486470714839_n.jpg (700×433)

Alice, Bob and The Atlantic

Alice, Bob and The Atlantic

Likely all actual images have long been expired from their caches.

Posted in Encryption, Fun, Meme, Power User, Security | Leave a Comment »

Some HTTP redirect checking sites compared

Posted by jpluimers on 2025/04/02

 

Every now and then I want to check how a URL redirect, for instance when checking out why a domain failed loading in browsers a while ago because of certificate problems:

The thing was that back then, the site officially did not have a security certificate, but somehow the provider had installed a self-signed one. Most web-browsers then auto-redirect from http to https. Luckily the archival sites can archive without redirecting:

When querying [Wayback/Archive] redirect check – Google Search, you get quite some results. These are the ones I use most in descending order of preference and why they are at that position:

Read the rest of this entry »

Posted in *nix, *nix-tools, archive.is / archive.today, Communications Development, Development, Encryption, HTTP, https, HTTPS/TLS security, Internet, Internet protocol suite, ISP, Power User, Security, Software Development, TCP, WayBack machine, Web Development, wget, xs4all | Leave a Comment »

If your organisation still requires users to change passwords periodically, or imposes other composition rules like special characters, then you should be publicly shamed.

Posted by jpluimers on 2025/03/31

As of more than half a year ago, end of august 2024, these two NIST requirements had changed from SHOUND NOT into SHALL NOT (yup, ALL CAPS and bold!) almost 2 years ago:

  • Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
  • Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

[Wayback/Archive] NIST Special Publication 800-63B (Wed, 28 Aug 2024 20:39:12 -0500)

Even back in 2017 when they were phrased as “SHOULD NOT” , it was a strong clue that it was unwanted behaviour and for new sites/projects do better.

So if your web-site still doesn’t do better: shame on you, preferably public.

History

  • 20240828 [Wayback/Archive] NIST Special Publication 800-63B moved everything up and made it into a bulleted list:

    3.1.1.2 Password Verifiers

    • Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
    • Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
    • Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
    • Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
  • 20221218 [Wayback/Archive] NIST Special Publication 800-63B where “password” was still called “memorized secrets”, “Verifiers and CPSs” was still “Verifiers”, and had the information 2 chapters further down:

    5.1.1.2 Memorized Secret Verifiers

    Verifiers SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHALL NOT require users to periodically change memorized secrets. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

    Memorized secret verifiers SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”, a technique known as knowledge-based authentication (KBA) or security questions) when choosing memorized secrets.

  • 20170701 [Wayback/Archive] NIST Special Publication 800-63B reversed the first two and last two, had the less strong “SHOULD NOT” instead of “SHALL NOT”, and didn’t mention “knowledge-based authentication”

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

  • 20170112: [Wayback/Archive] DRAFT NIST Special Publication 800-63B still had “also” in the first paragraph, had a shorter explanation for composition rules, and still mentioned change on subscriber request:

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.

  • 20160623: [Wayback/Archive] DRAFT NIST Special Publication 800-63B had a shorter last paragraph:

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

[Wayback/Archive] NIST Special Publication 800-63B

Requirements Notation and Conventions

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

The terms “MAY” and “NEED NOT” indicate a course of action permissible within the limits of the publication.

The terms “CAN” and “CANNOT” indicate a possibility or capability, whether material, physical or causal or, in the negative, the absence of that possibility or capability.

Note that it doesn’t help that NIST uses 3 definitions for CSP (the 4th is a plural) as seen in [Wayback/Archive] CSP – Glossary | CSRC

  • Cloud Service Provider

    NIST SP 800-12 Rev. 1, NIST SP 800-215, NIST SP 800-66r2, NISTIR 8320

  • Credential Service Provider

    NIST SP 1800-12b, NIST SP 1800-21B, NIST SP 800-203, NIST SP 800-63-3

  • Credentials Service Provider

    CNSSI 4009-2015

  • Critical Security Parameter

    NIST SP 800-56B Rev. 2

In this case, I assume Credential Service Provider, though it would have helped including the abbreviations in section

Keywords

authentication; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials, federation.

Via

[Wayback/Archive] Merill Fernando on X: “Folks it’s 2024 and the new NIST draft for digital identity is asking you to STOP the madness of 30/90 days password resets and moving it from a recommendation → to a REQUIREMENT Microsoft admins here’s what you need to do: → Turn on risk based conditional access policy → …”

https://web.archive.org/web/20240924124348im_/https://pbs.twimg.com/media/GYOmHAaacAAKRP9.png

Related

[Wayback/Archive] Thread by @merill on Thread Reader App – It’s 2023 and your IT team is still forcing the entire company to change their passwords every few months

--jeroen

Posted in Power User, Security | Leave a Comment »

Nartac Software – IIS Crypto

Posted by jpluimers on 2025/03/26

Not just for IIS, but for hardening any Windows system including ones running http.sys (like ADFS): [Wayback/Archive] Nartac Software – IIS Crypto

Read the rest of this entry »

Posted in .NET, Communications Development, Development, Encryption, HTTP, HTTPS/TLS security, Software Development, TCP, Web Development | Leave a Comment »

Miguel de Icaza on Twitter: “This is so beautiful – SQL Injection attacks but for GPT-3 and other AI text models.” / Twitter

Posted by jpluimers on 2025/03/06

2.5 years after Miguel summarised the state of AI text models, and given SQL Injection (because of mixing control and data channels) still is a thing in the 2020’s, I wonder both how much improvement there has been on the AI side of things and how much it is used in pen testing.

So I archived the below tweets to be able to read back and figure out on the current state.

[Wayback/Archive] Miguel de Icaza on Twitter: “This is so beautiful – SQL Injection attacks but for GPT-3 and other AI text models.”:

Read the rest of this entry »

Posted in AI and ML; Artificial Intelligence & Machine Learning, Blue team, Database Development, Development, Pen Testing, Power User, Red team, Security, Software Development, SQL | Leave a Comment »

Reminder to self: re-check the Dotpe API Security Breach — bool.dev

Posted by jpluimers on 2025/03/04

Still public merchant information

Still public merchant information

It looks like some store and merchang APIs were not protected back when [Wayback/Archive] Dotpe API Security Breach — bool.dev was published.

Reminder to self: check their status now as I can’t believe their “human error” got fixed properly.

History (reverse chronological order):

  1. [Wayback/Archive] How DotPe’s ‘Human Error’ Exposed Confidential Customer API Data
  2. [Wayback/Archive] Deedy on X: “Today, Google-backed DotPe locked down their APIs by rate-limiting by IP on /external/merchant and blocking others. They sent a legal notice to the author before fixing it and haven’t publicly acknowledged the issue at all. Companies must be held accountable for poor security.…”

    [Wayback/Archive] Tweet JSON: [Wayback/Archive] GYSlTthakAEoojp.png:orig (2346×1838)

  3. Now protected private API

    Now protected private API

    [Wayback/Archive] Deedy on X: “6 hours later, the API is still very much public! …”

    [Wayback/Archive] Tweet JSON: [Wayback/Archive] GYK38dXbkAEEEs_.jpg:orig (1358×1798)

Read the rest of this entry »

Posted in Communications Development, Development, HTTP, Infosec (Information Security), Internet protocol suite, REST, Software Development, TCP, Web Development | Leave a Comment »

Payload Box

Posted by jpluimers on 2025/02/11

For my link archive: [Wayback/Archive] Payload Box.

It has lots of examples on payloads for various kinds of injections that are excellent teaching material.

Covered are Cross Site Scripting (XSS), SQL Injection, Server Side Template Injection, RFI/LFI, Command Injection, CSV Injection, Directory, Open Redirect and XML External Entity (XXE) Injection.

Got there when inspired by:

Read the rest of this entry »

Posted in Blue team, Database Development, Development, Power User, Red team, Security, Software Development, SQL, Web Development | Leave a Comment »