Is fourteen characters long password really weak? I've tried to sign in to Samsung Cyber Service Center1. Since I'm from Poland, at first I tried Polish version of that service. I have entered a password, that has:

6 numbers in total (in three groups of two numbers each),
6 lowercase characters,
3 uppercase characters,
1 special characer,

in following order: NNccccccNNCCC#.

I was smashed with an error message saying, that I can't continue, because... my password is too weak.

For verification, I went to English version of that sign-up form and after staring for two minutes directly at Password must be at least 8 characters error message, I finally understood, what they really mean. Password must contain at least eight characters in one row, on which my password fails, because it has only six and three characters in one row,(in each of two characters groups).

I'd like to know, how should I treat situatons like this? Is really my example password too weak (and I should consider not using passwords like that anymore) or are these first signs of Samsung ParanoiaTM (or some kind of bug on their site) and I should change password only this time, to match their crazyness.

1 To see mentioned sign-in form, you have to go Cyber Service Center, click - Registration and then Sign Up Now.

Is a password of the format

  NNccccccNNCCC#

weak?

Well, let's do some math two ways:

Assume it's purely randomly generated (not likely if it has a pattern), and assuming there are 32 choices for the trailing symbol (also unlikely; most passwords choose from a much smaller subset).

10^2 * 26^6 * 10^2 * 26^3 * 32 ~= 1.7E18 ~= 2^61
If the site hashes with a single round of MD5 (not unlikely), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 7 months.
A cracking group of 7 people each with one of those machines, in about one month.
A well funded adversary will spend more time on the paperwork, even if the paperwork is just "push the button".

Assume it's purely randomly generated except for the 6 character string, which is a word or string that appears in a common cracking dictionary+ruleset of 200,000 possibilities, and assuming there are 32 choices for the trailing symbol (also unlikely; most passwords choose from a much smaller subset).

10^2 * 200000 * 10^2 * 26^3 * 32 ~= 1.1E15 ~= 2^50
If the site hashes with a single round of MD5 (not unlikely), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 0.004 months, i.e. less than 3 hours.
If the site hashes with a single round of SHA-256, a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 0.035 months.
If the site hashes with a thousand rounds of SHA-1 without additional overhead (possible, I suppose), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 14 months.

Unless they upgrade their GPU's during that year, in which case it goes down further.
If you wait for, say, 3 years, then based on Moore's Law and House's Corrollary, the exhaustive search time would be only 3 and a half months.
If you wait for, say, 6 years, then based on Moore's Law and House's Corrollary, the exhaustive search time would be about three weeks.

So, what amount of time does a given level of adversary need to spend on an offline attack for you to consider your password "not weak"?  Only you can decide that, but here's the math to help.

That one machine with 8 GPU's in January 2015:

MD5 one round: 2.5E17 tries/30 days (2^58)
SHA-1 one round: 7.8E16 tries/30 days (2^56)
SHA-256 one round: 3.2E16 tries/30 days (2^55)
SHA-512 one round: 1.2E16 tries/30 days (2^53)
WPA/WPA2: 3E12 tries/30 days (2^41)


IEEE 1363 is inactive-reserved, having been withdrawn on 2019-11-07 : what does this mean? IEEE 1363-2000 - IEEE Standard Specifications for Public-Key Cryptography - has been withdrawn on 7th November 2019 and is now in inactive-reserved status. What does this mean? Why was it withdrawn? Are some of the contents suspect? Some serious vulnerabilities were discovered? Should we no longer use it as a reference?

After reading about the meaning of inactive-reserved and of withdrawn, I thought it's not possible for the same standard to be both, yet, that is what is showing on the IEEE 1363-2000 Standard's web page (linked above).

As already noted by Marc, information about the revision process for IEEE standards can be found on their website. There it says:

  A standard has a validity period of ten years from the date of IEEE SA Standards Board approval. (...) At the end of this period, one of two things has to happen: revision or withdrawal. If no action is taken, the standard will be moved to inactive-reserved status.

And from their FAQ we can learn that there are four categories of standards: active (currently being maintained), superseded (replaced with revised version), inactive-reserved (has not undergone a revision process within 10 years), and inactive-withdrawn (made inactive as a consensus decision).

So IEEE 1363-2000 was not withdrawn but only not revised recently. And as such it can safely be cited if you find its content cite-worthy.


Protecting against DOS attacks Our current site is easily DOS'd. I can perform an AB test against it from Apache and it disappears for about 5-10 minutes. We have been having problems with others DOSing the site - to the point where we had to shut it down for 8 hours (recommended by the server host).

The server is hosted by Rackspace. They recommended shutting it down for 8 hours, which when we brought it back up the attacked resumed.

We setup cloud flare for the DNS, however after an AB test with 58,000 requests sent the site was offline again (not as long as originally).

Rackspace is not offering anymore suggestions, and I need to figure out something to do for the time being, switching server hosts is not an option at this point and time (lead developer is leaving in 1 week for a new position).

This specific attack created a lot of connections in the mysql database with the command sleep.

Does anyone have any suggestions or recommendations on ways to protect again DOS attacks?

Would increasing the RAM on the virtual host help at all?

There are a couple of things you can do to prevent DOS/DDOS.
First I would recommend using an autoban firewall. I've been using Fail2Ban for some time now. Most of my problems with DDOS/DOS attacks to SSH,FTP,BIND and etc were solved. What fail2ban actually does is it's scanning a log file and when a regex pattern matches X times it bans the person. With a little more work you can make it read almost any type of log files.

Second there were a couple of mods for apache that prevent DDOS/DOS attacks. One of them was mod_evasive. I used it for a while but fail2ban worked for me best (for now) so I didn't quite get into mod_evasive.

Another possibility is to use Nginx as a front-end which would proxy-forward connection requests to your Apache server. Then set Nginx's HttpLimitZoneModule (info) to a desired number. This will reduce the maximum incoming connection from a single IP but it won't prevent DDOS.

Finally - close all of your unused ports. Leave only ports that need to be public as port 21,53,80,443 etc. This will limit the possibilities where the attacker may target.

Edit:
Make sure you don't get ping flood by setting some iptables rules that limit icmp. Here's a link which explains how ping flood works. Try looking at the pictures first then the text will make more sense to you.
If you're using iptables this command may help you prevent ping/icmp flood:

iptables -A INPUT -p icmp -m limit --limit 6/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -j DROP

The first one will limit icmp requests up to 6 requests per second. Afterwords the person will not receive any more responses. This will eliminate bots that are doing a cycle:

for(i=0; i<1000000; i++){
   some evil code that will bring your server down
   either by pinging or just connecting to random ports.
};


If someone has access to VPN and your computer, is there a point of using VPN? If someone sniffs requests coming from my computer and my VPN's computer, there's no point using VPN, right? Because they can see the time when I made a request to my VPN and they can analyze all of the requests coming from VPN at the specific timeframe and they can guess which request was made by me, correct? That's just theoretically.

I am going to interpret your question as meaning the attacker can see network traffic from your computer and the from the VPN endpoint.

It depends what you are protecting against.

Generally, the term VPN is used to refer to an encrypted communication channel across an open medium such as the Internet, so if you want to hide the information being communicated, then a VPN is a very good way to protect yourself. Encryption helps this information remain confidential.

If you want to hide the fact that you are communicating, then this won't necessarily help so much, as an attacker with the network visibility you describe can cross-reference requests and responses.

However, if the attacker actually has access to your computer - then you have far bigger problems, as all your communications and data can potentially be viewed, compromised or destroyed.


Is there a Security/Privacy risk in storing computers' hardware thumbprint? I'm asking this because according to this article  , Microsoft collects much less information than actually exists for Windows licensing (e.g. only 10 bits for MAC addresses, 6 for CPU serial number etc.) - perhaps this is because of privacy issues?

For its computations related to activation keys, Microsoft must perform a delicate dance between a number of booby traps. In particular, they aim at detecting people who reuse the activation keys on other systems, but not unduly block users who simply changed parts of their hardware. There is a fine limit between "this is a new computer" and "this is the same computer but with some upgraded parts".

Among Microsoft's preoccupations, I'll wager that "user privacy" ranks rather low. However, "user sues Microsoft because of privacy issues" is probably more of a concern, from Microsoft point of view, so chances are that they will make some token public relations effort on the lines of "your privacy is important to us" and collecting only 10 bits of a MAC address may be part of this apparent display.


As a website admin I could see encrypted passwords. Is this ok? I am building a website that requires the users to login through username and password. I have the passwords encrypted in my database with bcrypt. On the back end, I receive the usernme and password of the user, and use this code to check it:

bcrypt.compare(req.body.password, result[0].password, function(err, success) {...})

At this point, if the compare is successful, I could simply use console.log(req.body.password) and get the users password printed out on my console. I mean, I probably just realized something that have been like this all the time. Is this safe enough?

For most purposes that is secure enough minus the logging.

Your server must have the plain text password at one point, whether it's signing up or logging in. In this case, the user is passing their password to the API through an HTTPS POST request, the server is verifying the password against a hashed and salted password with many salt rounds using bcrypt and ideally generating a JWT after authentication. There is no way for an outsider (or you) to access the password. It was transfer securely through the internet, then it didn't leave your secured server (unless you log it). Do be diligent with logs; make sure no PPI including passwords are being logged (some companies do this and it really drives me nuts).

