Let’s Architect! Tools for Cloud Architects

Post Syndicated from Luca Mezzalira original https://aws.amazon.com/blogs/architecture/lets-architect-tools-for-cloud-architects/

This International Women’s Day, we’re featuring more than a week’s worth of posts that highlight female builders and leaders. We’re showcasing women in the industry who are building, creating, and, above all, inspiring, empowering, and encouraging everyone—especially women and girls—in tech.


A great way for cloud architects to learn is to experiment with the tools that our teams are using or could consider for the future. This allows us to learn new technologies, become familiar with the latest trends, and understand the entire cycle of our solutions.

Amazon Web Services (AWS) provides several tools for architects, including resources that can analyze your environment for creating a visual diagram and a community of builders who can answer your technical questions.

Today we’re excited to share  tools and methodologies that you should be aware of. In honor of the Architecture Blog’s International Women’s Day, half of these tools have been developed with and by women.

AWS Perspective

One of the main challenges for every architect is making sure their documentation is up to date. Recently, we’ve seen the rise of “architecture as code” tools for deriving architecture diagrams directly from the code in production.

In that vein, AWS developed AWS Perspective, a diagramming tool solution that helps you represent your live workload.

AWS Perspective analyzes your environment and creates a diagram with all your cloud components

AWS Perspective analyzes your environment and creates a diagram with all your cloud components

Chaos Testing with AWS Fault Injection Simulator and AWS CodePipeline

Chaos engineering is the process of testing a distributed computing system to ensure that it can withstand unexpected disruptions.

This blog post shows an architecture pattern for automating chaos testing as part of your continuous integration/continuous delivery (CI/CD) process. By automating the implementation of chaos experiments inside CI/CD pipelines, complex risks and modeled failure scenarios can be tested against application environments with every deployment

This high-level architecture shows how to automate chaos engineering in your environment

This high-level architecture shows how to automate chaos engineering in your environment

AWS re:Post – A Reimagined Q&A Experience for the AWS Community

Often when architecting we run into different design choices, issues, and roadblocks. What service should you use? What is the best way to implement this? Who do you ask?

AWS re:Post is a new question-and-answer service (think Stack Overflow specifically for AWS). It is monitored by the community who answers your questions, and then employees and official partners review these answers to ensure accuracy.

AWS re:Post is public. There is a wide community of AWS experts ready to answer your questions

AWS re:Post is public. There is a wide community of AWS experts ready to answer your questions

Establishing Feedback Loops Based on the AWS Well-Architected Framework Review

In 2018, AWS released the Well-Architected Framework, a mechanism for reviewing and/or improving your workloads that provides recommendations based on best practices in different areas such as security, costs optimization, or reliability. This article shows you how to improve iteratively your systems in the cloud using the Well-Architected Framework.

Creating a healthy feedback loop will enhance your architecture over time

Creating a healthy feedback loop will enhance your architecture over time

See you next time!

Thanks for reading! If you’re looking for more ways tools to architect your workload, check out the AWS Architecture Center.

See you in a couple of weeks when we discuss blockchain!

Other posts in this series

3 Reasons to Join Rapid7’s Cloud Security Summit

Post Syndicated from Ben Austin original https://blog.rapid7.com/2022/03/09/3-reasons-to-join-rapid7s-cloud-security-summit/

3 Reasons to Join Rapid7’s Cloud Security Summit

The world of the cloud never stops moving — so neither can cloud security. In the face of rapidly evolving technology and a constantly changing threat landscape, keeping up with all the latest developments, trends, and best practices in this emerging practice is more vital than ever.

Enter Rapid7’s third annual Cloud Security Summit, which we’ll be hosting this year on Tuesday, March 29. This one-day virtual event is dedicated to cloud security best practices and will feature industry experts from Rapid7, as well as Amazon Web Services (AWS), Snyk, and more.

While the event is fully virtual and free, we know that the time commitment can be the most challenging part of attending a multi-hour event during the workday. With that in mind, we’ve compiled a short list of the top reasons you’ll definitely want to register, clear your calendar, and attend this event.

Reason 1: Get a sneak peak at some original cloud security research

During the opening session of this year’s summit, two members of Rapid7’s award-winning security research team will be presenting some never-before-published research on the current state of cloud security operations, the most common misconfigurations in 2021, Log4j, and more.

Along with being genuinely interesting data, this research will also give you some insights and benchmarks that will help you evaluate your own cloud security program, and prioritize the most commonly exploited risks in your organization’s environment.

Reason 2: Learn from industry experts, and get CPE credits

Along with a handful of team member’s from Rapid7’s own cloud security practice, this year’s summit includes a host of subject matter experts from across the industry. You can look forward to hearing from Merritt Baer, Principal in the Office of the CISO at Amazon Web Services; Anthony Seto, Field Director for Cloud Native Application Security at Snyk; Keith Hoodlet, Code Security Architect at GitHub; and more. And that doesn’t even include the InsightCloudSec customers who will be joining to share their expert perspectives as well.

While learning and knowledge gain are clearly the most important aspects here, it’s always great to have something extra to show for the time you devoted to an event like this. To help make the case to your management that this event is more than worth the time you’ll put in, we’ve arranged for all attendees to earn 3.5 continuing professional education (CPE) credits to go toward maintaining or upgrading security certifications, such as CISSP, CISM, and more.

Reason 3: Be the first to hear exciting Rapid7 announcements

Last but not least, while the event is primarily focused on cloud security research, strategies, and thought leadership, we are also planning to pepper in some exciting news related to InsightCloudSec, Rapid7’s cloud-native security platform.

We’ll end the day with a demonstration of the product, so you can see some of our newest capabilities in action. Whether you’re already an InsightCloudSec customer, or considering a new solution for uncovering misconfigurations, automating cloud security workflows, shifting left, and more, this is the best way to get a live look at one of the top solutions available in the market today.  

So what are you waiting for? Come join us, and let’s dive into the latest and greatest in cloud security together.

Join our 2022 Cloud Security Summit

Register Now

Additional reading

Today’s Spectre variant: branch history injection

Post Syndicated from original https://lwn.net/Articles/887326/

A few days prior to the expected 5.17 release, the mainline kernel has just
received a series of Spectre mitigations for the x86 and ARM architectures.
The vulnerability this time is called “branch history injection”; it has
been deemed CVE-2022-0001 and CVE-2022-0002. Some information can be found
in this
Intel disclosure
, this
ARM advisory
, and this VUSec page:

Branch History Injection (BHI or Spectre-BHB) is a new flavor of
Spectre-v2 in that it can circumvent eIBRS and CSV2 to simplify
cross-privilege mistraining. The hardware mitigations do prevent
the unprivileged attacker from injecting predictor entries for the
kernel. However, the predictor relies on a global history to select
the target entries to speculatively execute. And the attacker can
poison this history from userland to force the kernel to mispredict
to more “interesting” kernel targets (i.e., gadgets) that leak
data.

According to a
documentation patch
merged into the mainline, the only known way to
exploit this problem is via unprivileged BPF.

Composing AWS Step Functions to abstract polling of asynchronous services

Post Syndicated from James Beswick original https://aws.amazon.com/blogs/compute/composing-aws-step-functions-to-abstract-polling-of-asynchronous-services/

This post is written by Nicolas Jacob Baer, Senior Cloud Application Architect, Goeksel Sarikaya, Senior Cloud Application Architect, and Shukhrat Khodjaev, Engagement Manager, AWS ProServe.

AWS Step Functions workflows can use the three main integration patterns when calling AWS services. A common integration pattern is to call a service and wait for a response before proceeding to the next step.

