SSH RFC User authentication Message SSH_MSG_USERAUTH_REQUEST - ssh

I'm working on some proprietary development on SSH protocol.
I want one clarification on message SSH_MSG_USERAUTH_REQUEST
As per RFC 4252, client can send this below message to server to just verify the whether publickey would be acceptable or not.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob
Once above message is replied properly by server with SSH_MSG_USERAUTH_PK_OK.
Then client sends actual authentication message described below.
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature :This extra than first message
Now I can see first message (without signature) contains publickey blob.
Should I verify the blob in first message or I should always skip that and do verification only during actual authentication message ?
I'm asking this because I have implemented my code like it does verification on both messages. But whenever i'm trying test against OpenSSH, it fails on first message for authentication but always get passed with second message. However i have debugged and found out OpenSSH is not sending same publickey blob in both message. so my question is why OpenSSH is doing so ?
Is OpenSSH is properly following RFC then seems like i should skip verifying publickey blob in first message. if i do that , am i not breaking the RFC ? doing that is right or not ?
Please help me to resolve this query.
Please let me know if more information is required.
Thanks in advance.

> Now I can see first message (without signature) contains publickey blob.
> Should I verify the blob in first message or I should always skip that and
> do verification only during actual authentication message ?
It is not clear what you mean "verify" for the first message,
but, for that message, sshd will just check if the given publickey blob exists in ~/.ssh/authorized_keys file. If it exists in that file, ssh client will receive SSH_MSG_USERAUTH_PK_OK .
> However i have debugged and found out OpenSSH is not sending same publickey
> blob in both message. so my question is why OpenSSH is doing so ?
I had implemented a ssh client in Java from scratch, but I had not recognized such OpenSSH behaviors.

Related

Informatica HTTP transformation, End point URL does not give response for GET method

I am trying to use HTTP transformation for getting response from an api. Here I am not sending any token or credentials for authorization. I am just using blanK text file as source and in HTTP transformation mentioned the URL. Below is mapping
SQ(Blank text file)-->HTTP(GET method and URL)-->http response(FlatFile)
Kindly correct if I can use blank text file as source since I am not sending any data for GET request. I am getting error as follows in the image
This error is not about data being sent. The error mentions a problem with the certificate. One of certificates in the chain is self-signed - this means (briefly) it cannot be trusted. Try reading this thread for more info.

Error 535 - sending SMTP Email to SendGrid using Telnet

