Attacks against WordPress 4.7 or 4.7.1 are still increasing.

   Still increasing. Do updating you WordPress ASAP. I read some articles and also got an email about this from my ISP. So I’m writing this.

   I talked about this with くりくりさん on Twitter. I first mentioned it on February 6. It was because of my finding a 徳丸’s post, “WordPress 4.7.1 の権限昇格脆弱性について検証した”.

   Yesterday, Security Next told us some IP addresses about attackers. I checked up on my log last night. I found an access from one of questionable IP addresses, which was on February 6. It caused 500 error on my server. Maybe because my WordPress was already version 4.7.2 at this point.
   Its user-agent is python-requests/2.11.1 and its destination is /wp-json/wp/v2/posts/.

   WordPress 4.7.2 was released more than a week ago, and WordPress has an auto-update feature enabled by default, along with an easy manual update process. Despite this, this situation. It’s indeed disappointing.

Memorandum #16.

   Steffen released a new version of Apache 2.4.18 which was built with OpenSSL 1.0.2f on February 11, so I updated my web server Apache to it on the day before yesterday. Its ChangeLog says it was built with nghttp2 1.5.0, however, Steffen already gave nghttp2 1.6.0(MSVC release) though nghttp2’s releases are like a waterfall. You should use it at least instead of nghttp2 1.5.0. The ChangeLog of nghttp2 1.6.0. You can download mod_http2 1.1.0 & nghttp2 1.6.0 from here. If you install Apache2.4.x at the first time, see “To create a Wamp-like Web Server in Windows7-#1”. Now I use a VC14 version of Apache which requires VC14. Continue reading “Memorandum #16.”

Updating Apache because of CVE-2015-1793.

   I updated my Apache 2.4.12( to 2015 Jul 9 version because of Alternative chains certificate forgery (CVE-2015-1793).

   It is built with ‘IPv6 Crypto apr-1.5.1 apr-util-1.5.4 apr-iconv-1.2.1 openssl-1.0.2d zlib-1.2.8 pcre-8.37 libxml2-2.9.2 lua-5.1.5 expat-2.1.0′. Its Changelog.
   This version is also built with the latest Windows® Visual Studio C++ 2015 RC aka VC14. I began to use VC14 version on June 2 due to OpenSSL 1.0.2. If you use the version, you need to install vc_redist_x64/86.exe before installing the version.

   I really appreciate Steffen’s hard and quick work. Thanks again, Steffen.

   By the way, I take this occasion to update to phpMyAdmin 4.4.11 and MariaDB 10.0.20.

   About phpMyAdmin I noticed two differences. From the version 4.4.10 the download URL changed from to And this version, I mean 4.4.11, they provide not only MD5/SHA1 but PGP. I wonder if something happened between sourceforge and phpmyadmin.

Yesterday, FireFox 39.0 came.

   Yesterday, FireFox 39.0 came by automatic update.

   Now FireFox deploys fixes for the Logjam attack really. You can see what vulnerabilities are fixed in 39.0 ⇒ Fixed in Firefox 39.

   As you know, they fix a lot of vulnerabilities in each version. So you must keep your web browser up-to-date status. Well, this is not for web browsers only (^^;).

Although belated, about Logjam.

Update information      Edit   Edit2(Jul.7)   Edit3(Sep.2)

   Yesterday, I came home around 8 pm and saw the first fireflies of this year in my garden. Wow!

Server Test1   By the way, I read the article “TLSに脆弱性「Logjam」 – 国家レベルなら1024ビットまで盗聴可能” on May 21. Then I went to Guide to Deploying Diffie-Hellman for TLS and did Server Test. I got the result like the right image. Before the test, despite I didn’t do anything else more than I had done until 2014.Oct.28 (= A self-sighed certificate with SANs and SHA256 by OpenSSL).

   And that night, I had a comment from くりくりさん on my Japanese blog. He let me know about Logjam. I wrote back him that I tried writing about Logjam and I’m writing it now, ha-ha.

   When I tested my server at the first time, the server supported the following Cipher Suites.


   But actually I don’t need most of them. Because the user of my SSL server is only me and I usually use the latest version Web Browsers as I always say. I only use ECDHE-RSA-AES128-GCM-SHA256 suite at my access. So I changed SSLCipherSuite directive on my ssl.conf like this.
   SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256
   This configuration is not useful for other servers. If you want to know a realistic configuration, see Guide to Deploying Diffie-Hellman for TLS. If your server is in newer versions of Apache (2.4.8 and newer) and OpenSSL 1.0.2 or later, you can directly specify your DH params file. But even if your server isn’t, you can use SSLCipherSuite and SSLProtocol instead of SSLOpenSSLConfCmd and can make your server safe from Logjam attack.

Sever Test2   Actually, ApacheLounge version HTTPD is still built with OpenSSL 1.0.1 branch. So I could not use SSLOpenSSLConfCmd directive. But after changing my SSLCipherSuite, I got the result like right image.

Another Test   Another Logjam Attack Checker gave me the right result.

   In addition, when using Apache 2.4 with OpenSSL 1.0.1 and later, SSLProtocol all means +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2. When using Apache 2.4.7 or later, aNULL, eNULL and EXP ciphers are always disabled.

   According to the The Logjam Attack page, Google Chrome (including Android Browser), Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari are all deploying fixes for the Logjam attack. But still now (9:45 am JST), I have Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser when I access the page by FireFox 38.0.1, Google Chrome 43.0.2357.65 or SeaMonkey 2.33.1. Only Internet Explorer 11.0.19 gives Good News! Your browser is safe against the Logjam attack.
Note) I don’t check this with other browsers and versions.

   Yesterday, FireFox 39.0 came. Now I have Good News! Your browser is safe against the Logjam attack by it.

   I’ve not checked it for a while. Today, Google Chrome ver. 45.0.2454.85 has come, so I check just now. The site gives Good News! Your browser is safe against the Logjam attack. When was Chrome deploying fixes for it? I have no idea!!

   Now 1:00a.m. SeaMonkey’s new version 2.35 has come after long interval. And, I’ve finally had Good News! Your browser is safe against the Logjam attack by it.

