Поредна димка за машинното гласуване и изборите в София

Post Syndicated from Bozho original https://blog.bozho.net/blog/4210

Гледам, че пак се правят опити за дискредитиране на машинното гласуване дори когато машините не отичтат резултат. Както обикновено, зад бомбастични твърдения като „откраднати гласове“, „масова фалшификация“, „не се знае кой печели“ и „липсващи флашки“ стои (в добрия случай) некомпетентност и (в лошия случай) политическа злонамереност. Затова нека обърна внимание на някои детайли:

На първо място трябва да подчертаем за пореден път, че след последните промени, машините не броят. Броят хората. Машината може да се ползва, за да се установят евентуални проблеми при броенето от хората в комисиите.

Това, което експертизата е установила (четох я преди заседанието на съда), е че има нищожни разминавания (200 гласа при 300 секции) между хартиените протоколи и данните на флашките. Нещо, което винаги го е имало, винаги се е оказвало, че е или човешка грешка при броенето или еднократен проблем с принтера и хартията. Именно заради тези разминавания настоявахме флашките да останат в изборния кодекс, настоявахме да се използват в РИК при приемане на протоколите. РИК не прави това сравнение, но флашките останаха именно заради настояването на ППДБ. За да могат да се правят такива сравнения. Но чували не са отваряни и бюлетини не са броени. Т.е. в момента отчитаме разликата между отчетеното от машината и отчетеното от секционната комисия, без да го броим повторно. Съответно всякакви твърдения кое е „вярно“ са несъстоятелни.

Разликите винаги са били нищожни и не са променяли резултата. Аз направих такова сравнение на парламетнарните избори и го публикувах. И тогава разминаванията не променяха резултата, и сега не го правят – кумулативно 200 гласа при 10% от протоколите значат, че дори да се запази това съотношение, при 100% сравнение ще има 1000 гласа разлика. При победа на Терзиев с около 5000 гласа. Трябва да отбележим, че на флашката има повече гласове и за двамата кандидати. Отчасти заради проблеми с ролката и хартията, отчасти заради човешки грешки при броенето.

Има твърдения, че протоколите не са подписани с квалифициран електронен подпис. Първо, по закон това не се изисква. Защото квалифицираният електронен подпис е на физическо лице, а ключовете (и картите) с които се подписват протоколите са на „секционна комисия“, т.е. законово те няма как да бъдат КЕП. Но технически са именно такива – смарткарта, частен ключ, удостоверителна верига и то (по стечение на обстоятелствата) от доставчик на квалифицирани удостоверителни услуги, т.е. с опит в тази сфера (Информационно обслужване). Подписите могат да се проверят от всеки и гарантират, че е нямало подмяна на файлове (по моя препоръка ЦИК публикува публичните ключове на смарткартите преди изборния ден, за да може да се установи дали подписите са направени с правилните карти, а не с други). (Твърдението за подписването е оттеглено в съдебното заседание от вещото лице след несъгласие от страна на нашите адвокати)

Липсващите 15 флашки (според експертизата) всъщност са проблем на организацията при предоставяне на материалите. Първоначално не е била предоставена нито една флашка (пак според експертизата). Данните от флашките, заедно с подписите към тях, са налични на сайта на ЦИК – проверих тези секции. Вещите лица е можело също да ги вземат от там и да ги сравнят, оставяйки все пак забележката, че не са дошли на флашка (аз сравних 4 от тях, няма нищо по-различно от останалите – +/- един глас)

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

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

Материалът Поредна димка за машинното гласуване и изборите в София е публикуван за пръв път на БЛОГодаря.

Седмицата (22–27 януари)

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-22-27-yanuari/

Седмицата (22–27 януари)

Нов разказ за бъдещето е все по-болезнено нужен както на ЕС, така и на България, особено на тази част от нея, която иска да гледа напред, а не назад. Този разказ е все по-спешен на фона на преизпълнената с избори година – и отвъд, и отсам океана. Според Емилия Милчева е важно проевропейските сили у нас да положат сериозни усилия за нов достоверен комплект от мечти за бъдещето преди изборите за Европейски парламент през лятото на тази година. Аргументите ѝ може да прочетете в нейния анализ, озаглавен „Българският казан и ЕС“.

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

