bwblabs

DNSSEC would have made the typo slightly less problematic. But [az.]mastercard.com does not do DNSSEC ...

See all issues on: https://internet.nl/site/mastercard.com/3122570

Nameserver is not reachable on advertised IPv6:

    $ dig +short +tcp @dns1.mastercard.com dns1.mastercard.com AAAA
    2607:3c00:6404:4::53

    $ dig +tcp @2607:3c00:6404:4::53 mastercard.com SOA
    ;; Connection to 2607:3c00:6404:4::53#53(2607:3c00:6404:4::53) for mastercard.com failed: timed out.

Also: no HSTS on apex, while HSTS with "includeSubDomains ; preload" on www, this does not work! And it's worse, they do some geo-redirect, so apperantly for US IP addresses http://www.mastercard.com redirects to https://www.mastercard.us/en-us.html (see https://hstspreload.org/api/v2/preloadable?domain=www.master...)

I also would expect an IPv6 on the apex/www, since there are quite some ISP's with IPv6 where IPv4 is a GCNAT, if there is a noisy user on the IPv4, it's tricky to block those, except if the ISP supports IPv6 and the web server too.

Weirdly enough the SOA serial which is in YYYYMMDDnn (see https://datatracker.ietf.org/doc/html/rfc1912#section-2.2) was not updated (still indicates 2011):

    $ dig +short +tcp @dns1.mastercard.com mastercard.com SOA
    dns1.mastercard.com. hostmaster.mastercard.com. 2011127982 14400 3600 2419200 300

Some other SOA record abnormalities:

    $ dig +short @a22-65.akam.net. az.mastercard.com SOA
    a1-29.akam.net. hostmaster.az.mastercard.com. 2020068768 3600 600 604800 300

Indicates 2020, and hostmaster@az.mastercard.com is not reachable because az.mastercard.com does not have an MX record, nor A/AAAA record.

Sadly nobody recorded this in either DNSViz history (https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf).

In the provided CSV's by DigiCert there are 83_267 unique serials and 166_397 crt.sh links (137 have #N/A in the precert column***). Please note that crt.sh is Precertificates heavy for DigiCert (see https://crt.sh/cert-populations?group=RootOwner).

I did a lookup of all serials and based on 84 batch requests to crt.sh between 2024-07-31T20:06:00Z and 2024-07-31T21:06:00Z this was the result:

  Pre  Leaf  Count   Percentage
  -    0        137   0.16% ***
  0    1      2_105   2.53%  
  1    0     71_732  86.15%  
  1    1      9_293  11.16%  

These are the match numbers based on the serial and sha256 fingerprint combination. Only 13.69% of the Leaf certificates are found, while 97.31% of Precertificates are found. Because of these numbers, it's not strange that the 137 certificates without Precertificates cannot be found.

All 92_423 can be found in this bzip2 compressed attachment in tab-separated values format: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c16

These are certificates for 172_047 unique domains, of which 20_702 are wildcard and 71 IP Addresses (63 IPv4 and 8 IPv6).*

I just rechecked, and now everything works again from tree IPv6 networks I have access to.

Update: https://twitter.com/BWBroersma/status/1762566155691082135

At Internet.nl we're seeing IPv6 connection issues on TCP port 25 (SMTP) to mx[1-4].smtp.goog. Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection. At least from AS20857, AS20860 and AS41887.

Can somebody ping Google/Gmail, it seems to be on their side.

Verify it yourself with: $ nc 2001:4860:4802:32::97 25

Replace 32 with 34, 36 or 38 for MX 2, 3 or 4, optionally use telnet / netcat / socat instead of nc. Please note in all cases ICMP (ping6 / traceroute6) does work.

Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).

Original posting of Dutch article: https://news.ycombinator.com/item?id=38681302

Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).

NLTimes link: https://news.ycombinator.com/item?id=38681707

It sounds 'late' to make it a docker container, but actually getting the IPv6 testing working with docker was challenging, only recently some IPv6 issues got solved, and the project needs the experimental and ip6tables docker flags to run.

The news.ycombinator.com setup isn't really modern:

- no IPv6 address for the webserver

- no DNSSEC

- no RPKI ROA for webserver BGP routes

- use of TLS 1.0 and no TLS 1.3

- use of insecure* ciphers