While this works well with AWS services, there is no built-in support for third-party, on-premises, or custom-built services running on AWS. When a workflow integrates with such a service in an asynchronous fashion, it requires a primary step to invoke the service. There are additional steps to wait and check the result, and handle possible error scenarios, retries, and fallbacks.

Although this approach may work well for small workflows, it does not scale to multiple interactions in different steps of the workflow and becomes repetitive. This may result in a complex workflow, which makes it difficult to build, test, and modify. In addition, large workflows with many repeated steps are more difficult to troubleshoot and understand.

This post demonstrates how to decompose the custom service integration by nesting Step Functions workflows. One basic workflow is dedicated to handling the asynchronous communication that offers modularity. It can be re-used as a building block. Another workflow is used to handle the main process by invoking the nested workflow for service interaction, where all the repeated steps are now hidden in multiple executions of the nested workflow.

Overview

Consider a custom service that provides an asynchronous interface, where an action is initially triggered by an API call. After a few minutes, the result is available to be polled by the caller. The following diagram shows a basic workflow interacting with this custom service that encapsulates the service communication in a workflow:

Workflow diagram

  1. Call Custom Service API – calls a custom service, in this case through an API. Potentially, this could use a service integration or use AWS Lambda if there is custom code.
  2. Wait – waits for the service to prepare a result. This depends on the service that the workflow is interacting with, and could vary from seconds to days to months.
  3. Poll Result – attempts to poll the result from the custom service.
  4. Choice – repeats the polling in case the result was not available yet, move on to failed or success state if result was retrieved. In addition, a timeout should be in place here in case the result is not available within the expected time range. Otherwise, this might lead to an infinite loop.
  5. Fail – fails the workflow if a timeout or a threshold for the number of retries with error conditions is reached.
  6. Transform Result – transforms the result or adds additional meta information to provide further information to the caller (for example, runtime or retries).
  7. Success – finishes the workflow successfully.

If you build a larger workflow that interacts with this custom service in multiple steps in a workflow, you can reduce the complexity by using the Step Functions integration to call the nested workflow with a Wait state.

An illustration of this can be found in the following diagram, where the nested stack is called three times sequentially. Likewise, you can build a more complex workflow that adds additional logic through more steps or interacts with a custom service in parallel. The polling logic is hidden in the nested workflow.

Nested workflow

Walkthrough

To get started with AWS Step Functions and Amazon API Gateway using the AWS Management Console:

  1. Go to AWS Step Functions in the AWS Management Console.
  2. Choose Run a sample project and choose Start a workflow within a workflow.
    Defining state machine
  3. Scroll down to the sample projects, which are defined using Amazon States Language (ASL).
    Definition
  4. Review the example definition, then choose Next.
  5. Choose Deploy resources. The deployment can take up to 10 minutes. After deploying the resources, you can edit the sample ASL code to define steps in the state machine.
    Deploy resources
  6. The deployment creates two state machines: NestingPatternMainStateMachine and NestingPatternAnotherStateMachine. NestingPatternMainStateMachine orchestrates the other nested state machines sequentially or in parallel.
    Two state machines
  7. Select a state machine, then choose Edit to edit the workflow. In the NestingPatternMainStateMachine, the first state triggers the nested workflow NestingPatternAnotherStateMachine. You can pass necessary parameters to the nested workflow by using Parameters and Input as shown in the example below with Parameter1 and Parameter2. Once the first nested workflow completes successfully, the second nested workflow is triggered. If the result of the first nested workflow is not successful, the NestingPatternMainStateMachine fails with the Fail state.
    Editing state machine
  8. Select nested workflow NestingPatternAnotherStateMachine, and then select Edit to add AWS Lambda functions to start a job and poll the state of the jobs. This can be any asynchronous job that needs to be polled to query its state. Based on expected job duration, the Wait state can be configured for 10-20 seconds. If the workflow is successful, the main workflow returns a successful result.
    Edited next state machine

Use cases and limitations

This approach allows encapsulation of workflows consisting of multiple sequential or parallel services. Therefore, it provides flexibility that can be used for different use cases. Services can be part of distributed applications, part of automated business processes, big data or machine learning pipelines using AWS services.

Each nested workflow is responsible for an individual step in the main workflow, providing flexibility and scalability. Hundreds of nested workflows can run and be monitored in parallel with the main workflow (see AWS Step Functions Service Quotas).

The approach described here is not applicable for custom service interactions faster than 1 second, since it is the minimum configurable value for a wait step.

Nested workflow encapsulation

Similar to the principle of encapsulation in object-oriented programming, you can use a nested workflow for different interactions with a custom service. You can dynamically pass input parameters to the nested workflow during workflow execution and receive return values. This way, you can define a clear interface between the nested workflow and the parent workflow with different actions and integrations. Depending on the use-case, a custom service may offer a variety of different actions that must be integrated into workflows that run in Step Functions, but can all be combined into a single workflow.

Debugging and tracing

Additionally, debugging and tracing can be done through Execution Event History in the State Machine Management Console. In the Resource column, you can find a link to the executed nested step function. It can be debugged in case of any error in the nested Step Functions workflow.

Execution event history

However, debugging can be challenging in case of multiple parallel nested workflows. In such cases, AWS X-Ray can be enabled to visualize the components of a state machine, identify performance bottlenecks, and troubleshoot requests that have led to an error.

To enable AWS X-Ray in AWS Step Functions:

  1. Open the Step Functions console and choose Edit state machine.
  2. Scroll down to Tracing settings, and Choose Enable X-Ray tracing.

Tracing

For detailed information regarding AWS X-Ray and AWS Step Functions please refer to the following documentation: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-xray-tracing.html

Conclusion

This blog post describes how to compose a nested Step Functions workflow, which asynchronously manages a custom service using the polling mechanism.

To learn more about how to use AWS Step Functions workflows for serverless microservices orchestration, visit Serverless Land.

2 New Mozilla Firefox 0-Day Bugs Under Active Attack (The Hacker News)

Post Syndicated from original https://lwn.net/Articles/887316/

According to this
report on The Hacker News
, there are a couple of recent Firefox
vulnerabilities that are currently being exploited.

Tracked as CVE-2022-26485 and CVE-2022-26486, the zero-day flaws
have been described as use-after-free issues impacting the
Extensible Stylesheet Language Transformations (XSLT) parameter
processing and the WebGPU inter-process communication (IPC)
Framework.

Updating seems like a good idea.

Security updates for Wednesday

Post Syndicated from original https://lwn.net/Articles/887309/

Security updates have been issued by Debian (kernel, linux-4.19, spip, and thunderbird), Fedora (cyrus-sasl and libxml2), Mageia (firefox and thunderbird), openSUSE (buildah and tcpdump), Red Hat (cyrus-sasl, kernel, kernel-rt, and kpatch-patch), Slackware (kernel), SUSE (buildah, kernel, libcaca, and tcpdump), and Ubuntu (linux, linux-aws, linux-aws-5.13, linux-azure, linux-azure-5.13, linux-gcp, linux-gcp-5.13, linux-hwe-5.13, linux-kvm, linux-oem-5.14, linux-oracle, linux-oracle-5.13, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-azure-fde, linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gke, linux-gke-5.4, linux-gkeop, linux-gkeop-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, and linux, linux-aws, linux-aws-hwe, linux-azure, linux-azure-4.15, linux-dell300x, linux-gcp, linux-gcp-4.15, linux-hwe, linux-kvm, ilinux-lts-xenial, linux-oracle, linux-raspi2, linux-snapdragon).