Но да поогледаме още малко детайли от темата за новите лица в Конституционния съд. Този път ще се вторачим повече в уж по-безкомпромисната кандидатура – на съдия Борислав Белазелков. Светла Енчева обръща внимание на някои от възгледите му, споделени по време на изслушванията, които заслужава да отбележим с едно наум. Прочетете повече в статията ѝ „Бракът – тайнство, сделка или съюз? България – светска или не?“.

За жалост, напоследък привикнахме да четем и следим военните хроники. Но това, че свикнахме, не означава, че е лесно, нито пък че не нараняват съзнанието и отношенията ни, дори отдалече. По тази тема е и статията „Снимките от войните и пораженията върху въображението“ – една много ценна дискусия за използването на образите като оръжия. Еми Барух разговаря с поета, есеист и културолог Кирил Василев и с философа, писател и преподавател Тодор П. Тодоров. Интервюто е важно и излиза далеч извън рамката на заглавието си.

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

„Грехът на цветовете“ пък е заглавието на стихотворението, което нашият екип избра за вас този месец. То е на португалския поет и преподавател от Университета на Порто Жоао Луиш Барето Гимарайш. Негова стихосбирка очакваме скоро и в превод на български, направен от Сони Бохосян.

Вероятно вече знаете, че изкуствен интелект, сглобка и времеубежище са думите на 2023 година за България. А няма как да не знаете, че Павлина Върбанова от „Как се пише?“ е езиков редактор и коректор на „Тоест“ от самото начало на нашия проект – вече почти шест години. Всеки материал, който някога сме публикували, задължително е минавал финално и през нея. Но тя никога не е писала за „Тоест“. Е, от тази седмица това вече не е така. Може да прочетете личния ѝ анализ на тазгодишната кампания „Думи на годината“. И това не е всичко. Текстът поставя началото на нейна редовна рубрика в „Тоест“, която се казва „Порция език“.

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

И накрая: през седмицата Google анонсира старта на своя новинарски продукт News Showcase за България. Така ползвателите на смартфони с Android (а и на iOS, ако си инсталират допълнително приложението Google News), могат да четат курирано новинарско съдържание от предпочитани източници. Още по-добрата опция е, че всеки може да си настрои и забранителен списък с медии, които не би искал да чете, което със сигурност поне засега позиционира Google News като по-удачен инструмент за консумиране на новини вместо социалните мрежи. И разбира се, може да откриете и съдържанието на „Тоест“ там и да ни добавите в списъка на предпочитаните си медии.

Приятно четене!

Friday Squid Blogging: Footage of Black-Eyed Squid Brooding Her Eggs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/01/friday-squid-blogging-footage-of-black-eyed-squid-brooding-her-eggs.html

Amazing footage of a black-eyed squid (Gonatus onyx) carrying thousands of eggs. They tend to hang out about 6,200 feet below sea level.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

Metasploit Weekly Wrap-Up 01/26/24

Post Syndicated from Alan David Foster original https://blog.rapid7.com/2024/01/26/metasploit-weekly-wrap-up-01-26-24/

Direct Syscalls Support for Windows Meterpreter

Metasploit Weekly Wrap-Up 01/26/24

Direct system calls are a well-known technique that is often used to bypass EDR/AV detection. This technique is particularly useful when dynamic analysis is performed, where the security software monitors every process on the system to detect any suspicious activity. One common way to do so is to add user-land hooks on Win32 API calls, especially those commonly used by malware. Direct syscalls are a way to run system calls directly and enter kernel mode without passing through the Win32 API.

This first implementation focuses on substituting the Win32 API calls used by the Reflective DLL Injection (RDI) library with Direct Syscalls to the corresponding Native API’s. For example, VirtualAlloc has been substituted by a system call to ZwAllocateVirtualMemory. Since RDI is used everywhere by Meterpreter and its extensions, it was a very good candidate for this initial work.

The main difficulty is to find the correct syscall number since it is not the same across Windows versions. Also, EDR’s usually hook the NTDLL native API, making the discovery of syscall numbers more challenging. The technique used for this is based on the assumption that the syscall numbers are assigned in a sequential order, starting from the number 0. If we look at how native API functions are stored in memory, the syscall number can be deduced from the position of the related native API function in memory. The technique consists in selecting the system call functions (Zw…) from ntdll.dll exports and sorting them in ascending order of their memory addresses. The syscall number of one given native API function is simply its index in this sorted list. This is very similar to the technique used by Halo’s Gate.

