1. nuga@groups.io
  2. Messages
   Date   
Re: PC Parts - Free

Jerry Tibor
 

Hi Sue,

 

Thanks for the offer!  NUGA is no longer accepting equipment donations because of the pandemic and also because our service project coordinator has moved out of state.

 

If anyone else can use those items, feel free to reach out to Sue offline at the email address below.

 

Jerry

 

From: nuga@groups.io <nuga@groups.io> On Behalf Of Sue Darby
Sent: Saturday, March 26, 2022 9:06 AM
To: nuga@groups.io
Subject: [nuga] PC Parts - Free

 

I know at one time this group used to take in donated PC parts to build Linux machines for Northstar Elementary (my kids went there at one time a long time ago!). I have a pile of parts with at least a couple working boards, cpu, ram cooler setups along with misc cables, a case etc. Does anyone know someone who'd want them?

 

I'm in the Valley and am tired of tripping over the box of stuff! LMK if someone wants them!

 

Thanks!

 

Sue Darby ~ Technical Writer

Remote.

907-707-5654 Alaskan Time
PC Parts - Free

Sue Darby
 

I know at one time this group used to take in donated PC parts to build Linux machines for Northstar Elementary (my kids went there at one time a long time ago!). I have a pile of parts with at least a couple working boards, cpu, ram cooler setups along with misc cables, a case etc. Does anyone know someone who'd want them?

I'm in the Valley and am tired of tripping over the box of stuff! LMK if someone wants them!

Thanks!

Sue Darby ~ Technical Writer
Remote.
907-707-5654 Alaskan Time
Re: FYI, Alaska USA Phishing Page in the wild

Tom Bentley
 

Thank you, reported to phishing@....

Tom

On Mar 24, 2022, at 17:30, JP <jp@...> wrote:


I haven't seen many that target local Alaskan companies, but I thought I would share this with you all. 

---------- Forwarded message ---------
From: JP <jp@...>
Date: Thu, Mar 24, 2022 at 5:28 PM
Subject: FYI, Alaska USA Phishing Page in the wild
To:


I wanted to warn you of a phishing text that a client received today. 

This is one of the most realistic phishing attempts I have seen, and it came in via text message. So, technically, this is a smishing scam. Feel free to share this.

This scam attempts to collect your Alaska USA username, password and credit card information.

Here is the text message
image.png

This is the web page if you click the link. This looks exactly like the real website, but none of the links work.
image.png

---
Book time with me here: https://calendly.com/jptechnical
     ___ _______ 
    |   |       |
    |   |    _  |
    |   |   |_| |
 ___|   |    ___|
|       |   |    
|_______|___|    
JP (Jesse Perry)
voice/text: 907-748-2200
email: jp@...
support: helpdesk@...
FYI, Alaska USA Phishing Page in the wild

JP
 

I haven't seen many that target local Alaskan companies, but I thought I would share this with you all. 

---------- Forwarded message ---------
From: JP <jp@...>
Date: Thu, Mar 24, 2022 at 5:28 PM
Subject: FYI, Alaska USA Phishing Page in the wild
To:


I wanted to warn you of a phishing text that a client received today. 

This is one of the most realistic phishing attempts I have seen, and it came in via text message. So, technically, this is a smishing scam. Feel free to share this.

This scam attempts to collect your Alaska USA username, password and credit card information.

Here is the text message
image.png

This is the web page if you click the link. This looks exactly like the real website, but none of the links work.
image.png

---
Book time with me here: https://calendly.com/jptechnical
     ___ _______ 
    |   |       |
    |   |    _  |
    |   |   |_| |
 ___|   |    ___|
|       |   |    
|_______|___|    
JP (Jesse Perry)
voice/text: 907-748-2200
email: jp@...
support: helpdesk@...
Re: tentative: Okta may have been breached since late January

Royce Williams
 

That's compatible with the theory that they did keep quiet about it - until they were caught.

Okta's blog post has been updated:


Excerpt (emphasis mine):

After a thorough analysis of these claims, we have concluded that a small percentage of customers – approximately 2.5% – have potentially been impacted and whose data may have been viewed or acted upon. We have identified those customers and are contacting them directly. If you are an Okta customer and were impacted, we have already reached out directly by email. We are sharing this interim update, consistent with our values of customer success, integrity, and transparency.

-- 
Royce