- CSP with 'unsafe-inline' in script-src

When I see TLS 1.0 and no TLS 1.3, I assume there is a bit of legacy openssl or at least the configuration of it. Probably wise to update the config since modern browsers don't support TLS 1.0.

* based on NCSC-NL: https://english.ncsc.nl/publications/publications/2021/janua...

Shameless plug of my TOTP in '4' lines of PL/pgSQL: https://gist.github.com/bwbroersma/676d0de32263ed554584ab132...

Note the Wizz Air anti-bot statement (https://skift.com/2020/08/31/wizz-airs-odd-fee-for-buying-a-...). The "System Surcharge Fee - Applicable to bookings made by automated systems" of € 10 is listed on the Wizz Air website as service fee https://wizzair.com/en-gb/information-and-services/prices-di....

I just opened https://wizzair.com/ with a default uMatrix config (only loading first party *.wizzair.com resources) and it complains straight away:

Are you human?

An unusual activity was detected from your web browsing activity, which may also be done by a robot or “bot”. For this reason it needs to be verified that you are human. Bots are not allowed to use our website/mobile app in order to protect your privacy and provide a reliable user experience.

Some activities may look like they are done by a bot, such as running multiple sessions of the WIZZ website, or performing more than one search in a web browser.

What if I am not a bot? Read on for a solution.

We take many factors into consideration to make sure real website/mobile app users are properly distinguished from bots. We recommend the following:

• Use the latest version of the supported web browsers (Chrome, Firefox);

• Don’t use your browser in incognito or compatibility mode;

• Don’t use ad blockers as they may conflict with our website’s protection;

• Don’t use anonymizer proxies with botnets to hide your identity;

• Try to book from another device and/or internet connection;

• Use our mobile apps on iOS or Android

Why can bots be harmful?

• Some third parties such as online travel agencies use bots. If you book your WIZZ ticket through their websites, we may not be able to contact you about possible flight disruptions or any relevant changes, and they may also apply additional fees on the top of the ticket price;

• Bots can overload our servers, slowing them down for our real customers.

If you are using a bot, please note that:

• By using automation tools on our website or mobile application, you are violating their terms of use.

• As per these terms, we have the right to detect and block your activity and cancel any booking you make via these channels.

• To provide the best service to our customers, bots can still access the Flight-Search capabilities, but we reserve the right to discontinue or block bot users even from Flight-Search, especially if over-use is detected;

• If you would like to show our flights in your inventory, please contact us beforehand and make sure users are redirected to wizzair.com when they are ready to make their booking. You can also use a deep link to the selected flight.

250k is off by one, actually 249999 entries:

  $ curl -s https://cdn.smoot.apple.com/static/autofill_tld_whitelist_url | jq '.tlds|length'
  249999

Dutch CERT has a advisory about it: https://www.ncsc.nl/actueel/advisory?id=NCSC-2022-0014 (in Dutch) with all relevant CVE codes, but the RCE in http.sys is rated the highest, that is CVE-2022-21907.

Update NOW, patch is out. CVSS:3.1 9.8/8.5

Summary of all European (EU+) apps initiatives: https://github.com/ct-report/summary

After a quit scan of the protocol and API outlined by Apple and Google: it looks privacy & technically sound to me.

I would remove the Android FAILED_REJECTED_OPT_IN status code (https://www.blog.google/documents/55/Android_Contact_Tracing...).

I cannot find it in the Apple API specs, but maybe it's not defined in there yet.

Some TUDelft students from The Netherlands are trying just that: https://youtu.be/DI4V32gNzYk?t=120 (in Dutch)

Reminds me of the !sql in rust-postgres-macros:

https://github.com/sfackler/rust-postgres-macros#sql

With the difference: it uses the PostgreSQL parser, not a generic SQL parser

Sapper is very useful and has quite some nice properties:

- automatic SSR (Server Side Rendering)

- possibility to export to server-less plain HTML/CSS/JS

- option to resource preload/fetching on mouseover/touchstart (a headstart of 300+ms)

- serviceworker cache: PWA, offline support, etc.

- session stores

Sure there is room for improvement (e.g. i18n), but it very useful and powerful already today.

Read tip: https://blog.smartdec.net/you-do-not-need-blockchain-eight-p... previous HN talk: https://news.ycombinator.com/item?id=19225857

Ever looked at https://svelte.dev ?

https://youtu.be/gJ2P6hGwcgo?t=1055 https://twitter.com/wolfr_2/status/1164621105476329472

I use KeePassXC in multiple groups with different synchronization software (Dropbox, self hosted client side encrypted Seafile, etc.), for each group I use a different .kdbx and .key (of course that one not synchronized).

There are multiple .kdbx apps, like MiniKeePass on iOS, which is decent, but it's lacking active development at the moment.

I use to (ab)use their Outlook Social Connector (OSC) from the now gone API (https://outlook.linkedinlabs.com/osc/people/details), they stopped it in 2015. I used it just to get names and profile images for easy onboarding (like gravatar).

There was a LSC-Signature header that was a sha1_hmac("POST%2Fosc%2Fpeople%2Fdetails$auth_token$unix_timestamp", "aa15bd5f089eb93a5b2b4a0e11443cb78e44f34d"); which I reversed from the Social Connector DLL, I never found it posted online, but others must have done the same.

"Security Analysis of Estonia's Internet Voting System" @31C3 (December 2014)

https://media.ccc.de/v/31c3_-_6344_-_en_-_saal_1_-_201412281... (starts at 20:26)

They failed on quite some points, I cannot believe they fixed all issues.

Better use an old printer indeed, since modern printers can have tracking dots with a timestamp and a serial number of the printer, which both can give away the backdating (https://en.wikipedia.org/wiki/Machine_Identification_Code)

Or faking/randomizing your UA? Some sites (e.g. YT) serves other image formats based on the UA string.

I've looking into this issue for the last 2 days: The APK we all looked into is IronChat-3.40-release.apk [1], after decompiling I think it is a copy/fork of Conversations version 1.14.6 with a few more commits until October 13th 2016 [2] with Secret Space Encryptor version 1.7.2c [3].

About unencrypted support: "supportUnencrypted() { return false; }" is in the config, so probably not [4]. There is a theory (I kind of started [5]) that it might be MitM because of bad UX. This is because they used OTR without TOFU which was only added in Conversations 1.15, after the fork [6].

[1] https://ironphonestore.com/IronChat-3.40-release.apk

[2] https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7...

[3] https://paranoiaworks.mobi/sse/

[4] https://twitter.com/BWBroersma/status/1060136620383453195

[5] https://twitter.com/BWBroersma/status/1059851925234036739 / https://twitter.com/Schellevis/status/1059852605801852929 (= the author of the article quoted by ars: https://nos.nl/l/2258309 )

[6] https://twitter.com/BWBroersma/status/1060278116315262976

We (OpenStateFoundation) scanned 15070 Dutch (.nl) Symantec certificates that are in the Certificate Transparency via crt.sh, which are valid for 45822 different domain names (including wildcard certificates), which of 26971 are below the .nl-tld (and of which 19648 unique names, if www/non-www and * are normalized to the plain domain), which resulted in 3801 that still needing replacement (the scan in the article is based on a CN scan, later I also did a scan based on the valid DNS names in the cert).

On average 1 in 5, probably other TLDs have a similar score.

I had some years I thought the same way, however:

From a DNS point of view: you can't have CNAME's on your root (can be useful, especially in some DNS load balancing situations, or load balancing on third party providers)

From HTTP point of view: A no-www domain might not be the best solution if you ever want a 'Cookie-free Domain' (static.) for images etc. which speeds up your site. If you start with a no-www domain you have to setup a different domain (no subdomain) for it: like sstatic.net for SO, ytimg.com for YT and yimg.com for Yahoo.

When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.

If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. https://developer.yahoo.com/performance/rules.html#cookie_fr...

in my view having a www record (and no-www redirect) has more benefits that a no-www

I think instead of moving everything to one new (central hosted) silo like GitLab.com, we should move to self hosted git instances, with some GitHub like web interface to do remote comments/pull requests (e.g. gitea/gogs with some simple modifications).

Pretty elaborate research indeed, I once filed a very simple, but just as dangerous, stored XSS on www.linkedin.com (with access to cookies) + some other bug, hoping to speedup my Partner API Request, got $400 for the XSS and many weeks later $400 for the other bug too (which took them 6+ months to fix). The $/time wasn't worth it, and of course the Partner API Request got declined without explanation.