Another improvement is to make sure the call to the syscall instruction is made through ntdll.dll. EDR/AV can monitor this and flag any system calls not coming from ntdll.dll as suspicious. This technique is directly taken from RecycledGate. Here, the complexity is that Meterpreter must be compatible with all Windows versions from WinXP to the most recent flavors. This implementation will take care of parsing ntdll.dll and get the correct trampoline address that will be used when the system call is executed.

This work is a first step and we expect more additions this year. The next step is to switch additional Win32 API requests that Meterpreter and its extensions make to their corresponding native API using Direct Syscalls. The long-term goal is to make Direct Syscalls a standard for any future Windows-based development (payload, exploit, etc.).

New module content (8)

GL.iNet Unauthenticated Remote Command Execution via the logread module.

Authors: DZONERZY, Unknown, and h00die-gr3y [email protected]
Type: Exploit
Pull request: #18648 contributed by h00die-gr3y
Path: linux/http/glinet_unauth_rce_cve_2023_50445

Description: This PR adds an exploit module for a number of different GL.iNet network products. The module combines an authentication by-pass vulnerability (CVE-2023-50919) with an RCE (CVE-2023-50445) allowing the user to remotely obtain, without authentication, a Meterpreter session running in the context of the root user.

Ivanti Connect Secure Unauthenticated Remote Code Execution

Author: sfewer-r7
Type: Exploit
Pull request: #18708 contributed by sfewer-r7
Path: linux/http/ivanti_connect_secure_rce_cve_2023_46805

Description: This PR adds an exploit chain that consists of two vulnerabilities, an authentication bypass (CVE-2023-46805) and a command injection vulnerability (CVE-2024-21887). The exploit chain allows a remote unauthenticated attacker to execute arbitrary OS commands with root privileges. As per the Ivanti advisory, these vulnerabilities affect all supported versions of the products, versions 9.x and 22.x. It is unknown if the unsupported versions 8.x and older are also affected.

MajorDoMo Command Injection

Authors: Valentin Lobstein and smcintyre-r7
Type: Exploit
Pull request: #18630 contributed by Chocapikk
Path: linux/http/majordomo_cmd_inject_cve_2023_50917

Description: This adds an exploit for a command injection vulnerability in MajorDoMo versions before 0662e5e.

Saltstack Minion Payload Deployer

Authors: c2Vlcgo and h00die
Type: Exploit
Pull request: #18626 contributed by h00die
Path: linux/local/saltstack_salt_minion_deployer

Description: This PR adds an exploit module which allows for a user who has compromised a host acting as a SaltStack Master to deploy payloads to the Minions attached to that Master.

Apache Commons Text RCE

Authors: Alvaro Muñoz, Gaurav Jain, and Karthik UJ
Type: Exploit
Pull request: #18638 contributed by errorxyz
Path: multi/http/apache_commons_text4shell

Description: Adds an exploit module for CVE-2022-42889 that targets web apps utilizing Apache Commons Text’s (1.5-1.9) StringSubstitutor interpolator class in an insecure fashion.

Atlassian Confluence SSTI Injection

Authors: Harsh Jaiswal, Rahul Maini, and Spencer McIntyre
Type: Exploit
Pull request: #18734 contributed by zeroSteiner
Path: multi/http/atlassian_confluence_rce_cve_2023_22527

Description: This adds an exploit for CVE-2023-22527 which is an unauthenticated RCE in Atlassian Confluence. The vulnerability is due to an SSTI flaw that allows an OGNL expression to be evaluated. The result is OS command execution in the context of the service account.

PRTG CVE-2023-32781 Authenticated RCE

Author: Kevin Joensen [email protected]
Type: Exploit
Pull request: #18568 contributed by ggisz
Path: windows/http/prtg_authenticated_rce_cve_2023_32781

Description: This PR adds a module leveraging CVE-2023-32781, an authenticated command injection vulnerability in PRTG versions 23.2.84.1566 and earlier. The result is command execution as SYSTEM.

Memory Search

Author: sjanusz-r7
Type: Post
Pull request: #18713 contributed by sjanusz-r7
Path: multi/gather/memory_search