Notes:

The passwords are hashed as opposed to encrypted, in general and with bcrypt (though depending how deep you want to dive, you could argue bcrypt "does" encryption, but not for the reason you think). Always refer to "hashed" passwords because encryption refers to something entirely different.
Assuming the server is securely hosted (if using a 3rd party container service, this is probably true)
Assuming the password is given to the API through HTTPS and cannot be intercepted during transit. Depending on the application, you may want to go as far as certificate pinning to avoid MITM attacks through HTTPS.

By using bcrypt, you have already done your part in securely storing relatively passwords -high five-. You can also explore scrypt or Argon2.


Are there any security reasons for an organization to disable browser session restoration? Does the browser setting to restore the previous session on startup pose any security concerns on a machine with separate logins for each user?  Are there any security reasons for an organization to block that setting?

Restoring sessions means that there is a token saved in the browser that automatically logs the user in to that service.

The security issue with this is that the only thing protecting the online accounts is the device's local login. Once someone gets that, then they automatically get access to all the web services that were open. That kind of leverage is not the best.

In addition, it might be possible to obtain that token from the network and log in without access to the device.

It is better to have proper layers of protection that can be enforced:

device login
network login
web services login

Each with their own sets of credentials and with expiring sessions.


How to handle as a Tester if the website is kicking out the user for recreating the session? Suppose a website is logging out the user after some time to re-create the session and start using the website. As the security tester, how will you handle this situation? Isn't it frustrating? Yes! looking from a security perspective this is a nice mechanism, but if you are a penetration tester, how will you handle this, will you just simply get login again and again, or you will do something else to get rid of it?

Burp has session handling functionality that allows you to make a request to check if your session is valid, and if it has expired then it will login again. You can find it in the Project Options > Sessions tab.
Official documentation is here: https://portswigger.net/support/configuring-burp-suites-session-handling-rules


Tracing an email's MAC address Can someone trace the MAC address of an email to the point of origin if the email address has been deleted? I received an email from an unknown sender regarding an issue at my work, and when I tried to reply to it, I got a "message send: failure" email from my email provider. This tells me that whoever sent me this message deleted the email account to prevent being discovered. The message contained a some statements to my boss from some of my co-workers. I had never seen them until I got this email. Is there a way to find out where it came from?

Short answer: no

Long(er) answer:

Up until some time ago you could see(in both yahoo and gmail) the network address of the sender by looking at the full headers of the e-mail message. Currently, this option is no longer available in gmail.

An attacker can use a service like this to send an e-mail with custom headers(meaning that the source address can be anything(i.e. b.obama@whitehouse.gov)) in conjunction with an anonymizing service such as a VPN, TOR, or both, in order to conceal his actual network address.

The MAC serves as an identifier within a subnet and is stripped and replaced once the packets leave that subnet(by the station that acts as the gateway). So, there is no way to tell the MAC address at it's not specified in the headers of the e-mail.


Who will fix the vulnerabilities found in Firewall As a security guy, i run vulnerability scan and found vulnerabilities in firewall
Like as follows
SSL Server Allows Anonymous Authentication Vulnerability
Solution
SOLUTION:
Disable support for anonymous authentication.
1) Apache:
Typically, for Apache/mod_ssl, httpd.conf or ssl.conf should have the following lines:

My question is who has to fix this vulnerabilities: Is the the FW administrator or the Security guy who perform the scan

Dr.Ü has no clue with such comment. Good pentesters break and fix stuff. Monkeys who just run tools are not considered pentesters.

Who should fix it? That really depends of the company's policy.

In one company it might be the sysadmin. In other company the network admin. In other company the security engineer. In other company the...


Why doesn't standard antivirus detect commercial keyloggers? I installed SSPRO (commercial keylogger) on my computer just for testing.

Then I ran a scan with Eset Smart Security, and it failed to detect it.  I also downloaded some free spyware removal programs and they all failed to detect it.

Why do they fail to detect it?

I was wondering if since SSPRO is sold as a commercial surveillance program it's not treated as spyware? Or is it a flaw with my antivirus?  Do popular antivirus software usually detect commercial keyloggers?

I would think that is very detectable since I can see the process.

There can be a lot of reasons that the AV did not detect the software:

The code is signed by a reputable company (known good)
The binary is a known-good in the NSRL
The software does not match a malicious signature or attempt to make suspicious network connections

For additional confirmation, check the list of AVs at avcomparitives.org and test another AV solution on the same system and compare results.


Course of action with this malware After clicking in a fake "download here" button in a webpage for film downloads, a computer has got infected with what I believe to be an adware. I have located the file, VirusTotal gives this analysis of it.

One wierd thing that makes me uneasy is that when I launch Norton's complete check, it freezes after a random number of files checked (~18k, ~30k).

I am familiar with NIFO, but it is really necessary in this case?

It is an unfortunate situation wherein virus infections are, by nature, insidious. Some infections can be cleaned; sometimes by using specific removal tools, sometimes with manual fiddling about with files and reg keys, sometimes using commercial AV products. Other times they intercept system calls and prevent detection or removal.

The best advice, in the general case, is to either restore to a known good back up or rebuild from scratch. If it is considered reasonable to clean then I would recommend doing it from a live cd of some kind. This provides the best chance to clean off the malicious code without it preventing you from cleaning it.


SHA1 - S/MIME and CRL validity after deprecation? In an internal PKI using SHA1 for hashing, will S/MIME signature and CRL/ARL signature be considered invalid in the next few years (SHA1 Deprecation) ?  End certificates can be revoked, CA certificates too (or may be updated and signed again), but what about S/MIME signature and CRL ?

The question is not really about certification path (in S/MIME case, suppose the upper path is SHA256 but not the end entity certificate), but more about signature or CRL validity.

The general situation looks like this:

A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date).
These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when a certificate has expired, it ceases to be included in CRL, so even if you can download a new CRL, you won't be able to know whether the now-expired certificate was still unrevoked at expiration time. Possibly, a CA may go out of business. And, as you note, involved cryptographic algorithms may also become deprecated.
The really important point is that when you want to verify a signature, you want to know whether the signature was valid at the time it was produced. Suppose, for instance, that somebody sent you a signed email (with S/MIME) on November 12th. Three weeks later (early December), the sender's computer is compromised and his key stolen; he dutifully contacts his CA, and the CA revokes his certificate. Does that mean that his signature ceases to be valid ? We certainly hope not !

When you sign, you really are building a legal weapon pointed at you. In the example above, if Bob sends you a signed email, then you want to keep it in order to sue Bob if he wants to default on his responsibilities described in the email. It would be too easy if Bob could escape your legal retaliation by simply losing his private key !

However, once Bob's certificate has been revoked, it can no longer be validated in the X.509 sense. What that implies is that S/MIME signature validation is transient. It works for some time, then ceases to work.

To really support long-term archival of signed object, you need to freeze things in time. The tool for that is a time stamp.

Suppose that Bob signs the email on November 12th, 2014. Two days later, you open your mailbox and you verify the signature; at that point, Bob's certificate is still valid and unrevoked, and you can obtain a set of CA certificates and CRL that demonstrate (within the X.509 model) that, on November 14th, Bob had really signed the email. Then you take the email, CA certificates and CRL, put all of these in a big bag (e.g. some archive format), and then obtain a time stamp from some time stamping authority. The time stamp is, basically, a short document containing both the time stamping date (November 14th) and the hash of the time stamped data (a hash of the Zip file containing the email, its signature, the extra CA certificate and CRL); and the time stamp is signed by the time stamping authority.

Then fast forward to December 11th. At that time, Bob's certificate is revoked, because he claimed to have been robbed of his private key on December 3rd. You want to revalidate the signature. To do that, you verify the signature on the time stamp; if it is correct, then it is a proof that the archive contents already existed "as is" on November 14th. So you can then validate the S/MIME signature, using the objects from the archive, as if the current date was still November 14th. At that date, no certificate was revoked, archived CRL were not expired, SHA-1 was still trustworthy, so everything is fine.

A time stamp is thus a time-travelling machine. The time stamp demonstrates that a set of objects existed at some date T; so it allows you to run any validation algorithm using these objects (and only them) as if the current date was T.

Now the problem becomes: how to organize that time stamping process ? In particular, the time stamp is itself a signature, that is verified at the current date (it is because the time stamp is valid now that you can then jump back to date T when using the archived objects). That signature, with standard time stamps, also uses X.509 certificates and is subject to the same kind of degradation. So what you really need is to chain time stamps: whenever the top time stamp is getting close to cessation of verifiability (typically the expiration date of the TSA certificate), freeze it with another time stamp. And so on.

Theoretically, there are standards for that. S/MIME relies on CMS, an extensible format for encrypted and signed objects. Among defined extensions for CMS are the CAdES attributes; when you get all of them, you have a CAdES-A object, which is basically the archive-with-chain-of-time-stamps that I was talking about.

(However, I strongly doubt that you will find any S/MIME-aware tool that also knows how to process CAdES attributes.)

The same concept is also applied for XML documents (and the XAdES standard), and for PDF (with PAdES). Recent versions of Adobe Acrobat support PAdES.


Cross site styling vulnerability? I stumbled across a "vulnerability" that allows me to include an arbitrary css stylesheet in a website.

I understand that this is potentially a tool for csrf or stealing url parameters. But on its own, should it be considered a security vulnerability?

