Analysts say an 18% drop in ransomware attacks seen in May is likely fleeting, as Conti actors regroup.

A 18% drop in ransomware attacks in May is probably the result of Conti's shutdown, but the actors are regrouping under other brands, including KaraKurt, Black Byte, Hive, and Black Basta, analysts said. 

The latest report from NCC Group's threat intelligence team shows LockBit 2.0 maintained its top spot among ransomware groups, launching 40% of all attacks in May. Black Basta, which was discovered in April, along with Hive were behind 7% of attacks last month.   

“Conti’s possible shutdown represents a significant change for the ransomware threat landscape, and it cannot go ignored," said Matt Hull, global lead for strategic threat intelligence at NCC Group, in a statement announcing the ransomware attack report findings. "It will be interesting to see which smaller groups replace it as it rebrands, and how these new or evolved actors will behave – which NCC Group will of course continue to monitor.”

The findings also show industrial and critical infrastructure remain an attractive target. The sector was on the receiving end of 31% of attacks in May, followed by consumer cyclicals at 22% and technology at 12%. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Without Conti on the Scene, LockBit 2.0 Leads Ransomware Attacks

By Deeba Ahmed
This newly discovered malware campaign is attributed to a Chinese hacking group called Tropic Trooper. Cybersecurity researchers at…
This is a post from HackRead.com Read the original post: Chinese Hackers Distributing Nim language Malware in SMS Bomber Tool

****This newly discovered malware campaign is attributed to a Chinese hacking group called Tropic Trooper.****

Cybersecurity researchers at Check Point have shared details of a new malware campaign suspected to be launched by a Chinese hacking group Tropic Trooper.

The malware operators are using a unique loader Nimbda, written in Nim language, and a new variant of Yahoyah trojan.

Researchers state that the hackers possess extensive cryptographic knowledge as they have extended the AES specification in a customized implementation.

**Info-Stealing Trojan Embedded in SMS Bomber Tool**

According to Check Point’s analysis, the info stealing trojan is hidden inside a Chinese language greyware tool called SMS Bomber. This tool is used for targeting cellphones with Denial of Service attacks (DoS attacks).

SMS Bomber tool allows users to enter any phone number to flood their phones with a message, rendering the devices unusable. Novice hackers typically use such tools to compromise websites.

**Attack Scenario**

When the infected version of SMS Bomber (equipped with standard functionalities and the tool’s binary) is downloaded to the device, the attack sequence is immediately initiated. The downloaded tool also contains additional coding injected into a notepad.exe process. 

In a blog post, researchers explained that This executable is the Nimbda loader, which uses the SMS Bomber as an icon and an executable while the loader injects shellcode in the notepad process in the background. The process then reaches a GitHub repository, fetches an obfuscated executable, decodes it, and executes it through process hollowing in Dllhost.exe, the new Yahoyah variant. 

This variant collects host-related data and transmits it to the attacker-operated C2 server. The final payload that Yahoyah executable drops is encoded in a JPG file through steganography. Researchers identified it as TClient. It is a backdoor used in previous campaigns by Tropic Trooper.

The interface of SMS Bomber (left) – Infection chain of the malware (right)

**What Information is Collected**

Yahoyah can collect device names, local wireless networks’ SSIDs located within the target device’s vicinity, MAC address, antivirus products installed on the device, OS version, and presence of Tencent and WeChat files.

The encryption used for Yahoyah is a custom AES implementation to perform the inverted sequence of round operations twice. Therefore, Check Point named it AEES. Though it doesn’t make encryption any stronger, it makes analyzing it complicated for researchers.

**Potential Targets**

Tropic Trooper has mainly focused on espionage in their previously identified phishing campaigns targeting Russian entities. However, in this campaign, the hackers have trojanized the SMS Bomber tool; hence they have narrowed down their targets.

Researchers believe their target could be based on the intelligence information the group collected during past espionages. Tropic Trooper also uses KeyBoy, Earth Centaur, and Pirate Panda monikers.

The group has a history of targeting targets in Hong Kong, Taiwan, and the Philippines. Moreover, their prominent targets are linked to the government, transportation, healthcare, and technology sectors.

**More Chinese Hackers in Action News**

*   China’s insidious surveillance against Uyghurs with Android malware
*   Android malware HenBox hits Xiaomi devices & minority group in China
*   China arrests 11 hackers for infecting 250M devices with Fireball malware
*   Someone from China is Distributing Mirai Malware Through Windows Botnet
*   Unofficial Micropatch for Follina Issued as Chinese Hackers Exploit the 0-day

Chinese Hackers Distributing Nim language Malware in SMS Bomber Tool

A China-based advanced persistent threat (APT) group is possibly deploying short-lived ransomware families as a decoy to cover up the true operational and tactical objectives behind its campaigns.
The activity cluster, attributed to a hacking group dubbed Bronze Starlight by Secureworks, involves the deployment of post-intrusion ransomware such as LockFile, Atom Silo, Rook, Night Sky, Pandora,

A China-based advanced persistent threat (APT) group is possibly deploying short-lived ransomware families as a decoy to cover up the true operational and tactical objectives behind its campaigns.

The activity cluster, attributed to a hacking group dubbed **Bronze Starlight** by Secureworks, involves the deployment of post-intrusion ransomware such as LockFile, Atom Silo, Rook, Night Sky, Pandora, and LockBit 2.0.

"The ransomware could distract incident responders from identifying the threat actors' true intent and reduce the likelihood of attributing the malicious activity to a government-sponsored Chinese threat group," the researchers said in a new report. "In each case, the ransomware targets a small number of victims over a relatively brief period of time before it ceases operations, apparently permanently."

Bronze Starlight, active since mid-2021, is also tracked by Microsoft under the emerging threat cluster moniker DEV-0401, with the tech giant emphasizing its involvement in all stages of the ransomware attack cycle right from initial access to the payload deployment.

Unlike other RaaS groups that purchase access from initial access brokers (IABs) to enter a network, attacks mounted by the actor are characterized by the use of unpatched vulnerabilities affecting Exchange Server, Zoho ManageEngine ADSelfService Plus, Atlassian Confluence (including the newly disclosed flaw), and Apache Log4j.