Description: Adds a new multi/gather/memory_search module that can read memory of processes on Windows and Linux hosts with Meterpreter. Regular expressions can be used to find passwords/credentials, and glob patterns and PIDs can be used to identify target processes.

Enhancements and features (6)

  • #17634 from adfoster-r7 – Reliability and stability notes that have been previously missing have been added to some modules.
  • #18645 from jvoisin – This adds a way to get the Build ID from ld.so by using the ‘perf’ command. Before this module depended on the commands ‘file’ and ‘readelf’ being installed to get the Build ID.
  • #18663 from sjanusz-r7 – Adds a new Postgres session type, which is current behind a feature flag that can be activated with: features set postgresql_session_type true. Example usage: use scanner/postgres/postgres_login followed by run postgres://postgres:[email protected]:9000/template1 createsession=true verbose=false.
  • #18720 from zeroSteiner – This enhancement marks the existing Unix encoders as also being compatible with Linux. Previously, no encoder modules were marked as compatible with Linux, so users could not set bad character when using the new fetch payloads.
  • #18735 from AleksaZatezalo – Adds additional module metadata to the exploits/windows/iis/iis_webdav_scstoragepathfromurl module.
  • #18737 from zeroSteiner – This updates metasploit-payloads gem to 2.0.165 to pull in changes to support direct syscalls for Meterpreter on Windows. See this PR and this PR for details.

Bugs fixed (3)

  • #18662 from dwelch-r7 – Fixes an edgecase where features set dns_feature true did not correctly parse a user’s /etc/resolv.conf file if there were multiple nameservers present.
  • #18712 from ekalinichev-r7 – Fixes a crash with Metasploit’s REST api when calling /api/v1/modules?name=aux.
  • #18746 from zeroSteiner – Fixes a module bug when using the generate OPTION=VALUE syntax. Previously, the module’s datastore would be unintentionally updated with the new option value.

Documentation added (1)

  • #18729 from poupapaa – This fixes a typo in Metasploit-Guide-SMB.md.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

Export a Software Bill of Materials using Amazon Inspector

Post Syndicated from Varun Sharma original https://aws.amazon.com/blogs/security/export-a-software-bill-of-materials-using-amazon-inspector/

Amazon Inspector is an automated vulnerability management service that continually scans Amazon Web Services (AWS) workloads for software vulnerabilities and unintended network exposure. Amazon Inspector has expanded capability that allows customers to export a consolidated Software Bill of Materials (SBOM) for supported Amazon Inspector monitored resources, excluding Windows EC2 instances.

Customers have asked us to provide additional software application inventory collected from Amazon Inspector monitored resources. This makes it possible to precisely track the software supply chain and security threats that might be connected to the results of the current Amazon Inspector. Generating an SBOM gives you critical security information that offers you visibility into specifics about your software supply chain, including the packages you use the most frequently and the related vulnerabilities that might affect your whole company.

This blog post includes steps that you can follow to export a consolidated SBOM for the resources monitored by Amazon Inspector across your organization in industry standard formats, including CycloneDx and SPDX. It also shares insights and approaches for analyzing SBOM artifacts using Amazon Athena.

Overview

An SBOM is defined as a nested inventory with a list of ingredients that make up software components. Security teams can export a consolidated SBOM to Amazon Simple Storage Service (Amazon S3) for an entire organization from the resource coverage page in the AWS Management Console for Amazon Inspector.

Using CycloneDx and SPDX industry standard formats, you can use insights gained from an SBOM to make decisions such as which software packages need to be updated across your organization or deprecated, if there’s no other option. Individual application or security engineers can also export an SBOM for a single resource or group of resources by applying filters for a specific account, resource type, resource ID, tags, or a combination of these as a part of the SBOM export workflow in the console or application programming interfaces.

Exporting SBOMs

To export Amazon Inspector SBOM reports to an S3 bucket, you must create and configure a bucket in the AWS Region where the SBOM reports are to be exported. You must configure your bucket permissions to allow only Amazon Inspector to put new objects into the bucket. This prevents other AWS services and users from adding objects to the bucket.

Each SBOM report is stored in an S3 bucket and has the name Cyclonedx_1_4 (Json) or Spdx_2_3-compatible (Json), depending on the export format that you specify. You can also use S3 event notifications to alert different operational teams that new SBOM reports have been exported.

