# Arkadiy Tetelman A security blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Reverse Engineering Protobuf Definitions From Compiled Binaries DevFeed: [Reverse Engineering Protobuf Definitions From Compiled Binaries]() Original publisher: [Read original article]() Published: 2024-03-03T08:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [Reverse Engineering](), [API](), [Command-line interface](), [Code](), [Compiler](), [Go Language]() Tags: [api](), [binaries](), [cli](), [code](), [compiler](), [golang](), [protobuf](), [reverse-engineering]() ### AI overview This tutorial explains how protodump extracts protobuf definitions from compiled binaries. It covers how protoc-generated Go code stores FileDescriptor data, how runtime reflection uses those definitions, and how to locate and decode the embedded data in a binary. ### Source excerpt A few years ago I released protodump, a CLI for extracting full source protobuf definitions from compiled binaries (regardless of the target architecture). This can come in handy if you're trying to reverse engineer an API used by a closed source binary, for instance. In this post I'll explain how it works, but first, a demo: How does it work? To understand how it works, lets take a look at a small test.proto example: syntax = "proto3"; option go_package = "./;helloworld"; message HelloWorld { string name = 1; } If we compile this with protoc to golang we'll get some golang code that defines the object type, creates getters and setters for the name field, and so on. We can use it as follows: func main() { obj := helloworld.HelloWorld{ Name: "myname", } fmt.Printf("%s\n", obj.GetName()) } $ go run main.go myname However protobuf also supports runtime reflection. Rather than invoking the getter method at compile time, we can fetch the list of fields and query them at runtime: func main() { obj := helloworld.HelloWorld{ Name: "myname", } fields := obj.ProtoReflect().Descriptor().Fields() for i := 0; i < fields.Len(); i++ { field := fields.Get(i) value := obj.ProtoReflect().Get(field).String() fmt.Printf("Field %d has value '%v'\n", i, value) } } $ go run main.go Field 0 has value 'myname' How can the generated golang code know the field names and types at runtime like this? The protoc compiler stores a whole copy of the protobuf definition in the generated output code. Here is the complete protoc output for our HelloWorld message type, and in particular, lines 72-78 store this protobuf definition: var file_test_proto_rawDesc = []byte{ 0x0a, 0x0a, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x22, 0x20, 0x0a, 0x0a, 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x42, 0x0f, 0x5a, 0x0d, 0x2e, 0x2f, 0x3b, 0x68, 0x65, 0x6c, 0x6c ## Detecting Manual AWS Actions: An Update! DevFeed: [Detecting Manual AWS Actions: An Update!]() Original publisher: [Read original article]() Published: 2024-02-18T08:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [Amazon Web Services](), [AWS CloudTrail](), [AWS IAM](), [Infrastructure as code](), [okta](), [API](), [Command-line interface]() Tags: [api](), [aws](), [cli](), [cloudtrail](), [iam](), [infrastructure-as-code](), [okta]() ### AI overview An update to an approach for detecting manual AWS actions performed by employees outside an approved infrastructure-as-code workflow. It replaces user-agent detection with CloudTrail event checks based on employee role session names and the readOnly flag, covering console and API activity. ### Source excerpt Back in 2019 I published Detecting Manual AWS Console Actions, which continues to be one of the more popular articles on this blog. In this post I'll do a refresh with what's changed in my approach over the last 5 years. The primary 3 updates are: A new trigger mechanism An updated list of filtered IAM actions, and Detecting session name bypasses Note that this post assumes you have context from the prior post, so if you haven't read that then I recommend at least giving it a skim first. The premise is how to detect when employees do something in your AWS account outside of an approved infrastructure-as-code workflow. A new trigger mechanism In the original post I spent a lot of time and energy trying to capture various user-agent combinations to detect console actions. This was misguided for several reasons: 1) It was a manual and error-prone process. It would never capture all user-agent combinations from the AWS Console, nor would it keep up with new changes over time 2) I was only capturing user-agents from the AWS Console and not from the aws-cli or other api clients. The term "Console" actions is a misnomer - what I really care about are "Manual" actions from employees, whether they're through the console or through the api The approach we take at my current employer is instead the following: The only way that employees can access AWS is through Okta / AssumeRoleWithSAML. There are no other mechanisms for an employee to get access to AWS (zero IAM users, etc) When someone assumes an employee role, Okta is configured to set the AWS role session name to be the employee email address The above two conditions are an invariant for employee access to AWS. And to detect when an employee performs a manual AWS action we simply check each Cloudtrail event for: the role session name ends with @employer.com, and the event has the readOnly flag set to false and isn't further filtered out below This solves both problems above - console and api actions are both alerted on an ## Scanning your iPhone for Pegasus, NSO Group's malware DevFeed: [Scanning your iPhone for Pegasus, NSO Group's malware]() Original publisher: [Read original article]() Published: 2021-07-25T07:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [Malware](), [iOS](), [Mobile](), [Android](), [Open Source](), [Filesystems](), [Jailbreak]() Tags: [android](), [backup](), [documentation](), [filesystem](), [forensic](), [infection](), [ios](), [iphone](), [jailbreak](), [malware](), [mobile](), [open-source](), [safari](), [scanner]() ### AI overview A practical guide to scanning an iPhone for indicators of Pegasus, NSO Group's mobile malware, using Amnesty International's open-source Mobile Verification Toolkit. It explains the trade-offs between scanning a device backup and a filesystem dump from a jailbroken device. ### Source excerpt In collaboration with more than a dozen other news organizations The Guardian recently published an exposé about Pegasus, a toolkit for infecting mobile phones that is sold to governments around the world by NSO Group. It's used to target political leaders and their families, human rights activists, political dissidents, journalists, and so on, and surreptitiously download their messages/photos/location data, record their microphone, and otherwise spy on them. As part of the investigation, Amnesty International wrote a blog post with their forensic analysis of several compromised phones, as well as an open source tool, Mobile Verification Toolkit, for scanning your mobile device for these indicators. MVT supports both iOS and Android, and in this blog post we'll install and run the scanner against my iOS device. Choosing your options For iPhones, MVT can either run against a device backup or a full file system dump (which is only available from jailbroken devices). The device backup method has access to less forensic data than the filesystem dump but has the benefit that you don't need to jailbreak your device. MVT conveniently documents which forensic artifacts are available to which method - the following artifacts are not available when using the backup method: cache_files.json net_usage.json safari_favicon.json version_history.json webkit_indexeddb.json webkit_local_storage.json webkit_safari_view_service.json The same documentation link also explains what data each file contains and where it's sourced from, and Amnesty's blog post describes in more detail how each data type is relevant for detecting Pegasus. For instance for the Safari favicon data (safari_favicon.json) they write: Although Safari history records are typically short lived and are lost after a few months (as well as potentially intentionally purged by malware), we have been able to nevertheless find NSO Group's infection domains in other databases of Omar Radi's phone that did not appear in Safa ## Getting Partial AWS Account IDs for any Cloudfront Website DevFeed: [Getting Partial AWS Account IDs for any Cloudfront Website]() Original publisher: [Read original article]() Published: 2021-07-09T07:00:00Z Content type: article Language: en Sources: [Arkadiy Tetelman]() Topics: [Amazon Web Services](), [AWS Certificate Manager](), [bug](), [TLS (Transport Layer Security)](), [private key](), [public key](), [domain]() Tags: [aws](), [bug](), [certificates](), [domain](), [private-key](), [public-key](), [ssl](), [tls](), [website]() ### AI overview This article explains how a bug in AWS Certificate Manager could bypass CloudFront's TLS-certificate requirement for looking up partial AWS account and distribution IDs associated with a domain. It describes manipulating RSA private-key parameters to match a public certificate. ### Source excerpt Yesterday Amazon released a new Cloudfront API that returns partial AWS account ids and Cloudfront distribution ids associated with some given domain name, to help you determine which of your own AWS accounts serves traffic for that domain. In Cloudfront, a domain alias can only be associated with a single distribution globally across all AWS accounts, and for companies that have a lot of assets it can be difficult to track down which account owns a given domain - this API helps solve that problem. Of course it would be problematic if we could lookup account ids (even partial ones) for arbitrary websites, so to help protect against this information leakage Amazon requires you to have a valid TLS certificate for the domain name you want to query. This is called out in their documentation: To list conflicting aliases, you provide the alias to search and the ID of a distribution in your account that has an attached SSL/TLS certificate that includes the provided alias. As it turns out it's possible to completely bypass this restriction, because ACM has a bug that lets you import certificates without a valid private key. Most people are aware that RSA consists of a public and private keypair which correspond to each other, with the public key completely derived from the private key. That is - if you give me only a private key, I can easily give you the public key that matches the private one. However what some people find surprising is that even though the public key is derived, the private key contains a full copy of the public key (the N and e parameters, in RSA parlance) in order to save on computation time. So if we want to find the partial AWS account id for some domain, we can fetch the real public certificate for that domain, generate a random private key, and update the precomputed public key parameters on our private key to be the same as the public key on the certificate we want to impersonate. ACM has a bug in that it does not validate the private key truly co ## A Summary of Zoom's Bad Security Month DevFeed: [A Summary of Zoom's Bad Security Month]() Original publisher: [Read original article]() Published: 2020-05-23T07:00:00Z Content type: opinion Language: en Sources: [Arkadiy Tetelman]() Topics: [Security](), [Encryption](), [Vulnerabilities](), [End-to-End Encryption](), [SDKs](), [Mobile](), [Linux]() Tags: [encryption](), [google](), [linux](), [mobile](), [sdk](), [security](), [security-and-privacy](), [vulnerabilities](), [zoom]() ### AI overview An analysis of Zoom's 2020 security and privacy controversies, including meeting access controls, Facebook SDK data sharing, misleading end-to-end encryption claims, encryption weaknesses, data leaks, desktop vulnerabilities, and Linux client security practices. ### Source excerpt As a result of the global pandemic Zoom has seen an explosion in usage (going from 10M to 200M daily active users) and has received quite a bit more scrutiny into their security and privacy practices. This has caused them to get reamed in the press for a number of issues: Their default meeting settings allowed anyone to join meetings just by entering the meeting id, which is easily enumerable. This lead to trolls "zoombombing" meetings and harassing people. The Zoom mobile app was using the Facebook SDK, which was sending device id and other data to Facebook, even if you don't have a Facebook account and before you could accept (or reject) any privacy policy. Zoom's marketing materials falsely claimed their video streams were end-to-end encrypted. Though there's no end-to-end encryption, Zoom does provide encryption in transit. However it turned out they were routing the decryption keys through servers in China, and were using weak encryption. They were leaking thousands of email addresses and profile photos. Their desktop apps got hit with multiple "0day" (brand new, unpatched) vulnerabilities: here, here, and here (all separate issues!). They also got called out for their missing basic security practices on their linux client. All this press caused the Zoom app to be banned by Google, SpaceX, many school districts, and other organizations. There were actually even more negative headlines than this but you get the idea. I have mixed feelings about all this. Undoubtedly Zoom has underinvested in security and is now paying a heavy price for it. At the same time I think some of these issues have been blown out of proportion. Consider just 3 of the issues linked above: 1) For the "end-to-end encryption" issue, there's not a single commercial teleconferencing product available today that provides end-to-end encryption (more on this later) - it is simply not an expectation that I ever had about their product. Obviously it was a mistake for them to claim they had it in th ## Detecting Manual AWS Console Actions DevFeed: [Detecting Manual AWS Console Actions]() Original publisher: [Read original article]() Published: 2019-11-12T08:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [Amazon Web Services](), [AWS CloudTrail](), [Infrastructure as code](), [Security](), [Terraform]() Tags: [aws](), [aws-cloudtrail](), [code-review](), [console](), [infrastructure-as-code](), [security](), [terraform]() ### AI overview This post explains how to detect manual changes made through the AWS Console using AWS CloudTrail alerting rules. It discusses the security and operational risks of console-based infrastructure changes, while advocating a balance between infrastructure as code and engineers' need for console access. ### Source excerpt UPDATE 2/18/24: Check out the update to this post 🙂 In this post I'll describe a set of AWS Cloudtrail alerting rules that let you detect when someone makes a manual change in your AWS Console. This has been one of the highest signal / lowest noise alerts we created in our organization - it lets us know when engineers do things like, i.e., manually add new security group ingress rules through the AWS Console: Motivation It's not a controversial opinion that making infrastructure changes through the AWS Console will never scale beyond the smallest organizations and projects. Engineers make temporary changes and forget to revert them, waste money with test infrastructure that never gets spun down, and step on each other's toes with conflicting changes. It leaves your AWS account in an ill-defined, unreproducible state. A better approach is practicing infrastructure as code, using tools like AWS Cloudformation, Terraform, or Cloud Development Kit (CDK). Using these tools all infrastructure can go through code review, maintain a change management history, and be searchable & auditable. At the same time it is undeniably true that certain actions are simply easier through the AWS Console - engineers might need to test some functionality quickly which would otherwise be cumbersome through, i.e. Terraform. As security practitioners this is unfortunate for us since manual changes are much more likely to unintentionally expose something to the internet or cause other problems. It would be very easy for us "solve" this issue by blocking engineering access to the AWS Console, but since security is an enabling function I want engineers to have the access they need to do their jobs and iterate quickly. Thus at my organization we grant all engineers full access to the AWS Console, and instead alert whenever they make a manual change. Together with our other AWS security controls, this strikes a good balance between usability and safety. Detecting AWS Console changes This sounds gr ## Pair Locking your iPhone with Configurator 2 DevFeed: [Pair Locking your iPhone with Configurator 2]() Original publisher: [Read original article]() Published: 2019-10-07T07:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [iphone](), [Security](), [iOS](), [bootrom](), [locking](), [Authentication]() Tags: [authentication](), [bootrom](), [forensic](), [ios](), [iphone](), [security]() ### AI overview A tutorial on pair-locking an iPhone with Configurator 2 to prevent forensic tools from pairing with the device, imaging it, scanning its contents, or extracting app authentication tokens. It explains the privacy rationale and how pairing works. ### Source excerpt In response to the recent iphone bootrom bug (and also because I was already in the market for a new phone), I recently purchased a new iPhone XR. This gave me a chance to re-run the steps required to pair lock the device, a process which prevents law enforcement from using forensics tools against your phone, and the result of which is this blog post. It covers: Why pair lock your device? How does it work? Supervising and pair locking your device Why pair lock your device? It's an unfortunate state of affairs but people's digital privacy is increasingly under attack by law enforcement agencies, especially at protests, airports, and border crossings. Articles like the following have become all too common: A US-born NASA scientist was detained at the border until he unlocked his phone Man sues feds after being detained for refusing to unlock his phone at airport Phone and laptop searches at US border 'quadruple' US deports foreign student 'over friends' social media posts' Are Police Searching Inauguration Protesters' Phones? and closer to my home in San Francisco we see tweets like this one: By pair locking your device you will prevent iPhone forensics tools from being able to connect to your device, image it, scan through your messages and camera roll, read your contacts and call history, etc - even if you've been compelled by law enforcement to unlock your device! They can still manually look through your unlocked phone contents, but they can't image the device for offline analysis, they can't run automated content scanners, and they no longer get access to your various app authentication tokens. I originally learned about this feature / unintended side effect from Jonathan Zdziarski's excellent blog post about it. Jonathan was a well-known iOS security researcher who now works on Apple's security team. Unfortunately since joining Apple he stopped blogging about iOS security (and deleted his twitter), and the instructions in his original 2014 blog are now slightly ## Quantifying Untrusted Symantec Certificates DevFeed: [Quantifying Untrusted Symantec Certificates]() Original publisher: [Read original article]() Published: 2018-02-04T08:00:00Z Content type: article Language: en Sources: [Arkadiy Tetelman]() Topics: [Certificate Transparency](), [TLS (Transport Layer Security)](), [Security](), [certificates](), [Chrome](), [incident](), [Internet](), [Website](), [Google](), [Mozilla]() Tags: [browser](), [certificate-transparency](), [certificates](), [chrome](), [google](), [incident](), [internet](), [mozilla](), [security](), [tls](), [website]() ### AI overview This article quantifies websites affected by Google Chrome's distrust of Symantec TLS certificates. It describes the certificate misissuance incidents behind the decision and explains a scanner that detects affected certificates using Chrome's logic across the Alexa Top 1 Million sites. ### Source excerpt I was reading Hackernews the other day when I came upon the following tweet: which made me curious to quantify exactly how many and which sites will have their trust removed. This blog post answers these questions by writing a scanner to detect bad Symantec certificates (using the same logic Google Chrome uses), and running it against the Alexa Top 1 Million sites. But first, some context. Why, and when, is Google distrusting Symantec TLS certificates Symantec is a certificate authority, capable of issuing certificates for any website. As with all CAs, they have an incredible amount of power over the trust ecosystem of the internet, and must follow a strict set of operational requirements (called the Baseline Requirements). These requirements are set forth by the CA/Browser Forum, a consortium of certificate authorities and browser vendors, in order to hold CAs responsible and accountable for the trust we place in them. However, Symantec has had a long history of TLS/PKI incidents. Two of the more notable incidents are: In September 2015 they misissued ~2600 valid certificates that were never requested, including certificates for google.com and www.google.com. As a result of this incident Google required all Symantec certificates to be published into the Certificate Transparency logs. Symantec also fired the employees who issued the Google certificates, due to backlash and perhaps pressure from Google. In January 2017, it came to light that Symantec had misissued at least 30,000 certificates over a period of several years. There's a long public thread on the mozilla.dev.security.policy group with all the details and fallout. As a result of these incidents, in September 2017 Google announced a timeline for completely distrusting Symantec certificates, which meant certain death for Symantec's PKI business. Symantec was understandably displeased and published their own open letter in response, objecting to Google's actions. However in the end Symantec relented, and dec ## Deploying EFF's Certbot in AWS Lambda DevFeed: [Deploying EFF's Certbot in AWS Lambda]() Original publisher: [Read original article]() Published: 2018-01-26T08:00:00Z Content type: tutorial Language: en Sources: [Arkadiy Tetelman]() Topics: [AWS Lambda](), [AWS IAM](), [Amazon EC2](), [Python](), [TLS (Transport Layer Security)](), [Amazon Route 53](), [AWS Certificate Manager]() Tags: [aws](), [aws-lambda](), [certificates](), [configure](), [dns](), [ec2](), [gcc](), [iam](), [openssl](), [python](), [security](), [ssh](), [tls](), [wget](), [x86-64]() ### AI overview A tutorial explains how to deploy EFF's Certbot in AWS Lambda to automate TLS certificate renewal. It covers packaging Certbot and its Python dependencies, creating an IAM role, scheduling daily execution, and importing renewed certificates into Amazon Certificate Manager. ### Source excerpt This post describes the steps needed to deploy Certbot (a well-maintained LetsEncrypt/ACME client) inside AWS Lambda. The setup used below is now powering 100% automated TLS certificate renewals for this website - the lambda runs once a day and if there's less than 30 days remaining on my existing cert it will provision a new one and import it to be served by my CDN. The post is broken down into 3 sections: building a self-contained, deployable zip file that includes certbot and its dependencies (the bulk of the work) creating an IAM role for the lambda function that gives it the necessary permissions to execute creating a CloudWatch timer that triggers the lambda function once a day Building a self-contained certbot zip file Certbot is written in python and supports both python 2 & 3. We're going to use Lambda's python 3.6.1 runtime, and to make sure all our packages and dependencies work in the Lambda environment we'll perform all the installation steps in an environment identical to the Lambda one. Amazon's documentation states: The underlying AWS Lambda execution environment is based on the following: Public Amazon Linux AMI version (AMI name: amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2) which can be accessed here. So we'll need to bring up an EC2 instance like that. Step 1: Launch an EC2 instance with the amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2 AMI. You can use the cheapest instance with all the default settings - it will not require any IAM permissions or security group configuration. Step 2: SSH onto the instance and install python3 (it's not installed by default): # Install python 3.6.1 sudo yum install -y gcc zlib zlib-devel openssl openssl-devel wget https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tgz tar -xzvf Python-3.6.1.tgz cd Python-3.6.1 && ./configure && make sudo make install Step 3: Install virtualenv to isolate all the python dependencies, install certbot, and zip it up: # Install & activate virtualenv sudo /usr/local/bin/pip3 install virt