On Tue, Mar 22, 2022 at 6:48 PM Tom Bentley <TomBent@...> wrote:
My first thought was that if they had obtained sufficient access to compromise clients they would have kept quiet about it.

On Mar 22, 2022, at 17:35, JP <jp@...> wrote:


Thanks again Royce. 

I have been watching this on some MSP forums as well, a security vendor posted this yesterday afternoon, I was also kind of waiting to see what this really is once the dust settles. Currently the concern among that community is that our vendors may have been using Okta for authentication and everyone is really gunshy since the Kaseya and Log4J events. So even though I don't personally employ Okta I am asking my vendors if they do. If I find anything I will be sure to reply here.

On Mon, Mar 21, 2022 at 10:34 PM Royce Williams <royce.williams@...> wrote:
Developing story - take with a grain of salt. If you use Okta, it might be useful for IR resources to start tentative evaluation of applicability to your environment.


Early speculation is that the threat actor (LAPSUS$) may have lost their foothold, and so decided to "burn" it for the exposure.

Royce
Re: tentative: Okta may have been breached since late January

Tom Bentley
 

My first thought was that if they had obtained sufficient access to compromise clients they would have kept quiet about it.

On Mar 22, 2022, at 17:35, JP <jp@...> wrote:


Thanks again Royce. 

I have been watching this on some MSP forums as well, a security vendor posted this yesterday afternoon, I was also kind of waiting to see what this really is once the dust settles. Currently the concern among that community is that our vendors may have been using Okta for authentication and everyone is really gunshy since the Kaseya and Log4J events. So even though I don't personally employ Okta I am asking my vendors if they do. If I find anything I will be sure to reply here.

On Mon, Mar 21, 2022 at 10:34 PM Royce Williams <royce.williams@...> wrote:
Developing story - take with a grain of salt. If you use Okta, it might be useful for IR resources to start tentative evaluation of applicability to your environment.


Early speculation is that the threat actor (LAPSUS$) may have lost their foothold, and so decided to "burn" it for the exposure.

Royce

-- 
Royce Williams
Tech Solvency
Re: tentative: Okta may have been breached since late January

JP
 

Thanks again Royce. 

I have been watching this on some MSP forums as well, a security vendor posted this yesterday afternoon, I was also kind of waiting to see what this really is once the dust settles. Currently the concern among that community is that our vendors may have been using Okta for authentication and everyone is really gunshy since the Kaseya and Log4J events. So even though I don't personally employ Okta I am asking my vendors if they do. If I find anything I will be sure to reply here.


On Mon, Mar 21, 2022 at 10:34 PM Royce Williams <royce.williams@...> wrote:
Developing story - take with a grain of salt. If you use Okta, it might be useful for IR resources to start tentative evaluation of applicability to your environment.


Early speculation is that the threat actor (LAPSUS$) may have lost their foothold, and so decided to "burn" it for the exposure.

Royce

-- 
Royce Williams
Tech Solvency
tentative: Okta may have been breached since late January

Royce Williams
 

Developing story - take with a grain of salt. If you use Okta, it might be useful for IR resources to start tentative evaluation of applicability to your environment.


Early speculation is that the threat actor (LAPSUS$) may have lost their foothold, and so decided to "burn" it for the exposure.

Royce

-- 
Royce Williams
Tech Solvency
Registration is now open for INTERFACE Alaska Virtual on April 21st

Jerry Tibor
 

INTERFACE Alaska 2022 will take place online on April 21st.

 

Here is the registration link for NUGA members to attend at no cost:

 

https://f2fevents.com/register/?att=ANC&ref=Association&par=NUGA

 

Registration is open now, so feel free to share the link.

 

Members can earn up to 6 CPE credits during the day.

 

More information can be found below.

 

Jerry

 

--

 

Jerry Tibor
Electronic Student Services Lead

University of Alaska Anchorage

jftibor@...
(907) 786-4734 - office

 

Vice-President, Network Users Group Alaska
http://www.nuga.org

 

 

View in browser

Thurs., April 21, 2022  |  Virtual  |  Register

INTERFACE Alaska

The Conference for Forward-Thinking IT Leaders

Registration is now open for INTERFACE Alaska — a virtual conference addressing Information Security, Incident Response, Infrastructure, Disaster Recovery, Strategic Management, and more. Join us on April 21st, 2022.

 

 

  • Top-rated speakers from across the country, culminating in a local keynote selected by your INTERFACE Advisory Council
  •  INTERFACE Exhibit Hall showcasing the most sought-after tech companies and professional associations
  •  Exclusive prize drawings for gift cards, devices, and up to $500 cash!

 

 