Since August 2021, the group is said to have cycled through as many as six different ransomware strains such as LockFile (August), Atom Silo (October), Rook (November), Night Sky (December), Pandora (February 2022), and most recently LockBit 2.0 (April).

What's more, similarities have been uncovered between LockFile and Atom Silo as well as between Rook, Night Sky, and Pandora — the latter three derived from Babuk ransomware, whose source code leaked in September 2021 — indicating the work of a common actor.

"Because DEV-0401 maintains and frequently rebrands their own ransomware payloads, they can appear as different groups in payload-driven reporting and evade detections and actions against them," Microsoft noted last month.

Upon gaining a foothold inside a network, Bronze Starlight is known to rely on techniques like using Cobalt Strike and Windows Management Instrumentation (WMI) for lateral movement, although starting this month, the group has begun replacing Cobalt Strike with the Sliver framework in their attacks.

Other observed tradecraft relates to the use of HUI Loader to launch next-stage encrypted payloads such as PlugX and Cobalt Strike Beacons, the latter of which is employed to deliver the ransomware, but not before obtaining privileged Domain Administrator credentials.

"The use of HUI Loader to load Cobalt Strike Beacon, the Cobalt Strike Beacon configuration information, the C2 infrastructure, and the code overlap suggest that the same threat group is associated with these five ransomware families," the researchers explained.

It's worth pointing out that both HUI Loader and PlugX, alongside ShadowPad, are malware historically put to use by Chinese nation-state adversarial collectives, lending credence to the possibility that Bronze Starlight is more geared towards espionage than immediate monetary benefits.

On top of that, the victimology pattern spanning across the different ransomware strains shows that a majority of the targets are likely to be of more interest to Chinese government-sponsored groups focused on long-term intelligence gathering.

The key victims encompass pharmaceutical companies in Brazil and the U.S., a U.S.-based media organization with offices in China and Hong Kong, electronic component designers and manufacturers in Lithuania and Japan, a law firm in the U.S., and an aerospace and defense division of an Indian conglomerate.

To that end, the ransomware operations, besides providing a means to exfiltrate data as part of the double extortion "name-and-shame" scheme, also offer twin advantages in that it allows the threat actor to destroy forensic evidence of their malicious activities and act as a distraction from data theft.

"It is plausible that Bronze Starlight deploys ransomware as a smokescreen rather than for financial gain, with the underlying motivation of stealing intellectual property or conducting espionage," the researchers said.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

State-Backed Hackers Using Ransomware as a Decoy for Cyber Espionage Attacks

Bronze Starlight’s use of multiple ransomware families and its victim-targeting suggest there’s more to the group’s activities than just financial gain, security vendor says.

A China-based advanced persistent threat (APT) actor, active since early 2021, appears to be using ransomware and double-extortion attacks as camouflage for systematic, government-sponsored cyberespionage and intellectual property theft.

In all of the attacks, the threat actor has used a malware loader called the HUI Loader — associated exclusively with China-backed groups — to load Cobalt Strike Beacon and then deploy ransomware on compromised hosts. Researchers at Secureworks who are tracking the group as “Bronze Starlight” say it’s a tactic they have not observed other threat actors use.

Secureworks also says it has identified organizations in multiple countries that the adversary appears to have compromised. The group’s US-based victims include a pharmaceutical company, a law firm, and a media company with offices in Hong Kong and China. Others include electronic component designers and manufacturers in Japan and Lithuania, a pharmaceutical company in Brazil, and the aerospace and defense division of an Indian conglomerate. Some three-quarters of Bronze Starlight’s victims so far are organizations that have typically been of interest to government-sponsored Chinese cyber-espionage groups.

**Cycling Through Ransomware Families**

Since it began operations in 2021, Bronze Starlight has used at least five different ransomware tools in its attacks: LockFile, AtomSilo, Rook, Night Sky, and Pandora. Secureworks’ analysis shows that the threat actor used a traditional ransomware model with LockFile, where it encrypted data on a victim network and demanded a ransom for the decryption key. But it switched to a double-extortion model with each of the other ransomware families. In these attacks Bronze Starlight attempted to extort victims by both encrypting their sensitive data and threatening to leak it publicly. Secureworks identified data belonging to at least 21 companies posted on leak sites associated with AtomSilo, Rook, Night Sky, and Pandora.

While Bronze Starlight appears on the surface to be financially motivated, its real mission appears to be cyberespionage and intellectual property theft in support of Chinese economic objectives, says Marc Burnard, senior consultant information security research at Secureworks. The US government last year formally accused China of using threat groups such as Bronze Starlight in state-sponsored cyber-espionage campaigns.

“The victimology, tooling, and rapid cycling through ransomware families suggest that Bronze Starlight’s intent may not be financial gain,” he says. Instead, it’s possible that the threat actor is using ransomware and double extortion as a cover to steal data from organizations of interest to China and destroy evidence of its activity.

Bronze Starlight has consistently targeted only a small number of victims over short periods of time with each ransomware family — something that threat groups don’t often do because of the overhead associated with developing and deploying new ransomware tools. In Bronze Starlight’s case, the threat actor appears to have employed the tactic to prevent drawing too much attention from security researchers, Secureworks said.

**The Chinese Connection**

Burnard says the threat actor’s use of the HUI Loader along with a relatively rare version of PlugX, a remote access Trojan linked exclusively to China-backed threat groups, is another sign that there’s more to Bronze Starlight than its ransomware activity might suggest.

“We believe the HUI Loader is a tool unique to Chinese state-sponsored threat groups,” Burnard says. It is not widely used, but where it has been used, the activity has been attributed to other likely Chinese threat group activity, such as one by a group dubbed Bronze Riverside that is focused on stealing IP from Japanese companies. 

“In terms of the use of the HUI Loader to load Cobalt Strike Beacons, this is one key characteristic of the Bronze Starlight activity that connects the broader campaign and five ransomware families together,” Burnard says.

Another sign that Bronze Starlight is more than just a ransomware operation involves a breach that Secureworks investigated earlier this year, where Bronze Starlight broke into a server at an organization that had previously already been compromised by another China-sponsored threat operation called Bronze University. In this incident, though, Bronze Starlight deployed the HUI Loader with Cobalt Strike Beacon on the compromised server, but it did not deploy any ransomware. 

“Again, this raises an interesting question around links between Bronze Starlight and state-sponsored threat groups in China,” Burnard says.

