I noticed a strange charge for SMS messages being sent a few months back and since our code doesn't yet support sending SMS messages, I have been investigating it.
It turns out AWS Cognito is sending text messages when we call "UpdateUserPool" to +12064350128 (206-435-0128). This is not a phone number associated with our account, in our code, or with any of our personnel. What's worse is that this AWS account hosts only development environments where the public doesn't have access. So we know it's either an Amazon employee's number or a security leak (or both).
Has anybody else had this happen? A google for that phone number turned up nothing, other than it is probably from somebody in Seattle.
Does anybody know what kind of data is being sent in these messages or how to figure out what's in them? Is it passwords & confidential info?
I turned on SMS logging and this is all of the data I could gather:
{
"notification": {
"messageId": "975e37a9-a5f1-5397-b6d0-63fdbad40d83",
"timestamp": "2018-10-31 21:21:41.756"
},
"delivery": {
"destination": "+12064350128",
"priceInUSD": 0.00645,
"smsType": "Transactional",
"providerResponse": "Message has been accepted by phone",
"dwellTimeMs": 168,
"dwellTimeMsUntilDeviceAck": 2514670
},
"status": "SUCCESS"
}
I received the following from AWS support. Looks like it's innocuous. Whew!
I completely understand your concern of AWS Cognito sending messages
to phone number +12064350128. I got in touch with the Cognito team and
found that it is an expected behaviour that when you make an
UpdateUserPool API call, a message is sent out to +12064350128 and
this applies to all AWS accounts. The phone number +12064350128 is an
internal number and a message to this number is sent out to verify if
Cognito and SNS are integrated correctly so that Cognito can send SMS
to other numbers. Please note that no security information including
passwords is being passed in the content of this SMS message, It's
just a sample message indicating SNS is integrated with Cognito
correctly.
Please be rest assured that we treat customer's data with utmost
privacy and we have a strict security mechanism in place to check any
fraudulent activities.
I also completely agree that the above behavior needs to be documented
and hence I will be reaching out to the Cognito team to get this
updated in our docs to avoid further confusion.
Related
Brief Description:
What is an unregistered long code when it comes to an application sending SMS messages?
Plus, I'm using AWS SNS to send text messages through a node js application. Do I have to switch to Amazon Pinpoint to send to SMS messages?
Detailed:
I got an email from AWS saying that the US telecom carriers would no longer support sending Application-To-Person (A2P) SMS messages over unregistered long codes
It then says If you are using long codes, Amazon strongly recommends that you complete the transition to toll free numbers, 10DLC, or short codes.
In addition to that it appears that AWS wants me to use Amazon Pinpoint to send sms messages and email. And the deadline to make the change is on June 1, 2021.
First off, whats an unregistered long code? I imagine those are the long international phone #'s you'd see for someone in Europe or Latin America. But to be sure I looked at AWS's docs and don't really see an example of one.
I have a node app running on an EC2 instance that uses AWS SNS to send messages to US text messages based off certain business logic. The phone numbers in the config files have the following format: US Country Code - 10 Digit phone Number so an example is +13215441222 which is a 10DLC plus the us country code.
In other words, my app is already sending text messages using 10DLC but its doing so using AWS SNS. So do I even have to do anything that the AWS email recommends?
I don't have aws support to ask them this question so I'm asking it here.
In addition to that it appears that AWS wants me to use Amazon Pinpoint to send sms messages and email.
You can still use SNS to send SMS messages, either using 10DLC, short codes or toll-free.
First off, whats an unregistered long code?
It is any number used in application-to-person (A2P) SMS messaging not registered with The Campaign Registry (TCR)
Let me quote documentation:
In order to use a 10DLC number, first register your company and create a 10DLC campaign using the Amazon Pinpoint (not Amazon SNS) console. AWS shares this information with The Campaign Registry, a third party that approves or rejects your registration based on the information. In some cases, registration occurs immediately. For example, if you've previously registered with The Campaign Registry, they might already have your information. However, some campaigns might take one week or longer for approval. After your company and 10DLC campaign are approved, you can purchase a 10DLC number and associate it with your campaign. Requesting a 10DLC might also take up to a week for approval. Although you can associate multiple 10DLCs with a single campaign, you can't use the same 10DLC across multiple campaigns. For each campaign you create, you need to have a unique 10DLC.
Reference: https://docs.aws.amazon.com/sns/latest/dg/channels-sms-originating-identities-10dlc.html
So do I even have to do anything that the AWS email recommends?
Yes, you need to switch to 10DLC, toll-free or short codes.
Short codes reference: https://docs.aws.amazon.com/sns/latest/dg/channels-sms-originating-identities-short-codes.html
Blog post about 10DLC: https://aws.amazon.com/blogs/compute/provisioning-and-using-10dlc-origination-numbers-with-amazon-sns/
As part of some testing that I was doing, I replied STOP to an SMS message that was sent via Amazon's Pinpoint service. I received the acknowledgement that I had been removed from further notifications.
I want to opt back in to receiving those messages, but I can't figure out how to do that. I looked at the Pinpoint documentation and I did not see a way to do it. I looked in the Amazon Pinpoint Console and I did not see a way to remove a number from the blacklist. I have tried the standard terms that other SMS providers use such as UNSTOP, UNBLOCK, and START, but none of those work either. Does anyone have any suggestions. I do not want to contact Amazon support about this unless I have to.
As described here: https://docs.aws.amazon.com/cli/latest/reference/sns/opt-in-phone-number.html
aws sns opt-in-phone-number --phone-number ###-###-####
You can also use AWS Console -> Amazon SNS -> Mobile -> Text Messaging(SMS) section to see a list of opt-out phone numbers that was done through Pinpoint and choose to opt-in these numbers...
AWS Pinpoint has not come up with the APIs to check if the number is opted out or not. You can use the AWS SNS APIs for checking this as well for marking a mobile number as active again.
I've been trying to figure this out as well and I think I have a solution from a set of documentation I found about setting up Pinpoint. Below is python pseudocode; from my understanding we just have to update the "OptOut" status for the endpoint (i.e. the phone number that originally opted out).
# Python pseudo code with comments
import boto 3
import datetime
pinpoint = boto3.Session(**login_kwargs).client("pinpoint")
opt_in_response = pinpoint.update_endpoint(
ApplicationId="<App ID from your project>",
EndpointId="<Endpoint you are updating>", # Same as your phone number?
EndpointRequest={
"Address": "<Phone you are updating>",
"ChannelType": 'SMS',
"OptOut": "NONE", # Change from "ALL" (which is opt-out) to "NONE", opt-in
"EffectiveDate": datetime.datetime.utcnow().isoformat(),
"Attributes": {
"OptInTimestamp": [datetime.datetime.utcnow().isoformat()]
}
}
)
I attempted to follow this documentation https://docs.aws.amazon.com/pinpoint/latest/developerguide/pinpoint-dg.pdf (the relevant stuff starts on page 92), which happens to not be in Python.
I wasn't successful but I'm pretty sure this is how you should be able to opt back in (if anyone who knows node.js can verify this solution that'd be awesome).
Currently, the message specified in the Document field while creating alerting policy appears in the Document field of the Stackdriver alert email.
I would like to overwrite the entire email message body with my custom content.
How can I overwrite the message body of Stackdriver Alert email with my custom message?
Is there any other workaround to do this?
You should be able to send the notification to a webhook, and this could directly be an HTTP-triggered Cloud Function.
This Cloud Function would receive all the information from the alert, and you can follow this tutorial to use SendGrid to send your alerts.
This is a lot more complex than just setting the email notifications, but also provides you with an amazing flexibility regarding alerts, as you'll be able to not just write the message however you want, but you could process the data in any way you want:
You have low priority alerts? Then store them and just send a digest
once in a while instead of spamming.
Want to change who is sent the
alert depending on a calendar rotation? Use the function to look up
who should be notified.
And those are just some random quick ideas I got while writing this message.
The information provided in the POST body is this one (that's just a sample):
{
"incident": {
"incident_id": "f2e08c333dc64cb09f75eaab355393bz",
"resource_id": "i-4a266a2d",
"resource_name": "webserver-85",
"state": "open",
"started_at": 1385085727,
"ended_at": null,
"policy_name": "Webserver Health",
"condition_name": "CPU usage",
"url": "https://app.google.stackdriver.com/incidents/f333dc64z",
"summary": "CPU for webserver-85 is above the threshold of 1% with a value of 28.5%"
},
"version": 1.1
}
You can create a single webhook that handles all the alerts, or you can create a webhook on a per-policy basis to handle things separately.
Setting up Meteor to use "out of the box" AWS SES is simple, and one can use native Meteor "Email" methods without modification.
Steps to implement this can be found here. Thanks to Brian
Shamblen for putting together a detailed answer.
But one caveat with the "out of the box" SES is you need to both verify the sender and receiver email address.
To remedy this, you can put in a request with AWS SES for what they call, Production Access.
And further, according to Brian Shamblen,
The process to get production access is rather complicated. One will
need to handle bounce and complaint notifications from SES and prevent
messages from being sent to those addresses in the future.
Question
What is the Meteor code involved in handling bounce and complaint notifications from SES and prevent messages from being sent to those addresses in the future?
EDIT: Made modifications to question for clarity.
Requesting production access is fairly straightforward. You just need to contact them and they usually give it to you in a couple of hours.
Information about the process is here: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html
Load up the URL : http://aws.amazon.com/ses/fullaccessrequest/ and let them know what you will be sending via Emails, for example if you will be sending transaction based email (verification of a transaction, etc)
With production access you can either send email from:
A specific verified email address, where you will be asked to click a link to an email sent to that address to verify you own it
Any email under an entire domain. Under this process you prove you own the domain by editing its DNS records to contain a 'key'.
Most use cases are covered under production access, they typically give you 2000 emails a day and rate limit emails to 5/sec (they queue them so the maximum send rate is 5/sec). If you need more than this you can contact them to raise this additionally.
The process of verification is to stop people quickly creating AWS accounts to mass-spam users. If they allowed this straight-off then AWS IPs would be looked at as spam by other email providers.
For bounce notifications, SES tracks these, and you have to make sure that you don't get an above average bounce rate. Typically these would come from sending unsolicited email, which I wouldn't advise sending via SES.
Production access is only approved by the AWS team. Wait a bit and they should easily give you 2.000 emails/day for free.
As per bounces-unsubscribes... You'll need to have the SES API notify you of each email address which has been 'marked' with such status.
You should store all those email addresses somewhere and tell your app not to send them ANYTHING else in the future.
I am fresh in implementing Amazon Web services. I am working on implementing an application for sending bulk emails from a queue. I have to check emails and remove non-verified emails from the queue before sending.
My question is: Is there any method available in Amazon to check whether emails are valid or not?
From your question, it is not clear whether you want to:
1-avoid sending messages to malformed email addresses; or
2-avoid sending messages to email addresses which are not verified under your AWS account.
The answer for 1 is spread in different forms accross forums, SO, etc. You either do it simple, i.e., craft a short and clear regular expression which validates roughly 80% of the cases, or you use a very complex regular expression (in order to validate against the full compliance -- good luck, check this example), check whether the domain is not only valid but also up and running, and, last but not least, check if the account is valid under that domain. Up to you. I'd go with a simple regex.
The answer for 2 is available at Verifying Email Addresses in Amazon SES -- the Amazon SES API and SDKs support the operations below, so you should be covered in any case:
Using the Amazon SES API
You can also manage verified email addresses with the Amazon SES API. The following actions are available:
VerifyEmailIdentity
ListIdentities
DeleteIdentity
GetIdentityVerificationAttributes
Note
The API actions above are preferable to the following older API actions, which are deprecated as of the May 15, 2012 release of Domain Verification.
VerifyEmailAddress
ListVerifiedEmailAddresses
DeleteVerifiedEmailAddress
You can use these API actions to write a customized front-end application for email address verification. For a complete description of the API actions related to email verification, go to the Amazon Simple Email Service API Reference.
You can use the "getIdentityVerificationAttributes" operation to check whether emails are valid or not. You can use this as shown below:
var params = {
Identities: arr // It is a required field (array of strings).
};
ses.getIdentityVerificationAttributes(params, function(err, data) {
if(err)
console.log(err, err.stack); // an error occurred
else
console.log(data); // successful response
});
And the Response will be:
{ ResponseMetadata: { RequestId: '7debf2356-ddf94-1dsfe5-bdfeb-efsdfb5b653' },
VerificationAttributes:
{ 'abc#gmail.com': { VerificationStatus: 'Pending' },
'xyz#gmail.com': { VerificationStatus: 'Success' } } }
If there is an email-id which is not sent previously for email verification request, then there is no key present in 'VerificationAttributes' object.
AmazonSimpleEmailServiceClient ses= new AmazonSimpleEmailServiceClient(credentials);
List lids = ses.listIdentities().getIdentities();
if (lids.contains(address)) {
//the address is verified so
return true;
}