Fraud on Zelle

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/03/fraud-on-zelle.html

Zelle is rife with fraud:

Zelle’s immediacy has also made it a favorite of fraudsters. Other types of bank transfers or transactions involving payment cards typically take at least a day to clear. But once crooks scare or trick victims into handing over money via Zelle, they can siphon away thousands of dollars in seconds. There’s no way for customers — and in many cases, the banks themselves — to retrieve the money.

[…]

It’s not clear who is legally liable for such losses. Banks say that returning money to defrauded customers is not their responsibility, since the federal law covering electronic transfers — known in the industry as Regulation E ­– requires them to cover only “unauthorized” transactions, and the fairly common scam that Mr. Faunce fell prey to tricks people into making the transfers themselves. Victims say because they were duped into sending the money, the transaction is unauthorized. Regulatory guidance has so far been murky.

When swindled customers, already upset to find themselves on the hook, search for other means of redress, many are enraged to find out that Zelle is owned and operated by banks.

[…]

The Zelle network is operated by Early Warning Services, a company created and owned by seven banks: Bank of America, Capital One, JPMorgan Chase, PNC, Truist, U.S. Bank and Wells Fargo. Early Warning, based in Scottsdale, Ariz., manages the system’s technical infrastructure. But the 1,425 banks and credit unions that use Zelle can customize the app and add their own security settings.

DNSSEC issues take Fiji domains offline

Post Syndicated from David Belson original https://blog.cloudflare.com/dnssec-issues-fiji/

DNSSEC issues take Fiji domains offline

DNSSEC issues take Fiji domains offline

On the morning of March 8, a post to Hacker News stated that “All .fj domains have gone offline”, listing several hostnames in domains within the Fiji top level domain (known as a ccTLD) that had become unreachable. Commenters in the associated discussion thread had mixed results in being able to reach .fj hostnames—some were successful, while others saw failures. The fijivillage news site also highlighted the problem, noting that the issue also impacted Vodafone’s M-PAiSA app/service, preventing users from completing financial transactions.

The impact of this issue can be seen in traffic to Cloudflare customer zones in the .com.fj second-level domain. The graph below shows that HTTP traffic to these zones dropped by approximately 40% almost immediately starting around midnight UTC on March 8. Traffic volumes continued to decline throughout the rest of the morning.

DNSSEC issues take Fiji domains offline

Looking at Cloudflare’s 1.1.1.1 resolver data for queries for .com.fj hostnames, we can also see that error volume associated with those queries climbs significantly starting just after midnight as well. This means that our resolvers encountered issues with the answers from .fj servers.

DNSSEC issues take Fiji domains offline

This observation suggests that the problem was strictly DNS related, rather than connectivity related—Cloudflare Radar does not show any indication of an Internet disruption in Fiji coincident with the start of this problem.

DNSSEC issues take Fiji domains offline

It was suggested within the Hacker News comments that the problem could be DNSSEC related. Upon further investigation, it appears that may be the cause. In verifying the DNSSEC record for the .fj ccTLD, shown in the dig output below, we see that it states EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for fj.'

kdig fj. soa +dnssec @1.1.1.1 
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 12710
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1
 
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for fj.'
 
;; QUESTION SECTION:
;; fj.                          IN      SOA
 
;; Received 73 B
;; Time 2022-03-08 08:57:41 EST
;; From 1.1.1.1@53(UDP) in 17.2 ms

Extended DNS Error 9 (EDE: 9) is defined as “A DS record existed at a parent, but no supported matching DNSKEY record could be found for the child.” The Cloudflare Learning Center article on DNSKEY and DS records explains this relationship:

The DS record is used to verify the authenticity of child zones of DNSSEC zones. The DS key record on a parent zone contains a hash of the KSK in a child zone. A DNSSEC resolver can therefore verify the authenticity of the child zone by hashing its KSK record, and comparing that to what is in the parent zone’s DS record.

Ultimately, it appears that around midnight UTC, the .fj zone started to be signed with a key that was not in the root zone DS, possibly as the result of a scheduled rollover that happened without checking that the root zone was updated first by IANA, which updates the root zone. (IANA owns contact with the TLD operators, and instructs the Root Zone Publisher on the changes to make in the next version of the root zone.)

DNSSEC problems as the root cause of the observed issue align with the observation in the Hacker News comments that some were able to access .fj websites, while others were not. Users behind resolvers doing strict DNSSEC validation would have seen an error in their browser, while users behind less strict resolvers would have been able to access the sites without a problem.

Conclusion

Further analysis of Cloudflare resolver metrics indicates that the problem was resolved around 1400 UTC, when the DS was updated. When DNSSEC is improperly configured for a single domain name, it can cause problems accessing websites or applications in that zone. However, when the misconfiguration occurs at a ccTLD level, the impact is much more significant. Unfortunately, this seems to occur all too often.

(Thank you to Ólafur Guðmundsson for his DNSSEC expertise.)

България и киберсигурността: Готови ли сме за предизвикателствата на XXI век? 

Post Syndicated from Йоанна Елми original https://toest.bg/delyan-delchev-interview-cybersecurity/

Няколко дни след началото на руската инвазия в Украйна министърът на електронното управление Божидар Божанов обяви, че съвместно с ГДБОП са предприети действия за „филтриране или преустановяване на трафика от над 45 000 интернет адреса, от които са извършвани опити за зловредна намеса в електронни системи“. Същевременно от януари насам са осъществени редица кибератаки срещу Украйна, като мишени са от държавни институции до банки. Много от тези атаки са приписвани на Русия. Вземайки предвид активната информационна война в България и геополитическите интереси на Русия в региона, Йоанна Елми разговаря с Делян Делчев – телекомуникационен инженер и експерт по информационни технологии с познания и опит в сферата на киберсигурността. 


Г-н Делчев, често говорим за „хибридна война“, за която имаше предупреждения и във връзка с инвазията в Украйна. Струва ми се обаче, че има разминаване в схващането на термина. Какво да разбират читателите под този етикет? 

По принцип терминът означава динамично и/или едновременно комбиниране на конвенционални и неконвенционални военни действия, дипломация и кибервойна, в т.ч. и информационна (или както си я наричахме ние – пропаганда). Но подобно на други термини, с времето оригиналният смисъл се загубва и днес по-скоро имаме предвид основно електронната пропаганда, понякога подпомагана от хакерство, търсещо сензация.

Може ли да кажем грубо, че хибридната война включва два елемента: комуникационен, например пропаганда, и технически – кибератаки срещу ключова инфраструктура? 

Да. Но обръщам внимание, че това, с което асоциираме термина в последно време, е предимно пропагандата по интернет, а всички други съпътстващи действия по-скоро целят нейното подпомагане.

Съществуват ли кибератаки, които са особено популярни? Какви са практиките? 

Светът на хакерството е интересен и много по-различен от това, което виждате по телевизията. Доминиращото количество хора, занимаващи се с тези дейности, не са войници, професионалисти или пък гении. Това са най-обикновени хора, например тийнейджъри, събрани в малки приятелски банди, които пробват неща, за които са прочели тук и там, в повечето случаи – без да ги разбират в дълбочина. Те се радват на тръпката от потенциален успех, дори той да е малък, на емоцията да правиш нещо забранено, да получиш същия адреналин като при екстремните спортове.

