Weirdness with Office 2013 opening Network Files

We had a client with document open problems. They can open up Word/Excel/PowerPoint from a document attached to an email by either clicking on it or saving to their desktop and then double clicking BUT if they double clicked on a network file it opens up a Blank Document dialogue (the standard Word/Excel dialogue when you just open up the program).

We tried repair of Office (both Quick and Full – and even re-licensed Office) without success. We tried resetting the the file associations – with no luck. We did a compare of local Word settings to the clients (luckily the same version) but still no luck.

What we then did on a computer that worked was the capture the actual command (via PROCMON) that gets used when we double click on a document to open it up:

"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "<<documentname>>"

So, we then did this on the client’s computer. In order to save a bit of typing we decided to take a local copy of the document to C:\temp\ so we had:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "C:\Temp\Test Document.docx"

as the command to open up Word with that document.

Bizarrely it worked! So, we then decided to open up the document from the S: (shared) drive and that failed (well, it started up two copies of Word – one that died and then the second one that opened up the Word start up screen):

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "S:\Administration\Test Document.docx"

We then decided to see if opening it up using the full path worked – and it did:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "\\SERVER\Shared\Test Document.docx"

So, we had “lucked in” and now had some more information to work with. This managed to get us via Google to the following article: Office docs from network drives won’t open, specifically:

Same problem here. Windows 2008R2, Office 2013 Standard after moving from Xen to VMWare virtualization. I just wanted to say that this problem is also affecting us, but as I was typing, our Admin called back.

He created a new account, which had never used Office 2013 before and that worked!

He then deleted then %APPDATA%\Local\Microsoft\Office folder from an account that didn’t work, after which Office claimed that the profile was corrupt, but then it started normally, regenerated the profile and he can now open the files.

It might be worth renaming this folder and seeing if that works for you.

So, we closed ALL Office programs and renamed the Office folder (we ran this as Administrator to ensure we could rename the file):

C:\Windows\system32>cd \users\TheUser\AppData\Local\Microsoft

C:\Users\TheUser\AppData\Local\Microsoft>ren Office Office.strange

C:\Users\TheUser\AppData\Local\Microsoft>

And then we tried that command again:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "U:\Administration\Test Document.docx"

And this time it worked!!!

Now, the client may have lost some settings/preferences – but at least he can now open up Word by double clicking.

Default SSH Key Found in Many Cisco Security Appliances | Threatpost

Many Cisco security appliances contain default, authorized SSH keys that can allow an attacker to connect to an appliance and take almost any action he chooses. The company said that all of its Web Security Virtual Appliances, Email Security Virtual Appliances, and Content Security Management Virtual Appliances are affected by the vulnerability.

This bug is about as serious as they come for enterprises. An attacker who is able to discover the default SSH key would have virtually free reign on vulnerable boxes, which, given Cisco’s market share and presence in the enterprise worldwide, is likely a high number. The default key apparently was inserted into the software for support reasons.

Source: Default SSH Key Found in Many Cisco Security Appliances | Threatpost | The first stop for security news

SANS: https://isc.sans.edu/diary/Cisco+default+credentials+-+again!/19839

Samsung deliberately disabling Windows Update | Debugging and reverse engineering

TL; DR

If you have installed Samsung’s SW Update software then you MAY have Windows Update disabled EVEN AFTER the removal of Samsung’s SW Update software.

Check the Folder %ProgramData%\Samsung folder (usually C:\ProgramData\Samsung) and remove “Disable_Windowsupdate.exe“.  Also, check for any scheduled tasks that run this program.

Source: Debugging and reverse engineering: Samsung deliberately disabling Windows Update

[Update] more on the story here: http://venturebeat.com/2015/06/23/samsung-is-actively-disabling-windows-update-on-at-least-some-computers/

When Solid State Drives are not that solid | Milliseconds Matter

TL;DR
Broken SSDs with the Linux kernel (specifically Ubuntu 14.04) and TRIM support:

  • SAMSUNG MZ7WD480HCGM-00003
  • SAMSUNG MZ7GE480HMHP-00003
  • SAMSUNG MZ7GE240HMGR-00003
  • Samsung SSD 840 PRO Series
    recently blacklisted for 8-series blacklist
  • Samsung SSD 850 PRO 512GB
    recently blacklisted as 850 Pro and later in 8-series blacklist

Working SSDs:

  • Intel S3500
  • Intel S3700
  • Intel S3710

Source: When Solid State Drives are not that solid | Milliseconds Matter

Issues with updates on Centos6 – nss-softokn-freebl

You may be unable to update Centos via yum after installing the most recent updates. The issue is described in this article:

http://kiteplans.info/2015/01/15/solved-bug-centos-yum-rpm-broken-by-nss-softokn-3-14-3-19-el6_6-update-error-rpmts_hdrfromfdno-error-rpmdbnextiterator-header-v3-rsasha1-signature-key-id-bad/

