Cross-site scripting vulnerability exists in WP Statistics versions prior to 13.2.0 because it improperly processes a platform parameter. By exploiting this vulnerability, an arbitrary script may be executed on the web browser of the user who is logging in to the website using the product.

CVE-2022-27231: WP Statistics

Lighttpd 1.4.56 through 1.4.58 allows a remote attacker to cause a denial of service (CPU consumption from stuck connections) because connection_read_header_more in connections.c has a typo that disrupts use of multiple read operations on large headers.

Hello folks,

I've run into an odd issue with some of the simple web servers we run (they serve some text in index.html). Specifically, it seems like there are connections that get stuck in close\_wait and eat up 100% of CPU resources.  
To note, these are 1 core VMs we run this on.

This issue started when we updated from lighttpd 1.4.55-2 to 1.4.57-1. I am going to provide full context on what was done in case it helps. Initially after this upgrade, I noticed that the service stopped starting up and saw these warnings:  
2021-01-13 20:21:21: (configfile.c.2269) server.upload-dirs doesn't exist: /var/cache/lighttpd/uploads  
2021-01-13 20:21:21: (plugin.c.195) dlopen() failed for: /usr/lib/lighttpd/mod\_openssl.so /usr/lib/lighttpd/mod\_openssl.so: cannot open shared object file: No such file or directory  
2021-01-13 20:21:21: (server.c.1238) loading plugins finally failed

and:  
2021-01-13 20:21:21: (configfile.c.253) Warning: please add "mod\_openssl" to server.modules list in lighttpd.conf. A future release of lighttpd 1.4.x **will not** automatically load mod\_openssl and lighttpd **will not** use SSL/TLS where your lighttpd.conf contains ssl.\* directives

So I went in and edited /etc/lighttpd/lighttpd.conf and added mod\_openssl and installed the lighttpd-mod-openssl package. That resolved the issue with the service not running.