edit: Question is primarily about whether this is a vulnerability in its own right, rather than how this could possibly be used to create further exploits.

If you are not the web site author/admin, and you can (as a site user) add a stylesheet to a page, then this could be an attack vector--though arguably not a full-blown vulnerability.

For example, one could link a style to an image on a web server of their choosing and log the requests.  This would reveal data from all page visitors (IP addresses and user agents) which can then be used for further attacks.


Saving encrypted username password in session I have Node.js server which serves an app. In that app you could be asked to login. The login credentials would be authenticated against LDAP.

That server could request/post data from other servers via REST. Those restful endpoints could be secured with basic auth against the same LDAP server.

Is it safe to encrypt <username>:<password> and store this in the session on the Node.js server and, on request, decrypt those credentials and pass them in the Basic Auth header value to the restful endpoint?

The encryption key would be randomly created for that session and then destroyed at the end of the session. The credentials only live for the period of a session as well.

From strictly a security standpoint, you can do it this way, but it is not ideal. Even though the credentials are only stored temporarily on the server (and perhaps configured to only be stored in memory too), the fact that they are there longer than they potentially need to be poses a risk, albeit a small one. Note that encrypting the credentials in session probably doesn't help you that much, since your key to decrypt must be accessible by the server. In order for someone to read unencrypted session they would need to gain control of the server, and if they did that they could read an encrypted session too, so encrypting it just makes it slightly more annoying for the attacker to get to it. That being said, I would prefer one of these options:

If both the web application and rest applications are using the same LDAP credentials, then there should be a way to configure the rest apps such that they can share the same token the web app is using to authenticate the user with each request. If you can accomplish that you would not need to store anything in session, since the web app could pass on the token it received with each request.
A simpler approach would be for your web server to have it's own set of (admin-like) credentials to access the rest applications, and it would authenticate on its own independently to gather data it needs for the user, perhaps by querying by a particular user id. Of course this assumes the rest services are able to provide this functionality.


Recent Fritz Box exploit Background info:

About 50% of the ADSL and cable internet access in Germany (and presumably parts of the EU) goes over AVM Fritz routers, either verbatim or rebranded as e.g. "1&1 Home Server" or "T-Online Box".
These are embedded MIPS systems with a couple of ethernet ports, an ADSL or similar plug, and other optional stuff (DECT, WLan, USB ports) running a Linux (2.6 ???) derivative.

About three weeks ago, an exploit became known which allowed gaining root access to the router. The exploit has apparently been used to call service numbers on the Falklands, charging unwitting users.

AVM's first public press release was that this was not a serious threat (what else would they say!) because it requires remote access being enabled, which is not the case by default, and which most users don't have enabled anyway.

A few days later, it was revealed that the exploit has nothing to do with remote access at all, and that someone could take over your router if you merely visited an otherwise harmless website which contains a page with malicious code. An OS update was released the same day.

Yesterday, it was alleged that a detailled description is being published on "specific hacker sites" while several millions of routers remain unpatched (i.e. vulnerable).

Questions:

1. How could such an exploit, conceptually and practically work?1. When you visit a website (or do pretty much everything else), your browser runs a DNS query and opens a TCP connection to the remote host. The router relays your DNS query and then NATs your SYN packet (and the SYN-ACK, and all following datagrams).
In other words, the router is pretty much copying packets from one ethernet port to another (updating the IP checksum after NAT, but that presumably happens in hardware anyway, but either way software implementations of TCP checksum have been stress-tested for 40 years, they're pretty much rock-solid?). Basically, as if doing a splice from one socket to the other, except it happens in the network stack.
One should seriously hope that merely forwarding a packet to another port works 100% reliably with no exceptions and no means whatsoever of being exploited! The router doesn't validate or execute anything inside the datagrams, there is no reason for the router to even look at the "binary blob" inside each packets (... and as far as I know, it  doesn't do any content filtering?).
I'm baffled how such an exploit could realistically work. Any idea?

2. Seeing how "Linux packet filter is bugged" looks like the only plausible explanation (what else could it be?), do I have reason to start panicking about my Debian server?

1Note that I'm not looking for a how-to recipe, and I don't want to run an exploit.