Има всякакви хора – някои са мотивирани и от възможностите за малки или големи печалби или просто за събиране на информация, която те си мислят, че може да е тайна – да разкрият нещо ново, някоя голяма конспирация. И тези хора са напълно случайно разпръснати по света и са удивително много. Само в Китай има милиони тийнейджъри (т.нар. script kiddies), които отварят за първи път някоя книжка или по-скоро онлайн хакерски документ и веднага искат да си пробват късмета, да видят какво ще стане. Паралелно има и неструктуриран черен пазар: малките банди си взаимодействат и си помагат с услуги, скриптове, достъп, поръчки, плащат си с пари, (крадени) стоки, услуги, програмен код, ресурси и криптовалута. Където има хора и търсене, има и пари, и награди.

Държавните „киберармии“ всъщност се възползват от тези хакери и големия им брой. Те им спускат поръчки чрез подставени лица, посредници или приятели и съответно ги награждават, ако някъде постигнат успех. Същото правят и обикновени престъпници, частни фирми, детективи и какви ли не други. Ако използваме аналогия от спагети уестърните: обявена е парична награда за главата на някого и всички ловци на глави се втурват да се пробват. Няма никакви гаранции за успех, а заниманието е времеемко, защото реалността не е като по телевизията – идва хакер, оплаква се от нещо, после трака пет секунди на клавиатурата и казва: „Вътре съм.“ В реалния живот дори малки пробиви може да отнемат години и се правят на малки стъпки. Затова и когато бъдат разкрити, пораженията са вече големи, защото пробивът може да не е бил от вчера, а да е отворена порта с години.

Тъй като повечето хакери не разбират занаята в дълбочина, често някои държави или фирми, които са специализирани в областта на сигурността и разполагат с интелигентни и способни ресурси, предоставят готови инструменти, непознати хакове или вътрешна информация на хакерските банди. Понякога дори начеват процеса и подготвят обстановката, а после оставят хакерите да довършат нещата. Хакерите са, един вид, мулета и дори някой да ги уличи, директната връзка с поръчителя е много трудна.

А има ли специфичен почерк според държавата, извършваща кибератака?

Индивидуалните банди се специализират в различни направления – във флууд (от англ. flood, „наводняване“– претоварване на интернет връзки, което води например до блокиране на достъпа до уебсайтове); сриване на ресурси, затрудняване на работоспособността на инфраструктури; хакване, вземане на контрол; създаване и събиране на бот мрежи (които после се ползват за прикриване на хакове и флууд)*; кражби на идентификация, пароли, лична информация, данни за кредитни карти и за криптовалути; рансъмуер (зловреден софтуер, който криптира информацията на заразения компютър и изнудва потребителя да му плати откуп, за да получи ключ за дешифриране) и т.н.

Трудно е от пръв поглед да се каже кой какъв е и дали поведението му е самопородено от хаоса, или има частен интерес, или някой му дърпа конците и го е мотивирал, без значение дали това е станало знайно, или незнайно за извършителя. Но светът е малък и има модели на поведение, които са специфичен стил на различните групи и мотиватори. Има и много улики. В действителност в интернет нищо не е наистина анонимно. Така чрез различни техники може да се идентифицира кой кой е и дали е под влиянието на поръчители от една или друга държава. Киберсигурността се развива и на обикновените хакери им е все по-трудно да откриват нови слаби звена. Това го могат основно хора, които имат познания, специфичен достъп до информация (например сорскод на WindowsMicrosoft го предоставя под различни програми на няколко държави, сред които са и Русия, и Китай), разузнаване, възможности за събиране и мотивиране на съмишленици или помагачи, работещи в различни компании.

В скандала Solarwinds например пакетът от хакове съдържаше инструмент с компонент, написан от хакерите, но подписан така, сякаш идва от Microsoft. Този компонент води до лесното и невидимо инсталиране на код, който позволява отдалечено управление на Windows. Това не може да бъде направено от обикновени хакери, тези ключове и процесът по подписването с тях трябва да са тайна. От Microsoft и досега изследват как хакерите са направили пробива. Съвсем вероятно е да е станало по описания по-горе начин – през програмите, по които Microsoft работи директно с някои правителства, и е сериозен сигнал за правителствено участие. Хакерските банди нямат тези възможности, а дори да ги имаха, всичко това щеше да се появи публично и светът щеше да е залят с подобни подписани компоненти. Сега обаче същите инструменти и ключ ненадейно се появиха в няколко хакерски кампании за изземване на украински ИТ системи, което очевидно уличава руски правителствени интереси.

Китайските държавни хакери, както и американските, и руските, имат своя колекция от хакерски инструменти, които разработват тайно, не са публични, но понякога биват предоставени на близки банди (някои често съдействат на всички служби, държави или частни компании едновременно). Така и по инструментите може да се познае кой стои зад атаката. Или по наградите. Или по „мулетата“. Или по начина на плащане. Или дори по пропагандните изрази, които използват (и които издават с кого си комуникират). Макар хаотичните банди да стоят на преден план, отзад понякога се виждат сенките на по-сериозни професионалисти и организатори на кампании. Все още обаче над 99% от кибератаките са изцяло хаотични и не са свързани с държавни „киберармии“.

Как се наказват кибератаките? Съществува ли в света ефективно разработена рамка, която да ги третира като престъпления?

Има опити, но не мисля, че са ефективни. Проблемът е, че обикновено се наказват тийнейджъри, които са на практика невинни или пък малолетни и неопитни както в живота, така и в това, което правят, и всъщност заради това ги хващат. В огромната си част по-опитните хакери или пък техните поръчители, ако има такива, си остават недосегаеми. Не мисля, че е възможно при тази „екосистема“ въобще да има начин да изхвърлим мръсната вода, без да изхвърлим и бебето. Обществените реакции ще са тежки. Затова ако нещо се прави по темата, е епизодично и според мен никой не се опитва сериозно да се занимава с наказания, поне в свободния свят.

Друг проблем е, че видимите хакери са често разпръснати между много държави и просто няма как да хванеш един и после чрез него да намериш и хванеш друг, а чрез него – трети, без подкрепата на тези държави. А това е трудно и понякога невъзможно. Ето защо и никой не иска да прави нещо наистина сериозно и масово, когато не става въпрос за финансови престъпления. От известно време съответните полицейски служби се опитват – под предлог за борба с детската порнография – да разработят по-координирана комуникация между различни държави и често правят масови транснационални кампании. Създадената инфраструктура автоматично впоследствие може да се използва за всякакви киберпрестъпления – от най-големите до примерно нарушаване на авторски права (изтеглили сте някакъв филм от интернет). Но засега тази координация е в процес на подготовка и се фокусира върху детската порнография като общо безспорно припознат проблем от службите.

За мен това, че има куп младежи, които искат да се научат „на хакерство“, не е проблем. Така се натрупва познание. Ако някой хакер е намерил как да влезе в пощата или сървъра ви, не е чак такава беда в повечето случаи, защото загубите са най-често малки. Може да се възползвате от това, за да се учите да се пазите по-добре. Защото ако хакери, които не са държавно спонсорирани, могат да пробият системите ви, то държавно спонсорираните вероятно отдавна се разхождат там необезпокоявано.

Образът на руския хакер е почти фикционален, като на филм. В действителност има ли Русия особена роля в сферата на кибератаките? 

Има, но не и по този романтичен начин, по който повечето хора си го представят. „Руските хакери“ всъщност са всякакви хакери, с всякаква националност. Има немалко българи сред тях например. Има и американци, китайци, западноевропейци, какви ли не. И тези хора нямат задължително идеология, нито правят това от любов към Путин; мнозина дори не знаят, че са спонсорирани от Москва чрез посредници. Просто техните банди, приятелски кръгове и контакти ги поставят в позиция да получават, понякога през десетки посредници, възможности за поръчки, които са спуснати от руски поръчители или са в техен интерес.

