Bork Tuesday, Any Problems Yet?

Something has deactivated my Windows Time Service synchronization in group policies. I guess it has been done by 4023057, which, BTW, appeared today in the download list of updates, even though I still have it.

EDIT: I tried hiding that update with that one troubleshooter, but it wont go away. Any ideas?
Also: Can I block changes to group policies by the system somehow?

 

Same here in that it tried to reinstall today although it is already installed.

I currently have the Windows Remediation service disabled which will block sedsvc.exe startup at boot time. I additionally block sedsvc.exe and sedlauncher.exe startup with a HIPS rule. It gets better on this POS KB4023057 forced update. Both sedsvc.exe and sedlauncher.exe establish ICMP tunnels to upload data from your PC. This will bypass any firewall checking on the transmissions. Since sedsvc.exe and sedlauncher.exe reside unprotected in C:\Program Files directory, they would be ideal targets for any malware wanting to establish a bot on your device since the tunneling of outbound traffic is already built in.

Anyway, all the above caused the KB4023057 update today to fail. Great and hope it remains this way! Only Microsoft would think up an abomination like this. Consider this to be the new Home ver. user "cannon fodder" technique in leu of prior forced Win 10 Feature upgrading.

I think its time all Wilders users and anyone else they could find file a class action lawsuit against Microsoft.

 

Are you jealous guys?

I'm not in a rush, not anytime soon, reading this topic

 

I strongly suspect that both the Chrome and Edge mitigation errors are originating from WDEG.

In the case of Chrome, check and see if the "Disable Win32 system calls" app mitigation is enabled for it.

In the case of Edge, appears the "Block low integrity images" app mitigation is the culprit. Now I have no Edge app set up by default in WDEG. Appears that is by design since Microsoft has internally locked down Edge.

 

A connection over ICMP? Oh come on...
Does it send data over it? What data?

Why jealous?

 

The problem with the metered connection blocking approach is it will have to be disabled eventually to receive other critical security updates.

 

Found this out when I was getting alerts from Eset's IDS which monitors for such activity.

Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;User
12/2/2018 12:52:56 PM;ICMP Hidden Channel;Blocked;192.168.1.xx;23.40.18.91;ICMP;;;

 

Maybe it just pinged it?

 

No. This detection specifically looks for data being sent in an echo request.

 

Could you look at it with Wireshark?

 

Cuz I haven't downloaded and installed the update, and you have

That was just an exemplary image to show I haven't downloaded it yet, there are many ways you can block updates

 

No need to. If you doubt me, do likewise yourself.

 

Let us know if you can do so with this bugger. Appears it can bypass those.

 

No, I mean to see WHAT is getting transferred

 

Quite simple really

(You also have to disable automatic updates, for example through group policy)

Now, for how to block only this update and allow other updates to install, for when you have more than 1 update but you only don't want to install this one, Idk cuz I only have 1 update right now. If I get more than 1 update to install from check for updates, then I'll be able to test how to only install a particular update and not either install or block all updates that are shown from check for updates

 

That's usually what this is for, but it wont help in this case. Those sneaky ********.
https://support.microsoft.com/en-ca...t-a-windows-update-from-reinstalling-in-windo

 

Ahh yes, the famous wushowhide, as I like to call it. I've been using this thing for years. It used to work before (last time I ran it was like, a few months ago?) Now I can't even get to the scan part, just instantly says it couldn't find the problem. Although, that's probably (almost certainly) cuz my windows is tweaked (almost) beyond recognition (thank you tairiku), and likely something it needs is missing thus it fails. Normally, it shows some updates, especially driver ones, but not all, so no guarantee it would work for this one, just like you say it doesn't

 

Here's an article on the latest KB4023057 update which really doesn't state anything more than previous articles on it: https://news.softpedia.com/news/mic...-pcs-for-windows-10-version-1809-524161.shtml . Appears Microsoft has the "world" fleeced on this one.

 

Actually no, this is disabled by default. If you enable it then the browser broker can't access the kernel driver, GUI will be blocked and Chrome will fail to start altogether. You have to allow access to the resource, but disable it on a per-sandbox (process) base - not so simple and can't be achieved with current OS implementations.

There is nothing to worry about with these errors, this is just how these mitigations are implemented in Chromium (thus in all it's forks), Firefox (and all forks) and it seems Edge. Old builds, or independent browsers/single-process apps, do not have sandbox implemented, so do not fire these errors (and access the resource unrestricted).

James Forshaw explains the sandbox implementation nicely here, regarding Chrome of course. It's a bit long (and 2 years old).

There is an explanation on what diagnostic info is sent here. Look specifically at the Remediation section, as well as Sediment section, where it is clearly stated -

I have tried to reproduce this issue in order to look into the packets. I booted into freshly installed 1803 VM, the update in question is immediately offered and installed. But I still can't see any connections.

 

Found something that will actually hide latest KB4023057, Windows Update Mini Tool. You can download it here: https://www.majorgeeks.com/files/details/windows_update_minitool.html . Unbelievable how fast it checks for Win Updates. Also manually checked for Win Updates and indeed, none were shown.

 

How about Windows Update Manager? It's from our DavidXanatos, actively developed, feature rich and based on WUMT. Which's been dead for 2 years.
Never tried it though, but seen some people here praise it.

 

Never had any problems with windows updates since xp. Maybe I didn't make enough tweaks.

 

You bet

Lol you guys, downloading extra tools for something that can already easily be done manually - block the installation of updates as shown above using any SRP or w/e, download updates you want from microsoft catalog and install them separately
It's like, downloading daemon tools when you can already mount isos in windows 10, why use additional programs which aren't required, simplicity is best

 

How I verified the Eset ICMP hidden channel detection is I created a separate firewall rule to block outbound ICMP traffic to the detected target IP address. Sure enough that rule triggered when both sedsvc.exe (boot time) and sedlauncher.exe (scheduled task) started. Furthermore when both the processes were blocked from execution, the ICMP firewall rule never triggered again. Note: I don't believe the ICMP tunnel upload is constant but rather only occurs when the referred processes start. Or when they start is when the tunnel is established. What I do know is detecting an ICMP tunnel is extremely difficult since most firewalls allow outbound echo request traffic and the process that is doing it is System.

 

Don't call me man. I'm just trying to suggest an up to date app which basically does the same thing.
I, similar to OverDivine, never blocked an update in my life, and have no clue about these things.