Amazon Inspector requires that you use an AWS Key Management Service (AWS KMS) key to encrypt the SBOM report. The key must be a customer managed, symmetric KMS encryption key and must be in the same Region as the S3 bucket that you configured to store the SBOM report. The new KMS key for the SBOM report requires a key policy to be configured to grant permissions for Amazon Inspector to use the key. (Shown in Figure 1.)

Figure 1: Amazon Inspector SBOM export

Figure 1: Amazon Inspector SBOM export

Deploy prerequisites

The AWS CloudFormation template provided creates an S3 bucket with an associated bucket policy to enable Amazon Inspector to export SBOM report objects into the bucket. The template also creates a new KMS key to be used for SBOM report exports and grants the Amazon Inspector service permissions to use the key.

The export can be initiated from the AWS Inspector delegated administrator account or the AWS Inspector administrator account itself. This way, the S3 bucket contains reports for the AWS Inspector member accounts. To export the SBOM reports from Amazon Inspector deployed in the same Region, make sure the CloudFormation template is deployed within the AWS account and Region. If you enabled AWS Inspector in multiple accounts, the CloudFormation stack must be deployed in each Region where AWS Inspector is enabled.

To deploy the CloudFormation template

  1. Choose the following Launch Stack button to launch a CloudFormation stack in your account.

    Launch Stack

  2. Review the stack name and the parameters (MyKMSKeyName and MyS3BucketName) for the template. Note that the S3 bucket name must be unique.
  3. Choose Next and confirm the stack options.
  4. Go to the next page and choose Submit. The deployment of the CloudFormation stack will take 1–2 minutes.

After the CloudFormation stack has deployed successfully, you can use the S3 bucket and KMS key created by the stack to export SBOM reports.

Export SBOM reports

After setup is complete, you can export SBOM reports to an S3 bucket.

To export SBOM reports from the console

  1. Navigate to the AWS Inspector console in the same Region where the S3 bucket and KMS key were created.
  2. Select Export SBOMs from the navigation pane.
  3. Add filters to create reports for specific subsets of resources. The SBOMs for all active, supported resources are exported if you don’t supply a filter.
  4. Select the export file type you want. Options are Cyclonedx_1_4 (Json) or Spdx_2_3-compatible (Json).
  5. Enter the S3 bucket URI from the output section of the CloudFormation template and enter the KMS key that was created.
  6. Choose Export. It can take 3–5 minutes to complete depending on the number of artifacts to be exported.
Figure 2: SBOM export configuration

Figure 2: SBOM export configuration

When complete, all SBOM artifacts will be in the S3 bucket. This gives you the flexibility to download the SBOM artifacts from the S3 bucket, or you can use Amazon S3 Select to retrieve a subset of data from an object using standard SQL queries.

Figure 3: Amazon S3 Select

Figure 3: Amazon S3 Select

You can also run advanced queries using Amazon Athena or create dashboards using Amazon QuickSight to gain insights and map trends.

Querying and visualization

With Athena, you can run SQL queries on raw data that’s stored in S3 buckets. The Amazon Inspector reports are exported to an S3 bucket, and you can query the data and create tables by following the Adding an AWS Glue crawler tutorial.

To enable AWS Glue to crawl the S3 data, you must add the role as described in the AWS Glue crawler tutorial to the AWS KMS key permissions so that AWS Glue can decrypt the S3 data.

The following is an example policy JSON that you can update for your use case. Make sure to replace the AWS account ID <111122223333> and S3 bucket name <DOC-EXAMPLE-BUCKET-111122223333> with your own information.

{
    "Sid": "Allow the AWS Glue crawler usage of the KMS key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::<111122223333>:role/service-role/AWSGlueServiceRole-S3InspectorSBOMReports"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "arn:aws:s3:::<DOC-EXAMPLE-BUCKET-111122223333>"
},

Note: The role created for AWS Glue also needs permission to read the S3 bucket where the reports are exported for creating the crawlers. The AWS Glue AWS Identity and Access Management (IAM) role allows the crawler to run and access your Amazon S3 data stores.

After an AWS Glue Data Catalog has been built, you can run the crawler on a scheduled basis to help ensure that it’s kept up to date with the latest Amazon Inspector SBOM manifests as they’re exported into the S3 bucket.