За разлика от САЩ, които като цяло избягват да използват бандите (с малки изключения) и имат голям собствен и невидим ресурс, напълно отделен от хакерската общност, Русия е много по-прагматична и грубо казано, излиза на свободния пазар. Така тя разчита и на по-нискоквалифицирани хакери, които съответно повече се излагат и биват хващани, защото използват по-видими и груби подходи. Спокойно можем да определим руската практика като „слон в стъкларски магазин“. Но това работи за тях, защото те се радват на пропагандния ефект и на името, което си създават. Тази практика е и по-евтина и по-лесна, тъй като не се налага обучение на хора, нито създаване и развиване на специални държавни структури със специфично познание.

Но тук-там се виждат и по-прецизни руски изпълнения с директно въвличане на по-интелигентни участници от масовите хакери. Solarwinds, както и двете последни кампании в Украйна са добри примери и много служби осъзнаха, че Русия също започва да натрупва и такъв потенциал.

Показаха ли нагледно случаи като теча в НАП, че България е неподготвена в сферата на киберсигурността? Обществеността не се трогна много от изтичането на данни – защо? И как трябва да се обясни на хората, че проблемът ги засяга лично? 

Първо, повечето от хакванията, за които съм чул, че се случват в България, и по-специално това в НАП, са породени от небрежност и вероятно от незаинтересованост, често граничеща с глупост. Но основният проблем на България е, че работим след събитията – чакаме нещо да се случи, за да действаме. После работим на парче, докато следващото събитие не дойде да ни накара да действаме отново. Киберсигурността постоянно се променя. С единични действия не може да се постигне нищо. Трябва постоянно да следиш и да реагираш на това, което става или за което чуваш като възможни рискове в други държави. Дори хипотетично в момента да имаш най-добрата защита на света, след няколко месеца вече няма да е така. Държавата трябва да има процедури (а не само стратегии) и тези процедури активно да се изпълняват, а на киберсигурността трябва да се гледа много сериозно.

Усещането ми е, че киберхигиената в държавните ни институции не е на ниво и едва ли не още сричаме азбуката. Смешно е да слушаме изказвания как в НАП са си мислили, че имали сигурност, защото са минали обучение и са направили опит да се сертифицират по ISO27000. Както видяхме, това не е помогнало. Смешно е също някои други институции да си мислят, че като криптират нещо, то автоматично става защитено.

Разглеждайки внимателно как е разработвано хакването на някои от финансовите и държавните институции в Украйна, ще видим, че ако сме били ние на мушка, нито една от простите ни представи как да бъдем или да се чувстваме защитени, не би ни предпазила. Има големи разлики в изграждането на хигиена в киберсигурността на индивидуално или корпоративно ниво и на ниво държава, държавни институции и организации от сферата на сигурността. Ние засега се опитваме да покрием поне корпоративните стандарти – и дори в това нямаме големи успехи.

Гражданите няма как да следят какви пробиви се появяват в киберсигурността, нито пък ще се занимават постоянно с поддържането на киберхигиена, ако тя е трудна и неразбираема. Всяко нещо, което ти създава дискомфорт, скоро бива игнорирано, все едно никога не го е имало. Класически пример за това са изискванията за много сложни пароли – на пръв поглед трябва да се минимизира рискът някой хакер да ги познае, но пък така потребителят е принуден или да използва една и съща парола навсякъде, или да си ги записва и евентуално да ги оставя на публични места. Така вместо да се подобри сигурността с това правило, всъщност тя спада, както показва статистиката.

Киберсигурността трябва да се възприема сериозно отгоре надолу в държавата, а не обратното, от гражданите към властта. Решенията и процесите трябва да са прости и органични, в най-добрия случай невидими за крайните потребители, да не им пречат, и така всичко ще бъде разумно ефективно, дори да не е перфектно. Хората трябва да знаят, че никога нищо в киберсигурността не е перфектно, но може да е достатъчно добро, за да минимизира рисковете и експозицията. За пример: ако в НАП спазваха поне основните принципи на GPDR за съхраняване на личните данни, уязвимостта нямаше да е толкова голяма. Дали дори сега в НАП ги спазват? Или си мислят, че ако не публикуват бекъпите си в интернет достъпни сървъри, те ще са защитени? Предвид наблюдаваното напоследък, това е много измамно усещане.

А по въпроса как киберсигурността ни засяга лично: представете си, че всички електронни блага, които имате днес – банкови карти, пари, интернет, смартфони, лична информация, усещане за личен живот, – може да се загубят и/или да ги получи някой друг, а вие бъдете пренесен, метафорично казано, обратно в 70-те като ниво на комуникация. Ако тази мисъл ви създава дискомфорт, значи трябва да се отнасяте сериозно към киберхигиената си.

Мрежи от ботове се създават, като чрез вирус или по друг начин се заразят множество компютри, на които след това се инсталира софтуер (бот). Когато е нужно да се извърши атака, контролиращият мрежата активира тези ботове отдалечено и те започват координирано да атакуват конкретни сървъри. Така изглежда, че атаката идва от множество компютри по целия свят и е трудна за овладяване, а истинският извършител остава скрит зад своята армия от ботове. – Б.р.
Заглавна снимка: Michael Geiger / Unsplash

Източник

Detecting security issues in logging with Amazon CodeGuru Reviewer

Post Syndicated from Brian Farnhill original https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/

Amazon CodeGuru is a developer tool that provides intelligent recommendations for identifying security risks in code and improving code quality. To help you find potential issues related to logging of inputs that haven’t been sanitized, Amazon CodeGuru Reviewer now includes additional checks for both Python and Java. In this post, we discuss these updates and show examples of code that relate to these new detectors.

In December 2021, an issue was discovered relating to Apache’s popular Log4j Java-based logging utility (CVE-2021-44228). There are several resources available to help mitigate this issue (some of which are highlighted in a post on the AWS Public Sector blog). This issue has drawn attention to the importance of logging inputs in a way that is safe. To help developers understand where un-sanitized values are being logged, CodeGuru Reviewer can now generate findings that highlight these and make it easier to remediate them.

The new detectors and recommendations in CodeGuru Reviewer can detect findings in Java where Log4j is used, and in Python where the standard logging module is used. The following examples demonstrate how this works and what the recommendations look like.

Findings in Java

Consider the following Java sample that responds to a web request.

@RequestMapping("/example.htm")
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) {
    ModelAndView result = new ModelAndView("success");
    String userId = request.getParameter("userId");
    result.addObject("userId", userId);

    // More logic to populate `result`.
     log.info("Successfully processed {} with user ID: {}.", request.getRequestURL(), userId);
    return result;
}

This simple example generates a result to the initial request, and it extracts the userId field from the initial request to do this. Before returning the result, the userId field is passed to the log.info statement. This presents a potential security issue, because the value of userId is not sanitized or changed in any way before it is logged. CodeGuru Reviewer is able to identify that the variable userId points to a value that needs to be sanitized before it is logged, as it comes from an HTTP request. All user inputs in a request (including query parameters, headers, body and cookie values) should be checked before logging to ensure a malicious user hasn’t passed values that could compromise your logging mechanism.

CodeGuru Reviewer recommends to sanitize user-provided inputs before logging them to ensure log integrity. Let’s take a look at CodeGuru Reviewer’s findings for this issue.

A screenshot of the AWS Console that describes the log injection risk found by CodeGuru Reviewer

An option to remediate this risk would be to add a sanitize() method that checks and modifies the value to remove known risks. The specific process of doing this will vary based on the values you expect and what is safe for your application and its processes. By logging the now sanitized value, you have mitigated those risks that could impact on your logging framework. The modified code sample below shows one example of how this could be addressed.