There’s also evidence that Bronze Starlight is learning from its intrusion activity and improving the HUI Loader’s capabilities, he adds. The version of the loader that the group used in its initial intrusions, for instance, were merely designed to load, decrypt, and execute a payload. But an updated version of the tool that Secureworks came across while responding to a January 2022 incident revealed several improvements. 

“The updated version comes with detection evasion techniques, such as disabling Windows Event Tracing for Windows \[ETW\] and Antimalware Scan Interface \[AMSI\] and Windows API hooking,” Burnard notes. “This indicates the HUI Loader is actively being developed and upgraded.”

Secureworks’ investigation shows that Bronze Starlight primarily compromises Internet-facing servers on victim organizations by exploiting known vulnerabilities. So as part of a multilayered approach to network security, network defenders should ensure that Internet-facing servers are patched in a timely manner, Burnard says. 

“While the focus is often on zero-day exploitation, we often see threat groups like Bronze Starlight exploit vulnerabilities that already have a patch available," he says.

Chinese APT Group Likely Using Ransomware Attacks as Cover for IP Theft

The Bosch Ethernet switch PRA-ES8P2S with software version 1.01.05 runs its web server with root privilege. In combination with CVE-2022-23534 this could give an attacker root access to the switch.

CVE-2022-32535: Multiple Vulnerabilities PRA-ES8P2S Ethernet-Switch

Insecure permissions in OneBlog v2.3.4 allows low-level administrators to reset the passwords of high-level administrators who hold greater privileges.

**Current description**

OneBlog v2.3.4 is vulnerable to insecure privileges. Low-level administrators can reset the passwords of high-level administrators who exceed their permissions.

**vulnerability recurrence**

First log in to the background using the low-privileged user admin/123456，This is a low-privileged user  

