Why do some Java APIs bypass standard SecurityManager checks? In Java, normally permission checks are handled by the SecurityManager.  To prevent untrusted code from invoking privileged code and exploiting some bug in the privileged code, SecurityManager checks the entire call stack; if any of the callers in the stack trace are unprivileged, by default the request is denied.  At least, that's how the standard SecurityManager checks work.

However, a few special Java APIs follow different rules.  They bypass the standard SecurityManager checks, and substitute a weaker check.  In particular, they check only the immediate caller, not the entire call stack.  (See Guideline 9-8 of the Java Secure Coding Guidelines for details.  The special APIs include, for example, Class.forName(), Class.getMethod(), and more.)

Why?  Why do these special APIs bypass the standard checks and substitute a weaker check?  And, why is this safe?  In other words, why is it sufficient for them to check only the immediate caller?  Doesn't this re-introduce all of the risks that the standard SecurityManager checks were designed to defend against?

I first learned of this when reading an analysis of the recent Java zero-day exploit (CVE-2012-4681).  That analysis deconstructs how the exploit works.  Among other things, the attack involves taking advantage of the weaker checking done by these special APIs.  In particular, the malicious Java code manages to get a reference to a trusted system class (through a separate bug), then it fools that trusted system class into invoking one of these special APIs.  The resulting permission check looks only at its immediate caller, sees that the immediate caller is trusted, and allows the operation -- even though the operation was originally initiated by untrusted code.  Thus the weaker checks don't stop the attack, but as far as I can see, this attack would have been prevented by using the standard SecurityManager checks (since the caller's caller is untrusted).  In other words, this recent attack looks like an example of why the weaker check is risky.

However, I know the Java designers are smart folks.  I suspect the Java designers must have considered these issues and had some good reason to bypass the standard checks and substitute the weaker checks for these special APIs -- or, at least, thought they had a good reason why this was safe.  So, maybe I'm missing something.

Can anyone shed any light on this?  Did the Java designers screw up with these special APIs, or were there valid reasons for substituting the weaker checks?

Edit 9/1: I'm not asking about how the exploit works; I think I understand how the exploit works.  I'm also not asking why, in this particular example, the trusted code that invoked these special APIs was buggy.  Rather, I'm asking why the special APIs -- like Class.forName(), Class.getMethod(), and so on -- are specified and implemented to use the non-standard weaker permission check (only look at the immediate caller) instead of the standard SecurityManager permission check (look at the entire call stack).  This design decision (of using weaker permission checks for those special APIs) allowed the recent vulnerability, so it would be easy to criticize the design decision.  However, I imagine there might have been some good reasons for doing things this way, and I'm wondering what those might be.

(This is only a general comment on the "why", not on the specific attack you are alluding to.)
Unfortunately, the Java designers found that it was highly possible to paint yourself into a corner, structurally speaking. For instance, there are classes in java.io and in java.net, which are both involved in doing I/O. Let's assume that a given JVM has special OS-interaction native code in java.io.FileDescriptor, which allows it to do send() and receive() system calls (that's not the case of the Sun/Oracle JVM, but it could happen in another JVM, and indeed it does in at least the one I once wrote). To enforce the sandbox semantics, these methods are not public, of course.
The implementation of java.net.Socket would like, quite naturally, to use these methods. But, as per the naming conventions, Socket is a class which is located in the java.net package, not java.io. How can it access the non-public methods of java.io.FileDescriptor, considering that it must do so even if invoked from non-trusted code (non-trusted code can open sockets, albeit not to every destination) ? There are mainly two ways:

Add some "bridge" native methods in java.net.Socket, which forward the calls to the methods in java.io.FileDescriptor. Native code sneers at packages and visibility; native code can do everything.

Allow the code from java.net to do some reflection to access non-public methods in other packages. Code which can do that can do about everything, because it could modify the data structures used by SecurityManager itself (hey, I remember that you pointed that to me yourself, maybe ten years ago, in a Usenet discussion where we were both using our real names). So, unbounded reflection must not be granted to everybody, but, in the situation I describe here, it must be granted to code in a specific system package (java.net) even though that code is called from an untrusted applet.

The second method requires the weakening of the security model. Actually, it is quite generic: if the untrusted applet must do anything useful at some point, it must be able to access the system (if only to display the result of computations or send it back to the server), which needs a kind of gate. Native code is such a gate. The security weakening model is another kind of gate, which has the added benefit of staying in the "pure Java" world (I can understand that in the JVM maintenance team, native code is probably frowned upon because it makes things more expensive). The bad side is that by weakening the security model, the attack surface is greatly enlarged: now, all the Java code in the packages-with-privileges has become critical. To reuse @Hendrik's analogy, it is about giving a root setuid bit to a substantial chunk of code (from the java.* packages).
In particular, the way that Java weakened the security model is to designate some special APIs -- like Class.findClass(), Class.newInstance(), Class.getMethod(), and other reflection-related APIs -- as using weaker permission checks.  In the example above, this allows trusted system code in java.net.Socket to use these special APIs to get a reference to a non-public method in java.io.FileDescriptor and invoke it reflectively.

For instance, the java.net.Socket code can use Class.getMethod() to get a reference to the non-public method in java.io.FileDescriptor (this is allowed since the immediate caller of Class.getMethod() is java.net.Socket(), which is trusted code) and then invoke it.
Notice that this implementation strategy relies upon Class.getMethod() to use the weaker permission checks.  It just wouldn't work, if Class.getMethod() used the standard permission checks.  If untrusted code invokes java.net.Socket, and then the java.net.Socket code calls Class.getMethod(), the standard permission checks would reject this call because there is untrusted code somewhere on the call stack, and the java.net.Socket stuff wouldn't work right (in non-attack scenarios).  In contrast, the weaker permission checks used in the weakened security model do allow it.

So, the weaker permission checks help the Java designers get themselves out of the corner they painted themselves into.
Supposedly, with a "perfect" structure of the system code and naming conventions, a handful of native methods would be sufficient, but the presence of specific is-immediate-caller-from-a-trusted-package calls in the JVM system library code shows that the structure of said code is not perfect.


Corrupt password being pulled from wireshark data? Hello everyone,
                I currently have a pcap file that contains an unencrypted Telnet session, and when I trace the TCP stream the password is in a format like so: pas...ord (please note this is just the format not the actual password). My question is, what can  I do to be able to reconstruct the password fully? Thank you for your time.

What does the hex dump say? In general, 8-bit and non-printables are printed as '.' by most viewers. Pretty much like this (just on a Linux prompt though):

$ echo H€llo | hd
00000000  48 e2 82 ac 6c 6c 6f 0a                           |H...llo.|
00000008

And here is an example of how to decode the hex:

$ perl -ne 'chomp; s/ //g; print pack("H".length, $_)' <<< "48 e2 82 ac 6c 6c 6f 0a"
H€llo

You might also need to figure out what encoding was used and convert it to whatever your teminal is using.


How can I find out the password hashing schemes used by the specific Unix accounts I log in to? Every day I ssh in to 3 or 4 independent Unix accounts.  I have been regarding them as more or less "equivalently secure" on the grounds that I'm using ssh, but after learning of how much variety there is out there in password-hashing schemes and their resistance against dictionary attacks I've become a lot more interested in learning the specific details for the systems I use.

I have found some too-brief summaries of what some OSs use by default (e.g., see here), but I'd like something more detailed.  More importantly, I'm less interested in what various OSs do "out-of-the-box" than in what the specific systems I log in to do.  Is there a standard way to find this information?

(I hope this question is not too naive.  Yes, of course, a password cracker would also like to know the information I'm asking about, but my understanding is that no competently designed password-handling scheme hinges on its being secret.  Therefore, I expect that the information I'm after should be readily available to the users of a system.)

Short version:

/etc/shadow contents will tell you what format each user uses, but
needs root to see them - @MikeScott nails it.
/etc/pam.d/* files will tell you what format a system encodes new passwords
with, and should be accessible to regular users, which may be all you have.

Long version:

Most modern Unix and Linux systems use PAM, the Pluggable Authentication Modules, for handling authentication.  As a result, the hashing algorithm used to encrypt passwords is usually defined in one of the /etc/pam.d/* files.  Peeking at Ubuntu 14, I see it's in /etc/pam.d/common-password file:

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords.  Without this option,
# the default is Unix crypt.  Prior releases used the option "md5".
#
password    [success=1 default=ignore]  pam_unix.so obscure sha512

So, on this system, entries in the /etc/shadow file should have passwords starting in $6$.  If I look at /etc/shadow as root, I can see that indeed, all (both) of the passwords on this system are sha512:

# awk -F: '$2 ~ /^\$/ {print $2}' /etc/shadow | cut -c-10
$6$6I2Lrdb
$6$tvKWuGb
#

Pam being so flexible, you'll find it's in a different file on each type of system you look at.  Under RedHat, it seems to be /etc/pam.d/system-auth, for example.

This tells you what password hash will be created when a new password is set on this system.  The actual password hashes in use will vary depending on where or when they came from.  If a system used to use MD5, and switches to SHA512, then not all the hashes change - the old hash remains in use until the next time a user changes their password.  If hashes are copied in from elsewhere (yes, it happens) you can get a real melange of password hashes.  That's why the format used is encoded into the hashed password string (the $6$, $1$, etc. etc.) - so the system knows how to test against it.

So the only ways to know for sure what hash you're using is to either have root privileges (and look at your hash in /etc/shadow), or to see what the system default is (in /etc/pam.d/*) and change your password so that the default will apply to you.

Etcetera

As @grawity pointed out in the comments, older Linux systems/distributions may still honor the ENCRYPT_METHOD setting in the /etc/login.defs file.  (This file and setting is still there on new systems; it's more-or-less silently deprecated if PAM is in use).

And even though Solaris used PAM the last I checked, a little Googling suggests that to change the default password hash type you should instead change CRYPT_DEFAULT in /etc/security/policy.conf.

AIX laughs in the face of what passes for Unix standards these days, just as they always have.  The pwd_algorithm setting in /etc/security/login.cfg will do the trick for AIX 5.3+.

In general, though, any Unix variant that supports more than DES will provide some method for configuring the system default.  If you run into systems not mentioned here, tweak this Google search and see what you can find out.


How to mitigate credential disclosure in man in the middle attack I have the followin scenario and looking for a secure solution.

There is a web application, hosted on IIS. The connection is established over TLS 1.2 and is encrypted.

So the steps are

Client connects to the server over ssl
Client sends the username and password (as well xsrf token)
The server authenticates the user and creates an encrypted cookie that will go back and forth.

Assume that we are in a corporate environment were all communication occurs via a proxy server (for example when using SSL Inspection). If the inspector is compromised (quite probable based on this) then the user is vulnurable to credential theft.

I read about the crypto binding solution, but this only secures us from the MITM to not be able to keep the connection alive after the client has stopped creating traffic.

Is there a way to secure the user's passwords when ssl has been compromised this way?

The Secure Remote Password (SRP) protocol can be used to send credentials over an unencrypted network.

You could also require SSL/TLS client authentication which will prevent the proxy from being able to establish a connection to the web server.


One public key contains all subkeys? I've created a keypair with

gpg2 --gen-key

Then I created a subkey only for signing.

If I clearly understand the process I have now 3 pub/priv pairs. The master, one for encrypting and one for signing.

I exported public keys with:

gpg --armor --export FINGERPRINT > pub.asc

Now I have a file which seems to contain only one public key. Is it the master public key? Does this pub key contain the others public keys?

I'll sign with the third subkey I've created, so which public key do I need to upload on a keyserver?

Subkeys are bound to the primary key and exported together with it when calling gpg --export or gpg --send-keys. Same applies to signatures and user ID packages.


Is it a secure way to declare DB parameters in htaccess rather than in a PHP file? It has been suggested in securing PHP article that using directive as below in htaccess is more secure than hardcoding it into your app:

<VirtualHost ilia.ws>
Include /home/ilia/sql.cnf
</VirtualHost>

then declare your parameters in the sql.cnf as below:

SetEnv DB_LOGIN “login”
SetEnv DB_PASSWD “password”
SetEnv DB_DB “my_database”
SetEnv DB_HOST “127.0.0.1”

And finally access them via :

echo $_SERVER[‘DB_LOGIN’]; // login
echo getenv(“DB_LOGIN”); // login

This is a reasonable approach.  The benefit of this approach is that it avoids storing your password in the source code.  This is a good thing: you should not hardcode passwords in your source code.

(Of course, with this suggestion, the database password is not stored in the .htaccess file; instead, it is stored in a separate configuration file.  But the difference is inconsequential.)

Important: Make sure that sql.cnf is not stored within your web root.  If it is stored in your web root, maybe anyone who knows the right path to it will be able to request it just by sending a GET request.

There is an additional risk with storing passwords in a sql.cnf file within your webroot, which is a bit obscure but can be easily avoided by placing the file outside of your web root.  Consider: if you are editing sql.cnf using a text editor, and your connection drops while you are editing it, your editor will automatically save a copy of the sql.cnf file in some backup file: e.g., sql.cnf~ (in the same directory).  Now the backup file has a different extension, so if someone tries to fetch that file, the Apache server will happily serve up a copy of the file in plaintext, revealing your database password.  See 1% of CMS-Powered Sites Expose Their Database Passwords for details.

For more reading on the general principle:

Should a closed source website keep a secret key in its source?
where to store a key for encryption
How do open source projects handle secure artifacts?


How Secure are Authenticity Token in Rails I came across a website which uses Rails Authenticity token to prevent CSRF attacks. My concern here is that I can see the authenticity token in the source code of the web page. If any other service tries to carry out a CSRF attack and this token is the only thing which prevents it , why can't the attacker service just copy the token and then conduct the attack ?

Having a CSRF token in the body of the page is a standard way of preventing CSRF attacks. The token is different for every form that's presented by the application.  so when a form is submitted the submission can be checked for the validity of the token.

If an attacker takes a token from a page that he sees essentially that token won't be of use to him as when any other user visits the same page, the token won't be the same.

If you're looking for more information you could look at the OWASP page on CSRF or this post on StackOverflow about the rails specifics.


ASLR: why do only 12 bits change on 32bit system? I've been reading the posts here about bypassing ASLR. On 32bit systems this appears to be trivial but I was surprised to see how trivial. It takes mere seconds to bruteforce ASLR address'. The reason seems to be that according to my tests only 12 bits actually change in the address:

export BLAH=$"/bin/sh"

BLAH will be at 0xbff5a78b
BLAH will be at 0xbf87778b
BLAH will be at 0xbfe1e78b
BLAH will be at 0xbf9f778b
BLAH will be at 0xbffc378b
BLAH will be at 0xbffd978b
BLAH will be at 0xbfa7f78b
BLAH will be at 0xbf94878b
BLAH will be at 0xbfe4378b
BLAH will be at 0xbff7978b
BLAH will be at 0xbfe4078b

It seems that on my laptop all random address' are

BF XX X7 8B

where X is a random hex. My knowledge of the low level workings of a CPU are quite limited, so why are these the only bytes that change?

Is it correct to say that on a 32bit machine there are only 16^3 = 4096 ASLR address'?

How many bits change on a 64bit system?

ASLR on 32-bit is rather limited, but I think what you're seeing is an artefact of the system ASLR bias value.

Upon boot, a bias value is randomly generated for that "instance" of Windows running. Although parts of the address may seem to be the same across instances of the same process, they're actually just fed from the bias value, and that value will change on reboot.

So, in reality, it's not really exploitable. The address base will be random enough that a drive-by exploit will likely fail, even though it doesn't change much between instances.


Is https://div.show/options fraud/malware? Is https://div.show/options fraud/malware? I saw via https://app.uriports.com that a customer tried to load the page mentioned before and it was blocked thanks to CSP.

I am working at URIports and checked our stats:
We are processing millions of CSP reports daily and found 99 CSP violations on 14 different domains containing div.show since 2020-07-01. Triggered by multiple versions of Firefox and Chrome on Windows, Linux and MacOS. This is probably caused by a plugin or extension.


C&C domains used by Flame/Skywiper trojan I'm trying to figure out if any of our clients have been infected by the recent trojan/worm Flame.

I have access to our proxy logs, so I want to search for any requests made to the "known" C&C domains.

In this article, it says it uses 10 domains for C&C domain servers. Also in another report they found 50 C&C domains, IPs and mentioned domain-fluxing techniques.

Unfortunately, these domain servers are not publicly known (as-of-yet).

Have anyone found any publicly available sources mentioning the actual C&C domains?

As far as I'm aware, Kaspersky were the first company to discover it and they've written some great blogs on it, with excellent detail on the registry keys, files etc that are affected but there isn't much information on the IP addresses of CC servers. Here's their most recent blog detailed the registry keys etc -

http://www.securelist.com/en/blog/208193538/Flame_Bunny_Frog_Munch_and_BeetleJuice

and in a previous blog, they talked about the communications to the C&C servers -

http://www.securelist.com/en/blog/208193522/The_Flame_Questions_and_Answers

saying that

"Recorded data is sent to the C&C through a covert SSL channel, on a regular schedule. We are still analyzing this; more information will be available on our website soon.

......"

so I think it's probably best to keep watching Kaspersky's blog as they appear to be further along in analysing Flame (although that can obviously change).

According to this post (http://blog.cuckoobox.org/2012/05/29/cuckoo-in-flame/), the domains/ips are being actively sinkholed, which possibly explains why there's nothing been publicised as of yet.

Update: Looks like Kaspersky have identified information on the C&C servers - http://www.securelist.com/en/blog/208193540/The_Roof_Is_on_Fire_Tackling_Flames_C_C_Servers.


ISO 27001 compliance for application or hosting? I received a question as follows: Does the vendor solution need to have the ISO 27001 certification for the application itself, or just for the hosting of the platform?
In my understanding, ISO 27001 cert concerns companies/vendors and includes both solution and the hosting platform. Are they separable? In the case of SAAS solution, can I have the platform certified and the app not?

ISO 27001 is about how security is managed, not how secure a product is. It would, therefore, be very difficult to define a particular app as the scope for certification if the infrastructure is also under the company's control.
You manage the security of the infrastructure and then develop on top of that secure foundation. That's the intention of the certification.
If your scope of control is only the development of the app, then you still certify the development company, not the app.
That isn't to say that you couldn't convince some assessor somewhere to do certify you with just the app as the scope. I'm sure you could. But any potential partner/customer/stakeholder looking at the certification's scope will not take the certification seriously and start to doubt your competence more than if you had no certification to begin with.


What is the difference between login throttling and temporary account lockout? I am currently working on the redesign of a login page. I have initially suggested that login be throttled whereby pauses (incremental - in number of seconds) are introduced between each failed login attempt. The idea is that this will allow us to avoid locking the account and give users time to think about reseting their password and also counter any brute force attacks.

The development team suggested that login throttling will not help in preventing brute force attacks but a temporary lockout will. The temporary lockout works in the same way except that pauses introduced are (incremental - in number of mins and hours) so I am a bit confused...below is an example of how IBM QuickFile allows login to be configured:

So I have a number of questions:

Is a temporary lockout just another term for login throttling?
What is the difference between login throttling and temporary lockout? Are they  the same but use different configuration parameters. for example 3-6-12 seconds vs 5 -10 - 20 mins ?
What are the interaction design implications that I need to consider when adopting a temporary lockout mechanism? Can I let the user know when they will be able to try again? Perhaps using some form of visual indicator?
What are the most adapted time-frames for pauses between failed login attempts that will not frustrate the end user? This post on stakoverflow seems to suggest seconds rather than mins
What impact does this have on Denial of Service?

Update: Clarifications

A bit more to clarify! when a Login fails the "try again" button is disabled a for a duration of 3 sec after which it is enabled.The user attempts to login again and fails, the "try again" button becomes inactive for 6 sec.

The process is repeated for 5 consecutive attempts and error messages direct users to reset their password.At the 5th attempt users are presented with a password reset screen.

On the other hand users could attempt to login and have a specified number of attempts after which the account is "locked" for a period of time, say 5 mins this increases to 10 mins after another set of attempts.

Thanks

A) Yep you got it. Same in that they both result from a failed login attempt(s), though they differ in things like logging, the resulting UX implementation, and when one is used.

If a user is temporarily locked out, this is email-worthy. You should send an email or text-message to them notifying them that enough failed attempts were made to warrant a temporary lockout. This is an opportunity to empower the user to intervene in the event that it isn't them attempting to log in.

Alternatively you could use just a lockout timer in minutes, but requiring action from the user to unlock the account would be more ideal.

Throttling is more for pacing. "hold your horses, take a breath" and can be done without even informing the user. A simple UI spinner element can be used to prevent the user from accidental double-form-submits and prevent rapid attempts over the span of seconds as opposed to minutes or hours.

This can also be used as an opportunity to detect bruteforce attempts if the attacker isn't going through your UI. If 3 attempts are made per second but your UI only allows 1 attempt every 3 seconds, something is amiss.


Skype called someone and connected to them with no action on my part. What do I do? This happened to me today, September 12, at about 6pm. Any ideas about what happened, what's going on, and what I should do?

I was at home alone with my 2 year old -- I was feeding her dinner. All of a sudden, I hear my mom's voice saying, "Bob, Bob, where are you?" This was highly unusual, since my mom lives in another city.

I spun around and after a few seconds, figured out that the voice was coming from my phone, which was on a high shelf. That's where I normally put it, way out of my kid's reach. The phone had been sitting on the shelf for at least half an hour or more. It was locked. I hadn't touched it, my kid hadn't touched it, there was nothing leaning on it.

I took the phone in my hand. Skype was running. Video, from my mom's side, was on -- I saw her on the screen. I could hear her and she could hear me. The video from my side was apparently off -- she could not see me and there was no video of myself on the screen. The time elapsed was approximately 1:30 when I got the phone.

(I am not 100% sure about the order of the following, since it happened in a short period of time, and I was still shocked that this was happening.) The phone (Android 4.4.2) was still locked. When I pressed the home button, it took me to the PIN screen. I entered my PIN. Then I saw the home screen.

The home screen was blinking. This has never happened before. I would see the homescreen for a moment, then the screen would be completely black. Then home screen again. It blinked on and off several times -- perhaps 10 or 15. While it was blinking, nothing I pressed appeared to work.

It finally stopped blinking and I got into Skype right away. (Skype was in the notification area -- that's where I pressed.) (This ends the sequence where I'm not 100% sure of the order of events.)

I talked with my mom for a few minutes, still shocked. I turned on my camera during the conversation.

Here is what my mom said happened, from her side. She went into Skype on her tablet. It showed that I was not signed in. This is correct, I was not signed in. I rarely sign into Skype. I only use it to call my mom. Me being her only son, she decided to try me anyway. I didn't pick up. (On my side, I did not hear anything.)

Then, after a few minutes, she received a Skype call from me!!! She picked up. She says she could hear me talk to my kid. After I hadn't said anything to her for awhile, she started talking.

After the conversation, I immediately uninstalled the Skype app.

About half an hour later, I disconnected my phone from the Google account. Then turned off my phone. The phone does not have a removable battery -- it's off as far as I know.

Then, on my computer, I went into Google Account Permissions and revoked my phone's access. Finally, I changed my Google password.

Incidentally, on September 2, Google warned me about "unusual activity". There were a bunch of sign-in attempts that Google prevented. The attempts were from the same city that I live in. I had changed my password after receiving the warning, but didn't do anything else.

What do you think?

While I would not count out malware/spyware, there is distinct possibility this is hardware malfunction. From the description I could say the touchscreen is defective (it or the ribbon cable). Do you have cracked glass/screen protection? In that case it is entirely possible for the phone to dial "on it's own".
I've seen it on one phone already. It may be exacerbated if the phone was plugged in for charging.
Also, but this is more on the line of a WAG - the phone can be damp inside? It can happen if it's in a pocket close to skin and under clothes. It's winter, so... possible.
Sounds bit crazy, but had this issue as well. If you can take of back cover and let it dry in a warm place (but not too warm), you may also try that.


Combining a fingerprint scan and password for 2-factor-authentication UPDATE:

I found the answer to the "How To?" part of my question on superuser:

Require Fingerprint AND Password/Pin for Windows Logon
Is it possible to require a TOTP on Windows Login using existing or custom software?

ORIGINAL QUESTION:

I'm looking to upgrade my home computer security, and I've been thinking about using a biometric scanner.
At the time being, fingerprint scanners are the most easily obtainable biometric scanners, and they're also the most convient, which is why I'm considering using them. For the same reason, a TOTP application like Google Authenticator is not exactly what I'm looking for - sure, it's probably even more secure than just a password/fingerprint combination (compared to only having a password), but its impact on usability is too severe for my purposes.

Unfortunately, replacing my password with a biometric scan would actually be a downgrade, since obtaining a fingerprint is significantly easier than obtaining my computer password, which I only use for my computer. A fingerprint, on the other hand, can be found on anything I've touched.

Therefore, I'd like to utilize a 2-factor-authentication that requires both my password and my fingerprint (something I know + something I am). Unfortunately, it appears that Windows Hello doesn't support this natively (not unless you're connected to an Active Directory plus some other magic, that is).

Hence my question: at the time being, is it somehow possible to enable a 2-factor-authentication (using a biometric scan and a password) to log on to Windows 10?
Additionally, are there any password safes available that allow such a 2-factor-authentication?

If you take a look at this link or, better yet, this link you'll see examples of how to set up Google Authenticator as your second factor, which will then require your password AND the code to log onto Windows.

There are other methods (some free) to do the same thing, too.


Good example of heap exploits on Linux I'm doing a demonstration of memory corruption attacks, and would like to show some working examples of exploits that feature heap corruption (such as use-after-free).  My requirements are:

A working exploit (remote or local)
on Linux (this is crucial, because I want to take people through it using Linux tools)
for a real application (i.e. not a dummy application made to be vulnerable, but something real)
that can be easily downloaded (open source, still available -- older versions are fine)

Preferably, I'd like:

an application that they've heard of (something fairly common, not something obscure)
with a metasploit exploit available
and, if possible, a server application or daemon (not a browser)

Surprisingly, I'm having trouble finding a good example.  Can you recommend a good example to use to teach and demonstrate heap corruption attacks? The main requirement is that an exploit should be available that works on a real Linux application.

UPDATE: Before posting, I searched exploitdb and metasploit, and was unable to find something that met even the requirements (let alone the desired points).  However, the search interfaces there are somewhat coarse, so there may be one lurking that I can't find.

Here are a couple exploits for remote heap overflows for some older Linux daemons.

Unauthenticated remote root vulnerability in Samba 3.x - This describes the module for the setinfopolicy_heap exploit, which is included by default in metasploit.
Remote heap overflow in OpenSSL < 0.9.6d - A fairly advanced exploit for its time (2002). Includes detailed information on the vulnerability and exploit development process, along with a tarball containing C source for the exploit. Not metasploit, but just as easy to use.

Both of these will work for your demonstration, and could be easily setup by compiling older versions from source, or installing older RedHat/Debian ISO's in a VM.


Sign records in a database I have a table in my database where I store records to be processed later (basically orders that need to be invoiced or something similar, but this is not the important part).
Since this software runs on-premises, admins control the database and they're able to insert records directly into it. They usually do this to make my system process records in an unsupported way. Obviously, this leads me to problems that I often need to deal with: inconsistency, invalid domain, missing fields, etc.
To avoid this problem, I'd like to know what are my options to "sign records", that is, identify the records generated by my system in a way that the admins can not reproduce.
Several approaches came to my mind when I think in this problem:

Create some undocumented record hash (that can be reverse engineered);
Use a digital certificate to sign records (where to store the digital certificate? the system runs offline on-premises);
Use some kind of blockchain approach: linking a record with the previous + some proof of work (maybe too hard to implement and error prone).

Are there other approaches I am not considering?  If not, between the ones I listed, is there an approach I should stick/avoid?

I'm continuing the theme of @schoeder's questions and answering the questions that you didn't ask.
First though let's answer your questions.  You don't want to sign records.  You want to figure out who is responsible for the manual edits to your database.  The most direct answer to your question is that you want an audit trail.   Many databases have solutions for that so google audit trail options for you database and use one of those.  Note however that this will be doomed from the start if people share username/passwords for database access.
However, that's not really what you want.  Whether you realize it or not, this is a disaster waiting to happen.  Direct admin access to the database is the sort of thing that should happen only rarely.  Direct access, especially regular direct access, carries some high risks:

The risk that someone becomes a disgruntled employee and uses their access to intentionally break things
The risk that someone does the wrong thing and accidentally deletes everything.
The risk that someone enters data wrong and causes inconsistencies or missing data.

And much more!  Having accidentally deleted things myself before (thank goodness for backups!), I take direct database access seriously and cautiously.  Not everyone does.  Things will eventually go very wrong.  Therefore there is only one answer:
Update your application to match your actual use-case, remove database access from everyone who doesn't need it, and make sure it is only used for necessary maintenance tasks!
I'm afraid that in the long term that's really the only correct answer.


Would trolling the people behind scams help decrease scamming? It is easy for smart people to identify scams. This isn't an accident, phishers want stupid people. Sending the emails is the easy part, getting their money is what takes effort.

My question is, being an at least some what smart person, should I respond to scams as a small way to reduce phishing globally? Like, I would respond to the scam, but really be trolling the scammer?

How does this affect me?

Obviously, I don't give them information/give them ridiculous information, so I am not at risk that way

Would this hurt the scammer very much?

If a large number of people did this, would scamming become more expensive/less effective?

How long could I keep the scammer going before they realize I'm not cooperating?

The website http://www.419eater.com (mentioned also by one commenter) is a community of scambaiters that do exactly what you wrote: they bait and troll scammers in order to make them waste their time and forces (and sometimes, even their money).

While this might be fun, and does a good service to the community by spreading the word and alerting against these scammers, I think it will not be very effective as a DoS until a large number of people starts doing scambaiting.  Scammers have a lot of time on their hands, and the reward is pretty big once they manage to find a fool and his money.  If you do this for the fun, fine, go ahead (and post your trophies on 419eater.com!) just don't expect this to have a huge impact.

Instead, a more effective countermeasure is to send a abuse report to the scammer's ISP.  Most scammers use a sender email address and a contact email address exactly for this reason; be sure to send the complaint to both providers.


How can WhatsApp restore local or Google Drive Backups? This is all not about their end-to-end transmission protocol and my question is mostly Android centric.

What I ask myself:
When reading about hacking and decrypting local WhatsApp database backups it is mentioned that a private key in a restricted app area is needed from Android. If you don't have a rooted phone you normally should not have access to this key. The backup files (file extension crypt5-12) are normally useless without this key.

When you switch phones (e.g. buying a new one) you can copy your local sdcard/WhatsApp folder to the new phone and WhatsApp can decrypt that backup if the same number is used: source is here https://www.whatsapp.com/faq/en/android/20887921#restore

First assumption: The backup key is saved on WhatsApp servers too. Otherwise a local phone to phone backup would not work?

Second assumption: So the worst part is that if you backup on Google Drive, WhatsApp has theoretically access (?) to your (hopefully encrypted) backup and also access to the en-/decryption key on their servers. Or is there at least a separation between Google Drive not readable by WhatsApp itself? Does somebody has more details?

One last word about end2end encryption protocol: It seems it is useless (not against normal hackers, but I think against US surveillance) when at least one of your friend will do a Google Drive backup of their chat (history of chats are retrievable).

First assumption: The backup key is saved on WhatsApp servers too. Otherwise a local phone to phone backup would not work?

TL;DR: Yes, after some investigation, this seems to be the case.

Secondary devices

The protocol is quite complicated and not limited to WhatsApp, but works generally like this; The phone that uses chat app is called the first device. This device is the almighty device storing all sensitive data like private identity keys, connection passwords, local encryption keys, attachment encryption keys etc. All other devices are called second devices, this includes WhatsApp web and desktop clients. These clients are essentially dumb.

Whenever a new device appears it needs to be authenticated via the first device first. WhatsApp does this using an initial QR-code (other apps use SMS tokens), and then via a set of proofs. Eventually the first device decides if a secondary device is allowed control over the sensitive data. If so, the second device receives these keys on request. With these keys the second device can download the contact file and decrypt it using the requested key. Same works for all media messages. A note for WhatsApp specific: these key requests live very short, and thus are secondary clients required to regularly ask the first device for a new key to access the data. This causes the annoying 'Phone not connected' alert in WhatsApp web.

Whenever you install WhatsApp on a new phone, this entire process will take place and the first device will authorize the new phone and immediately locks out one of the two active instances. You then have the choice to choose one of the phones. If you choose the new phone, ownership of all secrets will be transferred to the second device, which then becomes the first device which makes the circle complete.

Backups

After some investigation, decompiling of the app and running test scenarios, we can conduct the following:
The app is using several local (SQLite) databases. Messages are stored in these databases unencrypted, and the databases itself are not encrypted either. You can check this yourself by downloading the .db files from the data/ folder. This is the default storage location for WhatsApp in running mode, and is unencrypted for performance reasons most likely. Normal apps should not be able to access the .db files in the data folder, but there are quite a few adb workarounds.

Database files including settings and messages are backuped in Google Drive (if you choose to do so). The app can request a lock on the folder in Google Drive to prevent users from downloading or accessing the backup. The message databases send to the remote backup location are the msgstore.db.crypt[0-12] files, where the last number denotes the protocol version. The databases are encrypted with a key stored in the data folder. This key is in fact stored on the WhatsApp server.

  Second assumption: So the worst part is that if you backup on Google
  Drive, WhatsApp has theoretically access (?) to your (hopefully
  encrypted) backup and also access to the en-/decryption key on their
  servers. Or is there at least a separation between Google Drive not
  readable by WhatsApp itself? Does somebody has more details?

The moment you install a new device and setup your Google Account, the files can be requested by the app and configured on the local device. This includes the axolotl database containing the identity key which is necessary in order to prove your identity to others. The decryption key is retrieved after the proving ownership of the phone number (username) to the newly installed WhatsApp instance. In theory, WhatsApp should not be able to access those files, but only you and Google. Ofcourse, WhatsApp could download the files and send them to another location. But at some point we need to put trust in the app, especially if it's not opensource.

WhatsApp is making local backups as well, usually twice a day in sdcard/whatsapp. These local backups also contain the identity key and the message storage databases, and are in fact encrypted. Once again the encryption key is stored on the remote server together with your WhatsApp profile. This explains why you can move the entire WhatsApp backup folder from one device to another. Without a verified phone number you cannot read the backup files, or use the identity key, however any rooted device can give easy access to the original, unencrypted, database files.

  One last word about end2end encryption protocol: It seems it is
  useless (not against normal hackers, but I think against US
  surveillance) when at least one of your friend will do a Google Drive
  backup of their chat (history of chats are retrievable).

The story does not get any better from this point, as we know that Google and other companies such as Facebook and WhatsApp supply files on request under the FISA act. There is no need to strike at the end-to-end communication as there is already a 'backdoor'. E2E only protects against active adversaries on the communication channel, who do not possess the power to demand backup files from party one and the decryption key from the other.

Window of Attack

Suppose we look at the situation from a non-government or 'normal' attacker with limited resources, then the device is the obvious weakness. Any app with root privileges can also access databases, can copy keys and so forth. The default Android ROMs contains many apps running under the system user, but also the vendor's apps shipped with the ROM (and updates) are protected from user intervention, and thus run as system.

Malicious apps are not without risk either. With the correct permissions they have full control over the sdcard storage, and can access the encrypted backups. When the verification SMS is intercepted at the correct moment (hooking in on the SMS receive call) and the phone number is copied, it should be possible to activate a self-controlled WhatsApp instance and to receive the database decryption key. The attack becomes even more plausible if the adversary has control over mobile communications (which governments often do).

The adb attack is even worse since it doesn't require root permissions. Basically a downgrade attack is possible where an older version of WhatsApp is installed via the bridge interface. This so called legacy WhatsApp can be tricked into a full application backup, resulting in a tar archive. The tarball is pulled to the adb server side and extracted. When properly prepared it would take an USB cable and a matter of seconds.


What type of pattern should I use for my passwords? I have a lot of accounts and until some time ago I used an universal password for all of them. Right now I have a different password for every account depending on the website name that I am logging in. I use a pattern and the difference between patterns is the website domain name.

I dont want to store my password in some kind of password manager. I just want to have a pattern in mind and compose the password depending of it (and a piece of paper hidden somewhere safe in the house in case I am really dumb and I forget the pattern).

Could you suggest me some good patterns? So I can get one or a mix of them to make a better pattern for my passwords.
Is there any better way to store passwords but still access them if you need to log from another computer/device?(I dont really trust password managers)

None. Use a password manager application to generate long, random password for each site.

Make sure you are not using your master password (or a derivation of your master  password) anywhere else.

If you do not trust online or commercial password managers, then use one that is open source and works with local files.

Edit: For reference, Bruce Schneier has published in 2014 a rather complete (and very readable) blog post as to why using any kind of pattern for generating passwords is a bad idea.


OCSP doubts about CA and OCSP Responder My question is about this image. Suppose that client is Alice and Server is Bob.
So, basically, I'm trying to setup a scenario... I have a remote Server (Bob) that has an https website. I make:  openssl s_client  -connect host:443  -status -CApath /etc/ssl/certs/ -CAfile /etc/ssl/certs/ca-certificates.crt that gives me the response about the OCSP. The wireshark only shows packets between me and server... There are not a CA or another thing.

What am I doing wrong or what I am not understanding? Is the CA the OCSP responder? How do I get the answer?

If I'm not doing well, what do I have to change in my setup?

One important part of OCSP which you might not be aware of is that the OCSP response is signed and has a limited life time. This means it actually does not matter where the TLS client got the OCSP response from because the OCSP response itself can be verified independently of how the client got it. This property is used within OCSP stapling in that

The TLS server (i.e. web server, mail server ...) asks the OCSP responder about the validity of its own certificate.
The OCSP responder returns an OCSP response, which is (directly or indirectly) signed by the CA which issued the servers certificate. This OCSP response can be cached for some time by the TLS server.
The TLS server can include this OCSP response when doing the TLS handshake with the TLS client. This is called OCSP stapling.
The TLS client can treat this stapled OCSP response the same way as if the client would have asked the OCSP responder, i.e. verify the signature and life time on the OCSP response and only use it if the signature is valid and the response is not expired.


Practical way to communicate a pre-shared key? Company A needs to set up an IPsec VPN with company B, where each side will configure its own devices. Is there a recommended practical and quick way to communicate a pre-shared key from A to B? I understand that using e-mail is discouraged for security reasons. And telling it over the phone is inconvenient and error-prone.

This is a perfect application for public-key cryptography (ie. asymmetric cryptography).

They provide you with a public key (that needn't be a secret and can't be used to decrypt anything) which can be used encrypt what you need to send them, then they use their private key to decrypt it (which they don't give to anyone).

PGP would be a suitable implementation if email would otherwise be convenient:

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

http://www.openpgp.org/resources/downloads.shtml

https://www.mailvelope.com/

There is the issue of how do they give you their public key without the risk someone will substitute it for another. This is probably not a significant risk unless an adversary is expecting you to send a public key over a network they control. If you are concerned you could address this in one of these ways:

They could post it to you and you could read it via OCR (can the mail man be trusted though?)
You could both calculate a hash of the key and they could read it out over the phone so you could verify it (less error prone, you probably don't even need to check all characters)
Theoretically if they publish it on a page with SSL you should be safe


CSRF protection with cookie and AJAX I would like to note that I've read the other question with an embarrassingly similar title and it does not contain an answer to my question.

I have not used CodeIgniter as a programmer, but I have recently performed a penetration testing for a website that was using it. The site was very AJAX-heavy and as far as I understood it, it had CSRF protection in the form of a cookie (not marked httponly) that is copied into a hidden field of a form right before the form is submitted.

This automatically means if an attacker can find an XSS vulnerability in the website (as was the case), he can leverage it to achieve CSRF, too.

However, assuming the site is clear of XSS, is this solution inherently safe?
I feel pretty bad about an important cookie that is not httponly, and is by design accessed by JavaScript. Is it just me, or is this bad practice indeed?

I suppose that you cannot assume invulnerability to XSS as a defense, but still, is there any other attack on this (that does not leverage XSS)?

The difference between a httponly cookie and a non-httponly cookie is that the latter cannot be read or modified using JavaScript in the context of the website.

Having no XSS vulnerabilities implies that you cannot execute JavaScript in the context of the website you're attacking. Therefore, this solution is safe.


Is EFS on Windows useless? So, after reading through the dialog from one the EFS Windows--after encrypting certain files on my system--I ran into a possible complication.

If I'm not mistaken, the encrypted file or folders are only inaccessible to other users. In this case, I mean being able to read or open these items.

What if, however, someone manages to gain access to my account?

Wouldn't they then have access to these so-called encrypted files and folders?

How does that work at all? I would have thought that they'd implement it like they do for MS Office documents, but I've never been prompted for a password in this case. I can open all "encrypted" files by just double clicking.

So, I guess what I'm wondering is: is this enough?

Should I just use MS Word to encrypt my files? At least this application uses a password to read the file. Does it matter at all?

T.R.G.

EFS serves two purposes:

It encrypts your data at rest. An attacker who steals your computer but doesn't know your password cannot recover the encrypted data.
It secures files on a multi-user system in such a way that other users cannot read the files, even if the ACLs permit it. For example, any member of the Administrators group can usually override the ACLs to gain access to any file. With EFS, even an Administrator cannot decrypt the file (unless they were granted access to the encrypted data specifically, which is not something you're likely to do by accident).

Note that even if an Administrator resets your password, they can't access your encrypted files. In fact, resetting a password makes EFS-encrypted files permanently unrecoverable.

Now, if you're worried about attackers with access to your account, then you need to use a different mechanism, yes. Some good options:

VeraCrypt, based on the TrueCrypt project (before it was disbanded). Also lets you create entire encrypted volumes that can't be accessed without the password (although once mounted, they remain accessible without re-entering the password until you close them).
PGP (or more likely, GPG, which is free and open source). Lets you encrypt files either with a password, or with a public key; in the latter case they can't be decrypted without the private key, which is usually itself password-protected.
BitLocker, a full-disk - technically full-volume - encryption feature built into some Windows editions. Used on a on a removable drive, you can set a password (though once it is plugged in and the passkey entered, Windows will keep the drive decrypted until you reboot your PC or eject the drive).
7-Zip, a compression and archive management tool. Supports much higher-quality encryption than the (trivially breakable) legacy Zip encryption. Not really a crypto tool, but seems to have decent crypto quality.

Using Word as an encryption tool is... not a great idea, but if you have a modern version it's probably OK (at least for Word files). Office used to use really awful encryption, but it's supposedly better now. Still, you really ought to use something focused on crypto instead.


How can you be caught using Private VPN when there's no logs about who you are? I know there are 2 services of VPN (free and paid). Normally, free VPNs need money from somewhere and sometimes they can sell your information to any agency that needs it.
Now, if we are talking about a paid VPN where they use encryption and don't keep any logs or information about the user, IP addresses, or what you're doing, how can a hacker be traceable? Then, the best hackers who have been caught must have been a free VPN, because they were too cheap to pay 7-10$/month or I'm missing something.

An excerpt from the FAQs of one of these VPN services. They have it in the privacy policy.

Update/Note: This is not to discourage VPN usage. I personally use one of the providers mentioned below, and I'm very happy with it. The important point is not to have an illusion of being 100% protected by the VPN provider. If you do something bad enough that state actors are after you, the VPN provider aren't going to risk themselves for you. If those coming after you are motivated enough, they'll exert all possible legal (and not so legal) powers they have. Downloading torrents or posting on anarchist forums is probably not motivating enough, but death threats to up-high politicians on the other hand... If there's one thing to take from this post is this: Use common sense.

I've researched this subject for more than 3 years*: Looking for VPN providers, reading through their Privacy Policy and Legal pages, contacting them, contacting their ISPs when possible, and I've concluded the following:

I was able to find zero reputable/trustworthy and publicly-available (free or paid) VPN service provider that:

Actually doesn't keep usage logs.
Actually doesn't respond with your personal information when presented with a subpoena.

I'm not exaggerating, absolutely none, zero, nada, nula, nulla, ciphr, cifra.

* Obviously not a dedicated research for 3 years

Update: Regarding  "super awesome Swedish VPN service providers". Swedish service provider obey the 'Electronic Communications Act 2003 389'. Sections 5, 6, and 7 under "Processing of traffic data" completely protect your privacy, but go a little further and read section 8

  The provisions of Sections 5 to 7 do not apply

  When an authority or a court needs access to such data as referred to in Section 5 to resolve disputes.
  For electronic messages that are conveyed or have been dispatched or ordered to or from a particular address in an electronic
  communications network that is subject to a decision on secret
  wire-tapping or secret tele-surveillance.
  To the extent data as referred to in Section 5 is necessary to prevent and expose unauthorised use of an electronic communications
  network or an electronic communications service.

In case the authorities order secret wire-tapping, the service provider shall not disclose information about it

  Section 19 An operation shall be conducted so a decision on secret
  wire-tapping and secret tele-surveillance can be implemented and so
  that the implementation is not disclosed.

Update 2: Regarding other highly recommended super anonymous VPN services (I'll go over only the top two)

BTGuard: You only need to take one look at the Privacy Policy to know that there's something shady going on.

  Before or at the time of collecting personal information, we will identify the purposes for which information is being collected.
  We will collect and use of personal information solely with the objective of fulfilling those purposes specified by us and for other
  compatible purposes, unless we obtain the consent of the individual
  concerned or as required by law.
  We will only retain personal information as long as necessary for the fulfillment of those purposes.
  We will collect personal information by lawful and fair means and, where appropriate, with the knowledge or consent of the individual
  concerned.

You can clearly see the intentionally vague language: "fulfilling those purposes specified by us", what are those purposes specified by them? Nobody knows. They even clearly say that they'll collect personal information when required by the law. In the last point they even state that they even don't have to inform you about the collection of your personal information unless it's "appropriate".

PrivateInternetAccess: This is probably one of the easiest legal language in the business.

  You agree to comply with all applicable laws and regulations in
  connection with use of this service. You must also agree that you nor
  any other user that you have provided access to will not engage in any
  of the following activities:

  Uploading, possessing, receiving, transporting, or distributing any copyrighted, trademark, or patented content which you do not own or
  lack written consent or a license from the copyright owner.
  Accessing data, systems or networks including attempts to probe scan or test for vulnerabilities of a system or network or to breach
  security or authentication measures without written consent from the
  owner of the system or network.
  Accessing the service to violate any laws at the local, state and federal level in the United States of America or the country/territory
  in which you reside.

If you break any of their conduct conditions (mentioned above)

  Failure to comply with the present Terms of Service constitutes a
  material breach of the Agreement, and may result in one or more of
  these following actions:

  Issuance of a warning;
  Immediate, temporary, or permanent revocation of access to Privateinternetaccess.com with no refund;
  Legal actions against you for reimbursement of any costs incurred via indemnity resulting from a breach;
  Independent legal action by Privateinternetaccess.com as a result of a breach; or
  Disclosure of such information to law enforcement authorities as deemed reasonably necessary.


How to keep Internet of Things projects secure? I want to experiment with the use of sensors for data logging and potentially for automated actions based on data properties. An example of the latter is if a value being monitored exceeds a threshold for X amount of intervals, some kind of notification or response is triggered, whether an LED lighting up or email being sent out.

I'm not an expert about sensors, networking, IoT, robotics, scripting, machine learning, or programming in general. That's all part of the learning process. I know enough to know security is important and easier to achieve if it's a goal from the beginning. So my question as I embark on this learning excursion is, what do I need to be aware of or control for to keep these systems safe as I create and experiment with them? If that question is so broad a book answers it, could you recommend a learning resource? Where does one start for learning how to keep home brewed IoT systems secure?

I realize this depends on two major things: security is harder as complexity increases; and security depends on threat models. Well, my simple sensor systems are bound to get more complex if I pursue more significant projects with them, thus the importance of good security that scales from the start. As for threat models, I don't anticipate enemies and these would all be relatively low-value and plentiful targets (many sensors monitoring basic things) but I do expect there are malicious agents seeking to control any processing power they can or disrupt systems just for the sake of chaos. Lastly as an importart part of the threat model is physical security, because if I put a sensor outside with a solar panel to power it, how do I stop mischievous kids or crooks from destroying or stealing the technology?

You start by not giving them access to the Internet.  If your Intranet of Things devices have no direct contact with the outside world (eg. your IoT sprinkler controller is firewalled off from the Internet and needs to go through a proxy when requesting a weather forecast), it becomes much harder for an attacker to do anything.  If there's no connection whatsoever, any attacker needs to be physically present.


Is it dangerous to connect to a public unsecure wifi network a few seconds before connecting to a vpn? This might be common sense but I just can't seem to get it. I purchased a vpn subscription for security ( I travel a lot therefore I am dependent of public wifi networks ). I have configured all the settings to connect automatically.

Allow me to take you on the usual flow of connecting to my public library's wifi:

I turn on my laptop (windows 10). I see on my log in screen  (bottom right corner) that the laptop has already connected to the wifi network. I type my password, I log in to windows and the vpn desktop app takes a few seconds to open and connect.

What I am asking is : During the time  ( around 30 seconds ) the computer is booting,  logging in, turning on the vpn desktop app, actually connecting to the vpn, is my laptop exposed? I don't do anything until the vpn connects. The only thing that might happen is windows starting to download updates in the background.

Am I being paranoid or is this a legitimate concern?
Thank you very much!

First, let's just take a moment to appreciate the tin foil hats. Everyone has them, we just put them to different uses. As a security architect, I cherish mine for both the safety it provides and the bountiful feast it helps me supply for my family. Thank you, tin foil hats.

Your question is legitimate. Your concern is legitimate. So that's a good start. Let's start digging into why the question and concern are legitimate and discuss simple things you can do to analyze what's occurring on your machine to ensure you're not broadcasting anything you don't want to be.

VPN as a method of privacy on an encrypted network is great for ensuring that no one can eaves drop on the conversation. The tunnel provides encrypted security when there isn't one natively on the network to begin with. Since you stated that you travel a lot, it makes sense that you would want this peace of mind especially when travelling around the globe. There are some sketchy places out there not to mention shady ISPs and routers providing access for malicious purposes (eg. Evil twin attacks).

Now, when your machine boots up, it will load your core services and essential applications and any other non essential applications you may have chosen. These could be slack or email or a number of other services that you have used on your machine. If any of these services leverage a network protocol that is not secure (ie. HTTPS or IMAP/POP/SMTP w/o TLS) then you may have an oops moment.

Since most services start the back and forth with authentication, that means that any of these applications running at start up are attempting to authenticate to a remote service. This may mean that you are transmitting a password and username in the clear even though you didn't want/intend do (and again is largely dependent on the type of protocol the application is running). Ideally, you would not transmit any of this data before your VPN session is fully established.

So there is the risk, what can you do about it?

Look at your start up application lists. If there is anything you don't need to launch right away, remove it from the start up lists and launch it when you feel safe in your network environment. If you have multiple apps you wish to start at once, you could try building a simple start up script that you can execute at your leisure.
Determine if your VPN client permits the blocking of network communication before a tunnel is created. This restricts your application clients from reaching out before your network tunnel is established. A good way to keep your start up applications managed by the OS too.

NOTE: This may have adverse effects if you want to present inside of another company, as an example. I know companies I have worked for explicitly prevent VPN tunnel connections from any guest networks, which would be a set back if you needed internet hosted materials.

Ensure that you are using VPN only and not running in split tunnel mode. Split Tunnel Mode will allow your applications to bypass your VPN Tunnel to communicate. This is definitely a feature of some clients that should be turned off.

And I just want to circle back to the paranoia. So long as your paranoia doesn't prevent you from functioning in your role, it's probably a good thing. Being aware of security and the risks you run into, especially when you're on the go, is a good thing. In fact, depending on your travel I would tell you that there are some countries where you should never bring a device that you care about and use. Stay aware, share the awareness, and keep yourself secure and in your own way you're helping to make the internet a safer place.


Terms for input/output to and from a Firewall Is there an official/standard term for the stream of data sent into or out of a firewall? Obviously the inbound traffic would be the traffic under surveillance, and the outbound traffic would be the valid traffic not flagged/blocked/filtered by the firewall.

If nothing exists that is firewall-specific, is there any general term used for traffic being monitored (input), and/or traffic successfully passing said monitoring (output)?

Maybe you are thinking of:

Ingress which indicates inbound flow, for instance flows coming from Internet to your LAN/DMZ,
Egress which indicates outbound flow, for instance flow leaving your LAN toward the Internet.

These will be handled in quite a different way regarding your firewall policy.

If you are just referring to data coming to the firewall itself to be analyzed (no matter the origin) and the accepted data that the firewall let pass out, then as far as I know it is just as you said in the title: input and output flow, as it would be for any other kind of network device.


How to pass hash as password to ssh server I have a hashed password $6$salt$hash. I want to ssh to a linux server with this hash. How could I do that? Do I need to change cipher spec? Is that possible?

You will not be able to do that.
The password is verified by the SSH server (or better by PAM library or similar authentication backend on other platform) by taking the received password, hashing it and comparing it to the stored hashed one. There is no way to bypass this process and make the server use the hash directly for comparison.


Hashing Algorithms Costs vs Sleep I understand most of the concepts behind hashing password but this one still escapes me.

I understand that you want the hash to take some time ( a couple milliseconds) so the attacker can't brutteforce.  But at the same time you don't want the hashing to take too much computer resources.

Why don't you just hash and then sleep for 0.1 seconds?

Passwords are hashed for the case that an attacker can read the hashes from the database (e.g. SQL-injection). Afterwards he can brute-force with the full speed of his own environment, often with a GPU, this is called an offline attack.

A sleep on the other hand could only protect from online attacks, even then an attacker could make multiple requests and wait for the results which are a bit delayed but are not slower.


How important is it to protect demo data by HTTPS enabled server? If the application is not in production mode, there is no commercial contract signed with customer yet, and you just want to give a link to the customer (or give the demo yourself) so that they can experience the app themselves, then how important is it to use HTTPS enabled server?

SSL certificate comes with a cost, so deploying them for only demo or pre-production server may not be commercially viable for most solution providers. So, please let me know how critical is to use HTTPS enabled server even if the data is only demo data and no contract has been signed.

Edit: Application requires login, so no one can see data without login

It depends on your specific case. How valuable the demo data is, how security-critical the product is, and the probability of an attack during the demo. So I'll give you my personal opinion.

The general public has become more informed about SSL in the past few years. Everybody knows about checking for the "S" or checking for the padlock, so chances are that your customer already knows about HTTPS. Your customer might think "Why aren't they using the padlock? Does it mean this product is not secure?". Using self-signed certificates will show the big scary warning and will make you look unprofessional.

For those reasons, go with HTTPS. Besides, StartCom offers free SSL certificates, and Comodo offers a 90-day free trial.


Establishing trust between a device and a developer, TLS signal vs X.509, GnuPG (or both) Let's say you wanted to implement a "secure sideloading" mechanism for your embedded device so that the device could establish trust with authorized 3rd party developers. Developers would have local access to the device, the firmware is not updatable which contains the OS (Linux), the sideloading feature would provide them a way to load applications that run on top

These were my initial thoughts:

1.) Enable/Disable sideloading on the device via a remote signal (TLS), the client would initiate the request based on some user initiated action (the TLS client code being baked into the firmware)

2.) Use a system such as X.509 or GPG, pre-generate and embed a certificate in the firmware of the device prior to shipping it. Developers could then be issued keys from the device provider which could in turn be verified by the embedded public key/cert on the device. There are added advantages such as expiration dates and revocation methods that would work offline/OOB

3.) Use both 1 + 2

I'm not a security expert so I'm not familiar with the possible ways to exploit #1, however I think #2 would be inherently more secure than #1 as the establishment of trust is out of band (doesn't use the network). On that note, I'd just assume #3 would be better yet.

Any comments? Thank you

You really need both as the two achieve different things.

You achieve secure communications, which protect from interception/injection of data during comms.
You achieve confidence the 3rd party is both a trusted 3rd party and the 3rd party you think it is. (or in this case, a 3rd party which is trusted/authorised by the vendor).

The 1st one is pretty straight-forqward. The 2nd is a little more tricky and where many vendors have made mistakes. For example, the many IoT devices where they have used a GPG approach, but have made the mistake of using the same private gpg key on all devices.

Which type of solution you use for #2 will depend on your exact needs and risks. You need to balance the amount of protection required with the inherent level of complexity it introduces - there is no point having a really complex and highly secure solution if managing that solution becomes so complex that operational failure becomes more likely.

Consider what your requirements are and what the associated risks are to determine the minimum necessary protection and then look at how you will manage the solution and ensure this can be done without excessive burden.

There is no one right solution. It will depend on the risk profile you are addressing and how you structure things. For example, if you want the 3rd party developers to manage things i.e. the software is made available on developer managed web sites, then you probably want a signed certificate approach where you give an approved 3rd party a signed certificate and your device will only allow loading of apps from 3rd parties which have an appropriately signed certificate. This gives you the ability to revoke approval by revoking the certificate.

Alternatively, you could use an approach where you allow 3rd parties to submit applications to a site which you control. You would assess and approve the 3rd party apps and only make ones which you approve to be available on the site. In this case, you can probably just use a GPG based approach, which might be easier to manage.

The first approach would put greater trust in the 3rd parties, but would likely reduce administration overhead for you. The second would require less trust, but would create higher admin overheads for you because you have taken on a vetting role. It is also likely that there would be increased turn-around time i.e. from release of new/patched versions. However, it would also have the advantage of more control and increased quality, which may be important as the overall quality of your device may easily be judged by the quality of the apps it runs.

The two are not mutually exclusive either - you could do both, which may be warranted in some circumstances - again, depends on your risk profile and what levels of risk your comfortable with.


Is the Kaminsky bug still a problem for sites without DNSSEC? I have read about the Kaminsky bug, but I don't fully understand how easy it is to use this vulnerability for an attacker.
Are DNS-software updated now so it's not that easy to use this vulnerability for an attacker? or does a secure site need to use DNSSEC to be secure?
E.g. think of an Internet bank. Does it need to use DNSSEC in combination with SSL/TLS to be secure? or is there other ways to be secure for the kaminsky bug?
In august 2010, SecurityWeek listed the Kaminsky bug as the worst DNS security incident in The Top Five Worst DNS Security Incidents

1. “The Kaminsky Bug” puts the whole Internet at risk
Often regarded as possibly the greatest security threat the Internet has ever faced, the so-called “Kaminsky Bug” emerged in July 2008, creating great unease and even greater hype. Researcher Dan Kaminsky discovered that it was easy to exploit a weakness in the DNS and built the software to do it. This weakness would enable malicious hackers to transparently imitate any Web page or e-mail account by poisoning the DNS information cached by Internet service providers.
...
Today, DNSSEC, the new standard security extensions for the DNS protocol, offers the best way of preventing the kind of cache poisoning attack that Kaminsky's findings would have enabled.

Kaminsky isn't the first person to find a DNS cache poising vulnerablity. In fact many of these vulnerability have been found and that is why DNSSEC is important. DNSSEC is a defense in-depth strategy against this attack pattern.  However responsible software vendors patch vulnerabilities,  and when you find a DNS cache poisoning attack in BIND,  it will be fixed immediately.


What is the best Practice / Industry Standard for storing documents with social security numbers, date of birth, financial records, etc? I am building an app that will be storing sensitive info (SSN's, DOB's, Financial Information, Credit Cards, etc.

Is there a standard that will cover all these items and what is the best approach to storing? Should blobs be used?

This is very broad and as such, it's a little hard to exactly cover everything that applies to each. However, I'll try to cover the ones that I know apply.

Credit card information is generally governed by PCI DSS (Payment Card Industry Data Security Standard) as the credit card industry likes to regulate themselves and not be regulated by governmental regulations.
Financial Information is usually covered by SOX (Sarbanes Oxley) which is a governmental regulation.
SSN & DOB is PII (Personally Identifiable Information) which can be handled by PCI DSS, but is probably covered by another set of policies entirely.

SSAE16 is more of a security framework that provides a standard of security, which is very useful and can be used to protect this information and comply with the various regulations.


Linux Plausibly Deniable File System Is there any way to encrypt a Linux filesystem in such a way to maintain plausible deniability? E.g. "Hidden OS support," the way TrueCrypt and Veracrypt work, they only support Windows OS due to low level DISK IO (via filter driver) and support hasn't been extended to Linux.

As you know, TrueCrypt is no longer in development and VeraCrypt has yet to implement low level disk IO drivers.

What about running/chrooting a filesystem from a hidden partition/volume without it leaking in the 'normal'/unencrypted FS?

Edit:

Plausible Deniability a la (True/Vera)Crypt: there is an 'outer' encrypted container (which is encrypted/possess high entropy/appear random) and has an 'inner' encrypted container (which must possess the same trait) to where a password can be provided and depending on the password, it decrypts either the outer/inner container, so that an extortionist/blackmailer can be provided the 'outer' container password and be satisfied, yet still cannot prove the existence of any other encrypted data. Also, that I would want decrypt and chroot the filesystem and when I power down it stays encrypted.

TrueCrypt works with Linux, it just doesn't support full disk encryption by itself.

Within Linux, you can mount a TrueCrypt volume that features plausible deniability, and then simply chroot it.

Or if you feel fancy, have the volume contain a Docker image, and "Dock" it.


Is there a repository with different ssl related files for testing purpose? I am looking for a repository with various different ssl related files like certificates (PEM, DER, p7c, ...), certificate requests, keys, ... for testing purpose.

It would also be of interest to get files like .sst, .stl, .pvk

Is there a repository with files like this?

Frankencerts?
There was some research on mutated/misencoded "FrankenCerts" ("Frankenstein Certificates").

The paper is here: Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations
And also: "A package containing 357 mucerts that can trigger validation discrepancies among OpenSSL, PolarSSL, and GnuTLS can be downloaded here"

OpenSSL Test cases?
OpenSSL has several test certificates on board as part of internal test harness. (And I assume that all other TLS libraries have a similar stash of certs.)


Poodle vulnerability and eCommerce Our client has recently stopped getting new orders placed on their Magento eCommerce site. Could this be related with the Poodle vulnerability, as their server is still on SSLv3.

Is there any specific log files I can run through to see what is going on, except the access_log and error_log.

If their server is exclusively on SSLv3, then probably not yet, but very, very soon.

Apple has disabled features of SSLv3 already.  Mozilla plans to disable SSLv3 on Nov 25.  Google plans to disable it by the end of the year.  Microsoft may have already disabled it in Internet Explorer.

To test it, try disabling SSLv3 in your browser and connect to the site.   Viewing the cert in the browser might be enough, depending on whether or not there are multiple certs or multiple servers involved.

Poodle is a MITM attack, it won't take a site down, it will instead intercept communciations between the client and the server.  You may see nothing in the logs except an SSLv3 connection, as most browsers will use TLS 1.0 or higher.

Edit: Protocol renegotiation to SSLv3 should only occur between the client and the MITM, this wouldn't appear in the server logs.


Mail delivery delay at ``spf=fail``; may that be due to manual inspection and accept? A mail was delivered through a forward, with the final location at a company email server.  During this delivery there was a pretty long delay, and it looks like the delay is the result of SPF (Sender Policy Framework) fail as seen in spf=fail below:

Received: from [...]; Fri, 16 Sep 2016 09:47:57 +0200

Authentication-Results: ppops.net;
    spf=fail smtp.mailfrom=[...]@[...].com;
    dmarc=none

Received: from [...]; Thu, 15 Sep 2016 21:30:34 +0200

What is the reason for the delay, and why was the mail accepted and delivered after all ?

What is the reason for the delay, and why was the mail accepted and delivered after all ?

It is impossible to tell what has caused the delay since we have no information what software is running on the receiving and sending server, have no access to the log files etc.

One reason for the delay might be Greylisting where mail from yet unknown senders/recipient combinations gets temporary rejected in the hope that a good sender will retry later while a bad sender (spam) will just give up because retrying is too costly. But usually the delay is not that long as in your mail, i.e. maybe 15..60 minutes only.

Of course it can simply be that the server was not reachable, the mailbox was full or similar problems. I very much doubt that this has anything to do with the SPF record because an SPF fail might cause a mail not not be delivered at all but not to be just delivered some hours later.


/cron path found when testing site I am testing a site and using dirb tool built into kali and it picked up /cron with a 200 response. I went to that page and it is blank. Can someone tell me why that was picked up and there is nothing there to view?

Just because a webserver returns a 200, that does not mean that there has to be content there. Why this site is returning 200 and not displaying anything is not something we can tell you.

Just having a page or a directory is never a vulnerability on its own. Returning a 200 and not displaying content is not a vulnerability. But they are reasons for looking deeper.

dirb is part of the "recon" phase.


Security Concerns on clientside(Javascript) We are going to design and implement a UI for a big website. Owner of the site is really cautious about security issues. I wonder if there is a check list for security issues at the client-side ,while designing and coding in Javascript.

There will never be a single perfect checklist, but here's a few things worth going through:

Wikipedia doesn't do half bad on this one
More for AJAX or other rich interfaces, but worth a read depending on your architecture - OWASP
This seems worth a test drive - haven't tried it myself - Javascript sandbox

Yes, none of these is a true "checklist" - IMO what you need to look for in Javascript vulnerabilities has a lot to do with how you are using it and what the rest of your architecture looks like - so I'm not sure a checklist will really cover the real concerns.  It may be better to go through a risk analysis first, and then see how that translates into how you use the various web technologies as a collective.


Hashed master password and generated encryption key in a password manager program I'm writing a WPF password manager application to practice programming, so far this is the scheme I intend to use to store master password and individual site password:

Master password:

Generate a random salt.
Hash the master password + salt with SHA256
Stored the hash and salt in DB as text.

For each individual site password:

Generate a random salt.
Hash master password + salt with SHA256
Use the hash as AES256 encryption key to encrypt site password.
Store the encrypted site password as binary blob and the salt as text in database.

Obviously for this to work the user will have to retype master password everytime he want to decrypt a site password, or I will have to store master password in memory.

Now to my question:

Should I use the same hash function while hashing the master password and creating encryption key, or should 2 different hash functions be used?
Does the way I handle individual site password make sense?

If you want to create an encryption key or store a hashed password, you want to use a key derivation function, not a simple hashing function like SHA-256.  A KDF is like a hash that gets applied many times, but is typically designed to be computationally expensive in order to make brute-force searches harder.  While you might be able to use SHA-256 as a KDF by calling it multiple times, this is not the standard way to do things, and may be much less secure than it appears since you need a very large number of iterations to provide effective mitigation against brute-force attacks.

The most popular (read: carefully studied and probably secure) KDFs in current use are PBKDF2 ("password-based key derivation function 2") and bcrypt.  Either is suitable for hashing and storing passwords, as well as for creating encryption keys.  There are also some newer algorithms such as scrypt which may be more secure under some definitions, but it is my understanding that they are newer and less well-studied.  "Security" is, of course, not a numerically quantifiable variable, so it's not entirely meaningful to say that "algorithm X is the most secure choice."

Generally, a KDF will take a parameter called the work factor or the number of rounds.  This describes how much computational effort is required to compute a hash or derive a key.  As computers get faster, this parameter needs to be increased in order to ensure that your hashed passwords remain sufficiently resistant to brute-force attacks.


C++ memset() memory overflow I am new to C++.

Can any C++ expert tell me would this causing buffer overflow?

Sample Code:

MyObject op;
memset(&op, 0, sizeof(MyObject));

On my view it is ok to be this since the limit is the size of the object type itself but there is a security tools caught this as a buffer overflow. If it is really a buffer overflow, can you please describe a bit how could it be. Thank you for your clarification and explanation.

This is not a buffer overflow.
The buffer size you are giving to memset is exactly the actual size of the buffer (in this case, the object op).

If this is a C++ object with virtual functions, then the memset will zero memory that should not have been zeroed, and the call to the destructor is likely to blow up.
But this would be memory corruption, not a buffer overflow.

As for the reason that your tool complains:
there is a common idiom that uses the type of memset's first argument to determine the buffer size:

memset(&my_object, 0, sizeof(my_object));
memset(my_pointer, 0, sizeof(*my_pointer));
memset(my_array, 0, sizeof(my_array));

It's possible that your tool throws a warning whenever you use anything else for the size, because you might forget to update the sizeof when you later change the actual object.


How do I sign a short text message with ~/.ssh/id_{dsa,ecdsa,ed25519}? There are already a number of questions about reusing SSH keys for something else:

Converting keys between openssl and openssh
How to use public key in ~/.ssh for asymmetrical encryption with OpenSSL
https://superuser.com/questions/576506/how-to-use-ssh-rsa-public-key-to-encrypt-a-text
https://unix.stackexchange.com/questions/12260/how-to-encrypt-messages-text-with-rsa-using-openssl
https://gist.github.com/colinstein/de1755d2d7fbe27a0f1e

but they all seem to deal only with RSA keys.

How do I "misuse" id_{dsa,ecdsa,ed25519} for something non-networked, such as signing some [short] text file? How do I verify such signature with id_*.pub?

For DSA, ECDSA using OpenSSL and using different functions and structures than for RSA.

It won't work for ed25519 keys, because their operations are implemented in the openSSH itself. But you can again reuse OpenSSH code and check how the sing & verify works there. You would also need to use OpenSSH parser, because the ED25519 keys are stored in the new OpenSSH format, instead of standard PEM.


Is a SHA checksum enough to verify integrity and authenticity? This is a broader question but here a concrete example:
From apache.org:

File hashes are used to check that a file has been downloaded correctly. They do not provide any guarantees as to the authenticity of the file.

I don't understand this part: 'They do not provide any guarantees as to the authenticity of the file.'
The checksum used is from a trusted HTTPS source (e.g. this one).
How a file can not be authentic if it match a checksum from a HTTPS trusted source?
Or do I miss something and I still need to validate with a GPG key?

You're conflating two things, which is why you are confused about them. Let's pick both HTTPS and SHA-512 apart and then things will be much clearer.
What does a hash offer me?
A hash algorithm is a way for a program to take some arbitrarily large input and return a (usually small) fixed output. For example, a program can have several GB of data, but the output of the hash algorithm with that program as input is still 512 bit long.
This makes it very easy to check whether or not two files are identical, without checking every bit of the message itself (since that is essentially the same as transmitting the message itself again).
As such, if you downloaded a file and the hash of that file, you can calculate the hash yourself and then compare it to the file. You can be reasonably sure1 that the file is the same as the original if the hashes match.
However, this alone doesn't generate any authenticity. You can't know who generated the hash, or who published it.
What does HTTPS offer me?
HTTPS is based on TLS, which in turn uses different ciphers to satisfy confidentiality (nobody else can read your data), integrity (nobody else can modify your data) and authenticity (the source of the data is who you believe it is).
As you may expect, these ciphers use hash algorithms like SHA-1 or better yet SHA-2 to verify integrity. Public Key Cryptography such as RSA are used to authenticate the client.
So if TLS offers all of this, why might you want to still verify a download? The reasons are two-fold:

Not everyone might download via HTTPS. The practice of releasing a checksum together with a file predates the widespread use of HTTPS. Furthermore, the storage media you might copy your data to might be unreliable (think optical disks, etc.), and as such having a checksum already at hand that you can assume to be genuine is a good idea.

Attackers may have compromised the server. That means they could have replaced the legitimate files with malicious ones, and updated the SHA-512 checksums. However, if the releases were already signed with GPG and the GPG keys were not on the compromised webservers, everyone who would verify their download via GPG would get notified that the signature is invalid.

Do I need to do all of this?
It's up to your threat model. If you consider the chance of Apache's web servers being compromised lower than your willingness to do all of the extra steps, then just feel free to skip this step.

1 It is possible for two different inputs to generate the same output hash. In fact, since there are only 2160 different SHA-1 hashes, but there is a lot more data out there, you can be relatively sure that for any given SHA-1 hash, there are infinitely many other inputs that generate the same hash. However, finding such an input is very difficult and not feasible today.


Cryptography that looks like ordinary email I would like to stay out of the automatic filters in place by security agencies and not be accidentally placed on a no-fly list or such. Say I'm having a political debate with a friend about democracy and stuff, and terms like revolution, capitalism, freedom and such (oh, hello there NSA!) are thrown around a lot. Sending an encrypted email where normally I would send emails in plain text is a sure fire way to trigger some of the filters, I assume.

Is there a way to encrypt emails so that the cypher text is hard for an algorithm to distinguish from regular (let's say spam, hard to get any more regular than spam) email?

For example:

Normal PGP cyphertext, easy to distinguish:

-----BEGIN PGP MESSAGE-----
Comment: GPGTools - http://gpgtools.org

hQIMA7t6lidYOUd0AQ//Z7y+/tvQQ0TRoOT0ydUwVjJZh5sLQOEVQNDHGEUjfvL9
7UJhtEaisVwlDsqTEqpa04FWzgehBBDnxgOUFcPB3xSGD9Bi61MItK6gm1phTnEn
hOezHmGqAyrCarofkYn5vpwPZtpSmRvpS9tykhRTKMlhsN5EOLvaDa8TsqMnqwGm
pPC8j219YG2U/OmRa96GTslMaDtIx6470Ea4fcJf2jdo3RlgLEc7BGQVcrOpHj/0
-----END PGP MESSAGE-----

Cyphertext, less easy to distinguish:

pen3s grow for cheap russion brides are looking for parntners in
Detroid area visit our website now click to unsubscribe

Say what you actually want to do is to make your encrypted email look like spam. OK, how to accomplish that?

One possible way would be to take the ciphertext and break it down into managable chunks of, say, nine bits each. Using a set of dictionaries, these nine-bit quantities are mapped to one or more words in a target language (nine bits would require a dictionary of 512 words, which is feasible while at the same time providing variation). A Markov chain could possibly be used to pick the next dictionary based on the word selected in the previous dictionary, which likely could be made to make the output resemble very poorly written text in the given language.

By tweaking the interaction between the two parts, the output of such a scheme could conceivably be anything from nonsense to semi-legible text (much like a lot of spam emails). And it'll be text, not binary data.

An even simpler variant would be to simply encode the ciphertext using something like the PGP word list. The result of that will of course be complete and utter nonsense, but it'll probably pass the most simple statistical tests for a given target language.

Now that I've described these ideas, they are of course totally useless. You'll have to come up with something of your own. ;-)


How exactly was Sony Pictures hacked November 2014? There is lots of media coverage like this one but I have not yet been able to find details on how the hackers got into the network, the servers and the users' systems.

So what vulnerabilities / zero-days did they use ?
How did they apparently manage to take over virtually all of Sony Pictures systems, from the servers and computers to maybe even smart devices ?

How do we protect against being the next victim to the same attack vectors ?

Thanks to Bob Brown's hint and an article on Ars Technica he is probably referring to, we get to know at least some details on the hack rather than just gossip.

From the article:

  And it still remains unclear how the malware was implanted on Sony Pictures’ network in the first place—or how multiple terabytes of data from corporate systems could have been hauled out of the network within just a few days of the wiper attack.

According to the article, one malware used in the attack is Destover or a variant thereof, also known as (a) Wiper, which has also been subsequently code-signed with a Sony certificate and was used to remove/destroy data on the victim's computers, e.g. to cover up and remove traces of an intrusion.

UPDATE:
According to Security Week, attackers used a worm for Windows networks (referred to as SMB Worm Tool) to propagate their malware with brute-force authentication code and tools for file transfer, system survey, process manipulation, file time matching and proxy capability, an arbitrary code execution mechanism and aforementioned features to erase and destroy data.

A related Security Week article also refers to the US CERT alert detailing some Indicators of Compromise (IOC), i.e. hashes of the malware that can be added to security solutions / intrusion detection systems and malware detection engines.