After searching all day and digging through a few thousand more or less irrelevant posts in several user forums and a site which presumably "tests" for vulnerability (the telnet transcript however doesn't show anything but a somewhat broken HTML page), I found an actual exploit site.

Turns out that as usual the publicly available information was deceptive.

What is it?

The exploit, without too explicit details, is a combined XSRF / injection attack, and a sophistication of an attack that has been known since at least early 2009:

The router's web interface, which is accessible on the LAN (and optionally also remotely), has a localized user interface.
The web interface, which lets you change settings and run some commands, is a very obvious attack vector, which can be (or so you would think!) thwarted by setting a password.
The exploit works because the localization code does not verify its parameters. Localization, however, includes the login page, so the exploit will run before you even need to authenticate. Setting a password will therefore not prevent the attack.
This is the one spectacular new feature of the present exploit.
The router will pass the requested and unverified interface language to an utility which runs as root (... and executes its parameters in a shell).
Once that fact is known, the exploit becomes very obvious: Select a user interface language followed by a separator and an any shell commands which you wish to execute. This is a very typical injection attack (much like the more widely known SQL injection attacks).
Typically this would be used to enable remote access and upload the passwords/config file to another server via FTP, or download a dialer, or similar.
No "malicious code" per se is needed on the attacking website. The attack happens simply by providing an URL (for an image or such) which points to the router's default network name (or its emergency IP address) and contains the commands to execute as POST variables.
In principle, this could be done on any otherwise harmless site via an ad banner, even without the site owner knowing.
The user's browser tries to open the URL and thus runs the code on the router.

What to do about it?

Apart from the obvious thing, updating the firmware (hopefully a month ago already!), one should have a browser extension installed that prevents suspicious cross-site request/scripting, such as NoScript or RequestPolicy. This is something that everyone should have anyway.
Also, blocking ad banners is a definite consideration, if one doesn't already do that anyway.

What about Question 2?

Since it is not a router vulnerability per se (that is, a bug in the network stack), but merely an exploit of a broken user interface (which incidentially runs on the router), other Linux systems which don't have this interface, are not affected.


Why is asymmetric encryption less efficient than symmetric encryption? It's common knowledge that asymmetric encryption is in general much more expensive to compute than symmetric encryption, thus common practice is to use asymmetric encryption to establish a symmetric key for bulk data exchange. I'm not finding any information on exactly how much slower, though.

So, assuming I have some small piece of data X (say a 256 bit hash value), and I choose reasonable modern cryptographic algorithms, what is the rough relative cost to compute

X encrypted under some public key
X encrypted under some symmetric key
H(X), H being a cryptographic hash function

This depends on the algorithm. Especially with asymmetric cryptography, the speeds vary wildly. You may want to check out eBACS for more detailed and machine-independent benchmarking of various crypto primitives. As always, you need to perform your own benchmark on your own system to know exactly what to expect on a production system under the chosen conditions.
You should never use asymmetric ciphers to encrypt anything directly. If you encrypt anything other than a key, you can run into the risk of making cryptanalysis possible. RSA for example does not like encrypting non-random data. This is fine when you are encrypting a key (which is random, after all), but not if you are encrypting ASCII. Quoted from another answer (emphasis mine):

RSA has some operational constraints. With the most used variant (the one known as PKCS#1 v1.5), if the size of the RSA key is "1024 bits" (meaning that the central mathematical component of the key pair is a 1024-bit integer), then RSA can encrypt a message up to 117 bytes in length, and yields an encrypted message of length 128 bytes. That limited size, and the size increase when encrypting, are unavoidable consequences of the mathematical structure of the RSA encryption process. Due to these constraints, we do not usually encrypt data directly with RSA; instead, we select a small sequence of random bytes, which we call session key. We encrypt the session key with RSA; and then we use the session key with a symmetric encryption algorithm to process the whole message. This is called hybrid encryption.

Encrypting a small amount of data with a symmetric cipher will not let you benefit as much from its higher speed. Most symmetric ciphers have a certain one-time setup cost called the key schedule, where the key is processed and split up into separate subkeys for each component of the cipher, or spread out among the cipher's internal state. These subkeys are usually cached so they can be used directly each time the cipher is invoked. Each time a new key is used, the key schedule is run and must complete before anything can be encrypted. Some ciphers have very expensive key schedules, such as Blowfish, whose key schedule is equivalent to 521 Blowfish encryptions requiring 4 KiB of RAM and is the basis of the slow bcrypt function. Others have very simple key schedules, like TEA which simply splits the key up and mixes it with constants. When you are encrypting a large amount of data with a single key, you are able to benefit more from the speed of a fast cipher than if you are encrypting small chunks data independently.

A quick benchmark on a low-end system (Pentium III, 1 GHz) at medium load is below. Note that these benchmarks only show how fast these algorithms are on this specific machine. It may be accurate to within an order of magnitude, but a faster machine with different capabilities may not only be faster, the relative speed of the individual algorithms might be different! But to get an idea...
RSA, with different sizes:

OpenSSL> speed rsa
...
                  sign    verify    sign/s verify/s*
rsa  512 bits 0.001305s 0.000113s    766.2   8881.1
rsa 1024 bits 0.007685s 0.000372s    130.1   2687.5
rsa 2048 bits 0.050615s 0.001355s     19.8    738.1
rsa 4096 bits 0.353636s 0.005201s      2.8    192.3

AES, with different key sizes and input lengths:

OpenSSL> speed aes
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes     256 bytes    1024 bytes   8192 bytes
aes-128 cbc      21174.71k    23656.67k    24212.96k    39798.65k    40800.k
aes-192 cbc      18706.23k    20713.58k    21222.25k    34669.23k    35059.k
aes-256 cbc      16153.38k    17569.97k    18004.69k    30170.76k    30020.k

SHA-256, with various input lengths:

OpenSSL> speed sha256
...
The 'numbers' are in 1000s of bytes per second processed.
type              16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes
sha256            6537.11k    14781.14k    26256.93k    32630.49k    34562.k
* In textbook RSA, signature verification is identical to encryption, and signing is identical to decryption. Verification involves determining if se ≡ m (mod n), whereas encryption is running c ≡ me (mod n). In the real world, there are important differences involving special padding operations necessary to prevent RSA from being trivially broken.

I suppose you're wondering why there is this difference in performance. The reason has to do with how these cryptographic primitives work. A basic explanation of asymmetric ciphers, symmetric ciphers, and hash functions, along with what influences their performance, is below.
Asymmetric ciphers involve so-called hardness problems. These are open problems in mathematics which exploit the fact that an operation is easy to perform in one direction, but difficult to operate in reverse without a secret value. RSA uses the fact that it is trivial to multiply two huge prime numbers together, but prohibitively difficult to factor the resulting composite number back into the original primes without at least one of the original prime numbers. For textbook RSA, encrypting message m requires you compute c ≡ me (mod n). To decrypt c, compute m ≡ cd (mod n). Here, n is the product of the two secret primes, p and q, and d is the modular inverse of e (a public exponent which is often chosen to be a Fermat prime), found by calculating d ≡ e-1 mod (p - 1)(q - 1).
Asymmetric ciphers can vary wildly in speed because they all involve different mathematical concepts. Even distinct ciphers that use the same concepts (such as RSA and the Rabin cryptosystem) can vary in speed. These algorithms are often so slow because they require operating on very large numbers all at once, which is difficult for our modern CPUs that can only efficiently process 64-bit numbers (or a few times more, up to 512 bits for the most recent CPUs, when special optimizations are used). Modular arithmetic in particular is trivial when involving 64-bit integers on a 64-bit processor, but is very inefficient when massive 2048-bit numbers are involved.
Symmetric ciphers come in two types: stream ciphers and block ciphers*. Stream ciphers use the key to generate an endless deterministic stream of pseudorandom bytes (the keystream). This stream is combined with plaintext to form ciphertext. Decryption involves the same operation, combining the keystream with the ciphertext to obtain the plaintext. A block cipher on the other hand takes a key and uses it to permute an input of a fixed block, outputting a ciphertext block of the same size. A block cipher can be run in reverse with the same key to decrypt the ciphertext. Block ciphers must be run in a mode of operation to securely encrypt more than a single block of data with a key. Some modes allow for parallel implementations. Others must be serialized, whereas others still may be parallelized for encryption but not decryption, or vice versa.
Symmetric ciphers are very fast because they involve only the concepts of confusion (the output gives no hints about the input or key) and diffusion (a small change in either the input or the key causes a drastic change in the output). Unlike asymmetric ciphers which typically act on massive numbers, symmetric ciphers involve a large number of very simple key-dependent operations being repeated many times. Each operation is small enough to be computed efficiently by a CPU. In particular, ciphers using the ARX scheme (such as Salsa20) require only additions, rotations, and XOR operations on very small word-sized chunks of data, which can be implemented extremely efficiently on processors. There are no arithmetic operations on unwieldy numbers.
Hash functions are very similar to symmetric ciphers and they involve the same concepts of confusion and diffusion. In fact, hash functions are sometimes used to create ciphers, and vice versa†. This can be seen with Salsa20, a stream cipher that uses a hash at its core, and Whirlpool, a hash function which uses a modified version of AES. A hash function takes an input of effectively unlimited size and outputs a digest of fixed size. Like a cipher, confusion prevents an attacker from learning anything about the input from the output, and diffusion amplifies small changes to the input.
Hashes are often slower than symmetric ciphers because they have more strict requirements. In particular, hashes must not only prevent an attacker from reversing the operation (a preimage attack) and modifying an input without the hash changing (a second preimage attack), it also must make it hard to generate a pair of inputs that create the same hash (a collision attack). Being collision-resistant is hard and tends to require a rather slow and complex hash. To put it into perspective, an attacker can collide the horribly broken MD4 hash with less effort than it takes to invoke the function twice. Even still, the best preimage attack on it is purely theoretical.
* Stream cipher encryption is C = P ⊕ EK and decryption is P = C ⊕ EK where P is plaintext, C is ciphertext, and EK is the keystream generated with key K. For a block cipher, encryption is C = EK(P) and decryption is P = DK(C) for a single block of P and C. A mode of operation is required to process more than a single P or C given a single K.
† When using a hash function to construct a cipher or vice versa, the security properties demanded from the hash are different. For example, Salsa20 is a secure stream cipher despite the fact that it is built off of a hash function which lacks collision resistance. Likewise, a hash built out of a cipher requires the cipher be secure against related-key attacks, which is not necessarily required for a secure cipher on its own.


How to verify full USB drive's digital signature There are various ways to verify the validity of a file, usually checking the MD5 checksum or OpenPGP signature. Is it possible to do the same for a full USB Drive?

I'd like to be able send a USB Drive through the post and give the recipient a way to ensure that it hasn't been tampered with along the way (à la NSA's Tailored Access Operations). Part of this thinking relates to a drive of miscellaneous data but would also apply to sending a LiveUSB (e.g. Tails) with the certainty that it arrives clean.

Ideally the solution would be cross-platform open-source & OpenPGP/GnuPG-based. Physical write protection is a nice idea but still doesn't accommodate for verification.

OK, I think I'm missing something, but here's what I understand the question to be:

  How do you ensure that a flash drive cannot be tampered with (without the user knowing it) or read?

If that's the question, just encrypt the Flash Drive with a PSK. If the encryption is strong enough it will take even the NSA several thousand years (actually a huge understatement) to break it, and until then that drive can't be modified such that it will decrypt to anything intelligible.* The PSK can be securely communicated using a public-key cryptography scheme.

*Well, OK, it can. But the likelihood of them finding ANOTHER key that works if pretty low, and even then it won't be the key your recipient is using


Strange symbols in Firefox address bar with https Why are there dash marks through the https portion of this address?  Is this a feature that's supposed to further accentuate that this is unsecured https?  I just thought it was a graphical glitch because I have never seen these kinds of dash marks through any other site that I have accessed over https whether the cert is self-signed or issued through a CA.

Additionally, selecting the address in the address bar causes the dashes to go away for as long as the address is selected:

I am using Firefox ESR 45.1.1 in case that matters.

When the connection is insecure due to mixed content, and you've disabled mixed content blocking, the strike through is supposed to be solid line over the https scheme name:

(source: mozilla.net)

That yours show up as broken lines is probably a graphical glitch.


Avoid brute-force enumeration of customers in a SaaS application I'm involved in the development of a SaaS application. We host the application for different customers. A customer is a company. Each customer gets access to their hosted instance of the application via a URL https://example.com/customername.

We already got one instance where a customer tried different other companies (potentially competitors) for the customername in order to see if someone else is using our product as well. I personally don't think this is too much of an issue but I recognize that it could both be a problem for some potential customers as well as a security issue so I'm interested in mitigation strategies.

Possible solutions so far are

Add an unguessable string to the customername: https://example.com/acmeinc-8a4f. I think this a) looks ugly (and yes, we already got a customer who insisted on a particular spelling in the URL for CI reasons) and b) absolutely requires all users to have a bookmark or remember one more mostly irrelevant thing.
Just show a login form regardless of what's used as the customername and just reject any user/password combination. This looks promising at first but already we are implementing different login mechanisms including password-less login via SSO so customers will get different login screens. This also prevents a version of a login screen where the customer name becomes part of the user/password form. I'm sure sooner or later the login screen will have to match a customer's CI as well.

Is it even possible to mitigate this problem in a user-friendly way?

Adding a hard to guess string would only be security through obscurity (but somewhat effective in this instance to protect against enumeration).

You can state the security / convenience tradeoff (when using /customername) in your Terms & Conditions

You can also ask the customer to make a choice (when signing up or registering).

With the default option (using customername in the URL), anybody (including competitors) can easily go to the same URL and thus confirm that they are using your service.
If they wish to hide the fact that they are using your service, they must use an obfuscated URL (which would essentially serve as secret for that customer).

Before you implement the above, it would be useful to find out if your customers really care about it.

My guess is that they couldn't care less and the above choice would just be a source of confusion (depending on who does the actual signup at that company).

Your goal is to keep the process as simple as possible.

A better way perhaps, is to state the potential issue in your T&C and the customer can request to have their access URL obfuscated.

If they care about security, they will be reading the terms.


Difference between CVE and OSVDB? Can someone explain the differences between a CVE and an OSVDB identifier?
Both seem to serve the purpose of uniquely identifying a vulnerability or an expose, however not every OSVDB entry also has a CVE number.

How are both related and how is decided which one is assigned to a certain vulnerability?

They are both vulnerability tracking databases, if a vulnerability is registered in both databases it has both identifiers. There is no other correlation. OSVDB did track a much larger number than CVE (in part due to how MITRE assign CVEs) which is probably why you come across entries that only have OSVDB.

You could say it is similar to how different anti virus vendors have different identifiers for the same malware.


What are the security implications of losing a paper calendar? Assuming I have a paper calendar (organizer) with the following information on it:

dates/locations where I have been and where I'm planning to go
phone numbers and e-mail addresses of a few people
my own contact details so the calendar can be returned in case of loss

If I lose this calendar and a stranger picks it up, is there anything I should worry about?

As a fairly average person, I believe the worst that could happen is that

a) the finder doesn't return the calendar

b) may make annoying calls to the phone numbers / send annoying e-mails, although I wouldn't consider this as actually dangerous.

This depends a lot how valuable these information are for the finder, which also depends on who the finder is, what abilities and intentions he has, maybe what city or country you live in (amount of criminality...) etc. And it depends of course about the amount and detail of information in the calendar.

If for example you've put your vacation into the calendar and also where you live then he knows when you are not at home and might rob your home. If he knows who are your friends and maybe when you meet them (calendar) he might try social engineering attacks. If he knows what doctors you visit and how often he might make conclusions about specific illnesses. From the network of friends he might make conclusions about sexual orientation or special preferences which can be used in some countries to blackmail somebody etc.

In other words - something like Facebook could do with all the information collected about you but more physical, with more effort and probably directed against you or your friends.


Can any tools/tactics produce a higher confidence in a clean system than Microsoft Security Scanner? In the process of trying to recover data in bulk from what I assumed was a failing hard drive, Windows Security kindly notified me it had found a handful of malicious items among the recovered files. I immediately nuked that secondary drive, but for a few items it reported either "Remediation Failed" or "Item removed or restored from quarantine".

I did a full scan, then an offline scan, and a full scan in safe mode with Security Scanner, all of which found nothing. I have not seen any symptoms that match the items it detected, and have read that those two concerning reports are a common artifact of manually deleting items it found.

My finger is hovering over the "nuke it from orbit" button anyway, but for now I think this an interesting question:
Obviously nothing can guarantee it, but what tools, techniques, or combinations thereof that can produce a higher confidence than just running Microsoft's tools in sequence? Perhaps some combination of tools run on a Linux CD/USB?

If you want a guarantee, go back to scratch. Nuke the disk and reinstall from source media.

There are too many things that can't be "cleaned" using any tools.

When we want to see the contents of an untrusted hard drive, we spin up a clean VM (free stuff, look at virtualbox). We attach the drive to the VM, recover the files we know are safe. Run any kind of necessary scanning in the VM. Finally, transfer them to the host OS. Then nuke the VM and start again (or restore from the snapshot).

Hope that helps.


Self signed certificates for https Where I work, currently for internal sites, self signed certificates are being used.
In Firefox, the info regarding the certificate are displayed:

site domain: example.com
Owner: Site doesn't supply owner info
verified by: company name

I am curious as to how vulnerable self signed certificates are to a man in the middle attack, such as SSL strip. The obvious vulnerability, I can think of is that users would be used to trusting the certificate so an SSL strip wouldn't produce any new warnings in Firefox (correct me if I'm wrong). Also in a man in the middle attack, is it possible for the attacker to display the same exact certificate to end-users (also verified by: the same company name)?