You can further navigate to the added table using the crawler and view the data in Athena. Using Athena, you can run queries against the Amazon Inspector reports to generate output data relevant to your environment. The schema for the generated SBOM report is different depending on the specific resources (Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda, Amazon Elastic Container Registry (Amazon ECR)) in the reports. So, depending on the schema, you can create a SQL Athena query to fetch information from the reports.

The following is an Athena example query that identifies the top 10 vulnerabilities for resources in an SBOM report. You can use the common vulnerability and exposures (CVE) IDs from the report to list the individual components affected by the CVEs.

SELECT
   account,
   vuln.id as vuln_id, 
   count(*) as vuln_count
FROM
   <Insert_table_name>,
   UNNEST(Inset_table_name.vulnerabilities)as t(vuln)
GROUP BY
   account,
   vuln.id
ORDER BY
vuln_count DESC
LIMIT 10;

The following Athena example query can be used to identify the top 10 operating systems (OS) along with the resource types and their count.

SELECT
   resource,
   metadata.component.name as os_name,
   count(*) as os_count 
FROM
   <Insert_table_name>
WHERE
   resource = 'AWS_LAMBDA_FUNCTION'
GROUP BY
   resource,
   metadata.component.name 
ORDER BY
   os_count DESC 
LIMIT 10;

If you have a package that has a critical vulnerability and you need to know if the package is used as a primary package or adds a dependency, you can use the following Athena sample query to check for the package in your application. In this example, I’m searching for a Log4j package. The result returns account ID, resource type, package_name, and package_count.

SELECT
   account,
   resource,
   comp.name as package_name,
   count(*) as package_count 
FROM
   <Insert_Table _name>,
   UNNEST(<Insert_Table_name>.components) as t(comp) 
WHERE
   comp.name = 'Log4j' 
GROUP BY
   account,
   comp.name,
   resource 
ORDER BY
   package_count DESC 
LIMIT 10 ;

Note: The sample Athena queries must be customized depending on the schema of the SBOM export report.

To further extend this solution, you can use Amazon QuickSight to produce dashboards to visualize the data by connecting to the AWS Glue table.

Conclusion

The new SBOM generation capabilities in Amazon Inspector improve visibility into the software supply chain by providing a comprehensive list of software packages across multiple levels of dependencies. You can also use SBOMs to monitor the licensing information for each of the software packages and identify potential licensing violations in your organization, helping you avoid potential legal risks.

The most important benefit of SBOM export is to help you comply with industry regulations and standards. By providing an industry-standard format (SPDX and CycloneDX) and enabling easy integration with other tools, systems, or services (such as Nexus IQ and WhiteSource), you can streamline the incident response processes, improve the accuracy and speed of security assessments, and adhere to compliance with regulatory requirements.

In addition to these benefits, the SBOM export feature provides a comprehensive and accurate understanding of the OS packages and software libraries found in their resources, further enhancing your ability to adhere to industry regulations and standards.

 
If you have feedback about this post, submit comments in the Comments section below. If you have any question/query in regard to information shared in this post, start a new thread on the AWS IAM Identity Center re:Post or contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Varun Sharma

Varun Sharma

Varun is an AWS Cloud Security Engineer who wears his security cape proudly. With a knack for unravelling the mysteries of Amazon Cognito and IAM, Varun is a go-to subject matter expert for these services. When he’s not busy securing the cloud, you’ll find him in the world of security penetration testing. And when the pixels are at rest, Varun switches gears to capture the beauty of nature through the lens of his camera.

Научни новини: Климатични изменения, фотосинтеза и хвърковати хипотези

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-klimatichni-izmeneniya-fotosinteza/

Застудяване, причинено от затопляне

Научни новини: Климатични изменения, фотосинтеза и хвърковати хипотези

В началото на годината северните географски ширини бяха изложени на студена вълна, която доведе до нарушения в транспорта, затваряне на мостове и спиране на работата на редица институции. В северното шведско село Квикьок отчетоха –43,6°C – температура, която не е измервана през януари в последните 25 години. Застудяването не беше ограничено до скандинавските страни. В по-северните части на Европа температурите също паднаха осезаемо – в Москва температурата достигна –30°C, а в Санкт Петербург беше обявен оранжев код за опасно време. Сходна ситуация се наблюдаваше и в Северна Америка с няколко счупени рекорда за ниски температури в Канада. Междувременно във Великобритания, Франция и Германия имаше наводнения и силни ветрове, които нанесоха щети на инфраструктурата и наложиха евакуация на хора.

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

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

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