@RequestMapping("/example.htm")
public ModelAndView handleRequestSafely(HttpServletRequest request, HttpServletResponse response) {
    ModelAndView result = new ModelAndView("success");
    String userId = request.getParameter("userId");
    String sanitizedUserId = sanitize(userId);
    result.addObject("userId", sanitizedUserId);

    // More logic to populate `result`.
    log.info("Successfully processed {} with user ID: {}.", request.getRequestURL(), sanitizedUserId);
    return result;
}

private static String sanitize(String userId) {
    return userId.replaceAll("\\D", "");
}

The example now uses the sanitize() method, which uses a replaceAll() call that uses a regular expression to remove all non-digit characters. This example assumes the userId value should only be digit characters, ensuring that any other characters that could be used to expose a vulnerability in the logging framework are removed first.

Findings in Python

Now consider the following python code from a sample Flask project that handles a web request.

from flask import app, current_app, request

@app.route('/log')
def getUserInput():
    input = request.args.get('input')
    current_app.logger.info("User input: %s", input)

    # More logic to process user input.

In this example, the input variable is assigned the input query string value from a web request. Then, the Flask logger records its value as an info level message. This has the same challenge as the Java example above. However this time rather than changing the value, we can instead inspect it and choose to log it only when it is in a format we expect. A simple example of this could be where we expect only alphanumeric characters in the input variable. The isalnum() function can act as a simple test in this case. Here is an example of what this style of validation could look like.

from flask import app, current_app, request

@app.route('/log')
def safe_getUserInput():
    input = request.args.get('input')    
    if input.isalnum():
        current_app.logger.info("User input: %s", input)        
    else:
        current_app.logger.warning("Unexpected input detected")

Getting started

While log sanitization implementation is a long journey for many, it is a guardrail for maintaining your application’s log integrity. With CodeGuru Reviewer detecting log inputs that are neither sanitized nor validated, developers can use these recommendations as a guide to reduce risks related to log injection attacks. Additionally, you can provide feedback on recommendations in the CodeGuru Reviewer console or by commenting on the code in a pull request. This feedback helps improve the precision of CodeGuru Reviewer, so the recommendations you see get better over time.

To get started with CodeGuru Reviewer, you can leverage AWS Free Tier without any cost. For 90 days, you can review up to 100K lines of code in onboarded repositories per AWS account. For more information, please review the pricing page.

About the authors

Brian Farnhill

Brian Farnhill is a Software Development Engineer in the Australian Public Sector team. His background is in building solutions and helping customers improve DevOps tools and processes. When he isn’t working, you’ll find him either coding for fun or playing online games.

Jia Qin

Jia Qin is part of the Solutions Architect team in Malaysia. She loves developing on AWS, trying out new technology, and sharing her knowledge with customers. Outside of work, she enjoys taking walks and petting cats.

[$] Belenios: a system for secret voting

Post Syndicated from original https://lwn.net/Articles/887077/

As part of the recent discussion on switching
to secret voting
for Debian general resolutions (GRs), which has
resulted in a ongoing GR of its own, the
subject of voting systems that embody various attributes some would like to
see for voting in Debian has been brought up. One of the systems mentioned, Belenios, provides an
open-source “verifiable online voting system“. Whether or not
Debian chooses to switch to secret voting, Belenios would seem to provide what
other projects or organizations may be looking for as a mechanism to handle
their voting needs.

Patch Tuesday – March 2022

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2022/03/08/patch-tuesday-march-2022/

Patch Tuesday - March 2022

Microsoft’s March 2022 updates include fixes for 92 CVEs (including 21 from the Chromium project, which is used by their Edge web browser). None of them have been seen exploited in the wild, but three have been previously disclosed. CVE-2022-24512, affecting .NET and Visual Studio, and CVE-2022-21990, affecting Remote Desktop Client, both allow RCE (Remote Code Execution). CVE-2022-24459 is an LPE (local privilege escalation) vulnerability in the Windows Fax and Scan service. All three publicly disclosed vulnerabilities are rated Important – organizations should remediate at their regular patch cadence.

Three CVEs this month are rated Critical. CVE-2022-22006 and CVE-2022-24501 both affect video codecs. In most cases, these will update automatically via the Microsoft Store. However, any organizations with automatic updates disabled should be sure to push out updates. The vulnerability most likely to raise eyebrows this month is CVE-2022-23277, a Critical RCE affecting Exchange Server. Thankfully, this is a post-authentication vulnerability, meaning attackers need credentials to exploit it. Although passwords can be obtained via phishing and other means, this one shouldn’t be as rampantly exploited as the deluge of Exchange vulnerabilities we saw throughout 2021. Exchange administrators should still patch as soon as reasonably possible.

SharePoint administrators get a break this month, though on the client side, a handful of Office vulnerabilities were fixed. Three separate RCEs in Visio, Tampering and Security Feature Bypass vulnerabilities in Word, and Information Disclosure in the Skype Extension for Chrome all got patched.

CVE-2022-24508 is an RCE affecting Windows SMBv3, which has potential for widespread exploitation, assuming an attacker can put together a suitable exploit. Luckily, like this month’s Exchange vulnerabilities, this too requires authentication.

Organizations using Microsoft’s Azure Site Recovery service should be aware that 11 CVEs were fixed with today’s updates, split between RCEs and LPEs. They are all specific to the scenario where an on-premise VMware deployment is set up to use Azure for disaster recovery.

Summary charts

Patch Tuesday - March 2022
Patch Tuesday - March 2022
Patch Tuesday - March 2022
Patch Tuesday - March 2022

Summary tables

Apps vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-23282 Paint 3D Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24465 Microsoft Intune Portal for iOS Security Feature Bypass Vulnerability No No 3.3 Yes

Azure vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-24467 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24468 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24517 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24470 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24471 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24520 Azure Site Recovery Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-24469 Azure Site Recovery Elevation of Privilege Vulnerability No No 8.1 Yes
CVE-2022-24506 Azure Site Recovery Elevation of Privilege Vulnerability No No 6.5 Yes
CVE-2022-24515 Azure Site Recovery Elevation of Privilege Vulnerability No No 6.5 Yes
CVE-2022-24518 Azure Site Recovery Elevation of Privilege Vulnerability No No 6.5 Yes
CVE-2022-24519 Azure Site Recovery Elevation of Privilege Vulnerability No No 6.5 Yes