Bringing together over 3500 attendees every year across 14+ events, INTERFACE connects, celebrates, and supports the IT community with a no-cost, CPE-accredited conference series. Come explore the future of IT with industry leaders and easily build relationships with innovators from top companies.
 

 

 

 

 

INTERFACE Alaska is supported by these professional associations: 

ARMA Alaska  |  Alaska InfraGard  |  ISACA Anchorage |  ISC2 South Central Alaska  |  Network Users Group Alaska  |  PMI Alaska

 

 

LinkedIn

Twitter

Website

Email

 

 

INTERFACE is a series of educational conferences focused on information security, IT infrastructure, BC/DR, data storage, and communications. INTERFACE has received 15+ years of enthusiastic support from the regional IT communities it serves and is proudly produced by F2F Events, Inc.

You are receiving this email as a member of the IT community.
You can update your preferences or unsubscribe from this list.

Copyright © 2022 F2F Events, Inc., All rights reserved.

Our mailing address is:

F2F Events, Inc.

8020 SW Pfaffle Street Suite 150

Portland, OR 97223


Add us to your address book
using auto lab in vm ware player 16

blindgeekzone@...
 

Hi. Running windows 11 pro 64 bit. Now is there a way to get the auto lab iso files and then set them up in vmware player. Auto lab is a free project able to then able to use windows terminal which works great with windows 11 and jaws 2022. Now if so, if any one has used auto lab for creating lab configurations for learning.

Would like to know.

Marvin.
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Royce Williams
 

Important update:

All previous mitigations - based on anything other than upgrading to log4j 2.16 or entirely removing JndiLookup classes - are no longer effective mitigation.

If your vendors have not yet supplied patches that upgrade to 2.16, your best bet may be to remove the JndiLookup class.

This page from Apache itself is the best summary of the latest practical upshot of vulnerability and effective mitigation: https://logging.apache.org/log4j/2.x/security.html

For detection and mitigation on Unix-likes, this is a really good tool, based on pure shell (so highly portable), written by Yahoo's security team. By default it just detects. It has an optional flag that will make a zipped backup copy of a jar or war file, and then attempt to remove the affected class. 

    https://github.com/yahoo/check-log4j (Unix-likes only)

See my page for other mitigations - I'm updating best-effort in my spare time. My page also has other major lists you can check for your products if you haven't heard back from your vendor yet.

(Also for folks who play or have kids who do, update all Minecraft if you haven't already)

Royce

-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:42 AM Royce Williams <royce@...> wrote:
This one is developing quickly, so I'll push updates here as I discover them:


-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Peter Barclay PCNI
 

So far been pretty lucky, but turns out there’s a log4j vulnerability in CrashPlan – there was an update to it posted just yesterday, in case anyone’s using it.

 

Peter Barclay

 

From: nuga@groups.io <nuga@groups.io> On Behalf Of David W. Monroe
Sent: Monday, December 13, 2021 8:42 AM
To: nuga@groups.io
Cc: AKLUG <aklug@...>
Subject: Re: [nuga] log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

 

 

 

https://www.youtube.com/watch?v=oC2PZB5D3Ys [youtube.com]

 

 

Thank you,

 

Dave

 

David Monroe
Consulting Engineer, Diversified Industrials

o: +1 907 261 4700    m: +1 907 360 0517

david.monroe@...

 

 

Facebook  Twitter  LinkedIn 

Transformation Accelerated

 

Great Place to Work®
Certified Jan 2021-2022

 

 

To request Hardware or software, please use the form, available as a Word document, located at CTG HW-SW Request Form.  For account changes and file server access, please use the form CTG User Access Request Form located in the same location.  For support issues/requests you are welcome to and encouraged to contact the CTG Help Desk @ 1-800-544-9071 (from inside the CTG office x3556). If they are unable to help you solve the problem, they will escalate a Remedy ticket regarding your problem to someone that can assist you further. You may also contact the Help Desk via email. They are listed in the CTG Global Address List as "Helpdesk".

 

From: nuga@groups.io <nuga@groups.io> On Behalf Of Royce Williams
Sent: Sunday, December 12, 2021 7:33 PM
To: nuga@groups.io
Cc: AKLUG <aklug@...>
Subject: Re: [nuga] log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

 

Hi, Mike - Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with

Hi, Mike -

 

Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated, that parent products' vendors should be asked questions about upgrade plans.


-- 

Royce

 

 

On Sun, Dec 12, 2021 at 7:25 PM Mike <tibor@...> wrote:

Royce,

From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.

Have you seen any hard confirmation yet whether 1.x is vulnerable?

Thanks,
Mike


On Fri, 10 Dec 2021, Royce Williams wrote:

> This one is developing quickly, so I'll push updates here as I discover them:
> https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ [techsolvency.com]
>
> -- 
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
>       Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
> https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/ [logging.apache.org])
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
> https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b [gist.github.com]
>
> Good threads and summaries:
> - https://twitter.com/GossiTheDog/status/1469248250670727169
> - https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek [cert.at] (German)
> - https://github.com/YfryTchsGD/Log4jAttackSurface [github.com]
>
> -- 
> Royce Williams
> Tech Solvency
>
>
>
>