I remove Google AdSense until Adobe Flash Player new version coming.

Update information      Edit(Feb.5)    Edit2(Feb.7)

   Hey guys! I remove Google AdSense until Adobe Flash Player new version coming. Google AdSense is nothing wrong. But it sometimes includes bad sites. At this time, I mean until CVE-2015-0313 fixed, it might have a site which is infected hxxp://, Trend Micro calls it SWF_EXPLOIT.MJST. This bad swf spreads rapidly through popular sites, for example, Dailymotion, etc.

   When Adobe Flash Player new version reaches to us, I’ll restore Google AdSense to my sites. m(_”_)m

   Hi, they released Adobe Flash Player new version. Now (16:00JST), I’ve confirmed I have the new version on my IE, FireFox and Google Chrome. I strongly recommend everybody updates to the new version immediately.

   I’ll restore Google AdSense to my sites within a few days.

   Google AdSense has been restored.

ShellShock, shock shock shock!

Update information      Edit(Sep.30)    Edit2(Oct.6)

   Have you coped with the threat from ShellShock, yet? My server is on Windows OS. Hence I think the vulnerability gives no effect to mine. But it’s a very serious one. NVD gave the impact score 10 to this. I have a CentOS 6.5 on my VMware, so I updated its bash to bash-4.1.2-15.el6_5.2.i686.

   If you still have the following messages after updating and doing env x='() { :;}; echo
vulnerable' bash -c "echo this is a test"
, your bash need more updating.
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test

   I got the information form Masanari Iida’s comment on Red Hat Customer Portal.

   Several links which I am curious about, actually tons of articles about it on the Internet:

   By the way, I had the ShellShock attacks six times and blocked their IPs until yesterday, and today two more from other IPs until now on the Apache error log. I found that all of them my Apache returned HTTP Error Codes to.

   On “Bash bug: apply Florian’s patch now” he said “I very strongly recommend manually deploying Florian’s patch unless your distro is already shipping it.” and how to check the patch applied or not.

   When you do foo='() { echo not patched; }' bash -c foo within the shell, the patch is already applied if you have “command not found”. If you have “not patched”, your bash is still vulnerable.

   On its comment vdp wrote “These ‘toughen the feature’ patches still feel quite scary.” and a suggestion. I agree with him.

   Today, I’ve found this (Japanese).

   It says that it’s not enough to check the bash by the code foo='() { echo not patched; }'
bash -c foo
. Nonetheless, they have less critical than CVE-2014-6271 or CVE-2014-7169. But still dangerous.