Preregistration failed

[Displema]

http_preregistration
    assert r.status_code == 200, 'Preregistration failed ({} != 200)'.format(r.status_code)
AssertionError: Preregistration failed (403 != 200)

First request is failing. I tried to sniff the app but I couldn't see the same request being made. They added tls fingerprinting check so the module "requests" won't work. Try using a session from the package "tls_client"

[mr-brune]

Do you have any updates?

[fmaule]

@Displema I have tried using tls_client. Neither safari_ios_16_0 or okhttp4_android_13 would work even though I am getting a slightly different error (si è verificato un errore tecnico. La invitiamo ad effettuare una nuova richiesta di accesso.).

@simone36050 any idea if this is somehow fixable? How did you sniff the handshake in the first place?

[Displema]

@Displema I have tried using tls_client. Neither safari_ios_16_0 or okhttp4_android_13 would work even though I am getting a slightly different error (si è verificato un errore tecnico. La invitiamo ad effettuare una nuova richiesta di accesso.).

@simone36050 any idea if this is somehow fixable? How did you sniff the handshake in the first place?

I think that the login flow changed completely. I was able to manually decompile the APK and remove SSL pinning, but it was for an older version of the app. Also if you install an app with another signature the other apps from Poste Italiane (like Postepay) won't open

[simone36050]

Hi everyone, I'm sorry if I haven't been able to dedicate much time to the project lately. I've recently switched almost completely to CIE, so I'm no longer using the tool. For the few things that still don't support CIE, I use the official app, which is also why it would be useful to update this tool.

I think that the login flow changed completely.

You are probably right, since it has been two and a half years since this tool was written.

any idea if this is somehow fixable?

I think the API has changed because it literally fails on the first request, no specific data is sent in the HTTP request, and the session is still empty at the time of the request. Knowing Poste, we are probably talking about minor changes.

How did you sniff the handshake in the first place?

I didn't. I tried, but, perhaps in part because I'd never done it before, I couldn't. I decompiled the application and reproduced the operation of the parts needed to extract the seed without running the original application.

[Displema]

The app now uses Android Keystore. If I recall correctly, from the requests that I sniffed the app sends a public key and all subsequent communication is encrypted. Of course I couldn't tell which data was being sent, but by analyzing again the decompiled apk it might be possible to rewrite the complete flow. They tend to ban temporarly from login users that spam too much, so it's a PITA to analyze the requests. If one of either you two dms me I can send the APK that I used, which has pinning disabled.

[simone36050]

When I decompiled the application (two and a half years ago) keys, ids and other things were stored in self-signed digital certificates, at the time I didn't understand why, but I wonder if it could be because certificates are easier to store in a keystore?

Regarding encryption, there is an initial http_preregistration request that downloads the public key from Poste, all data sent after that is encrypted with this key (using JSON Web Encryption (JWE), objects similar to JSON Web Token (JWT) but implementing asymmetric encryption). So we can say that even at that point, the client was requesting a key from the server and encrypting all subsequent requests.

As for disabling certificate pinning, it would be helpful if you could share the procedure you followed to disable it.

[Displema]

If I recall correctly I disassembled the app using of course apktool. Opened the dir with VSCODE and used the plugin APKLab to remove almost all logic regarding certificate pinning. Then I reassembled the APK, and I ran the app using one of the publicly available Frida script to bypass the method that weren't modified by apk-mitm (the package used by APKLab) to bypass pinning

[simone36050]

@Displema thanks for the explanation!

Last week I started reverse engineering the latest version of the app to find out what they changed. If there is no major news, I will update you at the end of this week

[simone36050]

As promised, here is the update.

I got the latest version and set about deobfuscating it (not much has changed in the last two years), the differences I found so far are:

• They changed the "pre-registration" to make sure this request is encrypted*, I implemented the new version of the HTTP request;
• they migrated the infrastructure to Azure and now you need to use a user agent in a whitelist, this issue has also been fixed.

The changes are in an "experimental" branch named dev-posteid-2024, the code is quite dirty, in fact it should be considered as a proof of concept.

Now the tool generates a valid QR code. However, I have not been able to test it because every time I use SPID, after entering my username and password, it only offers me the option to log in with notification and not to log in with the OTP. Do you also?

In the meantime, I remembered that a user fork and implemented, among many other things, more HTTP requests.

Next week I will try to find out why it behaves this way and possibly implement other features. Next update at the end of next week.

---

* TL;DL: The change they made is ridiculous. Every request is protected with JWE (similar to JWT, but encrypted), except the "pre-registration", because it allows the client to get the server's key, and thus was only protected with HTTPS. Poste wanted to protect this request with JWE as well (I think to avoid MITM attacks over HTTPS or to avoid attacks on the HTTP server that distributes the key). To do this, the request and the response containing the server's public key are protected with a symmetric key hardcoded into the code. In practice, they basically solved nothing.

[Displema]

Yeah it seems like they disabled the option to login with OTP code from app, but they left the button in the app. It means that if your device is not connected to the internet or the SIM doesn't work for some reasons, then you cannot access using PosteID. Good thing that they are pushing to CieId. One cool thing to implement is the automation of the authorization process, which of course makes useless the second factor of authentication, but it could be useful for advanced users. Did you also find the code that handles the authorization?

[simone36050]

But when I log in directly to the PosteID site, it gives me the OTP option 😑

If you tell me that OTP is useless, this tool loses its meaning. It can be turned, as you suggested, into something that lists pending requests and allows the user to approve them.

I would be concerned about security, but if the user is aware of what they are doing, there would be no problem. I'll think about it.

Did you also find the code that handles the authorization?

Yes, I have found HTTP requests that are most likely to get the list of pending requests and approve them. Obviously I need to do a much better analysis of a large chunk of code and reimplement that chunk in Python.

---

I would love to get feedback from anyone who is interested in

[Displema]

Yeah I think that this tool lost its purpose because of their changes. Even though on the login page of Poste Italiane, after selecting the OTP from app as the second factor, it says "Attenzione: la funzionalità 'Genera PIN temporaneo' sarà resa progressivamente disponibile a tutti gli utenti tramite un aggiornamento dell'App PosteID. Se ancora non è disponibile, clicca il pulsante 'Annulla' e utilizza le altre modalità di accesso già attive.". I wasn't aware of these changes because I use almost always CieID, otherwise I would have told you before digging in the app again.

[simone36050]

Thanks for the feedback!

I wasn't aware of these changes because I almost always use CieID, otherwise I would have told you before digging into the app again.

Don't worry, it's always a pleasure to analyze such a surreal piece of nonsense.

I've been thinking a lot about what use case a tool for accepting access requests could have. I answered myself that someone might need to automate certain tasks that require SPID access, and so a tool that allows you to automate login requests would be great. Of course, the tool is designed for people who know what they are doing and understand the risks of having both authentication factors in the same device.

I will be working on implementing the ability to interact and approve access requests in the coming months.