Instead of using self-signed certificates for internal sites, I suggest you set up an internal CA and use it to sign certificate requests. You can import your CA's certificate into each browser used internally (either manually or via automated deployment mechanisms) and this should be as good security-wise as using certificates issued by a major CA -- as long as you take proper measures to secure the system used for signing certificate requests.

This is a much better solution than self-signed certificates and, depending on your environment, your domain controller may already offer CA services (MS Active Directory, FreeIPA, etc).


Is WhatsApp web able to read end to end encrypted messages? Is WhatsApp web able to read end to end encrypted messages between two people who have got their codes scanned?

1) Would say "NO" if they really implemented full end to end encryption..

2) Man in the middle attack scenario still exists

3) I really doubt the end to end encryption for images and videos or files,,. Considering below cases
  a) sending group messages
  b) getting content after a while even if the sender deleted the original files..


HTTPS verification failed - get certificate information iPad/iPhone I went to log onto my bank's internet banking website this morning using Google Chrome browser on my iPad. I get the red error message of death. I can't figure out why. It's happening on both my iPad and iPhone.

When I log onto the same website on Safari, I don't get a warning, and everything is dandy. Google chrome on my computer doesn't do the same thing. It thinks the website is fine too.

How do I get certificate information, or figure out why it's failing the verification?

The reason for the error, is that the intermediate certificates aren't supplied in the chain by their webserver.  Basically the SSL certificate was signed by "VeriSign Class 3 Extended Validation SSL SGC CA", but that's an intermediate CA (that was signed by "VeriSign Class 3 Public Primary Certification Authority - G5").  Ideally,  internetbanking.suncorpbank.com.au would chain the certificates together and also return the intermediate certificate.  For example, in firefox going to the site I get:

Other browsers aren't complaining as they are looking up the intermediate certificates.

For an analysis of this website and an explanation of the Chain Issue: Incomplete.   Also see google ios chrome help where they noted this issue.


Is there any way for my ISP or LAN admin to learn my Gmail address as a result of me logging into Gmail's web interface through via their network? The title says it all, really. I'm Alice, and I want to login to Gmail's web interface through my browser. Ike, the internet service provider, and Adam, the local network administrator, would like to know what my Gmail email address (username) is. Is there any conceivable way for things to happen so that either one of them could possibly learn it?

For your average home user, services like GMail (that are run over TLS) would not leak information like the username to the ISP or network administrator.

If you're using a machine that is also administered by the LAN administrator (e.g., a work computer attached to a domain run by the company), then you have to assume they can read anything you do on it.  They could have software to log your activity (browsing and/or keystrokes), they could have installed extra SSL certificates that allow them to MITM your connection to GMail (or any other site).

If you believe your computer has not been tampered with and is not under the control of someone you don't trust (i.e., the LAN admin doesn't control your machine), then you can connect to GMail over https.  (At this point, the LAN admin is equivalent to an attacker on the internet.)  Ensure that you connect to https://mail.google.com with a valid certificate, and then all your traffic between your computer and the GMail servers are encrypted.  This would include all information about your account, including the username with which you are logged in.


Security Implications of a ssh proxy vs ssh tunnel via a box I don't own In order to access my desktop or the hpc cluster at my university, I need to go though an intermediary server managed by the university.

Currently I use the "netcat method" (ssh -W) to access the desktop and hpc cluster. I have also previously used tunnelling (-L) to access these boxes.

What is the difference security-wise between these methods, given that I don't entirely trust the intermediary server?

There is no difference between those two methods as far as security is concerned.

In both cases, you first establish a connection between your current computer and the ssh proxy and then tunnel another connexion to your desktop or cluster inside the original connexion.

If you don't trust the intermediary server, your main concern should be to make sure that you're actually connecting to the real computers at the end and that your connection has not been tampered with by the ssh proxy.

To check this, you should compare the ssh host key fingerprints from your desktop and cluster computers to the one you accepted in your ~/.ssh/known_hosts file. If there is a mismatch, you ssh sessions have been intercepted (MITM) since the very beginning.

This is a perfect example of the importance of the often undervalued question asked upon a first ssh connexion:

The authenticity of host 'example.com (192.168.0.1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?


What do people mean when they talk about "hackers gaining access to our network" (at home)? Have I fundamentally missed something between the time when I sat with my 486 IBM PC in the house, fully offline, and today? Do normal people actually set up complex local networks in their homes where they have some kind of "trust anyone with an internal IP address" security scheme going on?

What does "gaining access" to a home network mean? Is that, like, exploiting the NAT router (if such a thing is used, which has not always been the case for me)? Even if they exploit the router, that doesn't magically give them any "access" to the "network" (meaning PCs connected to the router)? At best, they can maybe read plaintext traffic, but how much such is there these days? I shall hope 0% of all traffic.

So what do people mean when they talk about "gaining access"? No updated version of Windows has ever just allowed somebody to randomly connect remotely to "gain access", regardless of the presence/absence of a router/switch/whatever in between. Or, if it has, that's some kind of "0-day" exploit or unknown-to-the-public exploit. The so-called "hackers" that people talk about more than likely never "gain access" like that at all; I bet it's 100% social engineering and tricking them into running coolgame.exe as sent to them in an e-mail attachment and things like that.

My intention with this question is to understand people and the world. I'm genuinely wondering about this since not a day goes by without me feeling extremely paranoid about security and privacy, especially knowing how incredibly naive I used to be, and how naive people in general seem to perpetually be about these things.

Do normal people actually set up complex local networks in their homes where they have some kind of "trust anyone with an internal IP address" security scheme going on?

They do. Many have a PC or notebook, mobile phone, a printer, smart speaker (Alexa etc), SmartTV, IP camera for surveillance, smart home devices ... and these are typically all connected to the same router.  Especially the cheaper devices are often vulnerable enough so that they can be hacked and recruited to be part of a botnet, see  Mirai.