Browser vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-0809 Chromium: CVE-2022-0809 Out of bounds memory access in WebXR No No N/A Yes
CVE-2022-0808 Chromium: CVE-2022-0808 Use after free in Chrome OS Shell No No N/A Yes
CVE-2022-0807 Chromium: CVE-2022-0807 Inappropriate implementation in Autofill No No N/A Yes
CVE-2022-0806 Chromium: CVE-2022-0806 Data leak in Canvas No No N/A Yes
CVE-2022-0805 Chromium: CVE-2022-0805 Use after free in Browser Switcher No No N/A Yes
CVE-2022-0804 Chromium: CVE-2022-0804 Inappropriate implementation in Full screen mode No No N/A Yes
CVE-2022-0803 Chromium: CVE-2022-0803 Inappropriate implementation in Permissions No No N/A Yes
CVE-2022-0802 Chromium: CVE-2022-0802 Inappropriate implementation in Full screen mode No No N/A Yes
CVE-2022-0801 Chromium: CVE-2022-0801 Inappropriate implementation in HTML parser No No N/A Yes
CVE-2022-0800 Chromium: CVE-2022-0800 Heap buffer overflow in Cast UI No No N/A Yes
CVE-2022-0799 Chromium: CVE-2022-0799 Insufficient policy enforcement in Installer No No N/A Yes
CVE-2022-0798 Chromium: CVE-2022-0798 Use after free in MediaStream No No N/A Yes
CVE-2022-0797 Chromium: CVE-2022-0797 Out of bounds memory access in Mojo No No N/A Yes
CVE-2022-0796 Chromium: CVE-2022-0796 Use after free in Media No No N/A Yes
CVE-2022-0795 Chromium: CVE-2022-0795 Type Confusion in Blink Layout No No N/A Yes
CVE-2022-0794 Chromium: CVE-2022-0794 Use after free in WebShare No No N/A Yes
CVE-2022-0793 Chromium: CVE-2022-0793 Use after free in Views No No N/A Yes
CVE-2022-0792 Chromium: CVE-2022-0792 Out of bounds read in ANGLE No No N/A Yes
CVE-2022-0791 Chromium: CVE-2022-0791 Use after free in Omnibox No No N/A Yes
CVE-2022-0790 Chromium: CVE-2022-0790 Use after free in Cast UI No No N/A Yes
CVE-2022-0789 Chromium: CVE-2022-0789 Heap buffer overflow in ANGLE No No N/A Yes

Developer Tools vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-24526 Visual Studio Code Spoofing Vulnerability No No 6.1 Yes
CVE-2020-8927 Brotli Library Buffer Overflow Vulnerability No No 6.5 Yes
CVE-2022-24512 .NET and Visual Studio Remote Code Execution Vulnerability No Yes 6.3 Yes
CVE-2022-24464 .NET and Visual Studio Denial of Service Vulnerability No No 7.5 No

Exchange Server vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-24463 Microsoft Exchange Server Spoofing Vulnerability No No 6.5 Yes
CVE-2022-23277 Microsoft Exchange Server Remote Code Execution Vulnerability No No 8.8 Yes

Microsoft Office vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-24522 Skype Extension for Chrome Information Disclosure Vulnerability No No 7.5 Yes
CVE-2022-24462 Microsoft Word Security Feature Bypass Vulnerability No No 5.5 Yes
CVE-2022-24511 Microsoft Office Word Tampering Vulnerability No No 5.5 Yes
CVE-2022-24509 Microsoft Office Visio Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24461 Microsoft Office Visio Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24510 Microsoft Office Visio Remote Code Execution Vulnerability No No 7.8 Yes

System Center vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-23265 Microsoft Defender for IoT Remote Code Execution Vulnerability No No 7.2 Yes
CVE-2022-23266 Microsoft Defender for IoT Elevation of Privilege Vulnerability No No 7.8 Yes
CVE-2022-23278 Microsoft Defender for Endpoint Spoofing Vulnerability No No 5.9 Yes

Windows vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-21967 Xbox Live Auth Manager for Windows Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24525 Windows Update Stack Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24508 Windows SMBv3 Client/Server Remote Code Execution Vulnerability No No 8.8 Yes
CVE-2022-23284 Windows Print Spooler Elevation of Privilege Vulnerability No No 7.2 No
CVE-2022-21975 Windows Hyper-V Denial of Service Vulnerability No No 4.7 Yes
CVE-2022-23294 Windows Event Tracing Remote Code Execution Vulnerability No No 8.8 Yes
CVE-2022-23291 Windows DWM Core Library Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-23288 Windows DWM Core Library Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-23286 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24455 Windows CD-ROM Driver Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-24507 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-23287 Windows ALPC Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24505 Windows ALPC Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24501 VP9 Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24451 VP9 Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24460 Tablet Windows User Interface Application Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-23295 Raw Image Extension Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-23300 Raw Image Extension Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-22010 Media Foundation Information Disclosure Vulnerability No No 4.4 Yes
CVE-2022-21977 Media Foundation Information Disclosure Vulnerability No No 3.3 Yes
CVE-2022-22006 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-23301 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-22007 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24452 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24453 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24456 HEVC Video Extensions Remote Code Execution Vulnerability No No 7.8 Yes
CVE-2022-24457 HEIF Image Extensions Remote Code Execution Vulnerability No No 7.8 Yes

Windows ESU vulnerabilities

CVE Title Exploited Publicly disclosed? CVSSv3 base score Has FAQ?
CVE-2022-24454 Windows Security Support Provider Interface Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-23299 Windows PDEV Elevation of Privilege Vulnerability No No 7.8 Yes
CVE-2022-23298 Windows NT OS Kernel Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-23297 Windows NT Lan Manager Datagram Receiver Driver Information Disclosure Vulnerability No No 5.5 Yes
CVE-2022-21973 Windows Media Center Update Denial of Service Vulnerability No No 5.5 No
CVE-2022-23296 Windows Installer Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-23290 Windows Inking COM Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-24502 Windows HTML Platforms Security Feature Bypass Vulnerability No No 4.3 Yes
CVE-2022-24459 Windows Fax and Scan Service Elevation of Privilege Vulnerability No Yes 7.8 No
CVE-2022-23293 Windows Fast FAT File System Driver Elevation of Privilege Vulnerability No No 7.8 No
CVE-2022-23281 Windows Common Log File System Driver Information Disclosure Vulnerability No No 5.5 Yes
CVE-2022-23283 Windows ALPC Elevation of Privilege Vulnerability No No 7 Yes
CVE-2022-24503 Remote Desktop Protocol Client Information Disclosure Vulnerability No No 5.4 Yes
CVE-2022-21990 Remote Desktop Client Remote Code Execution Vulnerability No Yes 8.8 Yes
CVE-2022-23285 Remote Desktop Client Remote Code Execution Vulnerability No No 8.8 Yes
CVE-2022-23253 Point-to-Point Tunneling Protocol Denial of Service Vulnerability No No 6.5 No

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Announcing experimental DDR in 1.1.1.1

Post Syndicated from Christopher Wood original https://blog.cloudflare.com/announcing-ddr-support/

Announcing experimental DDR in 1.1.1.1

Announcing experimental DDR in 1.1.1.1

1.1.1.1 sees approximately 600 billion queries per day. However, proportionally, most queries sent to this resolver are over cleartext: 89% over UDP and TCP combined, and the remaining 11% are encrypted. We care about end-user privacy and would prefer to see all of these queries sent to us over an encrypted transport using DNS-over-TLS or DNS-over-HTTPS. Having a mechanism by which clients could discover support for encrypted protocols such as DoH or DoT will help drive this number up and lead to more name encryption on the Internet. That’s where DDR – or Discovery of Designated Resolvers – comes into play. As of today, 1.1.1.1 supports the latest version of DDR so clients can automatically upgrade non-secure UDP and TCP connections to secure connections. In this post, we’ll describe the motivations for DDR, how the mechanism works, and, importantly, how you can test it out as a client.

DNS transports and public resolvers

We initially launched our public recursive resolver service 1.1.1.1 over three years ago, and have since seen its usage steadily grow. Today, it is one of the fastest public recursive resolvers available to end-users, supporting the latest security and privacy DNS transports such as HTTP/3 for DNS-over-HTTPS (DoH), as well as Oblivious DoH.

As a public resolver, all clients, regardless of type, are typically manually configured based on a user’s desired performance, security, and privacy requirements. This choice reflects answers to two separate but related types of questions:

  1. What recursive resolver should be used to answer my DNS queries? Does the resolver perform well? Does the recursive resolver respect my privacy?
  2. What protocol should be used to speak to this particular recursive resolver? How can I keep my DNS data safe from eavesdroppers that should otherwise not have access to it?