What you will likely see if you attempt to do updates or certificate checks or even find out what packages are installed:

  1. You might see an email from the server telling you that the certwatch program (which checks for expired or expiring certificates) cannot run:

    /etc/cron.daily/certwatch:

    NSS_Init(“/etc/pki/nssdb”) failed

  2. Or you might see yum saying that it can’t update the nss-softokn-freebl library:

    An update to kpartx from 0.4.9-80.el6_6.1 to 0.4.9-80.el6_6.2 is needed.
    This update has been successfully installed.

    An update to nss-softokn from 3.14.3-18.el6_6 to 3.14.3-19.el6_6 is needed.
    This update has been successfully installed.

    An update to nss-softokn-freebl from 3.14.3-18.el6_6 to 3.14.3-19.el6_6 is needed.
    However, this update could not be installed! Try the update manually
    using the Package Updates module.

  3. Or you might see yum giving this error:

    yum update
    Loaded plugins: fastestmirror
    Setting up Update Process
    Loading mirror speeds from cached hostfile
    Resolving Dependencies
    –> Running transaction check
    —> Package nss-softokn-freebl.x86_64 0:3.14.3-18.el6_6 will be updated
    —> Package nss-softokn-freebl.x86_64 0:3.14.3-19.el6_6 will be an update
    –> Finished Dependency ResolutionDependencies Resolved

    ================================================================================
    Package                 Arch        Version                 Repository    Size
    ================================================================================
    Updating:
    nss-softokn-freebl      x86_64      3.14.3-19.el6_6         updates      166 k

    Transaction Summary
    ================================================================================
    Upgrade       1 Package(s)

    Total size: 166 k
    Is this ok [y/N]: y
    Downloading Packages:
    error: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
    Problem opening package nss-softokn-freebl-3.14.3-19.el6_6.x86_64.rpm

  4. Or, if you run this command rpm –qa, you will see errors like these:

    error: rpmdbNextIterator: skipping h#     514 Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
    error: rpmdbNextIterator: skipping h#       4 Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
    error: rpmdbNextIterator: skipping h#     518 Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
    error: rpmdbNextIterator: skipping h#     263 Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
    error: rpmdbNextIterator: skipping h#       8 Header V3 RSA/SHA256 Signature, key ID c105b9de: BAD

So, in all of these cases it looks like the RPM database (that holds all the details of what has been installed, what they contain, etc.) is corrupt – when in reality the nss-softokn-freebl library that we are trying to install is the wrong version – simply because they did not get installed AT THE SAME TIME as the nss-softokn libraries.  The Centos guys SHOULD HAVE set a dependency from nss-softokn to nss-softokn-freebl – but they forgot to do that and hence we have this issue.

Simple fix (NOTE: the following commands are for 64 bit versions of Centos):

Login as root (you may need to sudo bash to start up a shell as root if you use a USER login):

cd /root
wget  http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/nss-softokn-freebl-3.14.3-19.el6_6.x86_64.rpm
rpm2cpio nss-softokn-freebl-3.14.3-19.el6_6.x86_64.rpm | cpio -idmv
cp ./lib64/libfreeblpriv3.* /lib64
yum update

(hopefully the last step will work and fix up the yum & rpm databases).

Hope this helps others out with the updates.

Some 100,000 or more WordPress sites infected by mysterious malware | Ars Technica

More than 100,000 websites running on WordPress content management system have been found to be infected with malware that attacks the devices of site visitors. Google has blacklisted more than 11,000 domains. Reports suggest that the attackers exploited a vulnerability in the Slider Revolution Premium plug-in, which the company has known about since September 2014.

Moral of the story: Install WordFence and keep as up to date as possible with the WordPress plug-ins.

Some 100,000 or more WordPress sites infected by mysterious malware | Ars Technica.

WordPress 4.0.1 – Critical WordPress XSS Update| InfoSec Handlers Diary Blog

Today, WordPress 4.0.1 was released, which addresses a critical XSS vulnerability (among other vulnerabilities). [1]

The XSS vulnerability deserves a bit more attention, as it is an all too common problem, and often underestimated. First of all, why is XSS “Critical”? It doesn’t allow direct data access like SQL Injection, and it doesn’t allow code execution on the server. Or does it?

XSS does allow an attacker to modify the HTML of the site. With that, the attacker can easily modify form tags (think about the login form, changing the URL it submits it’s data to) or the attacker could use XMLHTTPRequest to conduct CSRF without being limited by same origin policy. The attacker will know what you type, and will be able to change what you type, so in short: The attacker is in full control. This is why XSS is happening.

The particular issue here was that WordPress allows some limited HTML tags in comments. This is always a very dangerous undertaking. The word press developers did attempt to implement the necessary safeguards. Only certain tags are allowed, and even for these tags, the code checked for unsafe attributes. Sadly, this check wasn’t done quite right. Remember that browsers will also parse somewhat malformed HTML just fine.

InfoSec Handlers Diary Blog – Critical WordPress XSS Update.