Routers are often vulnerable too. If these get hacked they allow an attacker not only to be part of a botnet but to intercept and change traffic. With luck one will only get lots of advertisements on your computer but links you click might also lead to phishing sites or downloads might be replaced with malware in transit.

And devices in the same LAN are usually configured to trust each other. Windows ask for the type of network and if private network is configured it will share folders to other systems in the same network etc and thus also to an attacker located on one of these systems.

  At best, they can maybe read plaintext traffic, but how much such is there these days? I shall hope 0% of all traffic.

If you look at "HTTPS usage in Chrome worldwide" in the Google transparency report you'll see that about 90% of the traffic is currently encrypted in western countries but that it might be much different in other areas, like currently only around 75% in Indonesia. And this is amount of traffic, not number of different websites. Especially many of the smaller sites are still HTTP only.

And this is for internet facing traffic only. Most traffic in the LAN itself (like Windows file sharing) is still not encrypted.


Issues with format of Logs generated by Auditd I have below snapshot of log generated by auditd when I tried to delete a user. It doesn't have hostname and addr in the logs:

 type=DEL_USER msg=audit(1404811391.243:4407153): user pid=5772 uid=0 auid=513 ses=185589 msg='op=deleting user entries id=532 exe="/usr/sbin/userdel" hostname=? addr=? terminal=pts/1 res=success'

My auditor wants that hostname and addr to be captured in logs when such administrative activity is performed. Also the date/timestamp is not in good format. Please suggest.

I am pasting my auditd.conf file

auditd.conf

#
# This file controls the configuration of the audit daemon
#

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 4
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = none
##name = mydomain
max_log_file = 5
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key

Here is a quick fix for your datetime format conversion http://www.linuxquestions.org/questions/linux-software-2/how-can-i-read-the-audit-time-stamp-msg%3Daudit-1213186256-105-20663-a-648547

As to your lack of hostname that is a factor of using the name argument as you are (defaults to none if not properly configured) - see http://man7.org/linux/man-pages/man5/auditd.conf.5.html Replace that with name_format=hostname and that issue should disappear.


Did I get hit by the recent Java exploit? Looks like the website iphonedevsdk was responsible for serving up the malware that's been causing some of the recent security exploits. According to my browser history, I visited that site back in December. I've had Java turned off in my browsers since forever, but I do have it installed in the OS (OS X 10.8). I did install the security update from Apple yesterday (2/19).

If Java is turned off, it is unlikely that a Java exploit could have hit you as it would have first had to exploit the browser in to executing Java despite being off.  It is worth clarifying that Java and JavaScript are not at all related though and verify that it is in fact Java that you have disabled.


How to find out what websites are associated with an IP that has port 80 open? New to security, so please forgive my ignornance - I have a machine with port 80 open, and I found the following information:

Starting Nmap 7.01 ( https://nmap.org ) at 2016-09-29 23:46 EDT
Nmap scan report for 127.0.0.1
Host is up (0.085s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh?
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-server-header: Apache/2.4.7 (Ubuntu)
| http-title: Trees of Large Sizes
|_Requested resource was site/index.php/

This clearly is information about a website of some sort, but I'm not sure how to go about finding out what/where that website is?  Any pointers would be super helpful.

Try 127.0.0.1/site/index.php , seems default doc root is /var/www/html/site


Can someone using Thunderbird with Enigmail plugin be a victim of email spoofing Let's say Bob pretends to be Alice, spoofs a non encrypted email to make it look like Alice and sends that to John who uses Thunderbird with Enigmail plugin.

Well, you can spoof an email address without signing the email. However, if you get an email from an address and the email is signed, you know it's not fake. The signing process will provide you with enough information to verify that the email is from who it's meant to be from.

For instance, you could spoof an email from a bank asking for customer details. You could not spoof an email signed with SHA256 from a bank asking for customer details. OpenPGP communication requires trust levels to be accurate. In the case of something like a bank, you should trust their OpenPGP key if you get it from them physically or (say) with your new credit card.

Without a web of trust, the idea behind OpenPGP falls down. If you don't know exactly who gave you a key in the first place, all you can confirm is that the same (unknown owner) key is being used to sign things. Nothing less, nothing more.


Circumventing Netflow's visibility on SSL traffic In a SSL handshake, the hostname is visible most of the time as it is needed to validate the certificate over HTTP. Netflow is thus able to pick up the common name from the certificate exchange, revealing the hostname.

Would a C&C server be better off using a self-signed certificate using IP as common name (since legitimate providers do not allow that) with a static IP and no domain name, so that when Netflow queries, it only sees the IP address? Since C&C IPs change frequently, it would be hard for any investigations to make out any meta data out of this. Also, SSL certs and domain names leave traces on whois, and might be breadcrumbs for investigation. The certificate is between servers without user interaction, and security is not key, so self-signed is acceptable.

While a C&C client would hide its real target by not using SNI it would be suspicious especially because it does not use SNI with HTTPS while everybody else does. It might be better then to claim that it connects to some innocent target by setting the SNI extension accordingly but in reality connecting to the C&C server. This only needs some fiddling in the TLS stack and is not much harder for an experienced attacker to do.

But since the certificate of the server is sent by the server in clear with a  full TLS handshake one can still check if the certificate returned by the server matches the name given in SNI and is also issued by a trusted CA. To bypass this the C&C client might try to simulate a resumed connection everytime. To do this way more fiddling with the TLS stack is needed so it might be simpler to use a protocol which looks enough like TLS to fool the detection but is not real TLS. I think this is what Skype has at least done in the past to bypass firewalls and maybe it still does this today.

Another approach would be to use domain fronting, i.e. (mis)use a system which is serving multiple domains on the same IP address, serves the certificate based on the SNI extension in the TLS handshake but serves the actual content based on the Host header which is encrypted within TLS and thus not accessible when doing passive inspection. In this case it looks like the client connects to some innocent site while in reality it connects to its C&C master.

If the attacker controls relevant parts of the server (for example because it was hijacked) it could also (continue to) serve a mostly innocent site and then use only specific path on it for the C&C communication. Since the path of the URL  is not visible when doing passive inspection of HTTPS it probably looks like the client is just accessing innocent data on this site.

Still, SNI is not the only thing which can detected with passive analysis. The handshake of the client also shows which kind of ciphers it supports and the preference and a variety of TLS extensions and their order. Also significant pattern of the traffic like size of request and response  or timing are still visible even if the traffic is encrypted.  This can also often be used to fingerprint the client and thus distinguish typical browser from other clients and maybe known C&C clients. Cisco has done interesting research in this area.


I suggest to just ignore it, it's not worth the trouble. There are way too many infected machines out there.

If you have too much time at hand, you can do a whois query on the ip-address. Then contact the ISP, telling them that they have an infected customer. The email address to contact is usually "abuse@" domain.

In this case whois 83.140.8.18 even returns a comment saying:

  In case of abuse, send mail to abuse (at) rixtelecom.se


Public-key-based website login I'm looking to implement a public-key based login / authentication for a website.

This will not be used for general users – it will be used by both automated scripts and for admin logins.

Before someone suggests it, I don't think I want to use client certificates – my understanding is that:

Client Certificates are sent automatically, whereas I'll not want the login to be performed automatically whenever an admin visits the site (they may not wish to login, or may wish to login as another user).
Using Client certificates will trigger browsers to prompt all users to provide certificates, which isn't acceptable
Client certificates require a config change in Apache/Litespeed. I need a solution which can be implemented entirely at the application level in PHP.

If there's an easy way to use client certificates which negates these issues, I'm interested.

My proposal is:

The client connects over HTTPS (everything is anyway, but it's relevant that hopefully this prevents any MITM attacks stealing tokens)
The client sends an identifier (username), and some data signed with a private key
The server looks up the public key for that username, and verifies the signature for the data is correct. If it is, the request is authenticated.

Obviously the data in question should change, to prevent replay attacks.
One option is that the server sends some random data to the user, but this requires an extra step.
I'm thinking this can be skipped by using the current time (modulo say 30 seconds) for the data, or a rolling code.

** Assumptions **

I will use existing openssl routines to perform the signing and verification. I'm not rolling my own cryptography!

Storing the private key for the client can be done securely. Storing the public key on the server can be done safely (or at least, this isn't the weak point; if an attacker can change that data in the database,
the server is already compromised).

Other Requirements

I don't want to use any 3rd party services such as OpenID; I need it to work just between the client and the server.

It needs to work with both CURL and a web browser. For a web browser, I can generate the signed data separately and enter it into a form, similar to a 2FA code.

In terms of how secure this is, I'm looking for something equivalent to SSH.

Questions

Is there an off-the-shelf solution which I should use instead?
Is this approach secure, or is there a flaw?
Is there any advantage to having the server send some data to the client to sign, rather than using a timestamp?

As stated in my earlier comments, and an answer to Question 1, a solution already exists for what you wish to implement, and that is the FIDO2 project by the FIDO Alliance. This is a project that consists of a set of specifications and protocols with the main idea being that of "leveraging common devices to easily authenticate to online services in both mobile and desktop environments" (source) and, thus, essentially get rid of passwords once and for all. Industry leaders such as Google and Microsoft have also started to adopt FIDO2 for their internal as well as consumer-facing services, while all major browsers support it.

FIDO2 includes a web authentication standard by W3C, WebAuthn, which in simplistic terms tells you how to implement an API for accepting public key credentials on your website. Clients are then able to use an authenticator that securely stores the private key and sign the data sent by the server to register and authenticate. This is performed by the Client to Authenticator Protocol (CTAP). The authenticator can be in the form of a security key (such as YubiKey), the TPM on a laptop, or even Android phones running OS version 7.0 or later (source). As such, users can secure their authenticators by adding another local authenticator factor, such as a PIN or Biometrics.

Getting into FIDO2 by reading through the actual specifications may be a bit daunting, so I would suggest to look at the following blog post which explains all of this pretty well, at a high-level of course. I also recommend this video by FIDO Alliance for a dive into the technical details. Something else that may be confusing is the difference between FIDO2 and FIDO, and other standards such as U2F and UAF. The answer to this question explains the differences.

As per Question 2, my recommendation would be to stick with well-research and well-developed solutions rather than coming up with your variation of public key based authentication system. All systems are susceptibles to flaws, but I would trust the wholistic effort going into FIDO2 more than I would trust my own efforts in devising something from scratch. To date, I am not aware of any vulnerabilities with WebAuthn or CTAP.

As per Question 3, @Angel's answer covered it well:

  You are allowing replay attacks for 30 seconds. Plus, all the
  complexity of the clocks of client and server drifting apart. You
  should have the client sign a server nonce (which can then include a
  timestamp), rather than trying to "simplify it".

A combination of a nonce and a timestamp is widely implemented in many popular authentication schemes, such as Kerberos to name one.


Securing a VPN connection I'm new to this
we want to install a new VPN connection that will be used to connect using Internet to some networks in the office
the contractor want to use a" Cisco NAC Network Module or Cisco IPS AIM and IPS NME "
-- I really don't know what he is talking about --

This is a server farm network and there will be 2 VPN connection to communicate with 2 server farm separately

I want to install a firewall but I wanna know how its going to help me securing the connection

Can you please tell me what the firewall in this case should be configured to do?

Firstly, firewall is not a magic word: simply installing one at random without a clear idea of what you want it to do is not going to help.

Secondly, neither NAC nor IPS are VPN solutions, so you need your contractor to explain her recommendations again.

More generally, firewalls used in conjunction with a VPN are normally designed to restrict what the VPNed in user can access on your internal network. By default a VPN connects a remote user over the public Internet to your internal network, giving them the exact same access as if they came into your server farm and connected their machine there.

Sometimes you want people coming in via VPN to have less than total access to the internal network: you do this by putting a firewall between the VPN connections and the rest of the network.

In this way you can define firewall rules such as "if someone comes in over VPN, only allow them access to servers A, B, and C, and nothing else."


Bitlocker: USB Key vs Password? My Windows 8.1 Pro laptop doesn't have TPM, so I can use bitlocker with either a USB key or a password.

If I use a password, it will be 20 almost random characters, it will contain no words in any language, it will have at least one small letter, one capital, one number and one special character.

Now, you will probably ask, in what environment you will use that laptop? It's a laptop, so I will take it with me everywhere. I am using bitlocker to protect it from:

a) thieves (most likely they will have no idea what encryption is)

b) friends (who know what encryption is better than me). We sit close to each other and I don't want them to see my personal projects.

Should I use a USB key or Password and why?

edit: In terms of brute force protection, how much better the usb key is?

The decision here is between something you know versus something you have.

Password, something you know:

Password cannot be stolen together with your laptop.
Humans are bad at choosing strong passwords.

USB key, something you have:

USB key will have some guaranteed cryptographic properties unlike most passwords.
If you keep the USB key with you, it might easily be stolen along with your laptop.

So for the two adversaries you mentioned. Thieves may be able to steal your USB key along with your laptop. Friends might also be able to get access to your USB key if you do not secure it. On the other hand, thieves cannot get your password if they only steal your device and friends can't casually get it if they fit my common-sense definition of friend.

However, if you have the scenario where someone has access to your device without you suspecting them, you are vulnerable to many attack vectors:

Someone installs a small keylogging device that intercepts your keyboard (only applicable if you use peripheral keyboard)
Someone with physical access to your device resets it and boots into a memory dumping utility. The memory dump can then be analyzed to retrieve the Bitlocker key (Elcomsoft Forensic Disk Decryptor can do this). This can be avoided with a TPM.
Someone shoulder surfs you and sees you typing in your password.
If you have a FireWire port, it's possible to dump the active memory by exploiting DMA. Dump gives them the key. I think it's possible to prevent this through Group Policy, disallowing FireWire devices from activating if the device is locked.

Other than that, it's worth remembering that if malware ever gets onto your machine (e.g. friend tricks you into running something) it can easily steal the encryption key (and do anything else).

In my opinion, a TPM is an important part of setting up BitLocker in a secure way.

Some additional information:

Building a Bulletproof Windows BitLocker
A Password is Not Enough: Why disk encryption is broken and how we might fix it


Is there any risk in allowing more failed login attempts before autobanning for a longer time? Most software and services seem to have low "burst" settings, like 3 to 5 login attempts before a temporary autoban for a couple minutes. Especially banks have a very low limit before access is denied.

I find this very annoying and, when possible, I always set it to allow 15 (or more) login attempts. My password are non-dictionary and brute-forcing in under 15 attempts is out of the question. If you have a number of passwords that are possible, for example from looking over my shoulder, you'll probably still need quite a few attempts. In some cases, benign software automatically attempts a number of logins (e.g. Filezilla FTP), making you trigger the autoban already because of that.

When configuring a higher number of failed login attempts, I also configure it to ban for a longer period (e.g. 24 hours instead of a few minutes). Surely that's no legitimate user, or they really did forget their password and need to reset anyway.

Why don't more websites and software do this by default? By now I have a pretty long (mental) list of passwords that I use. After not using a service for a while, it might be any of at least 3 different passwords, each having 2 or 3 variations, and each variation needs to be typed twice to be sure you typed it correctly. Additionally, the services that allow only 3 attempts are usually also the ones that enforce ridiculous passwords (8 character uppercase, lowercase, digit, special character, no spaces, no longer than 12 characters... try remembering what permutation you used there to make this work).

Same goes for delaying login attempts, FritzBox routers are really good at this. One failed attempt is 8 seconds delay, the next 16, the next 32... really great, except my fat fingers might end up getting me a delay of 16 seconds while I only had two failed attempts. I'd rather like that it limits me to two attempts per second and jumps to 300 seconds delay after 10 attempts.

Why does lots of software default to only a few login attempts and short bans, instead of a higher number of logins and a long ban? The latter seems much more practical to me. Is there any valid security reason behind this, or is it just another of those common practices that are there because they made sense at some point in history?

A lot of people have very short very weak passwords - 40% of all users share the same 100 passwords, 14% share the same 10 passwords (see article). So even a 10 or 20 passwords may suffice for an attacker trawling multiple user accounts. Hence the low cutoff bar.
If the user is legit and has simply mistyped their password several times, they have probably forgotten it. Some organizations like to be directly contacted for password reset, despite the possible support overhead.
While I personally like exponential time-locks; unless an organization has 24/7 tech support, timelocks will turn into normal user lockouts on a weekend. Additionally a distributed attack across multiple users at once may rearrange the exponential delays sufficiently that, on a bell curve, some user account will be cracked well before the exponential delay for a single user would imply.
The organisation may assume that a denial of service is either sufficiently resolvable  or unlikely enough that a DDoS lock out of all users is a low concern.
An organization may feel that the user's access to their service is a privilege and the user or service's information is more valuable than the user's ability to access it. Hence a priority toward operational security instead of user convenience. Afterall the actual users are rarely invited as direct stakeholders in the software design workshops.
Initial solutions for Points 1 - 5 were made on early computer systems and then often copied as "good enough" for computer systems made decades later. The original systems involving remote login were military and university projects; where the user was a supplicant not a customer.


Open (residential) less safe than Public WiFi? I connect to WiFi at coffee shops using VPN regularly but I'm apprehensive to join a random open network (ex. "CARRIER47393") in a residential area. Should I avoid using it (even with VPN)?

My concern is that a hacker could set up a free network, allowing greater access to data (because they have full control of the entire network "admin") vs hacker accessing the network remotely at a coffee shop ("user").

Open wifi is open wifi, whether is is residential or not.  A MITM can be performed on a coffee shop network just the same as it could be done on a residential network, albeit using different means.

There is no higher or lower level of security between a coffee shop's wifi and a residential wifi.


How is chase mobile deposit verified? I read this but it didn't ask the question I want answered.
How is Chase Mobile Deposit Secure?

What I want to know is how do they avoid accepting a Photoshopped check?

When someone gives me a printed check(which is the majority of checks I get), I could extremely easily take it, change the value on it (including the text portion) to some arbitrary number, change the date to a couple days before I plan on depositing it, and advance the check number by 20 or so, so that the bank doesn't see it as a check that has already been deposited. As one last precaution in case they check the signature for matching a previous check exactly, I can take the person's signature off and Photoshop in one from another document or really old check.

Once I forge the check on the computer, I could print it out and cut it to the right size. Take the picture, and now what? Does Chase have any way to verify that it is not a real check other than waiting to see if the other customer to says something about it?

(as a side note, if I tried to bring this into a bank, it would be very obvious that it is fake)

It doesn't help in Chase's favor that the app takes such LOW quality pictures either. That problem works in my favor because even somewhat large defects in my Photoshopping will be completely hidden by the low quality picture.

[edit]
We should assume the forged check looks just like the real one in the picture taken by the app (because it actually would.)

Just it would be check number 520 instead of 500 so that the bank doesn't see it as a duplicate.

Suppose I write you a check and you deposit it, but also produce a forgery that you deposit a few days later.  Soon or late, when I reconcile my account, the forgery will be detected, I'll complain to my bank, and my bank will claw back the money from your account at Chase.  Doesn't matter whether it's paper or a picture.

If the forgery happens to overdraw my account, it'll be detected at once, even if I have "overdraft protection," because I'll be notified that the protection kicked in.  Otherwise, it'll be detected during reconciliation of my account.

That is why well-run businesses keep only a few bucks more than their outstanding checks in their operating account, have a separate account for payroll, etc.


Is it okay to publish a TLSA records for non-DNSSEC CNAME'ed services? In the scenario with two domain names

example.com secured with DNSSEC
example.org not secured with DNSSEC

and a mail service running at smtp.example.org:

I want to secure the mail service using TLSA/DANE. Is this somehow possible and can I expect this to work for most DANE aware software?

The idea is to publish a TLSA record _25._tcp.smtp.example.com and a CNAME record smtp.example.com that points to smtp.example.org.
The response from the org zone cannot be trusted because it's not DNSSEC secure, but the TLSA record from com can. Is this a reasonable way to enroll DANE for zones that are not yet DNSSEC ready?

Update:
I just found this in section 7 of rfc7671:

  The complexity of coordinating key management is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 6.  Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated).  If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups.