The second question primarily concerns technical matters. In particular, whether or not a recursive resolver supports DoH is simple enough to answer. Either the recursive resolver does or does not support it!

In contrast, the first question is primarily a matter of policy. For example, consider the question of choosing between a local network-provided DNS recursive resolver and a public recursive resolver. How do resolver features (including DoH support, for example) influence this decision? How does the resolver’s privacy policy regarding data use and retention influence this decision? More generally, what information about recursive resolver capabilities is available to clients in making this decision and how is this information delivered to clients?

These policy questions have been the topic of substantial debate in the Internet Engineering Task Force (IETF), the standards body where DoH was standardized, and is the one facet of the Adaptive DNS Discovery (ADD) Working Group, which is chartered to work on the following items (among others):

– Define a mechanism that allows clients to discover DNS resolvers that support encryption and that are available to the client either on the public Internet or on private or local networks.

– Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions. This could be part of the mechanism used for discovery, above.

In other words, the ADD Working Group aims to specify mechanisms by which clients can obtain the information they need to answer question (1). Critically, one of those pieces of information is what encrypted transport protocols the recursive resolver supports, which would answer question (2).

As the answer to question (2) is purely technical and not a matter of policy, the ADD Working Group was able to specify a workable solution that we’ve implemented and tested with existing clients. Before getting into the details of how it works, let’s dig into the problem statement here and see what’s required to address it.

Threat model and problem statement

The DDR problem is relatively straightforward: given the IP address of a DNS recursive resolver, how can one discover parameters necessary for speaking to the same resolver using an encrypted transport? (As above, discovering parameters for a different resolver is a distinctly different problem that pertains to policy and is therefore out of scope.)

This question is only meaningful insofar as using encryption helps protect against some attacker. Otherwise, if the network was trusted, encryption would add no value! A direct consequence is that this question assumes the network – for some definition of “the network” – is untrusted and encryption helps protect against this network.

But what exactly is the network here? In practice, the topology typically looks like the following:

Announcing experimental DDR in 1.1.1.1
Typical DNS configuration from DHCP

Again, for DNS discovery to have any meaning, we assume that either the ISP or home network – or both – is untrusted and malicious. The setting here depends on the client and the network they are attached to, but it’s generally simplest to assume the ISP network is untrusted.

This question also makes one important assumption: clients know the desired recursive resolver address. Why is this important? Typically, the IP address of a DNS recursive resolver is provided via Dynamic Host Configuration Protocol (DHCP). When a client joins a network, it uses DHCP to learn information about the network, including the default DNS recursive resolver. However, DHCP is a famously unauthenticated protocol, which means that any active attacker on the network can spoof the information, as shown below.

Announcing experimental DDR in 1.1.1.1
Unauthenticated DHCP discovery

One obvious attacker vector would be for the attacker to redirect DNS traffic from the network’s desired recursive resolver to an attacker-controlled recursive resolver. This has important implications on the threat model for discovery.

First, there is currently no known mechanism for encrypted DNS discovery in the presence of an active attacker that can influence the client’s view of the recursive resolver’s address. In other words, to make any meaningful improvement, DNS discovery assumes the client’s view of the DNS recursive resolver address is correct (and obtained through some secure mechanism). A second implication is that the attacker can simply block any attempt of client discovery, preventing upgrade to encrypted transports. This seems true of any interactive discovery mechanism. As a result, DNS discovery must relax this attacker’s capabilities somewhat: rather than add, drop, or modify packets, the attacker can only add or modify packets.

Altogether, this threat model lets us sharpen the DNS discovery problem statement: given the IP address of a DNS recursive resolver, how can one securely discover parameters necessary for speaking to the same resolver using an encrypted transport in the presence of an active attacker that can add or modify packets? It should be infeasible, for example, for the attacker to redirect the client from the resolver that it knows at the outset to one the attacker controls.

So how does this work, exactly?

DDR mechanics

DDR depends on two mechanisms:

  1. Certificate-based authentication of encrypted DNS resolvers.
  2. SVCB records for encoding and communicating DNS parameters.

Certificates allow resolvers to prove authority for IP addresses. For example, if you view the certificate for one.one.one.one, you’ll see several IP addresses listed under the SubjectAlternativeName extension, including 1.1.1.1.

Announcing experimental DDR in 1.1.1.1
SubjectAltName list of the one.one.one.one certificate

SVCB records are extensible key-value stores that can be used for conveying information about services to clients. Example information includes the supported application protocols, including HTTP/3, as well as keying material like that used for TLS Encrypted Client Hello.

How does DDR combine these two to solve the discovery problem above? In three simple steps:

  1. Clients query the expected DNS resolver for its designations and their parameters with a special-purpose SVCB record.
  2. Clients open a secure connection to the designated resolver, for example, one.one.one.one, authenticating the resolver against the one.one.one.one name.
  3. Clients check that the designated resolver is additionally authenticated for the IP address of the origin resolver. That is, the certificate for one.one.one.one, the designated resolver, must include the IP address 1.1.1.1, the original designator resolver.

If this validation completes, clients can then use the secure connection to the designated resolver. In pictures, this is as follows:

Announcing experimental DDR in 1.1.1.1
DDR discovery process

This demonstrates that the encrypted DNS resolver is authoritative for the client’s original DNS resolver. Or, in other words, that the original resolver and the encrypted resolver are effectively  “the same.” An encrypted resolver that does not include the originally requested resolver IP address on its certificate would fail the validation, and clients are not expected to follow the designated upgrade path. This entire process is referred to as “Verified Discovery” in the DDR specification.

Experimental deployment and next steps

To enable more encrypted DNS on the Internet and help the standardization process, 1.1.1.1 now has experimental support for DDR. You can query it directly to find out:

$ dig +short @1.1.1.1 _dns.resolver.arpa type64

QUESTION SECTION
_dns.resolver.arpa.               IN SVCB 

ANSWER SECTION
_dns.resolver.arpa.                           300    IN SVCB  1 one.one.one.one. alpn="h2,h3" port="443" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001" key7="/dns-query{?name}"
_dns.resolver.arpa.                           300    IN SVCB  2 one.one.one.one. alpn="dot" port="853" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001"

ADDITIONAL SECTION
one.one.one.one.                              300    IN AAAA  2606:4700:4700::1111
one.one.one.one.                              300    IN AAAA  2606:4700:4700::1001
one.one.one.one.                              300    IN A     1.1.1.1
one.one.one.one.                              300    IN A     1.0.0.1

This command sends a SVCB query (type64) for the reserved name _dns.resolver.arpa to 1.1.1.1. The output lists the contents of this record, including the DoH and DoT designation parameters. Let’s walk through the contents of this record:

_dns.resolver.arpa.                           300    IN SVCB  1 one.one.one.one. alpn="h2,h3" port="443" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001" key7="/dns-query{?name}"

This says that the DoH target one.one.one.one is accessible over port 443 (port=”443”) using either HTTP/2 or HTTP/3 (alpn=”h2,h3”), and the DoH path (key7) for queries is “/dns-query{?name}”.

Moving forward

DDR is a simple mechanism that lets clients automatically upgrade to encrypted transport protocols for DNS queries without any manual configuration. At the end of the day, users running compatible clients will enjoy a more private Internet experience. Happily, both Microsoft and Apple recently announced experimental support for this emerging standard, and we’re pleased to help them and other clients test support.
Going forward, we hope to help add support for DDR to open source DNS resolver software such as dnscrypt-proxy and Bind. If you’re interested in helping us continue to drive adoption of encrypted DNS and related protocols to help build a better Internet, we’re hiring!

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close