I'm trying to send an SMTP Email to SendGrid using Telnet and getting "535 Authentication failed: The provided authorization grant is invalid, expired, or revoked" as a response when I enter my base64 encoded API Key.
I have authenticated my domain.
I have a Full Access SendGrid API Key (and converted it to base64).
I have created and verified a sender (but, it has a mere ...#gmail.com address).
I am following the steps at https://docs.sendgrid.com/for-developers/sending-email/getting-started-smtp.
I have tried port 25 and port 587, but I can't get beyond step 4: Enter your Base64 converted API Key.
What could be causing this error?
Do I need to create a sender with a business email address?
Do I need a paid SendGrid plan?

GPG Verify signature with public key

I have a file sent to me from a client. The file is being encrypted with public key and I have the private/public key pair, so I can decrypt and read it. We use GPG. Recently, the client started signing the file and gave me the new public key that is being used. However if I try to verify the file using
gpg --verify path/to/public/key.asc /path/to/encrypted/file
I get an error which is...gpg: verify signatures failed: Unexpected error
There is a high possibility that I'm doing something wrong, however conceptually I think I'm missing a few points.
Is there a way to verify the signature of an encrypted file using the provided public key ?
If new public key is used for signing/encryption I guess I'm going to need a new private key for the decryption? Or is it a valid scenario to use one public key for encryption and another for signing?

How does DKIM prevent impersonation?

I understand that DKIM can be used to prevent the spoofing of the "From:" header in an email. Email receivers can validate the DKIM-Signature to verify the "From:" header.
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; **d=example.com**;
h=from:to:subject:content-type; **s=smtpapi**;
bh=Qdu07jaeIipfZPkXZqzhD3HXzeo=; b=skdennE1MwDXUGfm/mox/OF8MJjaq
jrE3ETrbeE4PdvokFigU5qTuf2LJ8M9MmxCm4ji6G+CG4u7eKeCdMgAFgEwZCVhp
8UFYUwXkHFqgzKznGremWWHaXU9aIzUtWyFuOziZhqcP3Jn7/V8xyaCEIPP0dz6b
aaaI87oazVBMp8=
From: CEO <ceo#example.com>
For instance, in this email header, the DKIM-Signature says to check "smtpapi._domainkey.example.com" for the public key used to sign the email headers.
But couldn't the attacker simply replace the entire DKIM-Signature content to point to another domain that they control, and re-generate the DKIM-Signature with a set of keys that they own? This would create a valid DKIM-Signature, but would allow email spoofing.
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; **d=attackerDomain.net**;
h=from:to:subject:content-type; **s=attackerKey**;
bh=Qdu07jaeIipfZPkXZqzhD3HXzeo=; b=skdennE1MwDXUGfm/mox/OF8MJjaq
jrE3ETrbeE4PdvokFigU5qTuf2LJ8M9MmxCm4ji6G+CG4u7eKeCdMgAFgEwZCVhp
8UFYUwXkHFqgzKznGremWWHaXU9aIzUtWyFuOziZhqcP3Jn7/V8xyaCEIPP0dz6b
aaaI87oazVBMp8=
From: CEO <ceo#example.com>
Using DKIM, would an email receiver be able to determine that the first email is valid, while the second email is spoofed? How does the email receiver know which DKIM servers are authoritative for the "example.com" domain? (example.com vs attackerDomain.net)
If they created a new key pair and point it to their domain, then they would be authenticating on said domain and not the domain they are trying to spoof.
In order for them to spoof a legitimate domain, they would need to obtain your private key. Therefore, signing out on their mail server with the private key.
However, they will not pass SPF authentication because the server they are sending from are not authorized.
When your legitimate mail server sends out mail, it will sign the mail with a crypto signature using your private key. The receiving e-mail servers does a look up on the public key (remember, its your public key that you publish yourself) and validates it.
SHORT ANSWER:
DKIM makes impersonation DIFFICULT, not IMPOSSIBLE:
All a DKIM validated email proves is that it came from the domain whose key signed it. It might have come from a legitimate member of the organization, or it might be from a hacker who has gained access to their DKIM configured mail server either as an open-relay or through a compromised user's account that could put mail through the server.
But an email FAILING DKIM validation on the recipient's mail server DOES necessarily prove forgery and/or tampering in transit. A subtle but very important nuance.
So the only thing a DKIM signed email can prove in absolute terms is in the case of FAILED test: the email is either spoofed and/or has been modified in transit. An email PASSING DKIM validation only proves the mail was signed by the domain's key.
And in the case of an unauthorized user- somebody without a set of credentials issued by the organization to use their mail server- or an open-relay, then DKIM validation can actually serve to confer credibility on a bad actor leading staff to let their guard down when considering its' content.
LONGER Answer:
I received a DKIM signed email notifying me:
The password for your email account (victim#example.com) expires today 10/11/2022 12:01:50 p.m..
Keep and continue with the same password using the below portal.
I opened "view Source" and the link to the button was revealed to be:
https://jccm.com.ve/wap/MailUpdateFresh/index.html#victim#example.com
I found such a claim incredulous as I configured and administrate my own mail server. I have no relationship with any companies in Venezuela in respect to the provision of my mail services.
This clearly was a phishing email.
How did the Phishing email pass DKIM Validation?
So I checked the headers and found the email had successfully passed DKIM validation:
Received-SPF: pass (ee-smarts.top: 106.75.143.14 is authorized to use
'sales#ee-smarts.top' in 'mfrom' identity (mechanism 'a' matched))
receiver=mail.example.com; identity=mailfrom; envelope-
from="sales#ee-smarts.top"; helo=ee-smarts.top; client-ip=106.75.143.14
Authentication-Results: mail.example.com;
dkim=pass (1024-bit key; unprotected) header.d=ee-smarts.top
header.i=sales#ee-smarts.top header.a=rsa-sha1 header.s=default header.b=EO/D+N5H
Received: from ee-smarts.top (ee-smarts.top [106.75.143.14])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.example.com (Postfix) with ESMTPS id BD4245DAF4
for <victim#example.com>; Tue, 11 Oct 2022 13:02:44 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=default; d=ee-smarts.top;
Using the value of s=default in the header I then checked the TXT record for the key:
host -t txt default._domainkey.ee-smarts.top
default._domainkey.ee-smarts.top descriptive text "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCteqwk5m985UgrkYNFy0U6I6k+
QYGTilepE1Mrit5+LXAMFVfdArvbK99AljxpbSOJEOYvkQmAqgtCBgD0tlSmGjiFCQ
A7ylPzp9Owsq/OCPjpAMWA/eHwZua8FKFwPcPvRpww34z9lNr0+XJOb5+6B16tV+BK
La5y8fUgpCLKGQIDAQAB"
As far as I could see, the sending mail server WAS configured for DKIM and thus my own mail server rightly passed the validation.
So What happened?
Only two things were possible:
Either somebody was foolish enough to DKIM-sign phishing emails from their own domain OR
The phisihing email was passed through a DKIM-configured OPEN-RELAY mail server
Further investigation revealed the later was the case:
The following are attempts from publically listed open relays on
ordb.org, spamhaus.org and spamcop.net. If you're here, don't contact us
to get off. We do not determine who is in the ORDB. (These are the
connect attempts we've denied for the previous day)
What was the trick?
The miscreants weren't trying to get me to respond to the message itself, but merely trick me into clicking on a link in the email which now had DKIM-conferred credibility to trick me into compromising my email account credentials. Notice they didn't want me to CHANGE my credentials: the Phishers' defaults were "KEEP SAME PASSWORD"
Conclusion
In this case, DKIM served to confer a high level of credibility to phishers attempting to gain my email credentials. So DKIM works, but only if the DKIM configured mail server is not an open-relay. Thus, DKIM cannot 100% guarantee that impersonation is not possible in the case of an Open-Relay. This is a serious achilles' heal with DKIM from my own observations.

Using EWS to retrieve attachments from signed emails

I am using Exchange Web Services (EWS) to read emails and their attachments. I was successful until I started receiving some emails that were digitally signed. I found this link EWS: Retrieving attachments from signed emails where the solution starts off by saying "... Assuming your security context has access to the key. " which is exactly where it seems I have problem. How can I make sure my security context has access to the key? How do I achieve that? The code in the above link gives me an error: ASN1 bad tag value met
Are the messages signed or Encrypted (or both) ? To decrypt an encrypted message you would need to have the Private Key (eg for SMIME these should have been exchanged) the EnvelopedCms will search current user (security context) and computer certificate store for this certificate information. However in Exchange in addition to being stored locally the certificate that could be used to decrypt the message could be stored as an attachment on a Personal Contact or in Active Directory http://blogs.technet.com/b/exchange/archive/2008/04/23/3405402.aspx.