So in my case the the validation status is not "secure" and the rfc continues with:

  Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name.  That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name.

The client 'should' eventually resolve the initial domain name, but I'm not sure if that actually happens in most cases.

The configuration:

example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

Will yield DANE-secured TLS with at least some DANE implementations, e.g. Postfix.  However, this may not work in all cases, for two reasons:

CNAMEs violate the RFC requirement that the exchange field of the MX record be already canonical and not a CNAME (see https://tools.ietf.org/html/rfc5321#section-5.1), therefore, though I don't know of any MTAs that disallow CNAMEs here, they'd be compliant with the standard if they did.  However, in my survey of (today) 4,244,642 DNSSEC-signed domains that have MX records, I find 1,432,478 distinct MX hosts of which 21,262 are CNAMEs (serving 34,886 domains), and apparently not having problems. So in practice CNAMEs in MX records appear to work.
More importantly, https://tools.ietf.org/html/rfc7672#section-2.2.2 explains that TLSA lookups should be skipped when the MX host name lies in an unsigned zone, as evidenced by the security status of its A/AAAA records. When no CNAMEs are involved this is simple, and implementations are unlikely to mishandle this case.  When the MX hostname is a CNAME into an insecure zone, I expect that some implementations (e.g. I believe Exim) will not determine the security status of the initial CNAME, and so (unlike Postfix) will not attempt TLSA lookups in that case.

Figuring out whether the CNAME RR pointing at insecure A records is secure requires a separate CNAME query for the same name, which suppresses recursion in the resolver and returns the security status of the CNAME itself. Exim, and likely some other MTAs may not do that. While RFC7672 says they SHOULD do it, it is rather subtle logic, and likely to be skipped in implementations.

Bottom line, if you really want DANE to work, avoid CNAMEs into insecure domains, and if necessary, publish A/AAAA records in the secure domain that duplicate the A/AAAA records of the underlying host:

example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1


How can one secure Exchange 2010 cookies? We have received the below finding from an IT audit.

  Missing Secure Attribute in Encrypted Session(SSL) Cookie:
  It is best
  business practice that any cookies that sent over (Set-cookie) an SSL
  connection to explicitly state secure on them

Can someone can explain what they are and how to secure them?

A cookie that has the secure attribute set will only be sent over an HTTPS connection, so if the client in future attempts to connect to the server over unencrypted HTTP, the cookie will not be sent with the request, and will not, therefore, be exposed to theft.

As to how to ensure your specific cookie is marked as secure, you will have to consult with the application owners or documentation in order to ascertain what steps you will need to take.


How to protect publicly placed NFC tags? Recently, the appearance of public NFC tags are growing in major populated areas. The company I am currently working along side with wants to increase their advertisements with a NFC tag placed on the side of their ad so users can navigate to their website and,want to later expand it to opening up the app store to download a specialised application.

How would one go about protecting the tags at that point? As these tags are available to purchase to the public and do not take two wits to program something simple & someone who specialises in programming can figure out a simple malicious hijack (there's a few which come to my head, for security sake I will not name)

So with the scenario that unattended public NFC tags, how to prevent malicious hijacking ie. Prevent person A from swapping out legit nfc tag with a malicious tag in its place?

The two problems you are facing with NFC tags is either preventing a re-write of the tag by a malicious user, or the NFC tag being replaced by a malicious one in the advertisement.

The first problem can be resolved by using read-only NFC tags. These cannot be reprogrammed and thus thwart any attempts to modify the NFC tag contents.

The second issue is a bit harder to prevent and depends on the physical security of the advertisement. Embedding the NFC tag in such a way that it cannot be removed or, when removed, would invalidate the advertisement is one way to go. This is however specific to what that advertisement would look like. I would imagine if it's just a piece of paper, the NFC tag should be embedded in that piece of paper in such a way that if removed, the advertisement would have to be torn apart or something to that accord.


Linux Runtime Memory protection I'm searching for a solution to protect process memory at runtime level in Linux (just like GameGuard in Windows). I googled many times but didn't get any useful information.

Does anyone know any existing projects or research about this subject?

I read of one... You find a very remote place, preferably not on a map anywhere. You put the Linux run time you want to protect in a vault like bunker with no physical access, running on its on dedicate power supply (of course this has to be a perpetual motion machine based power supply), in a facility that has no staff, no network connections and is absolutely guaranteed to be inaccessible. Of course you must remove any USB, or other ingress ports into the machine, and pour super glue into all seams in the boxing of the machine to ensure no one can crack the case and put jumper cables into any communications layer.

One way to protect run time memory... Of course a very restricted and severe way.


Browsing exploits with Metasploit console Is there any way to browse certain exploits in MSFconsole? The show exploits command shows too many and I cannot find a way to show just Windows file format exploits, for example.

There's a couple of ways you could do this, that spring to mind

First up would be using search  which will show exploits matching the search term, (eg, search fileformat would return modules matching that term.  The other was would be to use the tab completion, so if you type:

use exploit/windows/fileformat/ and then hit Tab. It'll scroll through all the exploits under that folder.


Nmap results of home network I've been trying to up my security recently and decided to check my router's firewall by doing an nmap scan (wan). I'm surprised by home many ports it found:

Host is up (0.032s latency).
Not shown: 986 closed ports
PORT      STATE    SERVICE
22/tcp    filtered ssh
23/tcp    filtered telnet
53/tcp    open     domain
80/tcp    open     http
443/tcp   open     https
705/tcp   open     agentx
1026/tcp  open     LSA-or-nterm
1027/tcp  open     IIS
1028/tcp  open     unknown
1029/tcp  open     ms-lsa
2601/tcp  open     zebra
49152/tcp open     unknown
49153/tcp open     unknown
49154/tcp open     unknown

I don't think my router is doing a great job of closing unneeded ports. I think having ports 22,23,53,80,443 open is ok, since those are all necessary things, but I don't see what the rest are used for. Which ones should I close?

Here's an example for 1026: http://www.speedguide.net/port.php?port=1026

A lot of them seem to be associated with Trojans, actually. I have a firewall set up on my main linux machine, but there are other windows computers connected that I'm not in direct control of.

Edit: So maybe a better question is to ask what these ports are for and what they likely are open for.

If you really did check the WAN side of your router and found these open, you have a real problem.

If that is really the case, I recommend disconnecting it and doing a factory reset and upgrade of the firmware.

In particular, the TELNET port should NEVER be open since that is allowing unencrypted login and access to a machine, maybe even your router.

I rather suspect though that you checked the LAN side not the WAN side.


Demonstrating the risk of drive by downloads to the uninformed I have come across many people who don't believe in antivirus solutions and don't patch or update their OS and applications. "I never visit dodgy websites", "I only use the internet to read emails" "I am not stupid, I can distinguish between emails that are dodgy and which are not" ... you know what I mean.

I need to show them that they are vulnerable without causing them damage. Is there a way or a script I can use to show them exactly how naive they are? A script which would do a drive by download which would trigger a "you have been pwned" would do the job.

Is there a way or a website to show them exactly how naive they are?

Sure. Start by explaining them the vector attacks of this type of attacks. Tell them that it is common to find vulnerabilities in web browsers, their plugins or even extensions. Explain them that as such vulnerabilities  are common, drive-by download attacks are always possible.

This done, a good and effective method, is to give them real world examples of well known safe and reputed website that have been compromised to perform drive-by download attacks. In this, I can give you two examples:

Thousands of visitors of the Amnesty International's homepage on 2011  have been infected by a drive-by download attack. The webpage in question was running a Java applet suffering from the CVE-2011-3544 vulnerability.
On October 24th, 2013, the admins of the famous php.net website said that their website delivered malware to its visitors using a drive-by download attacK.