Search options (Page 1 of 64)

This issue is also relevant to those that use XPMode as well, BTW.
Perhaps we could refer to a statement (by perhaps number one fear-monger :lol):

Microsoft wrote:

"Important

    As of April 8, 2014, technical support for Windows XP and Windows XP Mode is no longer available, including updates that help protect your PC. This means that if you continue to use Windows XP or use Windows XP Mode on a Windows 7 PC after support ends, your PC might become more vulnerable to security risks and viruses. Therefore, to keep your Windows 7 PC secure after support ends, we recommend that you only use Windows XP Mode if your PC is disconnected from the Internet."

     quoted from:  http://windows.microsoft.com/en-us/wind … -windows-7

Here are some more aspects:

ChrisH wrote:

"I have XP-specific applications that won't run under wine or any later windows, as well as some windows-only applications, so for me an XP VM is an absolute requirement, which I've given some thought to.

You are at risk, but you can bring the risk down to an acceptable level by:

    1. Not browsing in the VM - do that in the host, copy files across as required.
    2. If there's some bizarre reason why you really must browse in the guest, throw all the browser-based security you can at it (strict noscript etc.) and only for the sites you really have to (and see item 4.).
    3. Cutting out all non-essential services from XP (especially network-related ones, but note that networking is used to share folders to the host.
    4. Running your VM from a file system that appears to be called immutable in the docs - it's reset to the starting conditions on shutdown. I asked about this here.
    5. or running still-supported security software on the guest (it's no use if you can't keep it up-to-date, which you can't if loads from immutable storage).
    6. Firewalling the VM on the host (which I haven't done properly yet, so can't go into more detail, but basically close all the ports to start with)."

     quoted from Apr 30 at 15:43:  http://askubuntu.com/questions/458306/v … e-browsing

Here is one possible reason for recommending a linux VM.  That is, the very nature of not only the OS, yet some of the malware itself.

Joshua Cannell wrote:

"It’s not uncommon for the malware of today to include some type of built-in virtual machine detection."

     quoted from:  http://blog.malwarebytes.org/intelligen … detection/

Joshua Cannell wrote:

"It’s not so much what it can do, rather, it doesn’t want to do anything. Since average PC users don’t run their OS within a VM, it’s suspicious to be running in a virtual environment from the malware’s standpoint, as it drastically increases the likelihood that’s being analyzed and/or reverse engineered. This is something the malware’s creator wants to prevent."

     quoted from:  http://blog.malwarebytes.org/intelligen … mment-5861

Of course, that doesn't preclude infection, just further aberrant behavior for the most part.
Virtual machine hosts can be vulnerable, even linux hosts.

ggalaxy wrote:

"A successful attack from Windows users will be as follows ;
    * You installed wine application in ubuntu
    * you forget to configure UFW (the firewall)
    * you unintentionally clicked on a malware link from your win xp virtual box
    * you opened ports and didn't secure them
. In your case, you are going to install WINDOWS XP in Virtual box, and VBox will create a disk image which will be impossible for users to get outside the disk image and mess with your Ubuntu, however, if you have wine in your ubuntu, and wrongly clicked a malware link from your Win XP virtual box, that will lead the attacker to your ubuntu and execute commands and harm your computer."

     quoted from Jan 9 at 20:21:  http://askubuntu.com/questions/403079/i … for-ubuntu

Apologies for not expanding upon security in VMWare.  Am hoping more people will offer insight.

Then again, there's the whole current flawed trust model.

Moxie Marlinspike wrote:

"Essentially, at some point a decision was made to anchor trust in an organization like Comodo, and now we’re locked into trusting them — forever."

     quoted from:  http://www.thoughtcrime.org/blog/ssl-an … henticity/

Dan Goodin wrote:

"Of 3.45 million real-world connections made to Facebook servers using the transport layer security (TLS) or secure sockets layer protocols, 6,845, or about 0.2 percent of them, were established using forged certificates. The vast majority of unauthorized credentials were presented to computers running antivirus programs from companies including Bitdefender, Eset, and others. Commercial firewall and network security appliances were the second most common source of forged certificates."

     quoted from:  http://arstechnica.com/security/2014/05 … tificates/

Few do think of updating those RootCerts & getting the current revocation update.  The RootCerts package is only an optional update for the masses, and curiously hasn't seen an update since before the HeartBleed revelation.

How long ago did schannel.dll (TLS/SSL) see an update?
  The latest i see for w2k is v5.1.2195.6960 from Apr 8, 2005.  That must be vulnerable in so many ways.
  The latest for xp is v5.1.2600.6370 from Mar 28, 2013, so that should be OK for at least a little while.  That seems to indicate pro-activity on MS's part.
  2k3's latest is v5.2.3790.5014 from June 4, 2012.  Curious that the supported OS has the older implementation, unless i have miscalculated the latest update for 2k3.  (25000 Servers a day need 2k3 updated before July of next year???)

  Is that the revision of schannel.dll in XPMode?

"Secure channel (aka SChannel) - Introduced in Windows 2000 and updated in Windows Vista to support stronger AES encryption and ECC [6] This provider uses SSL/TLS records to encrypt data payloads. (schannel.dll)"

     quoted from:  url=https://en.wikipedia.org/wiki/Secur … _Interface

  XP lacks support for stronger AES encryption and ECC?  I think the availability of something like P-521 or greater is something that should be available in today's day & age (especially in light of recent WPA2 vulnerabilities - recommendations of usage of greater complexity encryption at minimum.
There is an update for 2k3 to support AES256-SHA at least.  https://support.microsoft.com/kb/948963
  Perhaps one approach would be to disable support for the lowest and least secure ciphers.  See http://support.microsoft.com/kb/245030.  Those could go into the changelog.

Anyway, how should an advisory read (perhaps in addition to "* use at your own risk *" in networking packs) ?     
  "Avoid networking entirely on Win2000 unless it is a private wired and isolated network.  XP/2k3 will eventually and not necessarily in succession receive the same recommendation."???

  Check the changelogs and see if you disagree moderately to vehemently against any statement within, please.

Integrating official updates into one's source does seem like another proactive approach.  Of course, that is a whole other kettle of fish.
  There are some recent KB updates for xp that so-far seemingly have improved usb stability/performance from textmode on.
  Wouldn't integrating KB network files & related inbuilt protocols/drivers, etc. offer one less flaws and greater stability than what is stock for XPMode?  (What is stock in a XPMode distro?  I don't know.)

Ooo, XP sees another update, one for SilverLight --> http://www.microsoft.com/en-us/download … x?id=42250
  Just as well --> http://arstechnica.com/security/2014/05 … -the-rise/

OK; thanks for reminding me about the first post.  Will decorate the changelogs and get that up.  No wonder that one seems so popular.  d'oh.      :u

CAPICOM is not preferred at all.

The MMC.exe snap-in for "IP Security Policies" allows one to enable PFS (as referenced in the Robert Love article above, iirc.) for kerberos.  It looks like it might be possible to restrict further unsecured and other insecure communication, but i'm so far uncertain the entire affected (mountain) range.

Disabling DES seems wise, though i see no option for adding TLS there (Bummer)  Disabling MD4 hashing there seems relevant too.
.  Kerberos is therefore best limited to 3DES, unless somebody has other ideas.

Is kerberos used for Windows Update?  Would PFS be supported on the other end of the connection?

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

Of course, WiFi drivers & other browsers may have their own security routines, and may or may not be affected by any of the aforementioned registry goodies.
    (FireFox/IceWeasel/etc-about:config-Security.TLS.VersionMinimum="1" = KB3009008)

There is also a (lite) OpenSSL package available as a Windows port

See MicrosoftFixit50588 for MS-CSSP via KB951608 info concerning the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 is definately worthy of a gander (even if you are not from Newfoundland), imho (rotflmao).

The AutoPatcher community has some AAA-rated registry tweaks of their own, by the bye.
Lsa-LMhash/disallowAnonymous/AddLocalComputerToIEzones/etc/etc

Hasn't mdgx got some noteworthies as well?

Note that 5eraph's specific SA3009008 solution appears incomplete at best, and perhaps even erroneous.
Look at the last two lines of that post, where TLS 1.0 is "enabled" with a 0x01.  That is apparently incorrect.

Microsoft wrote:

"To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff. Or, change the DWORD data to 0x0. If you do not configure the Enabled value, the default is enabled."
     http://support.microsoft.com/kb/245030   see also:  http://support.microsoft.com/kb/187498 & http://support.microsoft.com/kb/811833

Is this not also true for protocols?

Hermann Wolf wrote:

"I also added the key SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56 with Enabled=1 and rebooted again bit the SSLScan.exe output is always the same"
     http://forums.iis.net/t/1187790.aspx

What of the value ""DisabledByDefault"=dword:00000001"?  I don't know which takes precedence.  RC4 128/128 disabling/undo should be included.  Win2k & 2k3 solutions are also missing thusfar.  Can AES work on XP?

  It does highlight the dire need for confirmation via testing.
There is a program that will test supported ciphers (except TLS 1.1 & 1.2).
  http://code.google.com/p/sslscan-win/
Here is some sample output, thanks to Wayne Zimmerman --> http://www.waynezim.com/2011/03/how-to- … rs-in-iis/

  Are there any UpdatePacks that include the full set of solutions?  I haven't seen any so far.  Correct me if i am wrong, please.

Outbreaker wrote:

... "people won't be able to connect to outdated HTTPS servers."

That is apparently actively being encouraged for servers.

Robert Love wrote:

"I advocate disabling SSLv3 support, which breaks Internet Explorer 6 on Windows XP, but prevents a downgrade attack for everyone else. If we're willing to drop support for all versions of Internet Explorer on Windows XP (Which likely just means the addition of IE 7 and 8), we can accomplish two other goals:
     http://blog.rlove.org/2014/04/the-end-o … p-and.html

  Also see:  http://blog.rlove.org/2013/12/strong-ssl-crypto.html

It's a bit of a sticky wicket, and it seems better to include it here as optional, as nobody other than 5eraph seems to have included any solution for NT5.
  I like to be able to confirm that the NULL cipher cannot be used with TLS 1.0 for instance, in my humble opinion.
  SSLScan seems to make that verification a little easier too.

Actually, as far as download is concerned,
  v1.0 is available here, in the LAN pack:
    --> http://forum.driverpacks.net/viewtopic. … 473#p58473 
  v2.0 to follow ...

Note:  there is no undo file for Harden_XP_TCPIP_Stack_by_GH0st.reg