Научни новини: Климатични изменения, фотосинтеза и хвърковати хипотези
Диаграма, показваща нормалното функциониране на полярните вихри (вляво) и случващото се при внезапно стратосферно затопляне (вдясно). Източник: NOAA

Това е ключова причина и за изключително студения февруари през 2021 г., когато арктичният въздух стигна чак до Тексас и причини смъртта на поне 700 души и щети за над 200 млрд. долара. 

За съжаление, този феномен най-вероятно ще започне да става по-чест поради затоплянето на полюсите. Покачването на температурите в региона на Арктика е почти четири пъти по-високо от това в глобален мащаб за периода 1979–2021 г. В някои региони на Баренцово море затоплянето е още по-рязко и надвишава между пет и седем пъти глобалното за периода 1981–2020 г.

Климатът на планетата е сложна система, съставена от множество елементи, които работят в синхрон. При нарушаване на някой от тях (полярни вихри, Ел Ниньо, снежната покривка и количеството лед по полюсите) смущението не се отразява само на конкретния феномен, а се предава и към останалите, което води до самоподхранваща се каскада.

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

Промените в климата променят хранителните мрежи, което влияе на климата – и така до безкрай

Със затоплянето на планетата пермафростът (вечно замръзналата почва, покриваща немалка част от земната повърхност) започва да се топи. Това е причина за освобождаване на големи количества от въглерода, запазен в него, което допринася за задълбочаването на проблема със затоплянето. Наред с това самият пермафрост започва да гние. Тази разлагаща се материя е нов източник на въглерод в хранителните мрежи, както и в новата размразена среда, в която вече може да се развива живот, но и над земята.

За да разбере повече за новосъздадените връзки, екип от учени се спира на няколко представители на фауната, обитаваща размразяващите се области на Аляска – два вида полевки, един вид земеровки и един вид паяци. Целта на изследването е да се определи дали има промяна в източника на въглерод в диетата на животните, дефиниран от авторите като „зелен“ – от растителни източници, или „кафяв“ – от микробиален произход (бактерии и почвени гъби).

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

За установяване на дълготрайните ефекти е анализиран колаген на земеровки и полевки. Пробите са събрани през 1991 и 2021 г. Краткотрайното влияние на затоплянето е наблюдавано върху две групи арктически паяци вълци: едната – в контролни условия, а другата – в специално устроена среда (мезокосмос) в която температурата е с 2°C по-висока.

Резултатите са впечатляващи – хищните паяци, хранещи се в по-топла среда, заменят около 27% от въглерода, който приемат, от растителен на такъв от гъбни хранителни мрежи, а процентът бактериен въглерод остава непроменен. При бозайниците се наблюдава сходно преминаване от растителен към гъбен произход. При всеядните червено-сиви горски полевки тази промяна е над 30%, а при хищните земеровки – над 40%. Това показва, че промяната в климата влияе на екосистемите и чрез реорганизиране на хранителните мрежи в тях, създавайки нови трофични пътища.

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

По следите на фотосинтезата

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

Освен източник на енергия тя отключва и натрупването на кислород – фактор, без който развитието на сложни многоклетъчни организми би било невъзможно. Преди възникването на фотосинтезата, в атмосферата на планетата на практика е отсъствал свободен кислород. Предполага се, че съставът ѝ е бил основно от азот и въглероден диоксид с малки количества други газове (метан, водни пари и др.). Тъй като установяването на нивата на кислород е доста сложно и повишаването им е станало поетапно, е трудно да се определи точният първоначален момент. 

За осезаемото повишаване на концентрацията на кислород в околната среда е било нужно известно време, но настъпва момент, в който тя става токсична за анаеробните организми. Това събитие понякога се нарича кислородна катастрофа, тъй като се оказва пагубно за над 80% от живите организми, населяващи планетата по онова време. Към момента се предполага, че събитието е настъпило преди около 2,4 млрд. години, което се подкрепя от генетичните вариации в различните видове днес – метод, известен като молекулярен часовник. Според него фотосинтезата е възникнала преди около 3 млрд. години, което съвпада с появата на цианобактериите – свободно живеещи прокариоти, част от които продължават да съществуват независимо, а друга част стават ендосимбионти в клетките на микроскопични водорасли преди около 1–2 млрд. години, превръщайки се в добре познатите ни хлоропласти в съвременните фотосинтезиращи еукариоти. 