Click the modify password function, enter the old password and the new password, and then use burpsuite to crawl the packet

    POST /passport/updatePwd HTTP/1.1
    Host: localhost:8085
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0
    Accept: */*
    Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 66
    Origin: http://localhost:8085
    Connection: close
    Referer: http://localhost:8085/
    Cookie: session_user="93lkCfVDA258ElC3HuO7gUY4xGkEK1BFLktUlzaQ+c8="; Hm_lvt_1040d081eea13b44d84a4af639640d51=1654896251; pageno_cookie=1; SHIRO_SESSION_ID=47e409dd-e488-4e2f-8a68-42ae7cd2de9c; 
    
    id=2&password=123456&newPassword=1234567&newPasswordRepeat=1234567
    

Modify the id parameter to the id of another user, Because there is no verification here that the user id is consistent with the current user.

If the passwords of other users with the same permissions are the same as the password fields passed in, you can change the passwords of users with the same permissions horizontally. If the password of the highly privileged user is the same as the password field passed in, you can change the password of the high privileged account vertically. This feature does not verify that the password field is consistent with the password of the currently logged-in user, so password can be entered at will

Change id to 1. The user with an ID of 1 is the root user with the highest authority, because the password of the root user is the same as the 123456 passed in by password, so it is prompted that the modification was successful, and then you are required to log in again.

Log in to the root account again and find that the original password is no longer available.

Log in successfully with the new password

You can also break the brute force to crack the password field and traverse the id field to try to change other users' passwords in batches.

You can see that the passwords of users with id 5 and 6 have been modified successfully.

**Vulnerability analysis**

com.zyd.blog.controller.PassportController

Reset the password in the updatePwd method of the / updatePwd path

Follow the com.zyd.blog.business.service.impl#updatePwd ：

First, obtain the User object according to the user id passed by the front-end user. If the User is not null, determine whether the password field passed by the user is consistent with the user password corresponding to the id, and if so, reset the password.

So in fact, neither verifying whether the user id is the currently logged in user, nor verifying that the original password is the password of the current user, which eventually leads to ultra vires vulnerability.

CVE-2022-34012: There is a Insecure Permissions vulnerability exists in OneBlog v2.3.4 · Issue #I5CB2O · yadong.zhang/OneBlog - Gitee.com

Redis v7.0 was discovered to contain a memory leak via the component streamGetEdgeID.

**Conversation**

 

add a comment to \`container\` in \`quicklist.h\`.
Because \`PLAIN\` and \`PACKED\` are not as easy to understand as \`NONE\`
and \`LISTPACK\` and we don't have a detailed comment on it.

Co-authored-by: Oran Agra <oran@redislabs.com>

\`the redis object pointer was populated.\` -> \`the sds pointer was populated.\`
We don't populate the redis object pointer in this function.

Till now, on MacOS we only used to enable SO\_KEEPALIVE,
but we didn't set the interval which is configurable via the \`tcp-keepalive\` config.
This adds support for that on MacOS, to match what we already do on Linux.

update macros ZIPLIST\_ENTRY\_END i think the right definition is ((zl)+intrev32ifbe(ZIPLIST\_BYTES(zl))-ZIPLIST\_END\_SIZE)

 

…#10663)

When user uses the same input key for SDIFF as the first one, the result must be empty, so we don't need to process the elements to test.

This method is like the one done in zset‘s \`zsetChooseDiffAlgorithm\`

Co-authored-by: Oran Agra <oran@redislabs.com>

In general, our error handler make sure the error
object is always a table. In some rare cases (such
as OOM error), the error handler will not be called
and the error object will be a string. The PR expose
the error even if its a string and not a table.

Currently there is no way to test it but if it'll ever happen,
it is better to propagate this string upwards than just
generate a generic error without any specific info.

 

\* Module API doc script: Mark unreleased API functions

\* fix broken quotes in generate-module-api-doc.rb

Co-authored-by: Oran Agra <oran@redislabs.com>

)

this seems to have been an oversight. syncing the flags so that NOTIFY\_NEW is available to modules.
missing in redis#10512

 

also fixing already defined constants build warning while at it.

Co-authored-by: Oran Agra <oran@redislabs.com>

Fixed RM\_Scan() usage example: \`RedisModuleCursor\` -> \`RedisModuleScanCursor\`

…edis#10661)

If we want to support bits that can be overlapping, we need to make sure
that:
1. we don't use the same bit for two return values.
2. values should be sorted so that prefer ones (matching more
   bits) come first.

Unintentional change in redis#9644 (since RC1) meant that an empty \`--save ""\` config
from command line, wouldn't have clear any setting from the config file

Added tests to cover that, and improved test infra to take additional
command line args for redis-server

fix some typo in "t\_zset.c".
1. \`zzlisinlexrange\` the function name mentioned in the comment is misspelled.
2. fix typo in function name\`zarndmemberReplyWithListpack\` -> \`zrandmemberReplyWithListpack\`

Changed cursor's type from \`int\` to \`unsigned long\`
allows handling database or key with more than 2^31 elements

Set \`old\_li\` to NULL to avoid linking it again on error.
Before the fix, loading an already existing library will cause the existing library to be added again. This cause not harm other then wrong statistics. The statistics that are effected  by the issue are:
\* \`libraries\_count\` and \`functions\_count\` returned by \`function stats\` command
\* \`used\_memory\_functions\` returned on \`info memory\` command
\* \`functions.caches\` returned on \`memory stats\` command

…0683)

It used to returns slots as strings, like:
\`\`\`
redis> cluster shards
1) 1) "slots"
   2) 1) "10923"
      2) "16383"
\`\`\`

CLUSTER SHARDS docs and the top comment of redis#10293 says that it returns integers.
Note other commands like CLUSTER SLOTS, it returns slots as integers.
Use addReplyLongLong instead of addReplyBulkLongLong, now it returns slots as integers:
\`\`\`
redis> cluster shards
1) 1) "slots"
   2) 1) (integer) 10923
      2) (integer) 16383
\`\`\`

This is a small breaking change, introduced in 7.0.0 (7.0 RC3, redis#10293)

Fixes redis#10680

I suggest to use "\[fpclassify\](https://en.cppreference.com/w/cpp/numeric/math/fpclassify)" for float
comparison with zero, because of expression "value == 0" with value very close to zero can be
considered as true with some performance compiler optimizations.

Note: this code was introduced by 9d520a7 to accept zset scores that get ERANGE in conversion
due to precision loss near 0.
But with Intel compilers, ICC and ICX, where optimizations for 0 check are more aggressive, "==0" is
true for mentioned functions, however should not be. Behavior is seen starting from O2.
This leads to a failure in the ZSCAN test in scan.tcl

Fix redis#10552

We no longer piggyback getkeys\_proc to hold the RedisModuleCommand struct, when exists

Others:
Use \`doesCommandHaveKeys\` in \`RM\_GetCommandKeysWithFlags\` and \`getKeysSubcommandImpl\`.
It causes a very minor behavioral change in commands that don't have actual keys, but have a spec
with \`CMD\_KEY\_NOT\_KEY\`.
For example, before this command \`COMMAND GETKEYS SPUBLISH\` would return
\`Invalid arguments specified for command\` but not it returns \`The command has no key arguments\`

…t dirty counter to 0 if we enable save (redis#10691)

## FLUSHALL
We used to restore the dirty counter after \`rdbSave\` zeroed it if we enable save.
Otherwise FLUSHALL will not be replicated nor put into the AOF.

And then we do increment it again below.
Without that extra dirty++, when db was already empty, FLUSHALL
will not be replicated nor put into the AOF.

We now gonna replace all that dirty counter magic with a call
to forceCommandPropagation (REPL and AOF), instead of all the
messing around with the dirty counter.
Added tests to cover three part (dirty counter, REPL, AOF).

One benefit other than cleaner code is that the \`rdb\_changes\_since\_last\_save\` is correct in this case.

## FLUSHDB
FLUSHDB was not replicated nor put into the AOF when db was already empty.
Unlike DEL on a non-existing key, FLUSHDB always does something, and that's to call the module hook. 
So basically FLUSHDB is never a NOP, and thus it should always be propagated.
Not doing that, could mean that if a module does something in that hook, and wants to
avoid issues of that hook being missing on the replica if the db is empty, it'll need to do complicated things.

So now FLUSHDB add call forceCommandPropagation, we will always propagate FLUSHDB.
Always propagating FLUSHDB seems like a safe approach that shouldn't have any drawbacks (other than looking odd)

This was mentioned in redis#8972

## Test section:
We actually found it while solving a race condition in the BGSAVE test (other.tcl).
It was found in extra\_ci Daily Arm64 (test-libc-malloc).
\`\`\`
\[exception\]: Executing test client: ERR Background save already in progress.
ERR Background save already in progress
\`\`\`

It look like \`r flushdb\` trigger (schedule) a bgsave right after \`waitForBgsave r\` and before \`r save\`.
Changing flushdb to flushall, FLUSHALL will do a foreground save and then set the dirty counter to 0.

… spaces for MULTI\_ARG configs parsing. And allow options value to use the -- prefix (redis#10660)

## Take one bulk string with spaces for MULTI\_ARG configs parsing
Currently redis-server looks for arguments that start with \`--\`,
and anything in between them is considered arguments for the config.
like: \`src/redis-server --shutdown-on-sigint nosave force now --port 6380\`

MULTI\_ARG configs behave differently for CONFIG command, vs the command
line argument for redis-server.
i.e. CONFIG command takes one bulk string with spaces in it, while the
command line takes an argv array with multiple values.

In this PR, in config.c, if \`argc > 1\` we can take them as is,
and if the config is a \`MULTI\_ARG\` and \`argc == 1\`, we will split it by spaces.

So both of these will be the same:
\`\`\`
redis-server --shutdown-on-sigint nosave force now --shutdown-on-sigterm nosave force
redis-server --shutdown-on-sigint nosave "force now" --shutdown-on-sigterm nosave force
redis-server --shutdown-on-sigint nosave "force now" --shutdown-on-sigterm "nosave force"
\`\`\`

## Allow options value to use the \`--\` prefix
Currently it decides to switch to the next config, as soon as it sees \`--\`, 
even if there was not a single value provided yet to the last config,
this makes it impossible to define a config value that has \`--\` prefix in it.

For instance, if we want to set the logfile to \`--my--log--file\`,
like \`redis-server --logfile --my--log--file --loglevel verbose\`,
current code will handle that incorrectly.

In this PR, now we allow a config value that has \`--\` prefix in it.
\*\*But note that\*\* something like \`redis-server --some-config --config-value1 --config-value2 --loglevel debug\`
would not work, because if you want to pass a value to a config starting with \`--\`, it can only be a single value.
like: \`redis-server --some-config "--config-value1 --config-value2" --loglevel debug\`

An example (using \`--\` prefix config value):
\`\`\`
redis-server --logfile --my--log--file --loglevel verbose
redis-cli config get logfile loglevel
1) "loglevel"
2) "verbose"
3) "logfile"
4) "--my--log--file"
\`\`\`

### Potentially breaking change
\`redis-server --save --loglevel verbose\` used to work the same as \`redis-server --save "" --loglevel verbose\`
now, it'll error!

Before this commit, all source files including those that are not going
to be compiled were used. Some of these files are platform specific and
won't even pre-process on another platform. With GCC/Clang, that's not
an issue and they'll simply ignore them, but ICC aborts in this case.

This commit only attempts to generate Makefile.dep from the actual set
of C source files that will be compiled.

…G flag for volatile configurations. (redis#10713)

This fixes a possible regression in Redis 7.0.0, in which doing CONFIG SET
on a TLS config would not reload the configuration in case the new config is
the same file as before.

A volatile configuration is a configuration value which is a reference to the
configuration data and not the configuration data itself. In such a case Redis
doesn't know if the config data changed under the hood and can't assume a
change happens only when the config value changes. Therefore it needs to
be applied even when setting a config value to the same value as it was before.

The purpose of the test is to kill the child while it is running.
From the last two lines we can see the child exits before being killed.
\`\`\`
- Module fork started pid: 56998
\* <fork> fork child started
- Killing running module fork child: 56998
\* <fork> fork child exiting
signal-handler (1652267501) Received SIGUSR1 in child, exiting now.
\`\`\`

In this commit, we pass an argument to \`fork.create\` indicating how
long it should sleep. For the fork kill test, we use a longer time to
avoid the child exiting before being killed.

Other changes:
use wait\_for\_condition instead of hardcoded \`after 250\`.
Unify the test for failing fork with the one for killing it (save time)

…10645)

Updated the comments for:
info command
lmpopCommand and blmpopCommand
sinterGenericCommand 

Fix the missing "key" words in the srandmemberCommand function
For LPOS command, when rank is 0, prompt user that rank could be
positive number or negative number, and add a test for it

Alias was mistakenly forgotten when the sub commands introduced as json files.

since the sharded pubsub is different with pubsub, it's better to give users a hint to make it more clear.

This allows the module to know the usable size of an allocation
it made, rather than the consumed size.

…truct (redis#10697)

Move the client flags to a more cache friendly position within the client struct
we regain the lost 2% of CPU cycles since v6.2 ( from 630532.57 to 647449.80 ops/sec ).
These are due to higher rate of calls to getClientType due to changes in redis#9166 and redis#10020

…M check bug, and new RM\_Call checks. (redis#10786)

\* Fix broken protocol when redis can't persist to RDB (general commands, not
  modules), excessive newline. regression of redis#10372 (7.0 RC3)
\* Fix broken protocol when Redis can't persist to AOF (modules and
  scripts), missing newline.
\* Fix bug in OOM check of EVAL scripts called from RM\_Call.
  set the cached OOM state for scripts before executing module commands too,
  so that it can serve scripts that are executed by modules.
  i.e. in the past EVAL executed by RM\_Call could have either falsely
  fail or falsely succeeded because of a wrong cached OOM state flag.
\* Fix bugs with RM\_Yield:
  1. SHUTDOWN should only accept the NOSAVE mode
  2. Avoid eviction during yield command processing.
  3. Avoid processing master client commands while yielding from another client
\* Add new two more checks to RM\_Call script mode.
  1. READONLY You can't write against a read only replica
  2. MASTERDOWN Link with MASTER is down and \`replica-serve-stale-data\` is set to \`no\`
\* Add new RM\_Call flag to let redis automatically refuse \`deny-oom\` commands
  while over the memory limit. 
\* Add tests to cover various errors from Scripts, Modules, Modules
  calling scripts, and Modules calling commands in script mode.

Add tests:
\* Looks like the MISCONF error was completely uncovered by the tests,
  add tests for it, including from scripts, and modules
\* Add tests for NOREPLICAS from scripts
\* Add tests for the various errors in module RM\_Call, including RM\_Call that
  calls EVAL, and RM\_call in "eval mode". that includes:
  NOREPLICAS, READONLY, MASTERDOWN, MISCONF

The important part is that read-only scripts (not just EVAL\_RO
and FCALL\_RO, but also ones with \`no-writes\` executed by normal EVAL or
FCALL), will now be permitted to run during CLIENT PAUSE WRITE (unlike
before where only the \_RO commands would be processed).

Other than that, some errors like OOM, READONLY, MASTERDOWN are now
handled by processCommand, rather than the command itself affects the
error string (and even error code in some cases), and command stats.

Besides that, now the \`may-replicate\` commands, PFCOUNT and PUBLISH, will
be considered \`write\` commands in scripts and will be blocked in all
read-only scripts just like other write commands.
They'll also be blocked in EVAL\_RO (i.e. even for scripts without the
\`no-writes\` shebang flag.

This commit also hides the \`may\_replicate\` flag from the COMMAND command
output. this is a \*\*breaking change\*\*.

background about may\_replicate:
We don't want to expose a no-may-replicate flag or alike to scripts, since we
consider the may-replicate thing an internal concern of redis, that we may
some day get rid of.
In fact, the may-replicate flag was initially introduced to flag EVAL: since
we didn't know what it's gonna do ahead of execution, before function-flags
existed). PUBLISH and PFCOUNT, both of which because they have side effects
which may some day be fixed differently.

code changes:
The changes in eval.c are mostly code re-ordering:
- evalCalcFunctionName is extracted out of evalGenericCommand
- evalExtractShebangFlags is extracted luaCreateFunction
- evalGetCommandFlags is new code

Apparently, GCC 11.2.0 has a new fancy warning for misleading indentations.
It prints a warning when BRET(b) is on the same line as the loop.

 

…, and inserting comments around module and acl configs (redis#10761)

A regression from redis#10285 (redis 7.0).
CONFIG REWRITE would put lines with: \`include\`, \`rename-command\`,
\`user\`,  \`loadmodule\`, and any module specific config in a comment.

For ACL \`user\`, \`loadmodule\` and module specific configs would be
re-inserted at the end (instead of updating existing lines), so the only
implication is a messy config file full of comments.

But for \`rename-command\` and \`include\`, the implication would be that
they're now missing, so a server restart would lose them.

Co-authored-by: Oran Agra <oran@redislabs.com>

Skip the print on AOF\_NOT\_EXIST status.

 

Redis 7 adds some new alias config like \`hash-max-listpack-entries\` alias \`hash-max-ziplist-entries\`.

If a config file contains both real name and alias like this:
\`\`\`
hash-max-listpack-entries 20
hash-max-ziplist-entries 20
\`\`\`

after set \`hash-max-listpack-entries\` to 100 and \`config rewrite\`, the config file becomes to:
\`\`\`
hash-max-listpack-entries 100
hash-max-ziplist-entries 20
\`\`\`

we can see that the alias config is not modified, and users will get wrong config after restart.

6.0 and 6.2 doesn't have this bug, since they only have the \`slave\` word alias.

Co-authored-by: Oran Agra <oran@redislabs.com>

\* Update time independent string compare to use hash length

On line 4068, redis has a logical nodeIsSlave(myself) on the outer if layer,
which you can delete without having to repeat the decision

…and instantaneous\_output\_repl\_kbps. (redis#10810)

A supplement to redis#10062
Split \`instantaneous\_repl\_total\_kbps\` to \`instantaneous\_input\_repl\_kbps\` and \`instantaneous\_output\_repl\_kbps\`. 
## Work:
This PR:
- delete 1 info field:
    - \`instantaneous\_repl\_total\_kbps\`
- add 2 info fields:
    - \`instantaneous\_input\_repl\_kbps / instantaneous\_output\_repl\_kbps\`
## Result:
- master
\`\`\`
total\_net\_input\_bytes:26633673
total\_net\_output\_bytes:21716596
total\_net\_repl\_input\_bytes:0
total\_net\_repl\_output\_bytes:18433052
instantaneous\_input\_kbps:0.02
instantaneous\_output\_kbps:0.00
instantaneous\_input\_repl\_kbps:0.00
instantaneous\_output\_repl\_kbps:0.00
\`\`\`
- slave
\`\`\`
total\_net\_input\_bytes:18433212
total\_net\_output\_bytes:94790
total\_net\_repl\_input\_bytes:18433052
total\_net\_repl\_output\_bytes:0
instantaneous\_input\_kbps:0.00
instantaneous\_output\_kbps:0.05
instantaneous\_input\_repl\_kbps:0.00
instantaneous\_output\_repl\_kbps:0.00
\`\`\`

Trying to avoid people opening crash report issues about module crashes and ARM QEMU bugs.

Current documentation only states a single GET token is needed which is not true. Marking the command with multiple\_token.

Currently generate-command.help.rb dose not handle the
multiple\_token flag, handle this flag in this PR.
The format is the same as redis-cli rendering.
\`\`\`diff
- bitfield\_ro key GET encoding offset \[encoding offset ...\]
+ bitfield\_ro key GET encoding offset \[GET encoding offset ...\]
\`\`\`

Re run generate-command-code.py which was forget in redis#10820.
Also change the flag value from string to bool, like "true" to true

Correcting the introduction version of the command \`BITFIELD\_RO\`
Command added by commit: b3e4abf 

Add history info of the \`FULL\` modifier in \`XINFO STREAM\`
Modifier was added by commit: 1e2aee3

(Includes output from \`./utils/generate-command-code.py\`)

Currently, we only increment stat\_rdb\_saves in rdbSaveBackground,
we should also increment it in the SAVE command.

We concluded there's no need to increment when:
1. saving a base file for an AOF
2. when saving an empty rdb file to delete an old one
3. when saving to sockets (not creating a persistence / snapshot file)

The stat counter was introduced in redis#10178

\* fix a wrong comment in startSaving

This change fixes failing \`integration/logging.tcl\` test in Gentoo with
musl libc, where \`ldd\` returns
\`\`\`
libc.so => /lib/ld-musl-x86\_64.so.1 (0x7f9d5f171000)
\`\`\`
unlike Alpine's
\`\`\`
libc.musl-x86\_64.so.1 => /lib/ld-musl-x86\_64.so.1 (0x7f82cfa16000)
\`\`\`
The solution is to extend matching pattern introduced in redis#8532.

 oranagra changed the base branch from unstable to 7.0

Jun 8, 2022

CVE-2022-33105: Release 7.0.1 by oranagra · Pull Request #10829 · redis/redis

The leak site essential to the operation of Conti ransomware has disappeared, but everything may not be as it appears.
The post Conti ransomware group’s pulse stops, but did it fake its own death? appeared first on Malwarebytes Labs.

The dark web leak site used by the notorious Conti ransomware gang has disappeared, along with the chat function it used to negotiate ransoms with victims. For as long as this infrastructure is down the group is unable to operate and a significent threat is removed from the pantheon of ransomware threats.

The Conti leak site is down (June 22, 2022)

Ransomware gangs like Conti use the threat of leaking stolen data on their dark web sites to extort enormous ransoms from their victims, making the sites a vital cog in the ransomware machine.

While the cause of the site’s disappearance isn’t known for sure, and criminal dark web sites are notoriously flaky, there is good reason to suspect that Conti has gone permanently.

However, while anything that stops Conti from terrorising businesses, schools, and hospitals is welcome, the disappearance of its leak site is unlikely to make potential ransomware victims any safer, sadly.

As we explained in our May ransomware review, recent research by Advintel suggests that Conti has spent the last few months executing a bizarre plan to fake its own death. If that is what’s happened, then the gang’s members have simply dispersed to other ransomware “brands” that are either operated by the Conti gang or affiliated to it.

**Conti—as bad as they come**

The gang behind Conti ransomware (called WizardSpider, although rarely referred to by that name) is believed to be based in Russia, and first appeared in 2020. The FBI recently called it “the costliest strain of ransomware ever documented,” and the US Department of State is offering a reward of up to $10 million for “information leading to the identification and/or location of any individual(s) who hold a key leadership position in the Conti ransomware variant transnational organized crime group.”

Conti has been used in a number of high profile attacks, including a devastating assault on Ireland’s Health Service executive on May 14, 2021. The attack disrupted healthcare in Ireland for months and the recovery effort could end up costing the country more than $100 million.

The real cost of the attack was measured in human suffering though. Speaking to Malwarebytes Labs, a doctor in one of the affected hospitals described how a 21st-century healthcare system deprived of it’s computers is brought to its knees. The attack caused enormous unnecessary suffering for both patients and healthcare professionals, and triggered hundreds of thousands of appointments to be cancelled.

The doctor’s brutal assessment of the Conti gang? “I think they lost their humanity.”

**Faking its own death**

According to Advintel, the Conti gang sealed its fate in February when it published a message in support of Russia’s invasion of Ukraine, declaring its “full support of Russian government.” By aligning itself to the Russian state it had made itself the subject of sanctions. Victims were not prepared to run the risk that their ransom payments might be treated as sanctions violations and Conti’s income dried up.

Ransomware gangs often react to trouble by going dark, or with ham-fisted attempts to pretend they’ve retired. These retirements are often quickly followed by the sudden appearance of a brand new ransomware gang that is obviously just the old gang working under a new name.

Advintel’s research suggested that Conti was aware of this pattern and determined to try something different. Instead of disappearing and then popping up a week later under a new name, the group created and operated new brands—Advintel names KaraKurt, BlackByte, and BlackBasta as examples—before retiring the Conti name, to make the transition less obvious. In addition to creating these new brands, it also dispersed parts of its workforce into existing gangs it had a relationship with, such as Hive and ALPHV.

To complete the deception, it maintained a skeleton crew that carried out extremely noisy, headline-grabbing attacks on Cost Rica, and continued to operate the leak site until the last moment.

Malwarebytes Threat Intelligence was able to independently confirm that Conti sent an internal announcement about its retirement to affiliates at the end of May, and that its internal chat servers stopped working around the same time.

The site had been inactive for 28 days before it disappeared, with the last new leak appearing on May 25. As our May ransomware report revealed, despite the noise it generated from its attacks on Costa Rica, Conti’s activity was significantly depressed in May, while the activity of gangs with alleged links to Conti increased, driven largely by the rise of BlackBasta.

Known ransomware attacks in May 2022

Conti ransomware group’s pulse stops, but did it fake its own death?

Farmers are incorporating high-tech solutions like IoT and drones to address new challenges facing agriculture.

The agriculture industry doesn't typically come to mind when thinking about sectors on the cutting edge. Yet it has been forging ahead through each industrial revolution, and today innovative farmers are starting to incorporate high-tech solutions to address the new challenges the industry is facing.

Automation and robotics, livestock technology, artificial intelligence, and precision agriculture are all opportunities to harness the power of future tech to bring farming into the 21st century.

Farmers face similar challenges regardless of the time period, including inflating operating costs and a shortage of laborers. This is compounded by the world population continuing to rise, increasing the demand on agriculture.

Now, in the Fourth Industrial Revolution, the Internet of Things (IoT) offers an opportunity for the agricultural industry to maximize efficiency while reducing costs, directly addressing the demands and challenges.

**What Is Smart Agriculture?**

Smart agriculture is the use of IoT in agriculture. IoT sensors collect environmental and machine metrics to inform decisions, monitor the state of crops, and optimize efficiency. For example, smart agriculture sensors can track how crops are doing and help farmers use fertilizers and pesticides judiciously.

Overall, the agricultural industry hasn't adopted IoT as quickly as other industries or consumers have, but the market is quite dynamic. The disruptions of the pandemic, including the shortage of workers and supply chain issues, have pushed more farmers to adopt and innovate.

According to reports, the global smart agriculture market size is expected to triple by 2025, reaching $15.3 billion, compared with around $5 billion in 2016.

The market is still developing, but currently IoT can improve agriculture by:

*   Collecting data to track performance and health, such as soil quality, growth progress, cattle health, and weather conditions.
*   Offering control over internal processes and reducing production risks, such as planning for product distribution based on production output.
*   Managing costs and waste with better control over production and risks.
*   Improving business efficiency with automation, such as automated irrigation, fertilization, pest control, and more.
*   Enhancing product volume and quality with better control over the production process, quality, and growth capacity.

**IoT Use Cases in Agriculture**

As the industry adopts more IoT devices, the use cases will likely increase. But here are the primary use cases for IoT in agriculture.

**Precision agriculture:** Precision agriculture offers information to make accurate, data-driven decisions and make operations more efficient. With IoT sensors, farmers can collect virtually any metric that's important for decision-making, including data on temperature, humidity, soil condition, lighting, CO2 levels, pest infestations, and disease. With this data, farmers can estimate the ideal amount of resources to use — like water, pesticides, or fertilizer — to reduce expenses and raise healthier crops and livestock.

**Climate monitoring**:**** Climate monitoring devices, such as weather stations with sensors, can be used to collect data about the environment. Farmers can then map climate controls and optimize crop capacity. These devices are often located in remote areas of the land , providing more accurate measurements in the growth environment and saving travel time.

**Crop management:** Part of the precision agriculture sector, crop management devices operate similarly to weather stations. They can be set up in the field to collect data related to crops, such as precipitation, crop health, and temperature. This allows farmers to monitor crop conditions and growth, as well as to spot any diseases or infestation that can negatively impact the crop yield.

**Cattle monitoring and management:** Similar to crop monitoring, IoT for cattle acts like medical wearables for livestock to monitor their performance and health. These devices can also be used for tracking to determine the location of the herd or an individual animal.

For example, sensors can alert farmers to potentially diseased animals for timely quarantine, sparing the rest of the herd. Drones can also be used for real-time livestock tracking.

**Agriculture drones:** Agricultural drones offer more precise data than planes or satellites. They can replace human labor in a variety of areas, including tracking livestock, combating pests, spraying, crop monitoring, and planting crops.

**Predictive analytics:** Predictive analytics is a component of precision agriculture. Real-time data offers many advantages for farmers, but the analytics aspect helps them use the information for better forecasting and optimization.

Overall, farming is at the whim of weather conditions, and data analytics can help farmers predict and manage the unexpected. For example, predicting upcoming precipitation can help farmers adjust irrigation to avoid over- or underwatering and optimize the use of fertilizers.

**Greenhouse automation:** Greenhouses are typically managed manually, but IoT sensors offer accurate, real-time information on changing greenhouse conditions, like soil quality, humidity levels, temperature, and lighting. Along with gathering data, these sensors allow controls to adjust the conditions to match the ideal parameters.

**End-to-end management:** This is the most complex part of agricultural IoT and includes a variety of IoT devices and sensors with analytical capabilities. Together, these devices offer remote farm monitoring and the capability to streamline operations.

**The Challenges of Smart Farming**

IoT for agriculture has virtually limitless applications, but it's not without its limitations.

**Hardware and sensor quality for accuracy.** The type of information you intend to collect should determine the hardware and sensors for your device, as well as the quality of the data you can collect.

**Data analytics and predictive algorithms.** Data analytics is an important component of smart agriculture, so it's vital to choose an option with robust capabilities.

**Ongoing maintenance.** One of the benefits of smart agriculture is that devices can be in remote or distant environments, but that also comes with challenges related to maintenance.

**Mobility for field use.** Similar to maintenance, smart devices should be designed for field use and enabled for remote access on a computer or smartphone.

**Connectivity.** Like all other smart technology, smart agriculture relies on communication. The connection must be able to travel over distances and be reliable enough for inclement weather.

**Security.** Smart farming involves large data sets, creating potential security vulnerabilities. Data security in IoT is an ongoing challenge, particularly in agriculture, so it's crucial to have AI-based security tools, data traffic monitoring, encryption, and remote access control.

IoT is seeing more and more adoption, but it's new in the farming industry. As farmers face greater obstacles, however, it's likely that IoT adoption will increase along with them. Young farmers are bringing about the Fourth Industrial Revolution in agriculture with future technologies that harness the power of data, automate processes, and optimize operations.

Reinventing How Farming Equipment Is Remotely Controlled and Tracked

Latest Prisma Cloud platform updates help organizations continuously monitor and secure web applications with maximum flexibility.

SANTA CLARA, Calif., June 23, 2022 /PRNewswire/ -- Over the last two years, organizations have expanded their use of cloud environments by more than 25%. Many are now struggling to manage the technical complexity of cloud migration, including the ability to secure their applications across the entire application development lifecycle. Palo Alto Networks (NASDAQ: PANW), a leader in The Forrester Wave™: Cloud Workload Security, Q1 2022, today announced the addition of Out-of-Band Web Application and API Security (Out-of-Band WAAS) to Prisma® Cloud to help organizations secure web applications with maximum flexibility.

Until now, a primary industry approach to securing web applications has been to deploy inline web application firewalls (WAFs). Some organizations are reluctant to introduce WAFs or API security solutions inline, however, due to performance and scalability concerns. With today's announcement, Prisma Cloud can provide organizations with deep web and API security both inline and out of band, allowing them to choose how to protect their applications in the cloud.

"Companies no longer have to decide between application security and performance. By adding Out-of-Band WAAS to Prisma Cloud, we are empowering customers with flexible security options that fit their evolving application needs," said Ankur Shah, senior vice president, Prisma Cloud, Palo Alto Networks. "As more organizations move workloads to the cloud, the capabilities that make up Prisma Cloud help provide the most complete protection, reducing complexity and increasing visibility across infrastructure, workloads, identities and applications."

"As organizations increasingly build and deploy their applications in the cloud, protecting their business-critical applications without impacting performance has been a challenge," said Melinda Marks, senior analyst, ESG. "Adding the option of Out-of-Band WAAS helps both developer and security teams secure their applications with the same level of security as traditional in-line WAFs and API security without impacting performance."

In addition to Out-of-Band WAAS, Prisma Cloud is getting new threat detection, alert prioritization and permissions management capabilities to help provide organizations with deeper, unified visibility across their entire cloud application portfolio:

*   **Multicloud Graph View for Cloud Infrastructure Entitlement Management (CIEM):** Discover over-privileged accounts and understand access risk across multicloud environments. Prisma Cloud now provides a graph view of the net effective permissions across AWS, Microsoft Azure and Google Cloud.
*   **Multicloud Agentless Cloud Workload Protection:** Extend visibility into cloud workloads and application risks across Azure and Google Cloud, in addition to AWS, to complement existing agent-based protection.
*   **DNS-Based Threat Detection:** Surface malicious activity and anomalous behavior in cloud environments. Prisma Cloud Threat Detection now leverages machine learning (ML) and advanced threat intelligence to identify bad actors hiding in DNS traffic.
*   **MITRE ATT&CK**® **Alert Prioritization:** Enable security teams to prioritize risks and incidents based on the industry's most widely adopted framework.

**Availability**

Out-of-band WAAS is available today for Prisma Cloud Compute Edition and will be available in the Enterprise Edition over the next month. The additional features will also roll out for Prisma Cloud Enterprise Edition over the next month.

**About Palo Alto Networks**

Palo Alto Networks is the world's cybersecurity leader. We innovate to outpace cyberthreats, so organizations can embrace technology with confidence. We provide next-gen cybersecurity to thousands of customers globally, across all sectors. Our best-in-class cybersecurity platforms and services are backed by industry-leading threat intelligence and strengthened by state-of-the-art automation. Whether deploying our products to enable the Zero Trust Enterprise, responding to a security incident, or partnering to deliver better security outcomes through a world-class partner ecosystem, we're committed to helping ensure each day is safer than the one before. It's what makes us the cybersecurity partner of choice.

At Palo Alto Networks, we're committed to bringing together the very best people in service of our mission, so we're also proud to be the cybersecurity workplace of choice, recognized among Newsweek's Most Loved Workplaces (2021), Comparably Best Companies for Diversity (2021), and HRC Best Places for LGBTQ Equality (2022). For more information, visit www.paloaltonetworks.com.

_Palo Alto Networks, Prisma, and the Palo Alto Networks logo are registered trademarks of Palo Alto Networks, Inc. in the United States and in jurisdictions throughout the world. All other trademarks, trade names, or service marks used or mentioned herein belong to their respective owners. Any unreleased services or features (and any services or features not generally available to customers) referenced in this or other press releases or public statements are not currently available (or are not yet generally available to customers) and may not be delivered when expected or at all. Customers who purchase Palo Alto Networks applications should make their purchase decisions based on services and features currently generally available._

SOURCE Palo Alto Networks, Inc.

Tag

#intel