Security updates have been issued by Arch Linux (ffmpeg, lib32-libgcrypt, libgcrypt, linux-zen, and newsbeuter), Debian (emacs25, freexl, and tomcat8), Fedora (cyrus-imapd, FlightGear, freexl, gdm, kernel, LibRaw, ruby, and xen), Gentoo (binutils, chkrootkit, curl, gdk-pixbuf, gimps, git, kpathsea, mod_gnutls, perl, squirrelmail, subversion, supervisor, and webkit-gtk), Mageia (389-ds-base, kernel, kernel-linus, kernel-tmb, and mpg123), openSUSE (ffmpeg, ffmpeg2, qemu, and xen), Slackware (kernel), SUSE (xen), and Ubuntu (gdk-pixbuf).
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/04/advances_in_ad_.html
Ad blockers represent the largest consumer boycott in human history. They’re also an arms race between the blockers and the blocker blockers. This article discusses a new ad-blocking technology that represents another advance in this arms race. I don’t think it will “put an end to the ad-blocking arms race,” as the title proclaims, but it will definitely give the blockers the upper hand.
The software, devised by Arvind Narayanan, Dillon Reisman, Jonathan Mayer, and Grant Storey, is novel in two major ways: First, it looks at the struggle between advertising and ad blockers as fundamentally a security problem that can be fought in much the same way antivirus programs attempt to block malware, using techniques borrowed from rootkits and built-in web browser customizability to stealthily block ads without being detected. Second, the team notes that there are regulations and laws on the books that give a fundamental advantage to consumers that cannot be easily changed, opening the door to a long-term ad-blocking solution.
Now if we could only block the data collection as well.
To help you secure your AWS resources, we recommend that you adopt a layered approach that includes the use of preventative and detective controls. For example, incorporating host-based controls for your Amazon EC2 instances can restrict access and provide appropriate levels of visibility into system behaviors and access patterns. These controls often include a host-based intrusion detection system (HIDS) that monitors and analyzes network traffic, log files, and file access on a host. A HIDS typically integrates with alerting and automated remediation solutions to detect and address attacks, unauthorized or suspicious activities, and general errors in your environment.
In this blog post, I show how you can use Amazon CloudWatch Logs to collect and aggregate alerts from an open-source security (OSSEC) HIDS. I use a CloudWatch Logs subscription to deliver the alerts to Amazon Elasticsearch Service (Amazon ES) for analysis and visualization with Kibana – a popular open-source visualization tool. To make it easier for you to see this solution in action, I provide a CloudFormation template to handle most of the deployment work. You can use this solution to gain improved visibility and insights across your EC2 fleet and help drive security remediation activities. For example, if specific hosts are scanning your EC2 instances and triggering OSSEC alerts, you can implement a VPC network access control list (ACL) or AWS WAF rule to block those source IP addresses or CIDR blocks.
The following diagram depicts a high-level overview of this post’s solution.
Here is how the solution works:
- On the target EC2 instances, the OSSEC HIDS generates alerts that the CloudWatch Logs agent captures. The HIDS performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, real-time alerting, and active response. For more information, see Getting started with OSSEC.
- The CloudWatch Logs group receives the alerts as events.
- A CloudWatch Logs subscription is applied to the target log group to forward the events through AWS Lambda to Amazon ES.
- Amazon ES loads the logged alert data.
- Kibana visualizes the alerts in near-real time. Amazon ES provides a default installation of Kibana with every Amazon ES domain.
For the purposes of this post, the primary OSSEC HIDS deployment consists of a Linux-based installation for which the alerts are generated locally within each system. Note that this solution depends on Amazon ES and Lambda in the target region for deployment. You can find the latest information about AWS service availability in the Region table. You also must identify an Amazon Virtual Private Cloud (VPC) subnet that has Internet access and DNS resolution for your EC2 instances to provision the required components properly.
To simplify the deployment process, I created a test environment AWS CloudFormation template. You can use this template to provision a test environment stack automatically into an existing Amazon VPC subnet. You will use CloudFormation to provision the core components of this solution and then configure Kibana for alert analysis. The source code for this solution is available on GitHub.
This post’s template performs the following high-level steps in the region you choose:
- Creates two EC2 instances running Amazon Linux with an AWS Identity and Access Management (IAM) role for CloudWatch Logs access. Note: To provide sample HIDS alert data, the two EC2 instances are configured automatically to generate simulated HIDS alerts locally.
- Installs and configures OSSEC, the CloudWatch Logs agent, and additional packages used for the test environment.
- Creates the target HIDS Amazon ES domain.
- Creates the target HIDS CloudWatch Logs group.
- Creates the Lambda function and CloudWatch Logs subscription to send HIDS alerts to Amazon ES.
After the CloudFormation stack has been deployed, you can access the Kibana instance on the Amazon ES domain to complete the final steps of the setup for the test environment, which I show later in the post.
Although out of scope for this blog post, when deploying OSSEC into your existing EC2 environment, you should determine the desired configuration, including target log files for monitoring, directories for integrity checking, and active response. This typically also requires time for testing and tuning of the system to optimize it for your environment. The OSSEC documentation is a good place to start to familiarize yourself with this process. You could take another approach to OSSEC deployment, which involves an agent installation and a separate OSSEC manager to process events centrally before exporting them to CloudWatch Logs. This deployment requires an additional server component and network communication between the agent and the manager. Note that although Windows Server is supported by OSSEC, it requires an agent-based installation and therefore requires an OSSEC manager to be present. Review OSSEC Architecture for additional information about OSSEC architecture and deployment options.
Deploy the solution
This solution’s high-level steps are:
- Launch the CloudFormation stack.
- Configure a Kibana index pattern and begin exploring alerts.
- Configure a Kibana HIDS dashboard and visualize alerts.
1. Launch the CloudFormation stack
You will launch your test environment by using a CloudFormation template that automates the provisioning process. For the following input parameters, you must identify a target VPC and subnet (which requires Internet access) for deployment. If the target subnet uses an Internet gateway, set the AssignPublicIP parameter to true. If the target subnet uses a NAT gateway, you can leave the default setting of AssignPublicIP as false.
First, you will need to stage the Lambda function deployment package in an S3 bucket located in the region into which you are deploying. To do this, download the zipped deployment package and upload it to your in-region bucket. For additional information about uploading objects to S3, see Uploading Object into Amazon S3.
You also must provide a trusted source IP address or CIDR block for access to the environment following the creation of the stack and an EC2 key pair to associate with the instances. For information about creating an EC2 key pair, see Creating a Key Pair Using Amazon EC2. Note that the trusted IP address or CIDR block also is used to create the Amazon ES access policy automatically for Kibana access. We recommend that you use a specific IP address or CIDR range rather than using 0.0.0.0/0, which would allow all IPv4 addresses to access your instances. For more information about authorizing inbound traffic to your instances, see Authorizing Inbound Traffic for Your Linux Instances.
After you have confirmed the input parameters (see the following screenshot and table for more details), create the CloudFormation stack.
|Input parameter||Input parameter description|
|1. HIDSInstanceSize||EC2 instance size for test server|
|2. ESInstanceSize||Amazon ES instance size|
|3. MyKeyPair||A public/private key pair that allows you to connect securely to your instance after it launches|
|4. MyS3Bucket||In-region S3 bucket with the zipped deployment package|
|5. MyS3Key||In-region S3 key for the zipped deployment package|
|6. VPCId||An Amazon VPC into which to deploy the solution|
|7. SubnetId||A SubnetId with outbound connectivity within the VPC you selected (requires Internet access)|
|8. AssignPublicIP||Set to true if your subnet is configured to connect through an Internet gateway; set to false if your subnet is configured to connect through a NAT gateway|
|9. MyTrustedNetwork||Your trusted source IP or CIDR block that is used to whitelist access to the EC2 instances and the Amazon ES endpoint|
To finish creating the CloudFormation stack:
- Enter the input parameters and choose Next.
- On the Options page, accept the defaults and choose Next.
- On the Review page, confirm the details, select the I acknowledge that AWS CloudFormation might create IAM resources check box, and then choose Create. (The stack will be created in approximately 10 minutes.)
After the stack has been created, note the HIDSESKibanaURL on the CloudFormation Outputs tab. Then, proceed to the Kibana configuration instructions in the next section.
2. Configure a Kibana index pattern and begin exploring alerts
In this section, you perform the initial setup of Kibana. To access Kibana, find the HIDSESKibanaURL in the CloudFormation stack outputs (see the previous section) and choose it. This will bring you to the Kibana instance, which is automatically provisioned to your Amazon ES instance. The source IP you provided in the CloudFormation input parameters is used to automatically populate the Amazon ES access policy. If you receive an error similar to the following error, you must confirm that your Amazon ES access policy is correct.
For additional information about securing access to your Amazon ES domain, see How to Control Access to Your Amazon Elasticsearch Service Domain.
The OSSEC HIDS alerts now are being processed into Amazon ES. To use Kibana to analyze the alert data interactively, you must configure an index pattern that identifies the data you wish to analyze in Amazon ES. You can read additional information about index patterns in the Kibana documentation.
In the Index name or pattern box, type cwl-2017.*. The index pattern is generated within the Lambda function as cwl-YYYY.MM.DD, so you can use a wildcard character for the month and day to match data from 2017. From the Time-field name drop-down list, choose @timestamp, and then choose Create.
In Kibana, you should now be able to choose the Discover pane and see alerts being populated. To set the refresh rate for the display of near-real-time alerts, choose your desired time range in the top right (such as Last 15 minutes).
Choose Auto-refresh, and then choose an interval, such as 5 seconds.
Kibana should now be configured to auto-refresh at a 5-second interval within the timeframe you configured. You should now see your alerts updating along with a count graph, as shown in the following screenshot.
The EC2 instances are automatically configured by CloudFormation to simulate activity to display several types of alerts, including:
- Successful sudo to ROOT executed – The Linux sudo command was successfully executed.
- Web server 400 error code – The server cannot process the request due to an apparent client error (such as malformed request syntax, too large size, invalid request message framing, or deceptive request routing).
- SSH insecure connection attempt (scan) – Invalid connection attempt to the SSH listener.
- Login session opened – Opened login session on the system.
- Login session closed – Closed login session on the system.
- New Yum package installed – Package installed on the system.
- Yum package deleted – Package deleted from the system.
Let’s take a closer look at some of the alert fields, as shown in the following screenshot.
The numbered alert fields in the preceding screenshot are defined as follows:
- @log_group – The source CloudWatch Logs group
- @log_stream – The CloudWatch Logs stream name (InstanceID)
- @message – The JSON payload from the source alerts.json OSSEC log
- @owner – The AWS account ID where the alert originated
- @timestamp – The time stamp applied by the consumer Lambda function
- full_log – The log event from the source file
- location – The source log file path and file name
- rule.comment – A brief description of the OSSEC rule that was matched
- rule.level – The OSSEC rule classification from 0 to 16 (see Rules Classification for more information)
- rule.sidid – The rule ID of the OSSEC rule that was matched
- srcip – The source IP address that triggered the alert; in this case, the simulated alerts contain the local IP of the server
You can enter search criteria in the Kibana query bar to explore HIDS alert data interactively. For example, you can run the following query to see all the rule.level 6 alerts for the EC2 InstanceID i-0e427a8594852eca2 where the source IP is 10.10.10.10.
You can perform searches including simple text, Lucene query syntax, or use the full JSON-based Elasticsearch Query DSL. You can find additional information on searching your data in the Elasticsearch documentation.
3. Configure a Kibana HIDS dashboard and visualize alerts
To analyze alert trends and patterns over time, it can be helpful to use charts and graphs to represent the alert data. I have configured a basic dashboard template that you can import into your Kibana instance.
To add the template of a sample HIDS dashboard to your Kibana instance:
- Save the template locally and then choose Management in the Kibana navigation pane.
- Choose Saved Objects, Import, and the HIDS dashboard template.
- Choose the eye icon to the right of the HIDS Alerts dashboard entry. This will take you to the imported dashboard.
After importing the Kibana dashboard template and selecting it, you will see the HIDS dashboard, as shown in the following screenshot. This sample HIDS dashboard includes Alerts Over Time, Top 20 Alert Types, Rule Level Breakdown, Top 10 Rule Source ID, and Top 10 Source IPs.
To explore the alert data in more detail, you can choose an alert type on which to filter, as shown in the following two screenshots.
You can see more details about the alerts based on criteria such as source IP address or time range. For more information about using Kibana to visualize alert data, see the Kibana User Guide.
In this blog post, I showed how to use CloudWatch Logs to collect alerts in near-real time from an OSSEC HIDS and use a CloudWatch Logs subscription to pass the alerts into Amazon ES for analysis and visualization with Kibana. The dashboard deployed by this solution can help you improve the security monitoring of your EC2 fleet as part of a defense-in-depth security strategy in your AWS environment.
You can use this solution to help detect attacks, anomalous activities, and error trends across your EC2 fleet. You can also use it to help prioritize remediation efforts for your systems or help determine where to introduce additional security controls such as VPC security group rules, VPC network ACLs, or AWS WAF rules.
If you have comments about this post, add them to the “Comments” section below. If you have questions about or issues implementing this solution, start a new thread on the CloudWatch or Amazon ES forum. The source code for this solution is available on GitHub. If you need OSSEC-specific support, see OSSEC Support Options.
What could possibly go wrong with <insert x86 instruction here>? беше описание и демонстрационен код как може да чрез ползване на кеша (flush-ване, напълване и т.н.) да се комуникира между несвързани процеси или дори виртуални машини, които се schedule-ват на същия процесор (т.е. и между core-ове, които споделят кеш).
How Do I Crack Satellite and Cable Pay TV? беше за reverse-ване на чиповете, които декриптират сателитна телевизия, прилично интересно.
Building a high throughput low-latency PCIe based SDR са хора, които разработват software-defined radio на mini PCIe карта, което може да се използва за всякакви по-сериозни цели (има включително синхронизация на часовника от GPS), като за момента са до средата (не са си постигнали целта за скорост на устройството), и ако постигнат прилична цена, това може да се окаже идеалното устройство за правене на софтуерни GSM/LTE неща.
Shut Up and Take My Money! беше за как са счупили на някакви хора мобилното приложение, което се занимава с потребителски транзакции. Звучеше като да трябва да затворят тия, дето са го мислили/писали.
What’s It Doing Now? беше доста интересна лекция за автопилоти по самолети, как тоя тип автоматика трябва да се следи внимателно и като цяло, че нещата не са толкова автомагически, колкото ни се иска. Лекциите за самолетни проблеми винаги са интересни 🙂
Nintendo Hacking 2016 описа какво са счупили по разлините nintendo устройства, exploit-и по boot loader-и и всякакви такива неща. Това беше една от лекциите, в която се споменаваше техниката с glitching – да се подаде по-нисък волтаж за малко, така че дадена инструкция да се намаже и да има шанс да се JMP-не някъде в наш код в някакъв момент, така че да можем да dump-нем нещо.
Where in the World Is Carmen Sandiego? беше лекция за чупенето на системите за резервиране на самолетни билети и като цяло пътувания. Силно тъжно, казаха си в началото, че няма много хакване в лекцията, понеже нещата са твърде счупени и лесни за атака. Кратък съвет – не си публикувайте снимка на boarding pass-а.
You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet е разработка с DNS за сравнително лесно сканиране на всички съществуващи IPv6 DNS PTR записи, та да се намерят повечето съществуващи сървъри. Доста идейно и вероятно ще го тествам някъде 🙂
Tapping into the core описва интересно устройство за дебъгване/слушане на intel-ски процесори през USB и вероятно и мрежа, т.е. дебъгер, който може директно да пипа процесора. Звучи многообещаващо (лекцията гледаше основно на това като начин за правене на rootkit-ове).
Recount 2016: An Uninvited Security Audit of the U.S. Presidential Election беше много празни приказки за изборите в щатите, за пре-преброяване, в което не са открили проблем, и като цяло за счупената им система.
The Untold Story of Edward Snowden’s Escape from Hong Kong разказваше за двете седмици на Edward Snowden в Хонг Конг и бежанците, при които са го крили, преди да отлети, заедно с призив за fundraiser за тях.
State of Internet Censorship 2016 беше нормалното описание, заедно с проектите, чрез които се изследва. В общи линии изводът беше, че вече цензурирането е узаконено почти навсякъде, където се случва и става все по-често явление някоя държава да си спре internet-а за малко, около разни събития.
Million Dollar Dissidents and the Rest of Us описа какви таргетирани методи се използват от различни правителства (и кой им ги продава и учи) за hack-ване и вадене на данни от всякакви устройства на неприятни за тях хора. Нещата са прилично напреднали и е все по-ясно как повечето ни софтуер не става за secure дейности.
On Smart Cities, Smart Energy, And Dumb Security беше за колко са счупени “smart” електромерите и как сигурността на тия неща никой не и обръща сериозно внимание.
Dissecting modern (3G/4G) cellular modems беше интересно описание на съществуващ хардуер, който може да се използва за 3g/4g модем (който се използва в единия iPhone даже), и който накрая се оказа, че търкаля android/linux в себе си (т.е. може спокойно да се каже, че в iPhone 6 (ако не се лъжа) има един linux/adroid).
Тия дни ще догледам още някакви от записи и каквото остава утре и ще пиша пак. Много ми се иска да изгледам повечето неща за random генераторите и лекцията за HDMI.
The US Department of Justice has announced
that it has arrested a suspect in the 2011
kernel.org breakin. “[Donald Ryan] Austin is charged with
causing damage to four servers located in the Bay Area by installing
malicious software. Specifically, he is alleged to have gained unauthorized
access to the four servers by using the credentials of an individual
associated with the Linux Kernel Organization. According to the indictment,
Austin used that access to install rootkit and trojan software, as well as
to make other changes to the servers.”
Ars Techica is reporting on a mistake by Microsoft that resulted in providing a “golden key” to circumvent Secure Boot. The “key” is not really a key at all, but a debugging tool that was inadvertently left in some versions of Windows devices that was found by two security researchers; the details were released on a “rather funky website” (viewing the source of that page is a good way to avoid the visual and audio funkiness).
“The key basically allows anyone to bypass the provisions Microsoft has put in place ostensibly to prevent malicious versions of Windows from being installed, on any device running Windows 8.1 and upwards with Secure Boot enabled.
And while this means that enterprising users will be able to install any operating system—Linux, for instance—on their Windows tablet, it also allows bad actors with physical access to a machine to install bootkits and rootkits at deep levels. Worse, according to the security researchers who found the keys, this is a decision Microsoft may be unable to reverse.” As the researchers note, this is perfect example of why backdoors (legally mandated or not) in cryptographic systems are a bad idea.
Update: For some more detail, see Matthew Garrett’s blog post .