The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this
message, please contact the sender and delete this material from this computer.
Computer Task Group, Inc.’s privacy statements may be found via
www.ctg.com/privacy-policy and www.ctg.com/privacy-shield.
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

David W. Monroe
 

 

 

https://www.youtube.com/watch?v=oC2PZB5D3Ys [youtube.com]

 

 

Thank you,

 

Dave

 

David Monroe
Consulting Engineer, Diversified Industrials

o: +1 907 261 4700    m: +1 907 360 0517

david.monroe@...

 

 

Facebook  Twitter  LinkedIn 

Transformation Accelerated

 

Great Place to Work®
Certified Jan 2021-2022

 

 

To request Hardware or software, please use the form, available as a Word document, located at CTG HW-SW Request Form.  For account changes and file server access, please use the form CTG User Access Request Form located in the same location.  For support issues/requests you are welcome to and encouraged to contact the CTG Help Desk @ 1-800-544-9071 (from inside the CTG office x3556). If they are unable to help you solve the problem, they will escalate a Remedy ticket regarding your problem to someone that can assist you further. You may also contact the Help Desk via email. They are listed in the CTG Global Address List as "Helpdesk".

 

From: nuga@groups.io <nuga@groups.io> On Behalf Of Royce Williams
Sent: Sunday, December 12, 2021 7:33 PM
To: nuga@groups.io
Cc: AKLUG <aklug@...>
Subject: Re: [nuga] log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

 

Hi, Mike - Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with

Hi, Mike -

 

Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated, that parent products' vendors should be asked questions about upgrade plans.


-- 

Royce

 

 

On Sun, Dec 12, 2021 at 7:25 PM Mike <tibor@...> wrote:

Royce,

From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.

Have you seen any hard confirmation yet whether 1.x is vulnerable?

Thanks,
Mike


On Fri, 10 Dec 2021, Royce Williams wrote:

> This one is developing quickly, so I'll push updates here as I discover them:
> https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ [techsolvency.com]
>
> -- 
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
>       Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
> https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/ [logging.apache.org])
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
> https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b [gist.github.com]
>
> Good threads and summaries:
> - https://twitter.com/GossiTheDog/status/1469248250670727169
> - https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek [cert.at] (German)
> - https://github.com/YfryTchsGD/Log4jAttackSurface [github.com]
>
> -- 
> Royce Williams
> Tech Solvency
>
>
>
>




The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this
message, please contact the sender and delete this material from this computer.
Computer Task Group, Inc.’s privacy statements may be found via
www.ctg.com/privacy-policy and www.ctg.com/privacy-shield.
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Royce Williams
 

Hi, Mike -

Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated, that parent products' vendors should be asked questions about upgrade plans.

-- 
Royce


On Sun, Dec 12, 2021 at 7:25 PM Mike <tibor@...> wrote:
Royce,

From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.

Have you seen any hard confirmation yet whether 1.x is vulnerable?

Thanks,
Mike


On Fri, 10 Dec 2021, Royce Williams wrote:

> This one is developing quickly, so I'll push updates here as I discover them:
> https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
>
> -- 
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
>       Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
> https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
> https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
>
> Good threads and summaries:
> - https://twitter.com/GossiTheDog/status/1469248250670727169
> - https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek (German)
> - https://github.com/YfryTchsGD/Log4jAttackSurface
>
> -- 
> Royce Williams
> Tech Solvency
>
>
>
>
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Mike
 

Royce,

From what I've been seeing, only version 2.x seems to be vulnerable, and 1.x is not, however nothing seems to be certain about that.

