Nowadays, we know Fido2 as passwordless authentication - which initializes authorized session. But in cryptography world, it’s useful for different purposes.
In my previous post, we know how fido2 works and its concept. If we see the signing method in a different way, we can use it for advanced authorization, and replace OTP - which something you know of.
If you use fido2 as passwordless authentication, how do you know that only authorized users connect to your system?
In my previous post, again, when you implement fido2 on client side, you must define the way user uses platform authenticator or security key: user verification instead of user presence. It leads to choosing method of user verification.
PIN and Password are something you know, only biometric is something you have. Then implementation must define biometric as primary of user verification.
CTAP 2.1 supports enterprise assertion, bank will know the key they manage and deliver to user as RSA token before.
For bank with custom implementation of Fido2 in their applications, they must allow biometric user verification only.
State of Bank Vietnam released new document about authentication method included fido2 when making transaction. It’s widely adopted now.
When customer uses OTP as their verification method, OTP is reused somewhere, and that’s why malwares on Android or IOS need to read OTP code from sms or smart otp application.
You need to remember that: what you know is what you reuse somewhere.
But someone said that: OTP is something you have. No, it’s totally wrong. OTP belongs to the OTP system, not you. You are revealed to know and send it back to server like other secrets: password. That’s why it’s named: one time password/pin.
Based on fido2’s implementation, when user makes transaction, the challenge is sent to customer, and they prove that they have private key, and sign this challenge for transaction - it likes advanced OTP when user received the challenge, it’s combined with static secret key and generate 6-8 OTP number but in fido2, user never knows the signed message and cannot reuse it somewhere, thanks to signature counter parameter.
When State of Bank Vietnam adopts fido2 as standard, developer should know how to implement it correctly. Modern secure system bases on something users have, behaviour detection, so on…You should get rid of password in the future.
]]>Web Public Key Infrastructure (Web PKI) helps us on privacy and security. Trusted Certificate Authorities issue certificates and we trust them by default. Although they must follow policy before they issue any cetificate, they can still issue the certificate for wrong usage as: impersonate website or man in the middle.
Cetificate transparency allows us to monitor issued certificates and inspect them, detect any misissued certificate. Because it only appends logs, we can use this for many purposes: track history of certificates, detect new domain in real time, terminate insecure connection,…
Purpose: replacement of SSL Pinning.
SSL Pinning is good choice, but when we replace the certificate, we must rebuild our application. Dynamic SSL Pinning is another choice to resolve this issue, but we need to maintain new PKI infra. In deep dive, dynamic ssl pinning embedded 1 static hash and pulls new hash, after that, it binds new hash to hash array.
The mobile app is limited version of web browser, then many features like OCSP, Certificate transparency are missing. Banking/Finance applications must check enviroment before running, and when it’s patched to fake safe environment, we need to prevent man in the middle between our application and api server. But how do we make it transparency without SSL Pinning?
In previous blog, I showed that JA3 can help us on our purpose. But it needs to rework TLS handshake algo. We have another choice, better implementation: Certificate Transparency.
When application initializes connection, after it received certificates from server, it needs to check Signed Certificate Timestamp (SCT). Google Chrome only allows certificate with atleast 2 SCT, mobile applications should follow this rule.
By default, all new certificates will include 2 SCT in their attribute.
With custom CA and self signed certificates, they doesn’t contain those SCTs. Therefore, it needs more step to break this protection.
]]>Fido U2F is renamed to CTAP1.
FIDO UAF: FIDO Universal Authentication Framework.
WebAuthn: New API supports passwordless login, compatible with Fido U2F/UAF.
Fido2: CTAP2 + Webauthn + UserVerification.
CTAP2: CTAP1 + resident key. Because it does not have key managment, when it reachs limitation of keys’s number, it must be reset.
CTAP2.1: CTAP2 + resident key management + authenticator attestion.
WebAuthn: authentication implementation supports passwordless login, multi factor authentication.
The flow:
Relying Party <—> WebAuthn <—> Browser/App <—-> CTAP <—-> Authenticator
Non-Resident Key: Authenticator stores master key and creates seed to derive sub key (ephemeral key). The encrypted seed and public key are sent to server. Authenticator does not store any seed or information about Relying Party, then it can generate unlimited keys.
Resident Key: Authenticator stores master key and private key to storage. Based on limitation of storage, amount of Resident Keys are limited: eg 25 for Yubikey and 50 for VinCSS Fido2 key.
Non-Resident Key requires Relying Party lookup Credential ID on their side. Then user must enter their username before looking up. Server must verify that authenticator has any public key for current user unless user sends unlimited keys and performance would be degraded.
With FIDO2, Relying Party sends list of Credential ID and Authenticator looks up on their side. It improves time and authentication process. Relying Party must allow user to choose public key for multiple users on same authenticator like: acme@gmail.com or severus@gmail.com.
]]>Android provides accessibility service for disabilities people. This service can access all events on phone’s screen. The security hole is that it can access platform authenticator’s values: pin, password. It introduces downgrading from biometric to PIN/PASS and reduces the security of Passkey/Fido2 (builtin android support in app, not physical fido2 tokens).
Android has UIAutomation class and command: uiautomator, I use uiautomator - it’s same as UIAutomation class but built as binary.
After enabling adb, on lock screen, run command:
adb shell uiautomator events | grep Text
The result looks like:
20:01-03 16:11:57.531 EventType: TYPE_VIEW_CLICKED; EventTime: 387545686; PackageName: com.android.systemui; MovementGranularity: 0; Action: 0; ContentChangeTypes: []; WindowChangeTypes: [] [ ClassName: android.view.ViewGroup; Text: [DEF, 3]; ContentDescription: 3; ItemCount: -1; CurrentItemIndex: -1; Enabled: true; Password: false; Checked: false; FullScreen: false; Scrollable: false; ImportantForAccessibility: true; AccessibilityDataSensitive: false; BeforeText: null; FromIndex: -1; ToIndex: -1; ScrollX: 0; ScrollY: 0; MaxScrollX: 0; MaxScrollY: 0; ScrollDeltaX: -1; ScrollDeltaY: -1; AddedCount: -1; RemovedCount: -1; ParcelableData: null; DisplayId: 0 ]; recordCount: 0
The plain key [DEF, 3] was there. Now, the accessibility service probably can read the input from platform authenticator. With key emulation, it can authenticate as user on screen with Passkey/Fido2 now.
adb shell input tap x y - switch from biometric to pin/password geometry.
adb shell input text 13337 - input pin/password.
I tested with: Cake By VPBank and VCB Digi Bank, the both are implemented correctly to prevent the service accessing password field:
It’s very clear, the application must protect itself from accessibility service.
Almost banking applications I tested do not have enough protection.
The question is why google does not prevent accessibility obtaining the pin/password from authenticator platform. It’s system level and it introduces new risk: downgrading from biometric to pin/password.
Google promotes Passkey as new modern authentication method, but leaves the risk with user when platform authenticator is used. The application, indeed, must use biometric only by using UserVerificationMethod. There is no other solution if you use platform authenticator until Google decides patching this issue.
I have another solution, using physical tokens, which authenticate via NFC/Bluetooth like: VinCSS fido2 keys or Yubikey.
Some malwares still exploit this flaw to obtain pin/password to perform further privileged actions.
]]>NFC ID card is new challenge for fraudsters and banking/fintech. Based on cryptography, the data on card must be consistent.
NFC ID card overview:
Fraudsters must bypass SoD and BAC/PACE.
Does NFC ID Card secure onboarding process? The answer is yes and no, based on your process validation.
In my previous post, we know the way to extract data from SoD. This poste will decribe new ways to attack NFC ID Card.
Passive Authentication only validates SoD signed message and compares hash from dg1-16 values. If fraudsters generate new certificate and signed with this certificate, the party must validate again with Country Signing Certification Authority (CSCA). Because Document Signer Certificate (DCS) is intermediate certificate, it must be validated with CSCA or maintained with well known trusted list. This is mandatory requirement if the party validates passive authentication only.
Active Authentication validates authentic chip by sending some random challenge to private key and gets signed message from it. There is a problem that if the private key is DSC, fraudsters could send raw SoD data and get signed SoD. This leads to generate any valid SoD. The private key must be not DSC private key. If fraudsters are rich enough, they can create a card with their own private key, the party must validate again with well known DSC, known chip public key or CSCA.
Chip Authentication is mutual authentication between NFC chip and terminal. It validates both terminal and NFC chip before reading data. Both parties share their public keys and validate the signed message with trusted public key. The trusted public key is stored in NCF chip and terminal. This is the most secure way to validate data on NFC ID card.
If many NFC ID Cards are stolen and they are used to onboard new customers, the party must validate information with liveness detection. And server side must use vector model instead of 2D image.
With all information I share, not only banking/fintech must validate NFC ID card carefully, but also goverment needs to seperate the key for internal chip and the key for signing document.
]]>When we connect to website, the TLS helps us with confidence, security but no privacy. The eyes of ISP still see your target server via SNI. They could terminate the connection if target is forbidden.
ECH is new technique to save us from the eyes of ISP. It encrypts real SNI (inter SNI) when fake SNI ( outer SNI ) is public. No one could see real SNI if they don’t private ech key. A request has 2 SNI, one for real connection, one for public announcement.
When I read RFC, I find that ECH will help us on intercepting, filtering the connections we connect to. But I’m wrong. The RFC is still a proposal. And I have some questions, I test it and I found that some engineers implement it blindly.
ECH has 2 modes: shared mode and split mode. In shared mode, backend and frontend are on same server. It doesn’t introduce any risk, because a connection must verify TLS after decrypting the ECH.
In split mode, ECH is only useful for decrypting real SNI. Therefore, if we implement transparent proxy, we would decrypt ECH with 2 conditions: we control type65 (https resource record) dns request and we modify the record content with our ech public key.
Funny, nginx stream is one of transparent proxy, but some engineers said: no, it is not transparent proxy. What does make it transparent?
Now, we talk about the transparent proxy: the connection is not modified through proxy and proxy does not terminate TLS connection. Wait, the connection is coming from proxy, not client, it’s not transparent proxy, right? No, it’s still transparent proxy. It likes NAT mode, with src address is modified and fallbacks to real client, the confidence is mutual agreement. If you need send client ip to target, some extra steps need to be setup. In this case, the geo bypass is broken.
Now, if someone intercepts type65 dns request and modifies ech and hint ip to their server, how could we prevent this?
In split mode, the frontend verifies ECH, decrypts it and send connection to backend. It likes ECH termination, when backend must verify connection from frontend.
DNS over HTTPS is required for ECH.
In previous article, if the site supports ECH, we forward the stream to target, it’s so simple. If the sites don’t support ECH. How could we support them?
The RFC said that frontend would terminate the TLS connection and act as proxy. But if we use stream module, and decrypt only ECH on stream, then stream TLS to backend, it should work. The ECH, by the way, after decrypting to real SNI, it doesn’t involveconnection.
With this idea, sftcd project makes some modifications on openssl and nginx to support ech termination only with stream module.
Build with these repo, we setup new ECH split mode. The frontend decrypts only ECH, then streams the connection to target. The configuration looks like:
stream {
map $ssl_preread_server_name $targetBackend {
foo.example.com 127.0.0.1:9444;
hidden.infosec.xyz 157.245.205.238:443;
}
log_format basic '$ssl_preread_server_name '
'$ssl_preread_alpn_protocols '
'$remote_addr [$time_local] '
'$protocol $status $bytes_sent $bytes_received '
'$session_time "$upstream_addr" '
'"$upstream_bytes_sent" "$upstream_bytes_received"';
access_log fe/logs/access.log basic;
ssl_preread on;
ssl_echkeydir /root/ech-test/openssl/esnistuff/keys;
server {
listen 443;
# proxy_connect_timeout 1s;
# proxy_timeout 3s;
#proxy_bind $remote_addr transparent;
proxy_pass $targetBackend;
}
}
To support transparent proxy, which sends client ip to backend, setup proxy_bind with extra network configuration.
Now, as we see in this blog, the RFC said that ECH does not support transparent proxy, it’s totally wrong. Real engineer implements something with RFC referrence, but RFC is changing day by day. We use it and improve it. Don’t implement it blindly, use it with your mindset. We’re engineers, we changes everything what we want. We hack it for better world.
]]>I discovered some Kafka brokers. And when I consume topic, I get the error: failed to get offset for topic pushgatway_send Partition 3: dial tcp 172.18.19.58:9092: i/o timeout or failed to get offset for topic __consumer_offsets Partition 17: dial tcp: lookup broker on 127.0.0.1:53: no such host.
How can we retrieve kafka stream?
Kafka broker handles all requests from clients to read and write events. The topic may be on different partition.
These above errors show that no dns and no route to internal broker.
Now, as network engineer, what’s in your mind?
DNS is alias of ip address. We remap DNS to exact ip show no such host.
How’s about i/o timeout? redirect the traffic to this ip with your state full firewall. Because broker may have multiple network interfaces, and it exposed 1 interface, redirect from public interface then it should redirect to internal interface.
iptables -t nat -A POSTROUTING -p tcp --dport 9092 -j MASQUERADE
iptables -t nat -A OUTPUT -p tcp --dport 9092 -j DNAT --to-destination $kafka_public_ip:$port
This code should work, except the host is 127.*.*.*. Kernel prevents reroute localnet by default. Then we need other trick
sysctl -w net.ipv4.conf.all.route_localnet=1
Then if the partition is on broker, data should be retrieved.
]]>We must verify the Security Object Document (SoD), it contains signature, data and certificate of Document Signer (DS).
Wait, what’s Document Signer Certificate (DSC)? DSC is intermediate certificate, which is signed by Country Signing Certification Authority (CSCA). DSC is in SoD, CSCA should be public, so everyone can verify the SoD independently.
Look at SoD, we have someway to inspect it.
Extract SoD, we have base64 data, then convert it to der format:
cat sod.txt| base64 -d > sod.der
strip out SoD header, we have pkcs7 format:
openssl asn1parse -inform der -in sod.der -strparse 4 -noout -out sod.pkcs7
with sod.pkcs7 we have all data group’s hashes.
openssl cms -inform der -noverify -verify -in sod.pkcs7 -out sod.message
openssl asn1parse -inform der -in sod.message
Extract the certificate from SoD:
openssl pkcs7 -inform der -print_certs -in sod.pkcs7
Inspect certificate from SoD:
openssl pkcs7 -inform der -print_certs -in sod.pkcs7 | openssl x509 -noout -text
We know the CSCA location from DSC’s content.
If we have CSCA, we can verify SoD from our end independently:
openssl cms -inform der -verify -certfile CSCA.cert -in sod.pkcs7 -noout
If we have CSCA - which should be public by default, we will validate without problem on our side.
]]>Some years ago, I heard that zerotrust would become the future of security. Nowaday, I see zerotrust in every security product advertisment. From my perspective, the architecture of zerotrust is just combining multiple way to identify the user at specific step. It reduces the risk by: defining the context: where user is coming from, which should be validated from request, privilege should be granted on this context or not…
It is context access managament, for simply understanding.
BeyondCorp Enterprise (BCE) provides the Identity-Aware Proxy (IAP) and Access Context Manager (ACM). The IAP replies on ACM to validate user before accessing the resoures.
The BCE is powered by Chrome Browser to delivery the policy, enforce workflows.
Let digging it in deep:
Chrome has extension: Endpoint Verification and Chrome’s sync is builtin.
When user logged in Chrome’s sync, a set of policies are pushed to user from ACM included: disable proxy on chrome, some enforcements,…
Enpoint Verification has run independently of Chrome’s sync.
User must sign in chrome’s sync to obtain the policy. Endpoint verification doesnot use chrome’s sync. Then no policy is distributed to users. It leads to all problems below.
When admin uploads device’s infomation to ACM, the data is static. Microsoft Intune is example here - will collect and validate the compliance of device. Google syncs device’s status and sends to ACM.
Endpoint verification collects: encrypted disk status, mac address, serial number, device model, os version and sends to Google. It will compare with existed device’s information then assign context to a resource.
ACM has 3 levels, when you impersonate device’s infomation, no difference between them.
The flow to avoid syncing policies:
users installed extension on chromium based browsers => login to extension not chrome’s sync feature => wait for device’s info synced completely => IAP validates submission then decides access context.
Look at http requests, I found 2 endpoints allowing me to impersonate device with those values above.
This enroll endpoint allows user to register device.
This reportDeviceState report device’s infomation per 15 minutes.
The body is encrypted with key which is rotated every month.
The magic here, when obtain the valid body request, anyone of corporation can register as owner this device and allowed to access internal resources.
Enpoint Verification has another feature: start connection which is based on OpenVPN, only available on Windows and MacOS.
On Mac/Windows, Chrome uses OpenVPN to acces internal resources. On Linux, it creates ec384 key pair at $XDG_HOME/google/Endpoint Verification/certs/, but I don’t see it is used anywhere. Extension’s code shows that it’s used as client authentication.
BCE Admin Helper on Mac/Windows uses OpenVPN and creates OpenVPN Management Interface to operate with Endpoint Extension.
The flow of OpenVPN:
Now, it uses Chrome’s sync here, the refresh token is obtained from Chrome’s sync and send 2 different requests: which obtains auth for issuetoken.google.com and 1 token for authenticating with OpenVPN.
Endpoint verification sends username and 1 time password to BCE Admin Helper through socket. The password is very short TTL.
As I see, I can obtain the body of register/report device state and relay to any device. In the dashboard, admin only see my authorized device. Intune only helps check compliance, the data is static even it is encrypted. No way to check the request is coming from authorized devices.
BCE is not perfect as I know, we cannot rely on single factor: Endpoint verification. Look at the http requests, more problem I discovered when attacker can obtain device info via assets management team and 1 account was compromise. Nothing’s secure here. Corporation must use Role Based Access Control, IAP is only additional enhancement.
I reported to Google and they acknowledged this problem. In the future, I think I would like to chain some problem to access something.
]]>Mobile applications are replacing the traditional web applications. Some techniques are developed to identify the requests are coming from official application - which they own and not from emulators.
We have some enterprise’s features as Appcheck from Google and DeviceCheck from Apple.
These features use cryptography to validate whether requests are coming from authorized devices and applications. Despite the complexity of system design, we must revalidate messages from Google and Apple again before proceeding with any further action.
JA3 is developed by Salesforce. It calculates the order of Client Hello’s fields (TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats), same client and TLS library should return the same JA3. The value depends on TLS library and client version supporting TLS cipher, extension’s order. if we own the implementation in our app, the value should be fixed for whitelisting purpose.
The implementation must be based on TLS initiation, where the application constructs the Client Hello’s fields. However if the Client Hello’s order extensions are the same, how do we check if it’s authentic? Google uses GREASE for another purpose, and we can leverage this for our purpose by adding a specific GREASE extension with our chosen ciphersuite and ALPN. It requires rewriting the JA3’s calculation, as it defaults to ignoring GREASE’s values and strictly follows the extension’s order from server side.
Since the TLS handshake is invisible to our users, it should not be relayed from malious actors. Of course, it’s weaker than Appcheck, which involves two-way validation through signed requests and platform providers like Google/Apple. Nevertheless, this is the easiest way to implement and explore some new ideas.
]]>