Interesting read. On thing i do not understand is why software updates/packages are still not cryptographically signed. It's a common thing on Linux. Notepad++ provides checksums[0] for their packages - so (i assume) they are actually aware of the problem.
Sure, but if you're MITMing DNS, you just serve a copy of the Notepad++ download page (or whatever) whose listed checksum matches that of your backdoored executable, so that's not a problem in this scenario.
Thats exactly what i mean - checksums are useless in this scenario. They should have been signed with a key your computer knows. (Retrieved before the first install)
Oh, I see what you mean. I wish I saw a way for that to happen in the Windows ecosystem, although I suppose the "Windows Store" might drive evolution in that direction.
Many applications will require signed updates, but considering how much software the average person has on their computer (especially a tech geek), odds are at least one will upgrade over regular HTTP.
It's common on Linux because they use package managers where you only have to implement that functionality once. Every PoS app on Windows and OSX has its own update process, which mostly is just downloading and running the new setup binary.
This happens even with software where you would think the manufacturer is aware of this kind of problem. 1Password downloaded updates over HTTP for a long time, then switched to HTTPS and failed to check certificates. When they finally started to check if binaries are signed (Windows provides for that), they didn't change keys so you could downgrade to a previous version that didn't. That is just one application.
> Every PoS app on Windows and OSX has its own update process, which mostly is just downloading and running the new setup binary.
Most OS X apps use either the Mac App Store, which signs everything, or Sparkle[0], which last time I used it made it really hard to use it without signing things. It's only stuff from big vendors like Adobe and Microsoft who do custom stuff you can't really trust.
Yes, they should. I'd be curious to hear more details about that.
I'd also like to know what domain was used for phishing, since you would think an infosec guy would either hover over the button/link before clicking, or get suspicious when he sees his browser load a site that isn't linkedin.com before redirecting.
The problem with most phishing emails are that they suck - they don't even pass a cursory smell test. A linkedin from someone I know who I'm not already connected with (not too hard to figure out potential connections especially if you've worked for small companies), worded exactly like a linked in email only changing the accept button link? Odds are I'd click and not look at the link target.
But the attacker didn't yet control the DNS when he sent the link to the exploit; he needed the exploit in order to compromise the router and put the DNS hijack in place. So I'm not sure how the hell it worked.
That's an excellent question, especially since LinkedIn publishes an SPF record specifying both the IP ranges and the second-level domain name of legitimate MXes for its mail; prior to the DNS hijack, I'm not sure how it would be possible to carry out the phishing attack without giving any hint of foul play. (I do implicitly assume such hints would've stopped the target from clicking the bogus link, but given the way he's described in the article, I think that's not too unreasonable an assumption.)
SPF only checks the message envelope. His target's email provider may not correlate the MAIL FROM statement in the envelope with the From header inside of the message content. Some large webmail providers will use this mismatch as a cue to send a file to the spam folder.
Delivering a targeted phish requires situational awareness, but it's quite feasible to pull off something convincing.
I find it hard to believe that an infosec professional would click a link in an email. Anybody who has ever run an phishing campaign as part of a pentest wouldn't. I only moonlight in the infosec industry, but I know that the Right Thing, upon receiving an unsolicited notification email from a website ("Friend" request, LinkedIn connection requests, "Track a package", etc) is to visit the site in your browser manually, versus clicking some link in an email that could likely be bogus.
Do you think configuring OS for your router manually would leave less chance for it to be broken? I suspect I'd leave more holes setting up all the stuff myself, than relying on MikroTik folks knowledge.
Besides, are there some step-by-step guides/checklists that would help build secure environment for your router/PC?
I should probably say that I have a dislike of (and am biased against) MikroTik because of their disregard of the GPL. For the price, though, I think the hardware is generally pretty decent.
Anyway, I don't feel real confident in the security of the RouterOS software although I don't have any hard or articulable reasons for that. It's just a "gut feeling", I suppose.
I do have much more confidence in both OpenWRT and FreeBSD. If you're just using the device as a home router/firewall, you don't really need many (if any) daemons running and exposed so the attack surface is pretty minimalized. My own router at home came with RouterOS on it (although it's not MikroTik hardware) but I replaced it with OpenBSD.
I've seen MikroTik router mentioned on HN quite few times, and have been wondering how is it better compared to say, Broadcom-based routers running OpenWRT/Tomato/DD-WRT. Could you clarify why? (I've looked at RB750GL, which looks very interesting considering its price, but still don't know how would compared to my current ASUS RT-N16+Tomato setup.)
In my experience, SPF has never lived up to it's promised and it's just one of many factors to create a spam/ham score. There are just too many SPF issues with many mail address to use SPF alone to filter an otherwise normally looking mail.
Did he say he was on gmail? Maybe I didn't catch that part.
That's an interesting decision for a security-minded person to make though. Do I use gmail as they'll have broad statistical analysis of attack vectors? Or do I use my own mail server which may not have the same features, but is more secure/private in other ways?
Well, I was all set to explain that SPF only checks the envelope sender, not the from: address header that is displayed to the user.
Then I decided to test it, and in fact Gmail does seem to be doing more than that. I ran a two-line script as root from my mail server to send a message with an envelope-sender from my domain (which has a basic SPF txt record in its DNS) and a from: header from LinkedIn, and Gmail spit it back at my return address a moment later saying that it smelled like spam. So, good for Gmail!
But, I don't think this is common behavior, and the article doesn't actually say that the target has a Gmail account.
It pretty much is. The actual settings vary between different mail providers and this is actually more complicated than checking header against sender IP. So everything is possible, but that mail-sending part needs more explanation anyway.
Sure - SPF may very well only check the envelope sender, but isn't that usually plenty? If you can't spoof the Linkedin envelope sender, and the mail goes to SPAM, who cares if the From: address is spoofed? The user likely won't see it anyway.
Ah, gotcha. You're saying that you sent an email with a valid envelope sender from your domain, with only a spoofed From: address, and gmail sent it back. If so, nice!
Plenty of other ways to catch even the security aware. The obvious, since he knows this person, would be to tweet some 'news link' and have the code only work for Bill. You can be security aware and not be perfect 100% of the time.
In the comments section of the original article, the attacker (Phikshun) notes that he worked at the same company as his victim, so he was able to test the phish on himself to make sure it passed through that company's email security.
He addresses this in the comments of the article[0]:
>Aaron says:
>April 5, 2014 at 3:52 pm
>So how’d you sucker Bill into clicking your exploit link? Since you hadn’t yet hijacked his DNS, I presume the link didn’t (couldn’t) actually point to linkedin.>com — shouldn’t his mail client have warned him? (Mine would.)
>>Reply
>>Phikshun says:
>>April 5, 2014 at 5:35 pm
>>See this video by Raphael Mudge[1]. He does a much better job of explaining it than I would. I also had another advantage — Bill and I worked for the same company at the >>time, so I could send the phish to myself to make sure it passed all the filters. This isn't so unrealistic though. An advanced adversary will scour RFPs, public records and >>job postings to learn what protection technologies a company has and attempt to duplicate their environment for testing.
Perhaps someone could comment on the possible prison time if an approach like this was taken without the authorization that this person had in advance?
Also it would seem that it would be fairly easy if you are in physical proximity to the target to use social engineering (as opposed to a bump key - opening the front door) to gain physical access to the premises and find the wifi password right under the router. Or plant something on the network that gives you access - you get the picture. Or plant a keylogger that might not be noticed for months. Or drop a USB key (wouldn't work with an infosec guy but maybe if it was mailed to him and it looked like it came from a reliable source it would).
One more reason to use NoScript - it would have made the CSRF significantly harder to pull off. And a reason to use an OS with a proper package manager, of course ;)
Nah, you just set target="iframe name" on the form and post into a (hidden) iframe. Then in 2 seconds you redirect to LinkedIn. In my experience, getting clicks from targets is easy. One simple way is to show a page with a single link that just says "Redirecting". After a moment most users will just click the link.
I don't know about the vulnerabilities in the Time Capsule router, but from my understanding the only router firmware even remotely worth a look in terms of security would be OpenWRT.
Curious how the author knew to seed the backdoor'ed Notepad++ before Bill clicked the link?
I suppose you could just serve up a fake backdoor program for every *.exe\msi download, and remove the honeypot on the second download? The first download would execute and maybe do nothing (or error) - prompting a second download which led to the real thing.
In the article, he mentions using Evilgrade to do the backdooring. If you click though the link, you can find the README, which lists a bunch of applications that Evilgrade supports seeding backdoored versions of http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt
He likely just enabled them all, or at least enabled several which are likely candidates for his target to download.
Ubiquiti AirRouter or AirRouter HP. Almost all Ubiquiti gear works completely transparently with OpenWRT, out of the box. In fact their stock firmware is built on top of OpenWRT.
Just wanted to thank you for the recommendation. New AirRouter is working great. I even set the power level down because I have pretty good connection everywhere in the house.
Maybe some NetSec guys could answer this please. What would happen with his update to Notepad++? Would it still update the package?
Even if the target set his computer to auto-update (or something that did not require admin authentication), wouldn't he have some type of notion that something went wrong during his update?
With the target being an InfoSec guy, I would've imagined he would at least be running some type of network monitoring, like wireshark or little snitch, ESP on his personal computer. Wouldn't he have to authorize the outgoing packets?
Sorry, if I come off analytical to the story...it's a great read...I just want to make sure my networks are locked down. I've even went as far as dedicated networks for my server and home usage, and preventing internal ip addresses from communicating to each other (sucks for airplay).
Wouldn't he have some type of notion that something went wrong during his update?
There is a way of injecting your code into an existing executable so that the executable still works like it did before. Basically your code gets called first and than the original program entry point gets called.
Wouldn't he have to authorize the outgoing packets?
He might have updated this Notepad++ on purpose? He obviously did not know his router was compromised.
Thank you. You helped me realized that even if the target had wireshark or little snitch, the router was acting as the MITM since the packets would piggyback on outgoing requests that appeared normal cause of the router's DNS settings.
I was trying to figure out how he had the key logger sending out it's packets.
> There is a way of injecting your code into an existing executable so that the executable still works like it did before.
Only if it's unsigned (or someone doesn't check the signatures) and it's over HTTP. I can't seem to find it, but someone complained about just how hard it is to get a version of putty that you can at least be sure came from the right domain.
"It took about a week before Bill decided to upgrade notepad++ to the new version."
Which is why I'm always wary of installing unsigned software. In such cases I try to check some hashes some way. Obviously if the download page lists them I check against those, but in most cases it's insufficient because that page is not HTTPS. So I always help myself with google, both by googling the filename to find some pages listing a hash, and by googling my own hash (note that Google is accessed with HTTPS).
I didn't understand which hashes you are talking about. Do installs usually provide a checksum or? I have not found any that do, or maybe I just ignore it.
The hashes of downloaded files, computed locally. E.g. with 'sha1sum' command or Microsoft's 'fciv'.
Suppose I download Putty and am unsure of whether it's the real thing or whether it's a Trojan, e.g. due to someone having hacked my router. I compute the hash of the file and google it: http://lmgtfy.com/?q=44ac2504a02af84ee142adaa3ea70b868185906... . I find many sites saying that's putty.exe. If I didn't, I'd be very suspicious.
I don't know about this specific bug, but there have been consumer routers bugs before (Netgear specifically) where not only were they vulnerable to CSRF, but authentication bypass at the same time if the request was crafted carefully.
Not really. Control of the router (of the kind he describes) can set up routing in such a way that it still goes to system under his control. It's easiest if he can get a shell with access to (e.g.) iptables, but even without a shell, it's possible to set up routing to do that.
95 comments
[ 2.8 ms ] story [ 164 ms ] thread[0] http://sourceforge.net/p/notepad-plus/discussion/1290588
http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authe...
The problem is that it doesn't help users any, the only way to stop them is to take control of the system away and it doesn't go that far.
And that's all an attacker needs.
This happens even with software where you would think the manufacturer is aware of this kind of problem. 1Password downloaded updates over HTTP for a long time, then switched to HTTPS and failed to check certificates. When they finally started to check if binaries are signed (Windows provides for that), they didn't change keys so you could downgrade to a previous version that didn't. That is just one application.
Most OS X apps use either the Mac App Store, which signs everything, or Sparkle[0], which last time I used it made it really hard to use it without signing things. It's only stuff from big vendors like Adobe and Microsoft who do custom stuff you can't really trust.
[0] http://sparkle.andymatuschak.org
I'd also like to know what domain was used for phishing, since you would think an infosec guy would either hover over the button/link before clicking, or get suspicious when he sees his browser load a site that isn't linkedin.com before redirecting.
Edit: Ignore it, I forgot he didn't control the DNS at that point. So this is invalid.
Delivering a targeted phish requires situational awareness, but it's quite feasible to pull off something convincing.
http://blog.strategiccyber.com/2013/10/03/email-delivery-wha...
Besides, are there some step-by-step guides/checklists that would help build secure environment for your router/PC?
Anyway, I don't feel real confident in the security of the RouterOS software although I don't have any hard or articulable reasons for that. It's just a "gut feeling", I suppose.
I do have much more confidence in both OpenWRT and FreeBSD. If you're just using the device as a home router/firewall, you don't really need many (if any) daemons running and exposed so the attack surface is pretty minimalized. My own router at home came with RouterOS on it (although it's not MikroTik hardware) but I replaced it with OpenBSD.
That's an interesting decision for a security-minded person to make though. Do I use gmail as they'll have broad statistical analysis of attack vectors? Or do I use my own mail server which may not have the same features, but is more secure/private in other ways?
Then I decided to test it, and in fact Gmail does seem to be doing more than that. I ran a two-line script as root from my mail server to send a message with an envelope-sender from my domain (which has a basic SPF txt record in its DNS) and a from: header from LinkedIn, and Gmail spit it back at my return address a moment later saying that it smelled like spam. So, good for Gmail!
But, I don't think this is common behavior, and the article doesn't actually say that the target has a Gmail account.
It pretty much is. The actual settings vary between different mail providers and this is actually more complicated than checking header against sender IP. So everything is possible, but that mail-sending part needs more explanation anyway.
>Aaron says:
>April 5, 2014 at 3:52 pm
>So how’d you sucker Bill into clicking your exploit link? Since you hadn’t yet hijacked his DNS, I presume the link didn’t (couldn’t) actually point to linkedin.>com — shouldn’t his mail client have warned him? (Mine would.)
>>Reply
>>Phikshun says:
>>April 5, 2014 at 5:35 pm
>>See this video by Raphael Mudge[1]. He does a much better job of explaining it than I would. I also had another advantage — Bill and I worked for the same company at the >>time, so I could send the phish to myself to make sure it passed all the filters. This isn't so unrealistic though. An advanced adversary will scour RFPs, public records and >>job postings to learn what protection technologies a company has and attempt to duplicate their environment for testing.
[0]http://disconnected.io/2014/03/18/how-i-hacked-your-router/c... [1]http://www.youtube.com/watch?v=OO_A8NHNBj8
Perhaps someone could comment on the possible prison time if an approach like this was taken without the authorization that this person had in advance?
Also it would seem that it would be fairly easy if you are in physical proximity to the target to use social engineering (as opposed to a bump key - opening the front door) to gain physical access to the premises and find the wifi password right under the router. Or plant something on the network that gives you access - you get the picture. Or plant a keylogger that might not be noticed for months. Or drop a USB key (wouldn't work with an infosec guy but maybe if it was mailed to him and it looked like it came from a reliable source it would).
That said, it would still require the victim to load the fake LinkedIn page (with the wrong domain), which is more likely to look suspicious.
And it would've loaded the router page after the POST (instead of redirecting to LinkedIn), which would definitively signal that something was wrong.
I don't know about the vulnerabilities in the Time Capsule router, but from my understanding the only router firmware even remotely worth a look in terms of security would be OpenWRT.
but I figured I should ask this guy, sounds like he knows what he's doing.
I suppose you could just serve up a fake backdoor program for every *.exe\msi download, and remove the honeypot on the second download? The first download would execute and maybe do nothing (or error) - prompting a second download which led to the real thing.
He likely just enabled them all, or at least enabled several which are likely candidates for his target to download.
Any hardware recommendations for what I should look in for in a router? Is old better than new? Any particular model that is well supported?
Even if the target set his computer to auto-update (or something that did not require admin authentication), wouldn't he have some type of notion that something went wrong during his update?
With the target being an InfoSec guy, I would've imagined he would at least be running some type of network monitoring, like wireshark or little snitch, ESP on his personal computer. Wouldn't he have to authorize the outgoing packets?
Sorry, if I come off analytical to the story...it's a great read...I just want to make sure my networks are locked down. I've even went as far as dedicated networks for my server and home usage, and preventing internal ip addresses from communicating to each other (sucks for airplay).
There is a way of injecting your code into an existing executable so that the executable still works like it did before. Basically your code gets called first and than the original program entry point gets called.
Wouldn't he have to authorize the outgoing packets?
He might have updated this Notepad++ on purpose? He obviously did not know his router was compromised.
I was trying to figure out how he had the key logger sending out it's packets.
Only if it's unsigned (or someone doesn't check the signatures) and it's over HTTP. I can't seem to find it, but someone complained about just how hard it is to get a version of putty that you can at least be sure came from the right domain.
Which is why I'm always wary of installing unsigned software. In such cases I try to check some hashes some way. Obviously if the download page lists them I check against those, but in most cases it's insufficient because that page is not HTTPS. So I always help myself with google, both by googling the filename to find some pages listing a hash, and by googling my own hash (note that Google is accessed with HTTPS).
>google "44ac2504a02af84ee142adaa3ea70b868185906f"
>see results are mostly "putty.exe"
Three steps, all relatively painless.
Suppose I download Putty and am unsure of whether it's the real thing or whether it's a Trojan, e.g. due to someone having hacked my router. I compute the hash of the file and google it: http://lmgtfy.com/?q=44ac2504a02af84ee142adaa3ea70b868185906... . I find many sites saying that's putty.exe. If I didn't, I'd be very suspicious.
Unless I'm missing something...