Have you seen any hard confirmation yet whether 1.x is vulnerable?

Thanks,
Mike

On Fri, 10 Dec 2021, Royce Williams wrote:

This one is developing quickly, so I'll push updates here as I discover them:
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
-- 
Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.
Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8
Exploitation: active:
https://twitter.com/GreyNoiseIO/status/1469326260803416073
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
messages.
Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
messages.
Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic
Exploit detection:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Good threads and summaries:
- https://twitter.com/GossiTheDog/status/1469248250670727169
- https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek (German)
- https://github.com/YfryTchsGD/Log4jAttackSurface
-- 
Royce Williams
Tech Solvency
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Royce Williams
 

JP - 

Excellent - my hope was to make it forward-ready.

And no need for lunch - just please ask any of those folks send me any items that are missing or wrong. :D

-- 
Royce


On Sat, Dec 11, 2021 at 1:09 PM JP <jp@...> wrote:
Thank you so much for the post Royce. Knowing how ubiquitous this logging package was, it really blew up big and is moving fast. I shared your notification with The Tech Tribe not long after your original post, it blew up the forums, even an out-of-band email alert was sent. About 8500 techs around the world owe you their thanks (and you made me look like a rockstar, lol). I was able to coordinate my systems, including patching unifi controllers, all before dinner.

Seriously though, many were caught totally flatfooted, some huge vendor names were affected, lots of really big MSPs shut down their PSA and RMM systems out of caution until the vendors could provide a fix or report their investigations. In many cases, we (the MSPs) were asking the vendors before they had released their findings. This was really fast action. It could have been like the Kaseya ransomware attack. You may have directly affected thousands of businesses. You are THE BEST! 

Please let me buy you lunch!
 
---
Book time with me here: https://calendly.com/jptechnical
     ___ _______ 
    |   |       |
    |   |    _  |
    |   |   |_| |
 ___|   |    ___|
|       |   |    
|_______|___|    
JP (Jesse Perry)
voice/text: 907-748-2200
email: jp@...
support: helpdesk@...



On Fri, Dec 10, 2021 at 7:43 AM Royce Williams <royce.williams@...> wrote:
This one is developing quickly, so I'll push updates here as I discover them:


-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

JP
 

Thank you so much for the post Royce. Knowing how ubiquitous this logging package was, it really blew up big and is moving fast. I shared your notification with The Tech Tribe not long after your original post, it blew up the forums, even an out-of-band email alert was sent. About 8500 techs around the world owe you their thanks (and you made me look like a rockstar, lol). I was able to coordinate my systems, including patching unifi controllers, all before dinner.

Seriously though, many were caught totally flatfooted, some huge vendor names were affected, lots of really big MSPs shut down their PSA and RMM systems out of caution until the vendors could provide a fix or report their investigations. In many cases, we (the MSPs) were asking the vendors before they had released their findings. This was really fast action. It could have been like the Kaseya ransomware attack. You may have directly affected thousands of businesses. You are THE BEST! 

Please let me buy you lunch!
 
---
Book time with me here: https://calendly.com/jptechnical
     ___ _______ 
    |   |       |
    |   |    _  |
    |   |   |_| |
 ___|   |    ___|
|       |   |    
|_______|___|    
JP (Jesse Perry)
voice/text: 907-748-2200
email: jp@...
support: helpdesk@...



On Fri, Dec 10, 2021 at 7:43 AM Royce Williams <royce.williams@...> wrote:
This one is developing quickly, so I'll push updates here as I discover them:


-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency
Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Royce Williams
 

This one is developing quickly, so I'll push updates here as I discover them:


-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency
log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228

Royce Williams
 

Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency
Re: Is anyone using proxmox in production?

Arthur Corliss
 

On Sat, 20 Nov 2021, JP wrote:

Good feedback everyone, I appreciate it. Just to clarify, I have been a
linux user since the 90s, and in addition to my service business I work as
a DevOps engineer for an enterprise, we build systems at scale with
kubernetes in both private and public clouds.

My question was more centered around the reliability of proxmox in a very
small business and from the standpoint of a small business service provider
who doesn't want to have to fiddle with it much. Was there any reason to
replace it. I am getting the feeling like there is no reason to replace it
other than the ford vs chevy argument.
I think you're spot on. If you already have it, no need to replace it, it
does the job.

--Arthur Corliss
Live Free or Die
1 - 20 of 528