After this point, the servers ran normally for a while, then we got an alert about CPU usage. Taking a look it seemed like lighttpd was constantly consuming the entire core. Luckily enough, it still seemed to be accepting connections normally (as far we we could tell from access.log and errors.log didn't show anything out of the ordinary).

At this point, looking at lsof, it showed the following (with some stuff deleted of course):  
  
mitd:~$ sudo lsof -p 157648  
COMMAND     PID     USER   FD      TYPE             DEVICE  SIZE/OFF    NODE NAME  
lighttpd 157648 www-data  cwd       DIR              254,1      4096       2 /  
lighttpd 157648 www-data  rtd       DIR              254,1      4096       2 /  
lighttpd 157648 www-data  txt       REG              254,1    375136 1966696 /usr/sbin/lighttpd  
lighttpd 157648 www-data  mem       REG              254,1     23160 1967130 /usr/lib/x86_64-linux-gnu/libnss_cache.so.2.0  
lighttpd 157648 www-data  mem       REG              254,1     51696 1968527 /usr/lib/x86_64-linux-gnu/libnss_files-2.31.so  
lighttpd 157648 www-data  mem       REG              254,1     14408 1844237 /usr/lib/lighttpd/mod_staticfile.so  
lighttpd 157648 www-data  mem       REG              254,1     30792 1841268 /usr/lib/lighttpd/mod_dirlisting.so  
lighttpd 157648 www-data  mem       REG              254,1   3076960 1967430 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1  
lighttpd 157648 www-data  mem       REG              254,1    593696 1967535 /usr/lib/x86_64-linux-gnu/libssl.so.1.1  
lighttpd 157648 www-data  mem       REG              254,1     22600 1835392 /usr/lib/lighttpd/mod_accesslog.so  
lighttpd 157648 www-data  mem       REG              254,1     55520 1839916 /usr/lib/lighttpd/mod_openssl.so  
lighttpd 157648 www-data  mem       REG              254,1     14408 1843016 /usr/lib/lighttpd/mod_redirect.so  
lighttpd 157648 www-data  mem       REG              254,1     14408 1835607 /usr/lib/lighttpd/mod_alias.so  
lighttpd 157648 www-data  mem       REG              254,1    149608 1968567 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so  
lighttpd 157648 www-data  mem       REG              254,1   1839792 1967267 /usr/lib/x86_64-linux-gnu/libc-2.31.so  
lighttpd 157648 www-data  mem       REG              254,1     43048 1966278 /usr/lib/x86_64-linux-gnu/libxxhash.so.0.8.0  
lighttpd 157648 www-data  mem       REG              254,1    257528 1966472 /usr/lib/x86_64-linux-gnu/libnettle.so.8.0  
lighttpd 157648 www-data  mem       REG              254,1     18688 1968044 /usr/lib/x86_64-linux-gnu/libdl-2.31.so  
lighttpd 157648 www-data  mem       REG              254,1    464848 1967316 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3  
lighttpd 157648 www-data  mem       REG              254,1     14408 1835248 /usr/lib/lighttpd/mod_access.so  
lighttpd 157648 www-data  mem       REG              254,1     14408 1842895 /usr/lib/lighttpd/mod_indexfile.so  
lighttpd 157648 www-data  mem       REG              254,1    177928 1966929 /usr/lib/x86_64-linux-gnu/ld-2.31.so  
lighttpd 157648 www-data    0u      CHR                1,3       0t0    7949 /dev/null  
lighttpd 157648 www-data    1u      CHR                1,3       0t0    7949 /dev/null  
lighttpd 157648 www-data    2u     unix 0xffff98ddb1b31800       0t0 1393254 type=STREAM  
lighttpd 157648 www-data    3w      REG               0,23         7 1393271 /run/lighttpd.pid  
lighttpd 157648 www-data    4u     IPv4            1393272       0t0     TCP *:http (LISTEN)  
lighttpd 157648 www-data    5u     IPv6            1393273       0t0     TCP *:http (LISTEN)  
lighttpd 157648 www-data    6u     IPv4            1393274       0t0     TCP *:https (LISTEN)  
lighttpd 157648 www-data    7u     IPv6            1393275       0t0     TCP *:https (LISTEN)  
lighttpd 157648 www-data    8w      REG              254,1   3423240 3670309 /var/log/lighttpd/error.log  
lighttpd 157648 www-data    9w      REG              254,1 117697465 3670308 /var/log/lighttpd/access.log  
lighttpd 157648 www-data   10u  a_inode               0,13         0    7868 [eventpoll]  
lighttpd 157648 www-data   11u     IPv4            1586902       0t0     TCP #####:https->#####.com:52059 (ESTABLISHED)  
lighttpd 157648 www-data   12u     IPv4            1435873       0t0     TCP ME.com:https->#####.com:41960 (CLOSE_WAIT)  
lighttpd 157648 www-data   13u     IPv4            1586953       0t0     TCP .com:https->:59153 (ESTABLISHED)  
lighttpd 157648 www-data   19u     IPv4            1415541       0t0     TCP ME.com:http->***********.com:43470 (CLOSE_WAIT)  
lighttpd 157648 www-data   20r      REG              254,1        27 3670597 /var/www/html/index.html  

You can see 12u and 19u are both stuck in close\_wait. They stayed in that state for hours. An strace of the lighttpd process showed the similar messages to the following spammed repeated:

epoll\_ctl(10, EPOLL\_CTL\_MOD, 12, {EPOLLERR|EPOLLHUP, {u32=1349789952, u64=94078313441536}}) = 0  
epoll\_ctl(10, EPOLL\_CTL\_MOD, 12, {EPOLLIN|EPOLLERR|EPOLLHUP|EPOLLRDHUP, {u32=1349789952, u64=94078313441536}}) = 0  
getsockopt(21, SOL\_TCP, TCP\_INFO, "\\10\\0\\0\\0\\0\\4x\\0\\200 \\5\\0@\\234\\0\\0\\264\\5\\0\\0\\264\\5\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\374\\231c\\1\\0\\0\\0\\0\\30\\231c\\1\\234\\257b\\1\\334\\5\\0\\0\\350\\301\\0\\0007\\275\\1\\0\\233\\336\\0\\0\\377\\377\\377\\177\\n\\0\\0\\0\\264\\5\\0\\0\\3\\0\\0\\0\\0\\0\\0\\0\\20r\\0\\0\\0\\0\\0\\0", \[104\]) = 0

At this point using the following I was able to kill the 12u and 19u specifically after which CPU usage returned to normal and strace stopped showing the previous messages:  
gdb -p pid  
call (int)close(12)  
call (int)close(19)  
exit

To mitigate this in the short term, I have setup a cron job to check CPU usage and restart the service if CPU usage is above a percentage.  
Any help to get to the bottom of this bug would be appreciated, let me know what other info you may need.

CVE-2022-30780: Bug #3059: Connections stuck in Close_Wait causing 100% cpu usage - Lighttpd

A vulnerability was found in SICUNET Access Controller 0.32-05z. It has been declared as problematic. This vulnerability affects unknown code of the component Password Storage. The manipulation leads to weak encryption. Attacking locally is a requirement.

Nmap Announce Nmap Dev Full Disclosure Security Lists Internet Issues Open Source Dev

**Full Disclosure mailing list archives****SICUNET Physical Access Controller - Multiple Vulnerabilities**

_From_: Andrew Griffiths <agriffiths+fd () google com>  
_Date_: Wed, 8 Mar 2017 11:17:13 -0800  

SICUNET Physical Access Controller - Multiple Vulnerabilities

-------------------------------------------------------------

Introduction

============

Multiple vulnerabilities were identified in the SICUNET Access Controller
Products. The vulnerabilities were discovered during a black box security
assessment and therefore the vulnerability list should not be considered
exhaustive.

Affected Software and Versions

==============================

Known vulnerable version is 0.32-05z. This version string was taken from
Spider.db.

CVE

===

No CVEs have been assigned.

Vulnerability Overview

======================

0. SN-01: HIGH: Outdated software

1. SN-02: HIGH: PHP include()

2. SN-03: CRITICAL: Unauthenticated remote code execution

3. SN-04: CRITICAL: Hardcoded root credentials

4. SN-05: High: Passwords stored in plaintext

Vulnerability Details

=====================

------------------------

SN-01: Outdated software

------------------------

Severity: High

A variety of software running on the device is outdated, making
exploitation of certain bugs far easier than it would be had they been
patched, or running up to date software.

 /usr/local/php\_b2/bin # ./php -v

 PHP 5.2.14 (cli) (built: Jul  8 2012 22:45:11)

 Copyright (c) 1997-2010 The PHP Group

 Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

http://php.net/eol.php has more information about PHP 5.2 being End Of
Life, and associated security issues.

 /usr/local/lighttpd/sbin # ./arm-linux-lighttpd -v

 lighttpd/1.4.30 (ssl) - a light and fast webserver

 Build-Date: Dec 26 2013 15:13:53

https://www.lighttpd.net/download/ has more information about security
changes in lighttpd.

 # uname -a
 Linux SICUNET 2.6.32.9 #72 PREEMPT Tue Feb 28 15:25:12 KST 2012 armv7l
 GNU/Linux


It is recommended that software is kept up to date, and that configurations
are reviewed to ensure that they’re secure. For example, there may have
been configuration options for PHP which may have made exploitation harder.

--------------------

SN-02: PHP include()

--------------------

Severity: High

When sending a request to /, the 'c' parameter is used as part of an
include() statement.

Excerpt from /spider/web/webroot/index.php:

 $class  = Input::get('c', 'layout');
 $method = Input::get('m', 'index');

 include APP\_DIR.'/controllers/'.$class.EXT;

(where EXT is defined as '.php’).

By crafting the c parameter, it’s possible to access arbitrary files on the
device:

 wget 'http://victim.ip.address/?c=../../../../../etc/passwd%00&apos;

The %00 trick is a known issue, and is addressed in a later PHP update. For
more information, please see SN-01.

It is recommended that the code be refactored to not require passing user
supplied input to the include() function. Alternatively, a strict whitelist
approach of known modules may be used instead.

--------------------------------------------

SN-03: Unauthenticated remote code execution

--------------------------------------------

Severity: Critical

A variety of functionality is implemented via insecure string concatenation
then passed to underlying exec() functions:

For example, in card\_scan\_decoder.php

16     $No = $\_GET\['No'\];
17     $door = $\_GET\['door'\];
18
19     $result = array();
20
21     $db   = new PDO('sqlite:/tmp/SpiderDB/Spider.db');
<snip>

27
28     if ($No < 1)
29     {
30         $DelTemp = $db->prepare("DELETE FROM CardRawData");
31         $DelTemp->execute();
32
33         exec("/spider/sicu/spider-cgi getrawdata ".$door." on");
34     }

This vulnerability can be exploited by:

 wget 'http://victim.ip.address/card\_scan\_decoder.php?No=0&door=$(sleep 3)’

This is just an example of the pattern of insecurely creating strings to be
executed, and not an exhaustive listing.

It is recommended that injection-proof API's are used instead of
error-prone string concatenation, or whitelist / blacklist being used (for
example, escapeshellcmd). However, it appears as if the closest option in
PHP is http://php.net/manual/en/function.pcntl-exec.php which requires the
user to perform a lot more work to avoid shooting themselves in the foot
(such as forking the process first).

---------------------------------

SN-04: Hardcoded root credentials

---------------------------------

Severity: Critical

There are 3 password fingerprints in /etc/passwd

 root:$1$VVtYRWvv$gyIQsOnvSv53KQwzEfZpJ0:0:100:root:/root:/bin/sh
 e3user:$1$vR6H2PUd$52r03jiYrM6m5Bff03yT0/:1000:1000:Linux
User,,,:/home/e3user:/bin/sh
 lighttpd:$1$vqbixaUx$id5O6Pnoi5/fXQzE484CP1:1001:1000:Linux
User,,,:/home/lighttpd:/bin/sh

The plaintext root password can be found in /spider/sicu binaries. The root
password may be used for the ftp or telnet service on the device. From our
observation, it appears as if FTP is running by default, along with the
ability to login as root via FTP.

The hardcoded root credentials are used by binaries on the system to run
commands as root. It is currently unknown what the purpose of the e3user
and lighttpd hardcoded passwords are.

For example, the root password is used in a variety of ways in the
following format:

 echo %s | su -c 'mkdir -p %s >& /tmp/message'
 echo %s | su -c 'chown %s %s >& /tmp/message'

Where %s is replaced at run time with the cleartext root password before
being passed to the system() function.

It is recommended that hardcoded credentials be removed, and instead
replaced with a more suitable mechanism. For example; sudo may be suitable,
combined with the NOPASSWD directive.

FTP access should be replaced with a more secure transfer mechanism (such
as SSH FTP, or SCP), and authentication should be managed by a user
(preferably via SSH public keys).

------------------------------------------

SN-05: Passwords stored in plaintext

------------------------------------------

Severity: High

A variety of credentials (for example, used for accessing the web front
end, or other devices part of the installation) are stored unencrypted on
the device in /tmp/SpiderDB/Spider.db:

sqlite> SELECT Name,Password FROM WebUser;
admin|ExamplePlaintextPassword
sqlite> SELECT Name,ID,Password FROM Controller;
Server|username|AnotherPlaintextPassword

It is recommended that where passwords must be stored, that they are
suitably cryptographically hashed using an appropriate standard (for more
information, please see https://password-hashing.net).

Author

======

The vulnerabilities were discovered by Andrew Griffiths from Google
Security Team.

Timeline

========

2016/12/06 - Contacted sicunet.com domain registrar, and sales () sicunet com
            for a point of contact to report security issues.

2016/12/08 - Pinged earlier email for a point of contact, additionally
            included tech () sicunet com on an email.

2016/12/08 - Report sent to Ike Huh, CEO.

2016/12/12 - Mentioned that reviewing spider-api would be worthwhile as it
            listens on port 7000, and strings suggests that there may be
            command injection / other vulnerabilities. No reply.

2017/01/17 - Asked point of contact if they had any questions about the
            advisory sent earlier. No reply.

2017/01/24 - Pinged vendor again, asked about resellers who may be able to
            make recommendations about restricting network access to the
            devices from the internet.

2017/01/30 - No contact from vendor.

2017/02/24 - Asked vendor if the affected users can expect patches. No
            reply.

2017/03/01 - Sent an email to the vendor, reminding them disclosure is
coming
            up soon.

2017/03/08 - 90 day disclosure deadline.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

**Current thread:**

*   **SICUNET Physical Access Controller - Multiple Vulnerabilities** _Andrew Griffiths (Mar 10)_

CVE-2017-20040: Full Disclosure: SICUNET Physical Access Controller

On the eve of their federal criminal trial for allegedly stealing vast swaths of Internet addresses for use in large-scale email spam campaigns, three current or former executives at online advertising firm Adconion Direct have agreed to plead guilty to lesser misdemeanor charges of fraud and misrepresentation via email.

At the outset of their federal criminal trial for hijacking vast swaths of Internet addresses for use in large-scale email spam campaigns, three current or former executives at online advertising firm **Adconion Direct** (now **Amobee**) have pleaded guilty to lesser misdemeanor charges of fraud and misrepresentation via email.

In October 2018, prosecutors in the Southern District of California named four Adconion employees — **Jacob Bychak**, **Mark Manoogian**, **Petr Pacas**, and **Mohammed Abdul Qayyum** —  in a ten-count indictment (PDF) on felony charges of conspiracy, wire fraud, and electronic mail fraud.

The government alleged that between December 2010 and September 2014, the defendants engaged in a conspiracy to identify or pay to identify blocks of Internet Protocol (IP) addresses that were registered to others but which were otherwise inactive.

Prosecutors said the men also sent forged letters to an Internet hosting firm claiming they had been authorized by the registrants of the inactive IP addresses to use that space for their own purposes.

All four defendants pleaded not guilty when they were charged back in 2018, but this week Bychak, Manoogian and Qayyum each entered a plea deal.

“The defendants’ jobs with Adconion were to acquire fresh IP addresses and employ other measures to circumvent the spam filters,” reads a statement released today by the U.S. Attorney for the Southern District of California, which said the defendants would pay $100,000 in fines each and perform 100 hours of community service.

“To conceal Adconion’s ties to the stolen IP addresses and the spam sent from these IP addresses, the defendants used a host of DBAs, virtual addresses, and fake names provided by the company,” the statement continues. “While defendants touted ties to well-known name brands, the email marketing campaigns associated with the hijacked IP addresses included advertisements such as ‘BigBeautifulWomen,’ ‘iPhone4S Promos,’ and ‘LatinLove\[Cost-per-Click\].'”

None of the three plea agreements are currently available on PACER, the online federal court document clearinghouse. However, PACER does show that on June 7 — the same day the pleas were entered by the defendants —  the government submitted to the court a superseding set of just two misdemeanor charges (PDF) of fraud in connection with email.

Another document filed in the case says the fourth defendant — Pacas — accepted a deferred prosecution deal, which includes a probationary period and a required $50,000 “donation” to a federal “crime victims fund.”

There are fewer than four billion so-called “Internet Protocol version 4” or IPv4 addresses available for use, but the vast majority of them have already been allocated. The global dearth of available IP addresses has turned them into a commodity wherein each IP can fetch between $15-$25 on the open market.

This has led to boom times for those engaged in the acquisition and sale of IP address blocks, but it has likewise emboldened those who specialize in absconding with and spamming from dormant IP address blocks without permission from the rightful owners.

In May, prosecutors published information about the source of some IP address ranges from which the Adconion employees allegedly spammed. For example, the government found the men leased some of their IP address ranges from a Dutch company that’s been tied to a scandal involving more than four million addresses siphoned from the **African Network Information Centre** (AFRINIC), the nonprofit responsible for overseeing IP address allocation for African organizations.

In 2019, AFRINIC fired a top employee after it emerged that in 2013 he quietly commandeered millions of IPs from defunct African entities or from those that were long ago acquired by other firms, and then conspired to sell an estimated $50 million worth of the IPs to marketers based outside Africa.

“Exhibit A” in a recent government court filing shows that in 2013 Adconion leased more than 65,000 IP addresses from **Inspiring Networks**, a Dutch network services company. In 2020, Inspiring Networks and its director **Maikel Uerlings** were named in a dogged, multi-part investigation by South African news outlet **MyBroadband.co.za** and researcher Ron Guilmette as one of two major beneficiaries of the four million IP addresses looted from AFRINIC by its former employee.

Exhibit A, from a May 2022 filing by U.S. federal prosecutors.

The address block in the above image — 196.246.0.0/16 — was reportedly later reclaimed by AFRINIC following an investigation. Inspiring Networks has not responded to requests for comment.

Prosecutors allege the Adconion employees also obtained hijacked IP address blocks from **Daniel Dye**, another man tied to this case who was charged separately. For many years, Dye was a system administrator for **Optinrealbig**, a Colorado company that relentlessly pimped all manner of junk email, from mortgage leads and adult-related services to counterfeit products and Viagra. In 2018, Dye pleaded guilty to violations of the CAN-SPAM Act.

Optinrealbig’s CEO was the spam king Scott Richter, who changed the name of the company to Media Breakaway after being successfully sued for spamming by **AOL,** **Microsoft**, **MySpace**, and the New York Attorney General Office, among others. In 2008, this author penned a column for The Washington Post detailing how Media Breakaway had hijacked tens of thousands of IP addresses from a defunct San Francisco company for use in its spamming operations.

The last-minute plea deals by the Adconion employees were reminiscent of another recent federal criminal prosecution for IP address sleight-of-hand. In November 2021, the CEO of South Carolina technology firm **Micfo** pleaded guilty just two days into his trial, admitting 20 counts of wire fraud in connection with an elaborate network of phony companies set up to obtain more than 700,000 IPs from the **American Registry for Internet Numbers** (ARIN) — AFRINIC’s counterpart in North America.

Adconion was acquired in June 2014 by **Amobee**, a Redwood City, Calif. online ad platform that has catered to some of the world’s biggest brands. Amobee’s parent firm — Singapore-based communications giant Singtel — bought Amobee for $321 million in March 2012.

But as _Reuters_ reported in 2021, Amobee cost Singtel nearly twice as much in the last year alone — $589 million — in a “non-cash impairment charge” Singtel disclosed to investors. Marketing industry blog **Digiday.com** reported in February that Singtel was seeking to part ways with its ad tech subsidiary.

One final note about Amobee: In response to my 2019 story on the criminal charges against the Adconion executives, Amobee issued a statement saying “Amobee has fully cooperated with the government’s investigation of this 2017 matter which pertains to alleged activities that occurred years prior to Amobee’s acquisition of the company.”

Yet as the government’s indictment points out, the alleged hijacking activities took place up until September 2014, which was _after_ Amobee’s acquisition of Adconion Direct in June 2014. Also, the IP address ranges that the Adconion executives were prosecuted for hijacking were all related to incidents in 2013 and 2014, which is hardly “years prior to Amobee’s acquisition of the company.”

Amobee has not yet responded to requests for comment.

Adconion Execs Plead Guilty in Federal Anti-Spam Case

By Owais Sultan
If you own a WordPress website this article is for you because it addresses WordPress security and protection…
This is a post from HackRead.com Read the original post: How To Secure WordPress Website From Cyber Attacks?

****If you own a WordPress website this article is for you because it addresses WordPress security and protection against cyber attacks.****

WordPress is a widely used CMS (content management system), powering a significant proportion of all available websites. Unfortunately, it also attracts cyber criminals who take advantage of the platform’s security flaws.

It does not mean that WordPress’s security mechanism is ineffective. Security issues can also occur due to the absence of security measures from the users’ side such as outdated or malware-infected plugins. Therefore, it is crucial to take security measures before your WordPress website becomes a target of a malicious attack.

Although you can maintain network security while transferring files by understanding the TCP vs UDP comparison and selecting the best one for web security, some valuable yet small details might help you secure your website in the long run.

*   **What Is the Importance of WordPress Website Security?**

A hacked WordPress site can significantly harm your company’s income and credibility. Cybercriminals can access passwords and user information and even exploit the site to spread malware or harvest login credentials and banking card information. Therefore, providing a secure platform for your website’s users/visitors is a must.

Also, keeping a high-end website requires maintaining your WordPress website’s safety. Website security has a direct impact on search engine visibility. And the most straightforward strategy to improve your search ranking is to improve your security. Thus, the importance of WordPress website security cannot be denied whatsoever.

*   **Is WordPress a Safe Platform?**

If this question always pops up in your mind, you are not alone. It is one of the most frequently asked questions. And the answer to this question is “Yes, it is safe.” It is safe for the most part as long as you take all necessary security precautions seriously.

*   **Avoid “Admin” Username**

The disclosure of a username may not appear to be particularly harmful. Still, it might set off a chain reaction of security flaws that can lead to account identity theft, hijacking, or financial harm.

If you have named the site’s administrator as admin, it is recommended to change it because cyber criminals are good at exploiting platforms with default setups. They understand that “admin” is frequently used as an administrator account. They may exploit that username in a “brute force” attack. Avoid the “Admin” username and save your WordPress website from such attacks.

*   **WordPress Must Be Updated Regularly**

WordPress publishes software updates regularly to enhance security and speed. These upgrades also help in keeping your site safe from cyber attacks. The most straightforward approach to improving your WordPress website’s security is to update your WordPress version. 

To see if you own the most recent WordPress version, go to Dashboard, then click on Updates.

Stay updated on the release dates for new upgrades to guarantee that your site isn’t running an old WordPress version. Moreover, try to update the plugins and themes on your WordPress site. Older plugins and themes might cause conflicts with the newly updated WordPress software, resulting in problems and security vulnerabilities.

*   **Limit the Number of Log In Times**

Cybercriminals may try to guess your admin password via a brute force attack or use leaked credentials to log in to the site. You can reduce their chances of winning by limiting the number of times they can try to log in. As a result, if someone continuously enters the incorrect password, they will be blocked for hours, months, or even years depending on what options you select.

Thus, Limit Login Attempts is a plugin that you may use to secure your website. It works by allowing you to set up a significant number of wrong passwords that may be entered before the IP address of the person who entered the wrong password is locked out.

*    **All Hotlinking Should Be Disabled**

Rather than downloading the file, putting it on your server, and providing a correct citation. Hotlinking or Inline linking is a technique of linking to a file stored on another site. It is most commonly used for images, but it may also be used for videos, music files, flash animations, and other digital content.

If you want to keep your WordPress website secure, hotlinking should be disabled. Otherwise, you’ll notice slower loading times, the possibility of more server expenses, and an increased risk of being hacked.

Although there are several manual methods for avoiding hotlinking, the most straightforward solution is to use a WordPress security plugin. The All-in-One WP Security and Firewall plugin, for example, has built-in solutions for preventing all hotlinking.

*   **Use Two-Factor Authentication**

Two-factor authentication, often known as 2FA, dual-factor authentication, or two-step verification, is a security method in which users validate their identity using two independent authentication factors. This is another smart step to include in your security strategies.

The authentication can be a conventional password followed by a security question, a combination of letters, a hidden code, or the Google Authenticator application delivering a secret code to your phone. The person who has your phone may log in to your website. It is used to safeguard a user’s credentials and the information they have access to.

**Conclusion**

Malicious actors are continuously coming up with new ways to use a company’s online presence against them, while cyber security specialists are always coming up with new ways to resist them.

This is the never-ending cycle of cybersecurity, and we’re all trapped in its center. Your WordPress site is just like any other website on the internet when it comes to cyber-attacks. However, by following the above-recommended tips and hacks, you can secure your WordPress website from cyber criminals or at least reduce the risk of being attacked. 

**More WordPress Security News**

1.  7 Tips to Increase Your WordPress Security
2.  5 WordPress Security Solutions with Free SSL Certificates
3.  Critical WordPress plugin vulnerability allowed wiping databases
4.  Flaws in 2 famous WordPress plugins put millions of websites at risk
5.  WordPress security: Steps to assess employee before granting admin access

How To Secure WordPress Website From Cyber Attacks?

Humio for Falcon provides long-term, cost-effective data retention with powerful index-free search and analysis of enriched security telemetry across enterprise environments

**AUSTIN, Texas and RSA Conference 2022, SAN FRANCISCO – June 6, 2022 –** CrowdStrike (Nasdaq: CRWD), a leader in cloud-delivered protection of endpoints, cloud workloads, identity and data, today introduced Humio for Falcon, a new capability that extends data retention of CrowdStrike Falcon telemetry for up to one year or longer, enhancing threat analytics and threat hunting abilities for organizations while helping them meet compliance requirements.

Humio for Falcon brings together an industry-leading security platform in CrowdStrike Falcon, with the powerful search capabilities of CrowdStrike’s centralized logging offering, Humio. The new capability gives security teams the ability to store security and IT telemetry from the Falcon platform, which is enriched and contextualized across endpoints, workloads and identities to address the challenge of operationalizing the ever-growing volumes of data. Humio for Falcon helps security teams analyze and act on all data – both real-time and historical data – in their environment. With longer data retention due to advanced compression of ingested data, security teams can uncover and detect potential threats within their environments with deep, contextual analytics and sub-second search results at any scale through a modern, index-free architecture.

“While the data available to threat hunters and incident responders grows at an exponential rate, they are routinely forced to reduce the duration they can store this information,” said Michael Sentonas, chief technology officer at CrowdStrike. “Humio for Falcon solves this problem by delivering scalable and cost-effective data retention that enables threat hunters and incident responders to look back and see if and when an adversary was active in an IT environment and reconcile every system they touched. It’s truly a game-changer in the industry.”

Humio for Falcon provides:

*   **Threat hunting and troubleshooting at unprecedented scale:** By retaining Falcon data for extended periods of time, security teams can proactively search and uncover hidden threats in the environment with sub second speed, remove advanced persistent threats (APTs) by sifting through the data to detect irregularities that might suggest potential malicious behavior and better prioritize and address vulnerabilities before they can be weaponized.
*   **Longer data retention to help meet compliance requirements and reduced cost:** With scalable storage and advanced compression techniques, customers can store and manage Falcon data for one or multiple years, based on customer requirements. This wealth of real-time and historical data enables completeness and accuracy of investigation and analysis, resulting in faster threat remediation.
*   **New user interface (UI) dashboard visualization for fast and custom search:** Feature-rich query language and index-free searches allows security teams to run queries on Falcon data and get immediate answers. Get the ability to seamlessly ingest, aggregate and search through massive security and IT telemetry and gain valuable, contextual insights with sub-second latency searches for meeting real-world security requirements, including advanced threat and vulnerability investigations.

  
“With Humio for Falcon, we were able to save approximately $150,000 in the first year,” said Tom Sipes, director, IT security and compliance at Tuesday Morning. “Also, the ability to save data for an extended time period is critical. When we detect an indicator of compromise, we can go back in time and analyze the entire attack chain to accelerate investigations and pinpoint issues more quickly.”

**Additional Resources**

*   For more information on Humio for Falcon, please visit our blog.
*   To watch a Humio for Falcon demo, please visit this page.
*   Did you know? Humio can ingest over one petabyte of data per day. Humio was also named “Log Analytics Solution of the Year” by the Data Breakthrough Awards for 2022.

  
**About CrowdStrike**  
CrowdStrike (Nasdaq: CRWD), a global cybersecurity leader, has redefined modern security with one of the world’s most advanced cloud-native platforms for protecting critical areas of enterprise risk – endpoints and cloud workloads, identity and data.

Powered by the CrowdStrike Security Cloud and world-class AI, the CrowdStrike Falcon® platform leverages real-time indicators of attack, threat intelligence, evolving adversary tradecraft and enriched telemetry from across the enterprise to deliver hyper-accurate detections, automated protection and remediation, elite threat hunting and prioritized observability of vulnerabilities.

Purpose-built in the cloud with a single lightweight-agent architecture, the Falcon platform delivers rapid and scalable deployment, superior protection and performance, reduced complexity and immediate time-to-value.

CrowdStrike Introduces Humio for Falcon, Redefining Threat Hunting with Unparalleled Scale and Speed

There is an assertion failure in SingleComponentLSScan::ParseMCU in singlecomponentlsscan.cpp in libjpeg before 1.64 via an empty JPEG-LS scan.

    ─────────────────────────────────────────────────────────────────────────────────────
    pwndbg> bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff7053859 in __GI_abort () at abort.c:79
    #2  0x00007ffff7053729 in __assert_fail_base (fmt=0x7ffff71e9588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555564a4120 <str> "lines > 0", file=0x5555564a4040 <str> "singlecomponentlsscan.cpp", line=100, function=<optimized out>) at assert.c:92
    #3  0x00007ffff7064fd6 in __GI___assert_fail (assertion=0x5555564a4120 <str> "lines > 0", file=0x5555564a4040 <str> "singlecomponentlsscan.cpp", line=100, function=0x5555564a4080 <__PRETTY_FUNCTION__._ZN21SingleComponentLSScan8ParseMCUEv> "virtual bool SingleComponentLSScan::ParseMCU()") at assert.c:101
    #4  0x00005555558189f0 in SingleComponentLSScan::ParseMCU (this=0x624000002120) at singlecomponentlsscan.cpp:100
    #5  0x000055555567a528 in JPEG::ReadInternal (this=<optimized out>, this@entry=0x61b000000098, tags=tags@entry=0x7fffffffd5a0) at jpeg.cpp:345
    #6  0x0000555555677709 in JPEG::Read (this=0x61b000000098, tags=0x7fffffffce10) at jpeg.cpp:210
    #7  0x000055555560ff53 in Reconstruct (infile=<optimized out>, outfile=<optimized out>, colortrafo=<optimized out>, alpha=<optimized out>, upsample=<optimized out>) at reconstruct.cpp:121
    #8  0x00005555555c350e in main (argc=<optimized out>, argv=<optimized out>) at main.cpp:747
    #9  0x00007ffff7055083 in __libc_start_main (main=0x5555555bafe0 <main(int, char**)>, argc=3, argv=0x7fffffffe318, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe308) at ../csu/libc-start.c:308
    #10 0x00005555555b55ae in _start ()

CVE-2022-32978: Abort in SingleComponentLSScan::ParseMCU  · Issue #75 · thorfdbg/libjpeg

In 1985, a group of klezmer musicians from the US rendezvoused with underground dissidents in Tbilisi, Georgia. This is the story of how they pulled it off with homebrew cryptography.

RSA CONFERENCE 2022 — Not all activists carry a picket sign. Some carry a soprano saxophone and a music notebook.

"1985 was a really rough go of it for people who were human-rights activists," said Dr. Merryl Goldberg, music professor at California State University San Marcos, at a keynote at RSA Conference 2022 on Wednesday. "Dissidents, human rights activists, refuseniks, Helsinki Monitors had formed — in Tbilisi, Georgia, of all places — a group, a musical group, to band together, literally." This was the Phantom Orchestra, which she would travel across the world to meet.

Her own band was Klezmer Conservatory Band. Goldberg and bandmates Hankus Netsky, Rosalie Gerut, and Jeff Warschauer traveled together to the USSR, according to a 1986 article. Activist groups in the United States, particularly Action for Soviet Jewry, conceived their mission as a way to bring international notice to a group of dissidents who otherwise could be disposed of namelessly. If the world knows these people exist and are facing persecution, the thinking went, the Soviet government would not have as free a hand.

"That's when some people in Boston had the idea, 'Maybe we should go in and support them — but also find out if there was information that should come out as well,'" Goldberg said. So this group of four young musicians volunteered to take a trip to the Soviet Union, during the Cold War.

    

Dr. Merryl Goldberg (Source: RSA Conference screengrab)

Despite the cloak-and-dagger feel, this wasn't a spy mission. The information they were seeking to smuggle out was simple personal information like names, family relationships, and birth dates. The information simple but essential if a Soviet citizen wanted to get an invitation to travel outside the USSR — and from there defect.

"There were a couple of people who wanted to be invited, and so we coded all of their information in order to bring that out so they could receive an invitation," Goldberg said. "Most of the folks ended up emigrating, which is really good, but what they had to put up with in order to emigrate was really something."

Don't worry. This ties into cryptography.

**What Music Can Mean, Literally**

Because of the precarious position of the people Goldberg and her bandmates were hoping to meet, the Americans had to encode the contact information for the Georgian dissidents.

"We couldn't write down the names of people or their addresses or things like that because it would put them in jeopardy if at customs they saw that," she said. "And it would put us in jeopardy as well."

So she found a way to write things down without making them explicit: using musical notation as an alphabet, essentially. Goldberg didn't go into the details of her code, though she did lead the audience through the directions to a dissident's apartment, shown in the image above.

Britta Glade, senior director of content and curation for RSA Conference, interviewed Goldberg. "Let's jump into some of your coding," she said.

The first Phantom Orchestra members they were to meet were the Goldsteins, brothers Isai and Grigory. 

"You're seeing directions to get to one of the apartments. So we knew we had to go on the Orange line \[subway\], stop at the end, Cross Street — that's the name of the street," Goldberg explained. "On the bottom line, I couldn't figure out a way to write it out, so I actually drew where the apartment was in the building. That's what that is. There's a little tiny square in the top square, and that was where the apartment was."

For the more complex information, like names and other personal information, Goldberg had to come up with a flexible alphabet that couldn't be read at a glance. "What I did — without giving away the story of the whole code — is I just assigned certain notes to certain letters, and then I played around with some decoy stuff in terms of the clefs," she said.

Glade is also a musician — she played one of Goldberg's encoded songs on a keyboard set up on the stage. "There's a scientific, predictable way music is gonna sound," Glade said. "It's just like programming, right?" And this programming sounded ... kinda bad.

"If you study music, like modern music, you would hear music like this, perhaps," Goldberg said, laughing. "One of the cool things about music and coding is people invent notation anyway. And they write crazy things." That made it difficult for anyone to look at even that awkward sheet music and see any real grounds for suspicion.

**What Music Can Mean, Metaphorically**

As technologist Bruce Schneier said during his RSA keynote, any system can be a code. Goldberg used her system — music — to encode directions that helped her and her bandmates connect with musicians in the USSR and to bring home information that would allow some of those dissidents to emigrate. So for those refuseniks, music meant freedom.

"Before I met the people in the Phantom Orchestra, I understood the power of music – I'm a musician. I play, and when I play, I get into this other space," Goldberg said. "When we played with the Phantom Orchestra, the power of our playing together and the freedom in our brains was something that I'll never forget. It has become a part of me."

She had to choke back some emotion to say, "But while we're playing, I understood: You can be imprisoned, you can be put wherever, and ultimately we were interrogated many more times and put under arrest, \[but\] in your brain you can still feel free. And I hadn't understood that power of music until then."

Glade brought it back to cybersecurity. "We're constantly getting pounded, pounded, pounded – you're under attack from this, this is happening here – we need to be taken, transformed, put in a \[new\] place," she said. "What does music offer us?"

Goldberg answered.

"Music is used as a way to center and ground yourself. The act and the discipline to practicing music enables you to listen better," she said. "A lot of what you do, from my understanding, is really dealing with people and understanding people and how they make decisions. They do problem-solving, right? The arts, music, but also visual arts, teach you how to solve problems, how to work well with each other."

**'Long Shadows of the Cold War'**

The invasion of Ukraine is casting "some long shadows of the Cold War that are maybe bringing up some emotions," Glade said. "What's in your heart and your head?"

"I really admire the musicians and the activists who are in Ukraine, who stay — Denys \[Karachevtsev\], who's the cellist you've seen," she answered.

Glade added, "The little girl singing in the subway."

"Yes," Goldberg said. "I also think about Brittney Griner. And I think, 'I hope she can ... keep her brain free, even though she's not.' Because that makes such a difference."

"I really think about what's going on and how people are coping," she added.

Glade and Goldberg closed out with one good way to cope: a klezmer song called "Broyges Tantz" — Yiddish for "angry dance."

How 4 Young Musicians Hacked Sheet Music to Help Fight the Cold War

**What are Kubernetes Operators?**

A Kubernetes operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is both deployed on Kubernetes and managed using the Kubernetes API. Operators automate the management of applications or service life cycles on behalf of a human operator, providing for the ability to automate at every level of the stack—from managing the parts that make up the platform all the way to applications that are provided as a managed service.

Engineering teams can use the power of Operators, which offer autonomous management by exposing configuration natively through Kubernetes objects, for quicker installation and more frequent, robust updates. In addition to the automation advantages of Operators for managing the platform, Red Hat OpenShift makes it easier to find, install and manage Operators running on clusters.

**Using Operators in Red Hat OpenShift**

OpenShift is an enterprise Kubernetes platform with full-stack automated operations to manage hybrid cloud deployments.

Included in Red Hat OpenShift is the embedded OperatorHub, a registry of operators from various software vendors and open source projects. Within the OperatorHub you can browse and install a library of operators that have been verified to work with Red Hat OpenShift and that have been packaged for easier lifecycle management. 

OpenShift offers two different systems to manage operators depending on their purpose:

*   **Platform Operators**, which are managed by the Cluster Version Operator (CVO), are installed by default to perform cluster functions.
    
*   **Add-on Operators**, which are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications.
    

Additionally, suitably privileged users can manage operators through other means such as using YAML files or helm charts.

**Why is security important to Operators?**

More engineering teams are moving toward using Operators to deploy in their production environments. While the full potential of Operators hasn’t yet been reached, it’s important to not lose sight of the benefits of building in more secure code and practices as early as possible in the development process. 

**Good security practices for Operators****Minimize cluster-scope and namespace-scope permissions**

There are two types of classification for Operators:

*   **Namespace-scoped** — Operator watches and manages resources within a namespace and requires permissions within these namespace to do so
    
    *   There are subtypes within this:
        
        *   in a single, prenamed namespace determined by the developer
            
        *   in a single namespace provided at installation time
            
        *   in multiple namespaces (e.g. using the MultiNamespace install mode type in the OperatorGroup)
            
*   **Cluster-scoped** — watches and manages resources across or all namespaces within a cluster and requires cluster-scoped permissions to achieve this
    

Generally speaking, following the Principle of Least Privilege (PoLP), you should restrict access as much as possible while still allowing your Operator to function. Permissions can be granted by creating role bindings and cluster role bindings that bind the Operator’s service account to the required roles and cluster roles. This can be achieved using  Operator Lifecycle Manager (OLM) bundle deployment architecture.

Apart from the Operator image itself, an Operator bundle is an OLM-prescribed format for holding metadata about an Operator. The metadata contains everything that Kubernetes needs to know in order to use the Operator — its custom resource definitions (CRDs), role-based access control (RBAC) roles and bindings required, dependency tree and other information as outlined in Deploying Operators with OLM bundles.

A benefit of using OLM is that it manages the permissions needed to install and run the Operator. OLM uses the cluster-admin role to do the installation and separates the install time requirements, for example the APIService and CustomResourceDefinition resources are always created by OLM using the cluster-admin role, thus reducing the overall permissions surface. 

Using OLM, cluster administrators can choose to specify a service account for an Operator group so that all Operators associated with the group are deployed and run with the privileges granted to the service account. A service account associated with an Operator group should never be granted privileges to write these resources. Any Operator tied to this Operator group is now confined to the permissions granted to the specified service account. If the Operator asks for permissions that are outside the scope of the service account, the install fails with appropriate errors.

**Reduce the usage of cluster-scope permissions**

The use of cluster-scoped Operators should be justified. If not necessary, the recommendation is to run namespaced-scoped Operators with the minimal permissions required.

Cluster-scoped Operators require access to resources across the entire cluster, including the control plane, using permissions obtained by using cluster roles and cluster role bindings.

Namespace-scoped Operators require access only to resources in single namespaces and these permissions can be obtained by using roles and role bindings. Exception to this is where a namespace-scoped operator must create a CustomResourceDefinition (CRD) which is a cluster-scoped resource.

If there are static cluster-scoped resources whose definition won’t change based on the inputs given to the Operators, you can move the creation of those resources to the Operator Lifecycle Manager (OLM) catalog. For example, you can move CRD creation from your Operator to OLM since it doesn’t change throughout the Operator’s lifecycle.

**RBAC permissions**

Both Kubernetes and OpenShift platforms offer authorization through role-based access control (RBAC). The security context is an essential element of pod and container definitions in Kubernetes. Note that this is different to the OpenShift security feature called security context constraint (SCC).

Kubernetes Operators also define permissions granted to the Operator, generally in a YAML definition called role.yaml. Roles are assigned at the namespace level, so any escalation of privilege is inherently limited by the namespace itself. However, ClusterRole needs to be checked more carefully because they apply cluster wide. 

One possible way that privileges could be escalated is if a non-privileged user (with system:authenticated role) gets access to the service account token used by the operator. A common way of reducing this risk is to deploy the Operator in a separate namespace from its Operands, in which the non-privileged user doesn’t have access to read secrets, or if deployed in a namespace shared with non-privileged users, those users should not have access to read secrets in that namespace. It is recommended that Operators are never deployed in a shared namespace, especially one that allows non-privileged users access.

We recommend that code reviews should include looking for RBAC roles that can leverage themselves to gain extra privileges. 

 Examples to watch out for:

*   The Bind verb can be applied to Roles or ClusterRoles and allows a principal to bypass a general restriction on (cluster)role binding creation, which stops users who can create role bindings from escalating their privileges by binding to high privilege roles like cluster admin. This restriction is described in the Kubernetes documentation: Restrictions on role binding creation or update.
    
*   Escalate rights on cluster roles: Escalate bypasses the Kubernetes RBAC check, which prevents users who are able to create roles or cluster roles from creating (or editing) these objects to have more rights than they do.
    
*   Multiple Roles should be described to reduce the scope of any actions needed for containers that the Operator may run on the cluster. For example, if you have a component that generates a TLS Secret upon startup, a Role that allows Create but not List on Secrets is more secure than using a single all-powerful Service Account.
    
*   If you grant cluster-admin, cluster-admin can itself update/alter SCCs.
    
*   If you have usage of a given SCC and also have "create pod" then you can create a new pod to grab the full extent of what the SCC will permit.
    
*   If you have RBAC that permits editing of RBAC you can edit your own limits.
    
    *   For example:
        

resources:
\- roles
\- rolebindings
verbs:
\- patch
\- create

Would potentially allow the operator to give unprivileged users permissions to access privileged namespaces by 'giving' them the roles when requested. (Note: by default Operators are limited to only granting permissions to others that it has itself).

**Avoid wildcards**

Instead of using the wildcard character in RBAC definitions as per the image below, it is good practice to explicitly list out each verb or resource. Each item in the list can then more easily be examined to confirm where and how the permissions are needed, or if they were accidentally grabbed as a convenience during earlier development.

For example, instead of using "\*" in the verbs section, you can list them out in full, such as: get, list, watch. If the operator knows the name of a resource it will edit, it can be limited to only get/edit and will frequently not need "list".

Being explicit with lists will also future-proof the permissions for if the "\*" changes to match additional items not currently present.

**Using RBAC to define and apply permissions**

The relationships between cluster roles, roles, cluster role bindings, role bindings, users, groups and service accounts are illustrated below.

_Figure 1: Default cluster roles_

**Descoped Operator**

Since operators are run with a service account in a namespace, anyone with the ability to create workloads in that namespace can escalate to the permissions of the operator. To address these concerns, a notion of scoping operators was introduced via the OperatorGroup object. An OperatorGroup would specify a set of namespaces within a cluster in which all operators installed would share the same scope. The Operator Lifecycle Manager (OLM) ensures that only one operator within a namespace owns a particular CRD to avoid collision problems.

The problem is that APIs in a cluster are cluster-scoped. They are visible via discovery to any user that wishes to see them. Even Operators that agree on a particular Group, Version, Kind (GVK) may have differences of opinion in how those objects should be admitted to a cluster, or how conversion between API versions should happen. This means that it increases the likelihood that more than one "opinion" about an API exists in the cluster.

The article Operator Descoping Plan describes this further.

**Pod and container securityContext and Security Context Constraints (SCCs)**

When trying to containerize third-party applications, it may sometimes be necessary to bend to the expectations of those applications and run as specific UIDs, perhaps even running as root. For Operators that are created to be container-native, you should never make any UID expectations, and accept the customary "billion+" high UID that the OpenShift cluster assigns to the namespace your operator runs in.

*   Set a numeric USER in the Containerfile to avoid defaulting to, or assuming the expected user may have uid=0
    
*   Use group id permissions to manage shared file permissions instead of user id.
    

Similarly, the usage of hostPath volumes allows files on the host node to be accessible from the container. If a container is insecurely configured and it is compromised, the attacker could try to attack the host and other containers running on the host.

For hostPath specifically:

*   Operators should never require host paths unless they comprise part of the control plane itself.
    

Other deployment recommendations:

*   **readOnlyRootFilesystem** -- set it to TRUE 
    
    *   Avoid writing any local files to the root filesystem. Use /tmp or an emptyDir instead. Pay attention to PID files, as well as any log output that isn’t going to STDOUT.
        
*   **runAsNonRoot** -- set to TRUE 
    
    *   This can be set in either the podSpec or containerSpec’s security context. By enabling this, the container will refuse to run if other circumstances indicate it might run with uid=0.
        
*   **automount service account token** -- set to FALSE
    
    *   By default, the service account token is mounted as a file within the container. Operators will generally have an SA that they require access to in order to function (hence, set this TRUE). However, any pods that the operator creates may benefit from the added protections of setting it false. 
        

OpenShift Security context constraints (SCC) are gatekeepers that will limit which pods can be admitted to the cluster. Since the Operator process also runs as a pod in a cluster, you can use the same concepts to enhance the security posture of your Operator container as well.

The Udica tool was created to simplify the creation of custom SELinux policies that can then be tied to custom SCCs.

**Continuous security scans**

Continuously scanning helps to identify vulnerabilities and pick up the latest security bug fixes in Go, Kubernetes and the Operator container’s base image.

For the container images that are running in OpenShift and are pulled from Red Hat Quay registries, you can use an Operator to list the vulnerabilities of those images. The Container Security Operator can be added to OpenShift to provide vulnerability reporting for images added to selected namespaces.

Container image scanning for Red Hat Quay is performed by the Clair security scanner. In Red Hat Quay, Clair can search for and report vulnerabilities in images built from RHEL, CentOS, Oracle, Alpine, Debian and Ubuntu operating system software.

**Deployment location **

Where should an Operator run? Depending on what it is, we would recommend the Operator runs in an appropriate location. For an Operator that comprises part of the control plane, it can be scheduled to run on control plane nodes using Tolerations.

Even if Operators and Operands are split between namespaces, because the Operator itself may have a highly privileged service account to perform its kube API interaction, if it runs on a worker node any compromise of that worker node may reveal the Service Account credentials. Separation of workloads by node, as well as by namespace, is therefore beneficial.

**Useful resources**

*   **Get the Kubernetes operators e-book**
    

**References**

*   What is a Kubernetes operator?
    
*   Operator Framework - Operator Best Practices
    
*   Community-operators Best Practice
    
*   HackMD - Decoped/Scoped Operator
    
*   With Kubernetes Operators comes great responsibility
    
*   Kubernetes Operators Best Practices
    
*   How to build security in kubernetes operators
    
*   Operators and Red Hat OpenShift Container Platform
    
*   Using Kubernetes Operators to Manage Let’s Encrypt SSL/TLS Certificates for Red Hat OpenShift Dedicated
    
*   Udica
    
*   A Guide to OpenShift and UIDs
    
*   Using RBAC to define and apply permissions
    
*   Namespace vs Cluster Scoped Operators
    
*   Thinking of building a Kubernetes operator? Here’s what you need to know

Kubernetes Operators: good security practices

The ITarian Endpoint Manage Communication Client, prior to version 6.43.41148.21120, is compiled using insecure OpenSSL settings. Due to this setting, a malicious actor with low privileges access to a system can escalate his privileges to SYSTEM abusing an insecure openssl.conf lookup.

Tag

#ssl