As I promised during my 2014 Derbycon talk (amongst other places), this is an initial release of my complete re-write/re-design of the dnscat service / protocol. It's now a standalone tool instead of being bundled with nbtool, among other changes. :)
I'd love to have people testing it, and getting feedback is super important to me! Even if you don't try this version, hearing that you're excited for a full release would be awesome. The more people excited for this, the more I'm encouraged to work on it! In case you don't know it, my email address is listed below in a couple places.
Where can I get it?
Here are some links:
Wait, what happened to dnscat1?
I designed dnscat1 to be similar to netcat; the client and server were the same program, and you could tunnel both ways. That quickly became complex and buggy and annoying to fix. It's had unresolved bugs for years! I've been promising a major upgrade for years, but I wanted it to be reasonably stable/usable before I released anything!
Since generic TCP/IP DNS tunnels have been done (for example, by iodine), I decided to make dnscat2 a little different. I target penetration testers as users, and made the server more of a command & control-style service. For example, an old, old version of dnscat2 had the ability to proxy data through the client and out the server. I decided to remove that code because I want the server to be runnable on a trusted network.
Additionally, unlike dnscat1, dnscat2 uses a separate client and server. The client is still low-level portable C code that should run anywhere (tested on 32- and 64-bit Linux, Windows, FreeBSD, and OS X). The server is now higher-level Ruby code that requires Ruby and a few libraries (I regularly use it on Linux and Windows, but it should run anywhere that Ruby and the required gems runs). That means I can quickly and easily add functionality to the server while implementing relatively simple clients.
How can I help?
The goal of this release is primarily to find bugs in compilation, usage, and documentation. Everything should work on all 32- and 64-bit versions of Linux, Windows, FreeBSD, and OS X. If you get it working on any other systems, let me know so I can advertise it!
I'd love to hear from anybody who successfully or unsuccessfully tried to get things going. Anything from what you liked, what you didn't like, what was intuitive, what was unintuitive, where the documentation was awesome, where the documentation sucked, what you like about my face, what you hate about my face—anything at all! Seriously, if you get it working, email me—knowing that people are using it is awesome and motivates me to do more. :)
For feedback, my email address is my first name (ron) at my domain (skullsecurity.net). If you find any bugs or have any feature requests, the best place to go is my Issue tracker.
What's the future hold?
I've spent a lot of time on stability and bugfixes recently, which means I haven't been adding features. The two major features that I plan to add are:
- TCP proxying - basically, creating a tunnel that exits through the client
- Shellcode - a x86/x64 implementation of dnscat for Linux and/or Windows
Once again, I'd love feedback on which you think is more important, and if you're excited to get shellcode, then which architecture/OS that I should prioritize. :)
“Securing the future” is a huge topic, but our Chief Research Officer Mikko Hypponen narrowed it down to the two most important issues is his recent keynote address at the CeBIT conference. Watch the whole thing for a Matrix-like immersion into the two greatest needs for a brighter future — security and privacy.
To get started here are some quick takeaways from Mikko’s insights into data privacy and data security in a threat landscape where everyone is being watched, everything is getting connected and anything that can make criminals money will be attacked.
1. Criminals are using the affiliate model.
About a month ago, one of the guys running CTB Locker — ransomware that infects your PC to hold your files until you pay to release them in bitcoin — did a reddit AMA to explain how he makes around $300,000 with the scam. After a bit of questioning, the poster revealed that he isn’t CTB’s author but an affiliate who simply pays for access to a trojan and an exploit-kid created by a Russian gang.
“Why are they operating with an affiliate model?” Mikko asked.
Because now the authors are most likely not breaking the law. In the over 250,000 samples F-Secure Labs processes a day, our analysts have seen similar Affiliate models used with the largest banking trojans and GameOver ZeuS, which he notes are also coming from Russia.
No wonder online crime is the most profitable IT business.
2. “Smart” means exploitable.
When you think of the word “smart” — as in smart tv, smartphone, smart watch, smart car — Mikko suggests you think of the word exploitable, as it is a target for online criminals.
Why would emerging Internet of Things (IoT) be a target? Think of the motives, he says. Money, of course. You don’t need to worry about your smart refrigerator being hacked until there’s a way to make money off it.
How might the IoT become a profit center? Imagine, he suggests, if a criminal hacked your car and wouldn’t let you start it until you pay a ransom. We haven’t seen this yet — but if it can be done, it will.
3. Criminals want your computer power.
Even if criminals can’t get you to pay a ransom, they may still want into your PC, watch, fridge or watch for the computing power. The denial of service attack against Xbox Live and Playstation Netwokr last Christmas, for instance likely employed a botnet that included mobile devices.
IoT devices have already been hijacked to mine for cypto-currencies that could be converted to Bitcoin then dollars or “even more stupidly into Rubbles.”
4. If we want to solve the problems of security, we have to build security into devices.
Knowing that almost everything will be able to connect to the internet requires better collaboration between security vendors and manufacturers. Mikko worries that companies that have never had to worry about security — like a toaster manufacturer, for instance — are now getting into IoT game. And given that the cheapest devices will sell the best, they won’t invest in proper design.
5. Governments are a threat to our privacy.
The success of the internet has let to governments increasingly using it as a tool of surveillance. What concerns Mikko most is the idea of “collecting it all.” As Glenn Glenwald and Edward Snowden pointed out at CeBIT the day before Mikko, governments seem to be collecting everything — communication, location data — on everyone, even if you are not a person of interest, just in case.
Who knows how that information may be used in a decade from now given that we all have something to hide?
We were recently asked a series of questions about how Freedome protects private data by TorrentFreak.com. Since we believe transparency and encryption are keys to online freedom, we wanted to share our answers that explain how we try to make the best privacy app possible.
1. Do you keep ANY logs which would allow you to match an IP-address and a time stamp to a user of your service? If so, exactly what information do you hold and for how long?
We do not keep any such logs. If ever required by law under a jurisdiction, we would implement such a system, but only where applicable and keeping storage time to the minimum required by law of that respective jurisdiction. Note also that no registration is required to use our service, so any log information would generally map to an anonymous, random user ID (UUID) and the user’s public IP address.
2. Under what jurisdiction(s) does your company operate?
Freedome is a service provided from Finland by a Finnish company, and manufactured and provided in compliance with applicable Finnish laws.
3. What tools are used to monitor and mitigate abuse of your service?
We have proprietary tools for fully automated traffic pattern analysis, including some DPI for the purpose of limiting peer-to-peer traffic on some gateway sites. Should we detect something that is not in line with our acceptable use policy, we can rate limit traffic from a device, or block a device from accessing the VPN service. All of this is automated and happens locally on the VPN gateway.
4. Do you use any external email providers (e.g. Google Apps) or support tools ( e.g Live support, Zendesk) that hold information provided by users?
We do not use any external email providers, but our users can, for example, sign up for beta programs with their email address and send us feedback by email. The email addresses are used only to communicate things like product availability.
In the future, paying customers can also use our support services and tools such as chat. In those cases, we do hold information that customers provide us voluntarily. This information is incident based (connected to the support request) and is not connected to any other data (e.g. customer information, marketing, licensing, purchase or any Freedome data). This data is purely used for managing and solving support cases.
5. In the event you receive a DMCA takedown notice or European equivalent, how are these handled?
There is no content in the service to be taken down. Freedome is a data pipeline and does not obtain direct financial benefit from user content accessed while using the service. While some of the other liability exclusions of DMCA (/ its European equivalent) apply, the takedown process itself is not really applicable to (this) VPN service.
6. What steps are taken when a valid court order requires your company to identify an active user of your service? Has this ever happened?
The law enforcement data requests can effectively be done directly only to F-Secure Corporation in Finland. If a non-Finnish authority wants to request such data from F-Secure, the request will be done by foreign authorities directly to Finnish police or via Interpol in accordance to procedures set out in international conventions. To date, this has never happened for the Freedome Service.
7. Does your company have a warrant canary or a similar solution to alert customers to gag orders?
We do not have a warrant canary system in place. Instead, Freedome is built to store as little data as possible.
Since a warrant canary would be typically triggered by a law enforcement request on individual user, they are more reflective on the size of the customer base and how interesting the data in the service is from a law enforcement perspective. They are a good, inventive barometer but do not really measure the risk re: specific user’s data.
8. Is BitTorrent and other file-sharing traffic allowed on all servers? If not, why?
BitTorrent and other peer-to-peer file sharing is rate limited / blocked on some gateway servers due to acceptable use policies of our network providers. Some providers are not pleased with a high volume of DMCA takedown requests. We use multiple providers (see Question #12) and these blocks are not in place on all the servers.
9. Which payment systems do you use and how are these linked to individual user accounts?
There are multiple options. The most anonymous way to purchase is by buying a voucher code in a retail store. If you pay in cash, the store will not know who you are. You then enter the anonymous voucher code in the Freedome application, and we will then confirm from our database that it is a valid voucher which we have given for sale to one of our retail channels. The retail store does not pass any information to us besides the aggregate number of sold vouchers, so even if you paid by a credit card, we do not get any information about the individual payment.
For in-app (e.g., Apple App Store, Google play) purchases you in most cases do need to provide your details but we actually never receive those, we get just an anonymous receipt. The major app stores do not give any contact information about end users to any application vendors.
When a purchase is made through our own e-store, the payment and order processing is handled by our online reseller, cleverbridge AG, in Germany. Our partner collects payment information together with name, email, address, etc. and does store these, but in a separate system from Freedome. In this case we have a record who have bought Freedome licenses but pointing a person to any usage of Freedome is intentionally difficult and against our policies. We also don’t have any actual usage log and therefore could not point to one anyway.
10. What is the most secure VPN connection and encryption algorithm you would recommend to your users? Do you provide tools such as “kill switches” if a connection drops and DNS leak protection?
Our application does not provide user selectable encryption algorithms. Servers and clients are authenticated using X.509 certificates with 2048-bit RSA keys and SHA-256 signatures. iOS clients use IPSEC with AES-128 encryption. Other clients (Android, Windows, OS X) use OpenVPN with AES-128 encryption. Perfect Forward Secrecy is enabled (Diffie-Hellman key exchange).
We provide DNS leak protection by default, and we also provide IPv6 over the VPN so that IPv6 traffic will not bypass the VPN. Kill switches are not available. The iOS IPSEC client does not allow traffic to flow unless the VPN is connected, or if the VPN is explicitly turned off by the user. The Android app, in “Protection ON” state keeps capturing internet traffic even if network or VPN connection drops, thus there is no traffic or DNS leaks during connection drops. If the Freedome application process gets restarted by the Android system, there is a moment where traffic could theoretically leak outside the VPN. Device startup Android 4.x requires user’s consent before it allows a VPN app to start capturing traffic; until that traffic may theoretically leak. (Android 5 changes this, as it does not forget user’s consent at device reboot.)
11. Do you use your own DNS servers? (if not, which servers do you use?)
We do have our own DNS servers.
12. Do you have physical control over your VPN servers and network or are they outsourced and hosted by a third party (if so, which ones)? Where are your servers located?
In most locations we utilize shared hardware operated by specialized hosting vendors, but we also have our own dedicated hardware at some locations. Providers vary from country to country and over time. In some countries we also use multiple providers at the same time for improved redundancy. An example provider would be Softlayer, an IBM company whom we use in multiple locations.
Another Internet and Facebook chain letter you no doubt have seen. Paramedics recommend adding a contact record named ICE in your mobile phone. It stands for In Case of Emergency and helps contacting your closest relatives if you have an accident. Sounds great, but let’s take a closer look first.
This is actually not a typical hoax chain letter because it’s based on facts. The idea emerged in UK in 2005, and was indeed introduced by paramedics. It’s a novel idea with good intentions and might have worked in the era before the smartphone. But it’s badly outdated now. I sincerely hope that people start circulating updated instructions rather than the original 10 years old idea.
- First, ICE is a nice idea. But it’s NOT the primary interest of paramedics. Their job is to save your life. They are going to concentrate on that rather than playing with your gadget. But ICE-info may still come in handy later at the hospital when the dust settles a bit.
- Knowledge of some medical conditions is important to paramedics helping a trauma patient. Persons with conditions of this kind wear special medical IDs, necklaces or bracelets, and paramedics are trained to look for them. This has nothing to do with ICE.
- Our smartphone is a key to all our on-line accounts, e-mail, Facebook, Twitter, cloud storage, you name it. It MUST be locked with a good password, otherwise you take a huge digital risk. And that unfortunately kills the idea with an ICE phonebook record. It’s not worth leaving the phone unprotected because of the ICE-record. Don’t even consider that!
- Sometimes good old low-tech solutions are far better than digital technology. This is one of those cases. Write the ICE info on a sticker and put it on your phone or anything you carry with you. ID papers, like your driving license, are probably the best items as they are likely to be brought with you to the hospital.
- If you are a bit nerdy, like me, you may still want a digital solution. Check your mobile for a function or app that puts free form text on the lock screen and use it for ICE. Some phones may even have a separate ICE function for this purpose. But use it as a complement to the good old sticker, not as a replacement.
So to summarize. ICE is in theory a good idea, but not really crucial for your survival. It’s not worth sacrificing your digital safety for it. Especially when you simply need a pen and paper to create an ICE record that is more reliable, safer and easier to use!
PS. Full medical ID can also be put on the mobile’s lock screen, at least on Android and iPhone. I’m not sure if this is a good idea. A solid necklace of stainless steel somehow feels better for stuff that can mean the difference between life and death. A complement to the necklace is of course never wrong but I really hope that nobody who really needs it trust this as their only medical ID!
Image by Ragesoss through Wikimedia
With Net Neutrality close to becoming a reality in the United States, Europe’s telecom companies appear ready to fight for consumers’ trust.
At the Mobile World Congress in Barcelona this week, Telefonica CEO Cesar Alierta called for strict rules that will foster “digital confidence”. Vodafone CEO Vittorio Colao’s keynote highlighted the need for both privacy and security. Deutsche Telekom’s Tim Höttges was in agreement, noting that “data privacy is super-critical”.
“80% [of consumers] are concerned about data security and privacy, but they are always clicking ‘I accept [the terms and conditions], I accept, I accept’ without reading them,” said Höttges, echoing a reality we found when conducting an experiment that — in the fine print — asked people to give up their first born child in exchange for free Wi-Fi.
The fight for consumers’ digital freedom is close to our hearts at F-Secure and we agree that strong rules about data breach disclosure are essential to regaining consumers trust. However, we worry that anything that limits freedom in name of privacy must be avoided.
Telenor CEO and GSMA chairman, Fredrik Baksaas noted the very real problem that consumers face managing multiple online identities with multiple passwords. He suggested tying digital identity to SIM cards. This dream of a single identity may seem liberating on a practical level. But beyond recently exposed problems with SIM security, a chained identity could disrupt some of the key benefits of online life — the right to define your identity, the liberty to separate work life from home life, the ability to participate in communities with an alternate persona.
GMSA is behind a single authentication system adopted by more than a dozen operators that is tied to phones, which could simplify life for many users. But it will likely not quench desires to have multiple email accounts or identities on a site nor completely solve the conundrum of digital identity.
The biggest problem is that so many of us aren’t aware of what we’ve already given up.
The old saying goes, “If it’s free, you’re the product”. This was a comfortable model for generations who grew up trading free content in exchange for watching or listening to advertisements. But now the ads are watching us back.
F-Secure Labs has found that more than half of the most popular URLs in the world aren’t accessed directly by users. They’s accessed automatically when you visit the sites we intend to visit and used to track our activity.
Conventional terms and conditions are legal formalities that offer no benefits to users. As our Mikko Hypponen often says, the biggest lie on the Internet is “I have read and agreed with terms and conditions.” This will have to change for any hope of a world where privacy is respected.
In the advanced world, store-bought food is mandated to have its nutritional information printed on the packaging. We don’t typically read — nor understand — all the ingredients. But we get a snapshot of what effect it will have on us physically.
How about something like this for privacy that informs us how data is treated by a particular site or application.
What data is captured?
Is is just on this site or does it follow you around the web?
How long is stored?
Whom is it shared with?
Key questions, simply answered — all with the purpose of making it clear that your privacy has value.
Along with this increased transparency, operators and everyone who cares about digital rights must pay close attention to the effort to ban or limit encryption in the name of public safety. The right of law-abiding citizens to cloak their online activity is central to democracy. And all the privacy innovations in the world won’t matter if we cannot expect that right to exist.
We are entering an era where consumers will have more reasons, need and opportunities to connect than ever before. The services that offer us the chance to be more than a product will be the ones that thrive.
Yes, I often obtain samples from various sources for my own research.
I am sometimes too lazy/busy to post them but don't mind sharing.
If you are looking for a particular sample, feel free to ask. I might have it.
Send MD5 (several or few samples). I cannot provide hundreds/thousands of samples or any kind of feeds. If you ask for a particular family, I might be able to help if I already have it.
Unfortunately, I do not have time to do homework for students and provide very specific sets for malware with specific features as well as guarantee the C2s are still active. Send your MD5(s) or at least malware family and I check if I have it :) If i have it, I will either send you or will post on the blog where you can download.
If you emailed me in the past and never got an answer, please remind me. Sometimes emails are long with many questions and I flag them to reply to later, when I have time and they get buried or I forget. It does not happen very often but accept my apologies if it happened to you.
Before you ask, check if it is already available via Contagio or Contagio Mobile.
1. Search the blog using the search box on the right side
2. Search here https://www.mediafire.com/folder/b8xxm22zrrqm4/BADINFECT
3. Search here https://www.mediafire.com/folder/c2az029ch6cke/TRAFFIC_PATTERNS_COLLECTION
4. Search here https://www.mediafire.com/folder/78npy8h7h0g9y/MOBILEMALWARE
At every board meeting, whether it’s monthly, whether it’s quarterly, cybersecurity should be on [the agenda]. If not, you’re going to wind up in a situation where you’re having an emergency board meeting to discuss something that has gone wrong.
a former cyber-security adviser in both the Obama and Bush administrations
Similarly, if you are using "HTTPS Decrypt & Inspect" in Smoothwall, your clients' browsers will afforded some protection from attack, as their traffic will be re-encrypted by the web filter, which does not support downgrading to these "Export Grade" ciphers.
Nobody wants anyone looking at their search history. I get it. I mean, look at mine —oh wait, don't—that's quite embarrassing. Those were for a friend, honestly.
Fortunately for us, it's pretty difficult to dig into someone's search history. Google even forces you to log in again before you can view it in its entirety. Most search engines now encrypt our traffic by default, too —some even using HSTS to make sure our browsers always go secure. This is great news for consumers, and means our privacy is protected (with the noticeable exception of the search provider, who knows everything and owns your life, but that's another story).
This all comes a little unstuck though - sometimes we want to be able to see inside searches. In a web filtered environment it is really useful to be able to do this. Not just in schools where it's important to prevent searches for online games during lessons, but also in the corporate world where, at the very least, it would be prudent to cut out searches for pornographic terms. It's not that difficult to come up with a handful of search terms that give potentially embarrassing image results.
So, how can we prevent users running wild with search engines? The first option is to secure all HTTPS traffic with "decrypt and inspect" type technology —your Smoothwall can do this, but you will need to distribute a certificate to all who want to use your network to browse the web. This certificate tells the browser: "trust this organisation to look at my secure traffic and do the right thing". This will get all the bells and whistles we were used to in the halcyon days of HTTP: SafeSearch, thumbnail blocking, and search term filtering and reporting.
Full decryption isn't as easy when the device in question is user-owned. The alternative option here is to force SafeSearch (Google let us do this without decrypting HTTPS) but it does leave you at their mercy in terms of SafeSearch. This will block anything that's considered porn, but will leave a fair chunk of "adult" content and doesn't intend to cover subjects such as gambling —or indeed online games. You won't be able to report on any of this either, of course.
Some people ask "can we redirect to the HTTP site" - this is a "downgrade attack", and exactly what modern browsers will spot, and prevent us from doing. We also get asked "can we resolve DNS differently, and send secure traffic to a server we have the cert for?" - well, yes, you can, but the browser will spot this too. You won't get a certificate for "google.com", and that's where the browser thinks it is going, so that's where it expects the certificate to be for.
In conclusion: ideally, you MITM or you force Google's SafeSearch & block access to other search engines. For more information read our whitepaper: 'The Risks of Secure Google Search'. It examines the problems associated with mandatory Google HTTPS searches, and suggests methods which can be used to remedy these issues.
Featured news: Superfish, new malware warnings, universal SSL
Read Mozilla’s directions for getting Superfish out of Firefox (Feb. 27), Sophos on Superfish removal (Feb. 20), and a Fortinet Superfish FAQ. (Feb. 20) ESET also has a wise piece on unwarranted panic and false positives. (Feb. 20) Note: We hope we don’t ever have to write the word “Superfish” again.
Google Safe Browsing expands Chrome warnings: New warnings let users know when they’re about to visit a site known for encouraging downloads of unwanted or suspicious software. (Feb. 23)
Feedback and data-driven updates to Google’s Project Zero disclosure policy (Feb. 13)
Universal SSL: Public beta version of new CloudFlare service encrypts data from the browser to the origin for free. (Feb. 24)
Malware news + vulnerabilities
Google releases free, cloud-based web application security scanner that can help App Engine developers check for cross-site scripting and mixed content vulnerabilities. (Feb. 19)
Highlights from Internet Identity’s 2014 eCrime Trends Report (Feb. 25)
Fortinet: Decoy files used to spread CTB-Locker ransomware (Feb. 16)
SiteLock on a security flaw in the UpdraftPlus premium WordPress plugin (Feb. 17)
Security news + perspectives
In case you missed it: After six years, StopBadware is shutting down its community forum. Details and recommended alternatives here.
Automattic: WordPress 4.1.1 is out! This one’s a maintenance release. (Feb. 18)
ESET on exploits: What are they, and how do they work? (Feb. 27)
DreamHost’s Mika E. talks about the virtues of open source and his experience writing plugins for WordPress. (Feb. 10)
SiteLock: How you can tell if a website is secure (Feb. 24)
Sucuri: Why websites get hacked (Feb. 26)