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.
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.
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.
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.
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.
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.
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?
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.
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).
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.
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.
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.
"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.
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.
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.
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.
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.
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 ;)
[+] [-] ushi|12 years ago|reply
[0] http://sourceforge.net/p/notepad-plus/discussion/1290588
[+] [-] revelation|12 years ago|reply
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.
[+] [-] meowface|12 years ago|reply
And that's all an attacker needs.
[+] [-] aaronem|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jlgaddis|12 years ago|reply
[+] [-] brianmwaters_hn|12 years ago|reply
[+] [-] sillysaurus3|12 years ago|reply
[+] [-] siliconc0w|12 years ago|reply
[+] [-] vxNsr|12 years ago|reply
>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
[+] [-] thaumaturgy|12 years ago|reply
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.
[+] [-] adwf|12 years ago|reply
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?
[+] [-] dailycrud|12 years ago|reply
[+] [-] larrys|12 years ago|reply
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).
[+] [-] chmars|12 years ago|reply
[+] [-] thefreeman|12 years ago|reply
[+] [-] maccam94|12 years ago|reply
[+] [-] gnud|12 years ago|reply
[+] [-] revelation|12 years ago|reply
[+] [-] somerandomness|12 years ago|reply
[+] [-] svas|12 years ago|reply
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.
[+] [-] ivansavz|12 years ago|reply
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?
[+] [-] fiatmoney|12 years ago|reply
[+] [-] ambrop7|12 years ago|reply
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).
[+] [-] why-el|12 years ago|reply
[+] [-] tripzilch|12 years ago|reply
[+] [-] frozenport|12 years ago|reply
[+] [-] refurb|12 years ago|reply
[+] [-] meowface|12 years ago|reply
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.
[+] [-] nathannecro|12 years ago|reply
[+] [-] quackerhacker|12 years ago|reply
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).
[+] [-] ma2rten|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] userbinator|12 years ago|reply
[+] [-] frozenport|12 years ago|reply
[+] [-] pcunite|12 years ago|reply
[+] [-] k_os|12 years ago|reply
[+] [-] beagle3|12 years ago|reply
[+] [-] prez|12 years ago|reply
Unless I'm missing something...
[+] [-] pizzeys|12 years ago|reply
[+] [-] bartbes|12 years ago|reply
[+] [-] yp_master|12 years ago|reply
[+] [-] frozenport|12 years ago|reply
[+] [-] icebraining|12 years ago|reply
[+] [-] joev_|12 years ago|reply
[+] [-] conchy|12 years ago|reply
[+] [-] zurn|12 years ago|reply
[+] [-] CodeGlitch|12 years ago|reply
[+] [-] tsmash|12 years ago|reply
[+] [-] csears|12 years ago|reply