Въпреки че молекулярното датиране се приема за точно, липсата на преки доказателства за съществуването на фотосинтезиращи организми от този период донякъде поставя под въпрос доколко може да му се вярва в този случай. До момента само няколко микрофосила са определени като цианобактерии, повечето на базата на косвени доказателства. Само един – P. filiformis – със сигурност спада към тази група бактерии и е датиран на 1 млрд. години.

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

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

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

Хриле или криле, крака или крила

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

В подкрепа на всяка от трите (както и на техни алтернативи) може да се цитират много публикации, но едно от последните геномни изследвания показва връзка в развитието на крилата и хрилете при представител на разред Еднодневки. Заедно с водните кончета те имат морфология, много сходна с древните им предци, а освен това нимфите им живеят във водата, което налага наличието на трахейни хриле в началото на живота им. При анализа на данните се установява, че набор от гени, свързани с крилата, е много добре запазен при представителите на крилатите насекоми.

Интригуващо е и откритието, че транскриптомната програма (наборът от гени и последователността, в която се активират за провеждането на биологичен процес), отговорна за крилата, се състои от гени, които са част от други генни мрежи. Ако се групират по органи, най-близко са хрилете, споделящи 43% от гените, активни при формирането на крилата. При сравняване на тези общи гени с аналозите им в плодовите мушици (Drosophila melanogaster; класически моделен организъм) почти половината от тях имат ясна роля в развитието на крилата.

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

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

Inside the Secret Data Center at the Heart of the San Francisco 49ers Levis Stadium

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/inside-the-secret-data-center-at-the-heart-of-the-san-francisco-49ers-levis-stadium-intel/

We get to go inside the secret data center at the heart of the San Francisco 49ers Levi’s Stadium to see what it takes to run a NFL stadium

The post Inside the Secret Data Center at the Heart of the San Francisco 49ers Levis Stadium appeared first on ServeTheHome.

[$] Better handling of integer wraparound in the kernel

Post Syndicated from corbet original https://lwn.net/Articles/959189/

While the mathematical realm of numbers is infinite, computers are only
able to represent a finite subset of them. That can lead to problems when
arithmetic operations would create numbers that the computer is unable to
store as the intended type. This condition, called “overflow” or
“wraparound” depending on the
context, can be the source of bugs, including unpleasant security
vulnerabilities, so it is worth avoiding. This patch
series
from Kees Cook is intended to improve the kernel’s handling of
these situations, but it is running into a bit of resistance.

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/959640/

Security updates have been issued by Debian (xorg-server), Fedora (chromium, dotnet8.0, firefox, freeipa, and thunderbird), Red Hat (avahi, c-ares, curl, edk2, expat, freetype, frr, git, gnutls, grub2, kernel, kernel-rt, libcap, libfastjson, libssh, libtasn1, libxml2, linux-firmware, ncurses, oniguruma, openssh, openssl, perl-HTTP-Tiny, protobuf-c, python-urllib3, python3, python3.9, rpm, samba, shadow-utils, sqlite, tcpdump, tomcat, and virt:rhel and virt-devel:rhel modules), SUSE (cpio, jasper, rear23a, thunderbird, and xorg-x11-server), and Ubuntu (jinja2, kernel, linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gcp-5.15, linux-gke,
linux-gkeop, linux-gkeop-5.15, linux-hwe-5.15, linux-ibm, linux-ibm-5.15,
linux-kvm, linux-lowlatency-hwe-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4,
linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-hwe-5.4,
linux-ibm, linux-ibm-5.4, linux-iot, linux-oracle, linux-oracle-5.4,
linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp, linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2,
linux-azure-fde-6.2, linux-gcp, linux-hwe-6.5, linux-laptop,
linux-lowlatency, linux-lowlatency-hwe-6.5, linux-oem-6.5, linux-oracle,
linux-raspi, linux-starfive, linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe,
linux-kvm, linux-oracle, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-aws, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-oem-6.1, and mariadb, mariadb-10.3, mariadb-10.6).

The collective thoughts of the interwebz