Can a site I browse in private browsing mode tell if I visited it in regular mode before? I've noticed when updating a blog, that sometimes refreshing the page won't actually fetch it again, because it is still in the cache. Now, even when I open it in incognito in that same browser(say Chrome), it still uses the same cache, at least for some time. My understanding is that the site can "tell" my computer how long to store the page before fetching it again. So, say I set up a site that dynamically puts in the time and date, (or a unique code), into the page in a hidden field, and on loading, sends that back to me using Javascript or whatever. So I can tell if my site was browsed before by checking when I sent that code or what the time is, even though the browser is now in privacy mode.

Would this work, and if not, why not?

Yes and this is by design:

  The point of incognito mode is not to prevent server side tracking. The whole design is about not leaking information on the client (about visited sites).

This comes from the Chromium team - look at Comment #8 I believe other browsers work similarly.

Some of the ways a site could do this:

ETags - these are cache directives. If the page has been cached in normal mode, then these cache entries are available in incognito mode.
IP address
Browser fingerprint - screen resolution, installed plugins, etc.

You may be able to get better privacy by using Privoxy in combination with incognito mode.


Encryption for multiple recipients without private key? I have been looking into PGP, but do not want my users to have to worry about securely storing their own private keys. Therefore, I feel like maybe just symmetric encryption without private key would suffice.

What is the recommended way of doing so? Is it to use their passwords somehow? If I said users are tied to a role, and read permissions are based on that role, would it be simpler to just use some sort of shared symmetric key for each role?

Use case: It's transactions on a ledger, where the ledger is public and anyone can see it, but all the transaction information is currently stored in plaintext. I would like the transaction information to be encrypted for the user roles relevant to that type of transaction. Everyone can see that the transaction actually occurred, but the goal is just better security than letting everyone clearly see the full contents of every transaction.

Example: There is a Blue team and a Red team. When a Blue user uses the system, they are able to see a list of all transactions for both parties. This allows them to see that the Red team has indeed been transacting, but because they are not on the Red team and do not know the Red language, they cannot read exactly what was transacted, and only know that it occurred.

can store keys using cloud key management service
cannot expect users to manage their own keys with cold storage/paper wallets/etc.
works quietly under the hood, where users simply login with email and password, and should be able to view decrypted information relevant to their role
some transactions might be encrypted for multiple roles

I have been looking into PGP, but do not want my users to have to worry about securely storing their own private keys. Therefore, I feel like maybe just symmetric encryption without private key would suffice.

This feeling of yours doesn't seem to make sense since the users would still have to securely store the secret symmetric encryption key (or the password that generates the symmetric key). You do not seem to be gaining anything.

  What is the recommended way of doing so? Is it to use their passwords somehow?

You can protect a symmetric key with a password (or generate it with a password). You can also protect a asymmetric private key with a password. So, again, not sure what you are gaining here?

For a practical option, you could use gpg, which gives you the option of password-based symmetric encryption/decryption. In this case, the symmetric key is generated from the password, which the user enters on the command line. However, you can also use gpg with a password-protected asymmetric private keys, the password for which the user enters on the command line. This is why the move to a symmetric key seems like you aren't gaining much if anything.


Is this signature methodology secure? I'm working on authentication for my JSON-RPC API and my current working strategy is using signed requests sent via POST over SSL.

I'm wondering if anyone can see any vulnerabilities that I haven't taken into consideration with the following signature method.

All communication between the client and the server is done via POST requests sent over SSL. Insecure http requests are denied outright by the API server.

Dependencies

var uuid = require('node-uuid');
var crypto = require('crypto');
var moment = require('moment');
var MyAPI = require('request-json').newClient('https://api.myappdomain.com');

Vars

var apiVersion = '1.0';
var publicKey = 'MY_PUBLIC_KEY_UUID';
var secretKey = 'MY_SECRET_KEY_UUID';

Request Object

var request = {
    requestID : uuid.v4(),
    apiVersion : apiVersion,
    nonce : uuid.v4(),
    timestamp : moment.utc( new Date() ),
    params : params
}

Signature

var signature = crypto.createHmac('sha512',secretKey).update(JSON.stringify(request)).digest('hex');

Payload Packaging (Sent as cleartext via POST over TLS)

var payload = {
    request: request,
    publicKey : publicKey,
    signature : signature
}

POST Request

MyAPI.post('/', payload, function(error, response, body){
    console.log(result);
});

Resultant Payload

{
  "request" : {
    "requestID" : "687de6b4-bb02-4d2c-8d3a-adeacd2d183e",
    "apiVersion" : "1.0",
    "nonce" : "eb7e4171-9e23-408a-aa2b-cd437a78af22",
    "timestamp" : "2014-05-23T01:36:52.225Z",
    "params" : {
      "class" : "User"
      "method" : "getProfile",
      "data" : {
        "id" : "SOME_USER_ID"
      }
    }
  },
  "publicKey" : "PUBLIC_KEY",
  "signature" : "7e0a06b560220c24f8eefda1fda792e428abb0057998d5925cf77563a20ec7b645dacdf96da3fc57e1918950719a7da70a042b44eb27eabc889adef95ea994d1",
}

Server-Side

And then on the server-side the following occurs to authenticate the request:

PUBLIC_KEY is used to lookup the SECRET_KEY in the DB.
SECRET_KEY is used to create an HMAC of the request object from the payload.
The hash sent in the payload is compared to the hash created on the server. If they match, the PUBLIC_KEY is authenticated.
The timestamp is evaluated and the authentication is rejected if the request is too old, otherwise, the timestamp is authenticated.

So far as I understand, this is a secure method for signing and authentication requests sent over SSL. Is this correct?

Thanks in advance for any help.

One question you may want to consider is why you believe that signed requests are necessary if all APIs are SSL only? SSL provides both tamper & replay protection, so unless you have other concerns, this may be redundant.
Although you plan to use SSL everywhere, which is great! My comments below explore the possibility that there is no SSL in use.
1 - URL & HTTP Verb is not signed
In your sample above, the intended destination of the payload is not included in the payload signature. Consider if the payload could be captured, it could be redirected to another undesired location. Perhaps a request intended to be sent to /users/123 is routed to /users/456, or a request sent to 'v1.api.mysite.com' is sent to 'v2.api.mysite.com', or a POST is changed to a PATCH.
2 - Keyrolling Support
This may be outside the scope of your question, but I see no support to roll the signing key without the possibility of customer impact. It would be advantageous if your service could maintain two authorized secrets for a given public id. This way the key could be rotated regularly (say out of an abundance of caution) without tight coordination between client & service.
3 - Signing 'Agility'
What happens to your application if a new weakness is found in SHA2 or the current HMAC construction? What if you have a client that prefers to use ECDSA over HMAC? Consider having a version number, or signature 'scheme' identifier as part of the signed payload. This way your service can understand what approach the client has used to sign the payload.
4 - Too Old
You mention in your post that the service can reject requests that are too old (to mitigate replay attacks). What if the client doesn't agree with your definition of too old? Consider allowing the client to specify how old is too old in the signed payload. Again, this is not so much a weakness in your approach at generating signatures, more of a comment on the protocol in general.
5 - Other Nits

The 'nonce' field looks redundant. You already have a random GUID serving as a request id, unless your service requires the nonce, this can be safely removed.

Depending on your JSON parser (& how/when you deseralize), this may not catch all modifications to your payload. For example, if I modify the payload to escape a character that does not require escaping, the result is semantically equivalent. Because you are deseralizing the JSON before verifying if it's been modified, you may be vulnerable to attacks seeking to exploit your deseralizer, or attacks targeting subtle bugs in how escaped characters are handled.

But lastly, I repeat what I said earlier - signing your request may be redundant when you only support SSL as the transport. Simply authenticating your caller may be sufficient.


Can't brute force password cracking somehow be throttled? Online articles mention the importance of a strong password and suggest that hacking tools allows bad guys to attempt millions of passwords per second.  I am wondering why OSes and websites and such are not throttling attempts.  That is, if 3 bad attempts happen why wouldn't additional attempts be rejected for say at least the next 10 minutes?  Is there no low-level way of securely closing the floodgate of "millions of attempts per second"?

You are talking about online attacks, somebody is entering passwords via website. This you can slow down by the methods you described, though it is not as easy as you may think.

When you read about cracking passwords, normally you are speaking of offline attacks, that's why you calculate hashes after all. Think about the situation that somebody could read all your password hashes (e.g. SQL-injection, or from a thrown away backup...). Then the attacker can brute force as fast as his hardware can do, he can e.g. use the GPU to calculate hashes. Even then you can slow down the attack, this is why nowadays you use slow key-derivation functions like BCrypt or PBKDF2. This algorithms allow to define a cost factor, which defines how many iterations are done, so you can control how much time is used to calculate a single hash.

An example: If you can calculate 8 Giga MD5 hashes per second all password combinations up to 6 digits can be calculated in 2 seconds. If you even need 1 millisecond per hash, you already need 8 month.


Deciding CVSS v3 scope parameter for a few OWASP top 10 vulnerabilities I am trying to score owasp top 10 on cvss v3 and I am having difficulties assigning "scope" parameter for some. Please correct the below list if there are some faults.

SQL Injection: Changed.
Vulnerable component: Webserver/database server
Impacted component: Web application. Can cause webapp to be non-available.
XSS: Changed
Vulnerable component: webserver
Impacted component: browser
Unvalidated Redirects: Changed
Vulnerable component: webserver
Impacted component: browser  (malware can be downloaded)
CSRF: Unchanged
Session Fixation: Unchanged
Insecure Direct Object Reference: Unchanged
Unrestricted File Upload: Changed
Vulnerable Component: web server
Impacted Component: could be host OS

Scope in CVSSv3

Scope is defined in the documentation:

  When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred.

Examples

  1) SQL Injection: Changed.
  Vulnerable component: Webserver/database server
  Impacted component: Web application. Can cause webapp to be non-available.

I would disagree with your reasoning, but would agree that the scope is changed.

The vulnerable component is the web application: The vulnerability wasn't introduced by the server, nor by the DBMS, but the issue exists because the web application inserted user input into an SQL query.

The affected component is the database, as it governs the data it holds, and an attack can extract information from it that shouldn't be available. If system commands can be executed or if files can be uploaded, the server would also be affected.

Other opinions:

CVE-2015-8604 is rated as unchanged scope.
High-Tech Bridge rates SQL injections as changed scope in a blog post about CVSSv3.
High-Tech Bridge rates SQL injections as unchanged scope in their CVSSv3 calculator.

It can be seen that there is at least some unclarity about rating the scope of SQL injections. I haven't found any other examples that determine the scope of an SQL injection.

  2) XSS: Changed
  Vulnerable component: webserver
  Impacted component: browser

Makes sense, and this is also how First rates it in their XSS example.

  3) Unvalidated Redirects: Changed.
  Vulnerable component: webserver
  Impacted component: browser (malware can be downloaded)

This also makes sense, for the same reason as XSS.

  4) CSRF: Unchanged

This also makes sense, and is also how First rates it in their CSRF example. The vulnerable and the impacted component are both the web application.

  5) Session Fixation: Unchanged

This also makes sense, for the same reason as CSRF.

  6) Insecure Direct Object Reference: Unchanged

This also makes sense, for the same reason as CSRF.

  7) Unrestricted File Upload: Changed
  Vulnerable Component: web server
  Impacted Component : could be host OS

This makes sense.


How to mitigate risk of X11 buffer ghosting (palinopsia bug) The Buffer "Ghosting" Phenomenon

It is possible to observe contents of (old and currently used) graphics buffers on a monitor under certain circumstances, posing an information disclosure risk, when combined with shoulder surfing:

Growing a Window rapidly in some Stacking and Tiling Window Managers (always)
Shutting down the X11 server (sometimes)

Either part of (1) or the whole (2) screen will show portions of currently active windows (from possibly different workspaces/desktops), or long-since closed Windows.

These sometimes look lightly or heavily "corrupted" depending on age and buffer activity since window destruction. Remnant buffers shown sometimes look like "sprite sheets".

This phenomenon occurs for a fraction of a second on resize, or ~1 second on X11 shutdown, making it impractical to provide screenshots. Sorry.

The Core Question

How do I feasibly mitigate or eliminate the risk of disclosing the information contained in these remnant buffers?

This assumes that it is impractical to always hide my monitor, which would be the classic anti-shoulder-surfing method.

Additional information

Attempt at explaining the causes

This only happens on local X servers, not over ssh, so I assume the underlying buffers are in the graphics card memory.

Hypotheses based on consulting xlib documentation:

The X11 server provides an enlarged buffer in which to paint the (now larger) window, but the application providing the window does not fully clear/paint into this window before the X11 server begins to display it. This leads to the reading out of some garbage data in the buffers, which sometimes happen to be coherent images if the memory of the buffer was used for another window previously.
After X11 server shutdown there remains garbage data in the underlying buffers from old windows. The graphics card is still active, but kernel mode setting has not taken over yet, and garbage data is output for some time.

Reproduced on these setups

On Window resize & X11 Server shutdown:

Arch Linux (latest), i3, xorg-server 1.18.3-1, nvidia-340xx, Nvidia GT218
OpenSuSE Linux 13.2|42.1, i3, x11-video-nvidiaG02|G03|G04, Nvidia G98 Quadro
Debian Jessie Linux, i3, xorg-server, nouveau|mesagl, intel integrated graphics

On X11 server shutdown:

Opensuse 13.2|42.1, LXDE|GNOME|KDE, x11-video-nvidiaG02|G03|G04, Nvidia G98 Quadro

A partial answer:

What you call "buffer ghosting", is also known as palinopsia bug. The link provides a proof of concept, a short script to show your video RAM with content of already closed applications.
Other than regular RAM, GPU video RAM is not zeroed by default when it is allocated. Some drivers do it, some don't; zeroing the RAM slightly costs performance.

You can forbid an application to have access to GPU with untrusted cookies. Example:

xauth -f $HOME/mycookie generate . untrusted
XAUTHORITY=$HOME/mycookie glxgears

glxgears will fail to start because it has no GPU access. Using trusted instead of untrusted allows GPU access, and glxgears works.

Using untrusted cookies on a non-compositing window manager like i3 or openbox may be save. Compositing window managers respective desktops with 3D effects like Gnome or KDE may store window content in video memory even if the application itself does not.
I'm not sure if X itself may use video RAM in cases not preconceived here.

  This only happens on local X servers, not over ssh

Afaik, ssh always uses untrusted cookies.

  How do I feasibly mitigate or eliminate the risk of disclosing the information contained in these remnant buffers?

Never use your GPU (sigh). Yell at the developers Write a bug report. Don't view pron in chrome incognito mode.

The video RAM even survives a reboot from one system to another.

The only real secure way may be to disable GPU on kernel level.

From a security point of view, the driver should zero the video memory immediatly after deallocating, because the video memory can be accessed without using the driver and also persists after reboot. At least it should zero the video memory when allocated. Neither nore is done.

Some applications can have trouble with untrusted cookies. There is also the possibility to disable the OpenGL / GLX extension in the X server.
(Please regard that this has no effect for Wayland compositors like Gnome 3 Wayland session).

Create a file:

/etc/X11/xorg.conf.d/disable-gpu.conf

with the the content:

Section "Extensions"
    Option "GLX" "Disable"
EndSection

Instead of this permanent xorg.conf configuration you can run X a single time with GLX disabled. Start X from tty2 with startx -- -extension GLX vt2. (Set N in vtN to the number of the tty).


Forensics - trace back DNS query origin on host? So I tried to search the web for answers but didn't find any.

Is there any way to trace back which exe file or application caused the computer to make a specific DNS query?

Any application can easily submit any DNS resolution request. There are numerous libraries available and programmers can choose to perform the resolutions whichever way they want. For example, in Python it's one line of code (maybe two)

import dns.resolver
answers = dns.resolver.query('dnspython.org', 'MX')

To link an actual application to the UDP (assuming it is using the default UDP protocol) "session" it used to send the request, is a rather hard task. There are tools available for different Operating Systems (for example HomeProject or Microsoft Network Monitor) which can help to that direction.

Keep in mind, that the resolution process takes roughly a few milliseconds (DNS is competing among the fastest protocols). The process of resolving a domain name in order to get the IP address it resolves to, is being delegated from the stub resolver (the "application" that needs the IP address for a corresponding domain name) to a Recursive DNS Server (aka RDNS). An example of such server is Google's Public DNS, at 8.8.8.8 and 8.8.4.4. Your ISP will most likely provide the IP addresses of the RDNS servers it operates to your home modem/router, which will send them to the devices connected to it (via DHCP for example).

Among other things RDNS servers will store a matching domain name to IP address pair in their internal cache memory for a certain amount of time (TTL, Time To Live). This means that if you perform a resolution request within that time frame, the RDNS server will not go down the recursive resolution process, but will reply with the matching IP address it already has in memory. Therefore, the stub resolver will get a response extremely fast. For example, this is the time it takes to perform a resolution:

The first time

;; Query time: 248 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

The second time

;; Query time: 40 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

What you are trying to do, is monitor which application opened a UDP socket on your system and listened to that socket for a response, for less than 3 seconds (the default timeout value for DNS). If you are not continuously monitoring both traffic and processes listening to specific ports, then as far as I know, there is no way to get the match. For future use, you will be able to match a process and a corresponding DNS resolution request, by looking at the ports used. For example, if application 1 opens port 7788 and you see a DNS request in the network traffic at the same time with source port equal to 7788 (destination will most likely be 53), then you have the application!


How can I avoid buffer overflows when programming an Android app? I'm just starting out in Android and I've gotten my head around general programming within Android, but I've recently started trying to research security within Android.

What coding practices would you suggest I should avoid or programmatic situations to watch out for, in an effort to avoid overflow vulnerabilities?

Android is similar to other operating systems, if you code in Java then you shouldn't be worried about buffer overflows but if your code contains native code e.g. C++ or C, then you should avoid any possible buffer overflow vulnerabiliy. The instructions to avoid BOF in Linux can apply for android too, so you can use them.

http://www.cprogramming.com/tutorial/secure.html


How does PKI work for the client side? As I send this question as a request to yahoo's server, the information in the request will be encrypted with yahoo's public key (which is available for everyone). Then the information will arrive at the server. There it will be decrypted with yahoo's server private key. Will Yahoo's server send me a response

after encrypting it with its private key?!? Can I then decrypt with its public key?!? I don't understand

that bit..it is not correct.. How will the server encrypt its response and how do I decrypt it?

UPDATE

Some clarification:

I get the public key of yahoo, encrypt a message, and send the information to yahoo. Yahoo decrypts

the information with its private key (this is the part that I understand). From Yahoo's response stage..

what happens? How does it encrypt its information so that the client side will know how to decrypt it?

That's not quite what happens. As public/private key encryption is more expensive than symmetric encryption, its use is minimal. During the SSL handshake, the client and server agree upon a shared symmetric key that they use for bulk encryption. The remainder of the communication then occurs using this symmetric key. This symmetric key is then rotated on a regular basis to reduce the chances of an observer of the communication stream from guessing it.


OAuth2 vs. JSON authentication 1) To what extent is OAuth2 more secure than JSON authentication (both over SSL)?

The context is a client (one server) querying another server (via API) within a local network using RESTFul. Prior to the server sending a JWT, the client sends a password for authentication (over SSL).

2) So is there a justification, security-wise, to use instead OAuth2?

There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing).

As an example: you start off with one service which you authenticate against using JSON username/password. Everything's working well, but you decide to introduce another service which provides slightly different functionality. The new service also accepts username and password via JSON.

At some point, somebody points out to you that MD5 is broken, or you're not salting your passwords correctly. No problem - you can fix that. But you have to fix it in both (all) of your services which are performing authentication... How many of those do you have? Do you actually know where they all are? How can you deploy the change to all of the services at the same time?

By performing authentication against an Authorization Server, as in OAuth 2.0, you partially remove this dependency. You can easily change the authentication mechanisms within this server, and as long as your services continue to accept OAuth tokens, you have no problems.

The other important point is that OAuth is a standard pattern. When it comes to authentication, adopting standard patterns are always better than implementing your own authentication schemes. Furthermore, if you wanted to expose your services via the Internet at some point, the fact that they accept OAuth access tokens would make the whole process a lot easier.


Using sqlmap for SQL injection vulnerabilities in Vaadin I implemented a small website for penetration testing purposes using the Vaadin framework. I have a MySQL database running in the background as well as a Jetty server.

The website is vulnerable against manual SQL injection attacks. But when I want to use a powerful tool such as sqlmap I can't find any vulnerabilites. The main reason is that the url of my website doesn't contain injectable paramters. Instead I get following message:

!main/test: event not found

How can I change the URL to be vulnerable?

http://localhost:8080/#!main/text

Sqlmap does not see any injectable requests.
Vaadin heavily relies on client side JavaScript.
This is very common with current frameworks.
To get a better idea take a look at the W3C's Usage Patterns For Client-Side URL parameters .

You could try to log the request from the browser via the developer tools or use, e.g., ZAP. From there you should be able to identify the right request. I would also recommend to manually validate the SQL injection vulnerability with ZAP. Then you can be sure that you exploit the vulnerability and try sqlmap with that request.

Also, be aware that Vaadin utilizes CSRF tokens that might screw with automated attacks.


Is it possible to use S/MIME in the web client of Gmail? I could not find any options in the web interface of Gmail.

All I could find was a Firefox plugin to use S/MIME with Gmail, but it seems to be outdated.

There is Penango - https://www.penango.com/products - which seems to have a free edition for GMail. I looked into it a while back, since as you say, there isn't anything all that up-to-date, but haven't tried it (ended up going with S/MIME in Outlook checking my GMail account).


In Windows, what should I do to run a program with admin rights without concerns? I'm currently using Windows 8.1 - 64 bits.
In my computer, I have 2 accounts, 1 with admin power (used to install programs), and another without admin power (for everyday usage).

There's a certain game called "Ragnarok 2 Online", that to be played properly, I must start Steam and the program with admin rights (tried anything else, but no success).

I already played this game in the past (at that time, I always used an admin account, but now I learned the lesson), so the game is probably safe.

I tested running Steam and the game inside of a Sandbox with admin rights (Sandboxie, because Avast! Sandbox didn't worked out), and it worked out well.

But, I still have some sense of false security because of the "admin rights", so what should I do to prevent any problems caused by running a program with high privileges?

Thank you.

PS: When I said that I'm running something with high privileges, I mean that I'm logged in the normal user (without admin), and just running the necessary programs as an administrator.

Since you are already running it with Sandboxie, no need to be concerned about "admin rights", that shouldn't be an issue. The program won't write any changes to your hard drive or the windows registry directly, so it is "sandboxed" regardless of having administrator access.

If you'd like to be in greater control of what's going on when you run programs, I recommend trying a HIPS (host intrusion prevention system) plus a good firewall which will ask for your permission before any outgoing internet access and critical behavior (direct access to the disk or keyboard, changes to the registry etc).


Is there any interest in purchasing honeypot traffic data? A friend of mine asked me this recently, and besides the obvious "try with antivirus vendors" I didn't know what to answer.

He's been building a pretty large collection of data from a honeynet consisting of multiple nodes running Cowrie, Dionaea, Glastopf, Honeytrap and others, spread over multiple IPs in different geographical areas.

He's been gathering this data for the past year, while researching neural nets and a way to "learn" from what he gathers, but he realized that this project is taking longer than expected, and wants to possibly off-load some of the data to help pay for the research.

Besides the obvious antivirus companies, where could he look for entities interested in this type of data? Are there any broker-type entities out there? Where would you go looking?

Short answer: No. For 3 reasons.

First, there is little value in an amateur's personally collected data. One cannot know the errors, flaws, inconsistencies, etc. So, one would be buying very "dirty" data. Unless the source, subject, or nature of the data was so unique as to be able to say that purchasers could not have obtained the valuable data themselves, you are just selling random logs. The market value of the data is likely very low.

Second, people and organisations that run honeypots share their data to researchers for free. There used to be places where you could upload and download logs freely, but those repositories, themselves, cost money to maintain, so they rise and fall over time. The market for the data is non-existent.

Third, in many jurisdictions, there are legal issues with sharing honeypot logs because of privacy implications. I run honeypots and the amount of personal data that I collect on attackers is surprising (for a number of reasons). In some cases, attackers reveal everything about themselves (this is one reason why I run honeypots, to report them). The market for the data comes with major liabilities.

Instead of selling the logs, consider looking for sponsors for the research.


Prevent Process Hijacking and injection? How do you prevent Process Hijacking and escalation?  On Windows?
Is there any proactive ways to prevent DLL injections and Privalage escalation?
I know things like Virus Protection and Setting GPOs are great but are there any other proactive approaches?

As stated in kfiros answer, AVs will block known methods and flag known malware or DLLs.

The best way to go to block all kind of DLLs injections and more generally, to block code execution is to use built-in security measures like APPLOCKER.

Of course, to be an efficient mitigation, you need to configure it in white-list mode and not in blacklist mode.

AppLocker can be configured by GPO if your windows is on an ActiveDirectory domain.

Refer to :
https://docs.microsoft.com/fr-fr/windows/security/threat-protection/applocker/applocker-overview for more information.


backdoors in hardware (ie. intel/amd cpu) possible? There are several reports about hardware based attacks on IT-security as for instance those here:

http://wccftech.com/intel-possibly-amd-chips-permanent-backdoors-planted-nsa/
http://www.afr.com/p/technology/intel_chips_could_be_nsa_key_to_ymrhS1HS1633gCWKt5tFtI

duckduckgo-search using "nsa intel backdoor" easily yields much more comparable results and I am unsure if this is indeed a threat or if it is simply extreme paranoia. I have to admit that it makes much sense to me to temper with a cpu as if the concept works passwords by definition must be accessible in most cases, as the cpu will sooner or later "work" with them. Another thing that makes me think that there is some truth to the CPU-backdoor idea is that with the high level of complexity (millions of transistors) it is imho not out of the question that a certain subpart of the chip can be decicated to backdoor purpose while not making it a very obvious thing.

My question is if the concept "to embed a backdoor in a CPU (or bios chip)"
is not something to really be eventually considered?

Is it possible to do it?
If done, what are the implications upon further security measures like disk encryption or linux security modules kind of access control?

Assuming it cannot be finally decided if there is or is not a CPU backdoor, what would be a reasonable approach to encounter the problem, manufacture own cpus? i.e. Open source hardware?

There is no actual evidence of any backdoor and it would be nigh impossible to check anyway, save by "opening" the case and inspecting all the transistors one by one, with an electronic microscope -- there are billions of them, so this is not feasible. Backdoors of that magnitude tend to be revealed by disgruntled insiders, not by external analysis.

However, we can discuss the physical possibility. The articles you link to are confused messes of poorly used terminology, based upon some misunderstanding of about three concepts. These are:

microcode updates;
reflashable firmware;
hardware random number generators.

Microcode is instructions for a CPU-within-the-CPU. This relates to the traditional way CPU were implemented: a number of elementary blocks, which, for each instruction, are activated or not; the microcode describes the "activation sequences". Microcode can be thought as the software implementation of an emulator which interprets the opcodes in RAM that we think of as "machine language". However, in modern CPU, most opcodes are "hardwired" and microcode is used only for complex operations like fsin (computes the sine function on a floating point operand in x86 CPU). This answer contains a much more detailed description of what microcode is and what it can do.

In the CPU, the microcode is stored in ROM but is copied upon boot in a small static RAM element (still within the CPU), which is faster but also updatable. Thus, upon boot, the OS can upload some new microcode into the CPU, and it will be used until next poweroff. OS do that. The microcode format is very specific to each version of each CPU, it is not standard, it is not documented, and it is protected by unspecified cryptographic algorithms, so that a microcode update is, from the point of view of the OS, an opaque blob straight from Intel or AMD.

Microcode opens the possibility of a hidden backdoor. The CPU, by itself, has no network; it runs within the context of the current RAM and hardware and the OS orchestrates all communications. If a backdoor is planted in the machine, it still has to be exploitable from the outside, otherwise it is useless. the story, here, hinges on the opaqueness of the blob: supposedly, the NSA, working with Intel, could craft some specific microcode update which, when uploaded into the CPU, makes it scan the RAM to explore the OS kernel structures and alter them, adding a more common software-based backdoor. This microcode update would then be handed over to Microsoft, to be included in the next Windows update. In that case, Microsoft would be the victim, their OS unwillingly pushing the backdoor code into the CPU.

Such activity is risky, because of the possibility of detection of the runtime manipulation of OS code and structure. It suffices that some amateur somewhere plays with DMA to dump physical RAM into some other device and then uses a debugger to explore the live OS code. Spy agencies, as a rule, abhor risk. Thus, while theoretically possible, I deem the planting of a microcode-powered backdoor rather improbable: not that it cannot be done (it can), but it seems exceedingly hard to do properly. In my opinion, NSA would resort to such games only if easier paths have been closed, and it turns out that they have not. See below.

Firmware updates are actually out of scope of the question. This is not about the CPU or Intel; this is about pushing malicious code into the various Flash chips in the hardware elements which have such chips -- namely, many peripheral but not the CPU itself. Some demonstration called Rakshasa was made and gained some fame, although the implications are rarely well understood or explained. In particular, it does not take any kind of NSA-like political power to make such a virus; quite the contrary: pushing code into reflashable firmwares is open to everybody who could get his own malicious code to run on the machine with sufficient privileges. In that matter, what NSA or Intel could do, some schmuck programmer in Moldavia could do, too.

(I apologize if you are a Moldavian developer and felt offended.)

The yummy part, though, is in the possibility of rigging the PRNG. All crypto-related activities, in particular key generation, ultimately come down to the production of pseudo-alea which should be indistinguishable from pure randomness. Operating systems do that by gathering hardware events such as precise timing (to the nanosecond) of the arrival of hardware interrupts. Hardware interrupts occur for every key stroke, mouse movement, network packet, and so on. There is an assumed "jitter" in the exact timing of these occurrences, which (that's the crucial point) cannot be measured outside of the computer with enough precision, so that's "unknown data" (for the attacker) which can be used to power the PRNG.

Gathering hardware events like that is challenging in some contexts, especially virtual machines in servers, fresh upon boot (since they only have fictitious hardware, they tend to be much more reproducible, leading to a guessable PRNG state). To make things better, CPU vendors now provide hardware RNG which include some specific electrically unstable circuitry (like a Zener diode in reverse): such hardware is integrated in the CPU, accessible from VM, and produces "true randomness" with an acceptable rate.

Internally, the random events from the randomness-generating circuitry is first post-processed in a specific circuit which turns the physical measures into a sequence of bits which can be handed to the OS (which will then use hash functions to obtain a seed for its PRNG). It is conceivable that the post-processing stage be modified so that:

the hardware RNG will look random, and be indistinguishable from true randomness;
unless you know some secret "key" also embedded in the circuit, which would allow to unravel the system and rebuild the random events;
and even if the circuit was completely reverse-engineered, it could still look like a perfectly honest mistake, not a deliberate rigging.

So this would give a "backdoor" which leaves no trace (no need of microcode updates to push through the OS updates), is not detectable from the outside, and even comes with plausible deniability. Practical implementation would be a kind-of hash function which "unfortunately" includes a carry-propagation bug which reduces the internal state to something like 50 bits or so, thus within range of exhaustive search. The reference implementation of bcrypt had such a bug, and nobody saw it for several years, despite the implementation being software and opensource (!), and yet nobody supposed that the bcrypt author did it on purpose.

If I were the NSA or some other similar agency, and I wanted a backdoor in every computer on the planet, I would do it through the hardware RNG. This is the low-risk path.


Intel firmware/microcode updates that make processors "immune" to both Spectre and Meltdown? Recently Intel has claimed the following in a press release (emphasis added):

  SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero. Intel and its partners have made significant progress in deploying updates as both software patches and firmware updates.

  Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. In addition, many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services.

Another more-recent press release reiterated this (emphasis added):

  In early December we began distributing Intel firmware updates to our OEM partners. For Intel CPUs introduced in the past five years, we expect to issue updates for more than 90 percent of them within a week, and the remainder by the end of January. We will continue to issue updates for other products thereafter. We are pleased with this progress, but recognize there is much more work to do to support our customers.

It seems that they are claiming that they have developed firmware updates for their processors that somehow prevent both Meltdown and Spectre attacks from working, and they are being distributed through different vendors.

However I find this claim vague and unconvincing.

Are there Intel CPU firmware/microcode updates that, either partially or completely, prevent Meltdown and Spectre? If so, how do they achieve this and how does it affect performance?

MORE INFO:

Upon further research, it appears the "firmware" update may refer to a microcode update. Still no real details on what this update accomplishes though.

From Debian Bug report logs: intel-microcode: coming updates for meltdown/spectre:

  It's been rumored that Intel will be releasing microcode updates to
  (partially?) mitigate some of the effects of meltdown and spectre.

  Intel has released several updates already, but not all of them AFAIK.

  These microcode updates are of little impact until the kernel changes to
  activate the new MSRs are deployed.  But they do mess with conditional
  jumps and LFENCE.

  Anyway, uploading a partial, unofficial set of updates to unstable to
  close the bug.  Several processors are still missing.  I expect an
  official release from Intel soon, hopefully with updates for everything.

  Everyone should look for firmware updates, the usual good vendors
  already have them out, or will have them out by the end of the next
  week.

Intel will release patches for all processors that are not older than 5 years. Most of these patches will be provided within the next week, the rest until the end of January 2018.

They also released this pdf and this should answer all further questions regarding these patches.

TL;DR:

Mitigation for:

Bounds Check Bypass (=Spectre): Software modifications
Branch Target Injection (=Spectre): Software modifications and Microcode Update
Rogue Data Cache Load (=Meltdown): Operating systems have to be patched for now, but newer processors will "have hardware support" for mitigation.

A shortened quote from the whitepaper follows. I emphasized the parts, that concern your question:

  Bounds Check Bypass Mitigation

  For the bounds check bypass method, Intel’s mitigation strategy is focused on software modifications. The software mitigation that Intel recommends is to insert a barrier to stop speculation in appropriate places. In particular, the use of an LFENCE instruction is recommended for this purpose. Serializing instructions, as well as the LFENCE instruction, will stop younger instructions from executing, even speculatively, before older instructions have retired but LFENCE is a better performance solution than other serializing instructions. An LFENCE instruction inserted after a bounds check will prevent younger operations from executing before the bound check retires. Note that the insertion of LFENCE
  must be done judiciously; if it is used too liberally, performance may be significantly compromised.

  Intel’s analysis of the Linux kernel for example has only found a
  handful of places where LFENCE insertion is required, resulting in minimal performance impact.No comment on Windows/MacOS

  Branch Target Injection Mitigation

  For the branch target injection method, two mitigation techniques have been developed. This allows a software ecosystem to select the approach that works for their security, performance and compatibility goals.
  The first technique introduces a new interface between the processor and system software. This interface provides mechanisms that allow system software to prevent an attacker from controlling the victim’s indirect branch predictions, such as flushing the indirect branch predictors at the appropriate time to mitigate such attacks. [...] This mitigation strategy requires
  both updated system software as well as a microcode update to be loaded to support the new interface for many existing processors.

  The second technique introduces the concept of a “return trampoline”, also known as “retpoline”. Essentially, software replaces indirect near jump and call instructions with a code sequence that includes pushing the target of the branch in question onto the stack and then executing a Return (RET) instruction to jump to that location, as Return instructions can generally be protected using this
  method. This technique may perform better than the first technique for certain workloads on many current Intel processors. [...] For Intel® Core™ processors of the Broadwell generation and later, this retpoline mitigation strategy also requires a microcode update to be applied for the mitigation to be fully effective.

  Rogue Data Cache Load Mitigation

  For the rogue data cache load method, the operating system software may ensure that privileged pages are not mapped when executing user code in order to protect against user mode access to privileged pages.

  This basic dual-page-table approach was previously proposed as a mitigation for side channel attacks on Kernel Address Space Layout Randomization (KASLR) in the “KASLR is Dead: Long Live KASLR1” paper and was called KAISER. This approach also mitigates Rogue Data Cache Load. Intel has worked with various OS vendors to enable a dual-page-table approach in their operating systems.
  An OS implementing this dual-page-table mitigation may wish to take advantage of the Process Context Identifier (PCID) feature on processors which support it. PCID can greatly reduce the performance cost of TLB flushes caused by frequent reloading of CR3 during user/supervisor mode transitions.

  Future Intel processors will also have hardware support for mitigating Rogue Data Cache Load.

Also Intel’s CEO, Brian Krzanich apparently spoke to some of this during his CES 2018 keynote.

https://youtu.be/RlJ9zB74G_U?t=3545

What does this mean for me as an end user?

Does your machine have a Intel processor?

No? Get updates for your OS/VM and your browser. Look for patches by AMD or ARM. If you don't have any of those either, keep your eyes open, if your vendor pops up in the "is also affected"-list.
Yes! Get the patches from official sources. Also update your OS. You should be fine then. Possibly this can be done in one step.  Do this as soon as the patches are available, a new WannaCry might pop up tomorrow.


Is sending recaptchaPublicKey & RecaptchaToken in the post request a potential security threat? I have implemented reCaptcha in login form to slow down the potential brute force attack. However, the application sends recaptchaPublicKey & RecaptchaToken in the post request along with the login credentials. Does it lead to a security threat? As per my understanding, if the application reflects secrets ( such as tokens) in HTTP response bodies, that will be classified as potential BREACH (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) attack.

Is it safe to send RecaptchaToken in post request?

Sending the extra fields in the request is no problem.  Depending on your server-side implementation, you might need them to validate the request.  You should have no need to reflect them, so this would not lead to an XSS.  In any case, this would not be a BREACH attack -- a BREACH attack requires that the attacker is able to control part of the page, and I fail to see how this would be the case with ReCaptcha.  (Unless you consider Google to be the attacker, but then including their javascript on your site would have given them access anyway, so it does not change the threat landscape.)


Is generating an RSA key with password and then stripping it off more secure than no password at all? Some time ago I came across this question on SO; it asks how to remove the passphrase from an existing RSA key using a PHP equivalent to the existing openssl rss command.

I've posted an answer with the solution, but inside the comment thread the OP claimed the following:

  Encrypted key, which is later decrypted offers way better security than not encrypted at generation. source

To me that sounds like total BS; how could a key become more secure by generating it with a passphrase and then stripping it off?

But perhaps there's a valid reasoning behind this "fact"?

Disa would be referring to the fact that if an attacker steals the encrypted key, they also need to steal the passphrase securing the key.

So Disa is referring to operational security instead of mathematical security. The encrypted key is not more mathematically secure - the level of entropy hasn't changed from the viewpoint of a brute force attack1. But the theft or copy of the hard drive will not necessarily lose the key to the attacker as the passphrase might be never be stored on the computer; outside of its own password manager.

1. Unless the initial entropy of the key pair was so bad that encrypting the key temporarily adds more entropy...


Job applicants submit code, how do companies securely test it? Applicants for software engineering jobs sometimes go through coding challenges as part of the interview process. The company may send applicants code and a development task with a deadline, and applicants send back the code with modifications based on the development task.

How do companies presenting these coding challenges securely test the code they receive from applicants? Of course applicants could have the same question, how do they securely work on the code sent to them, but given the applicant reaches out to an established company I imagine the companies are more trustworthy in this situation. What precautions should be taken to safely open, explore, and run the code that someone barely known submits?

A good example of the code in question is an entire Visual Studio solution of ~100,000 lines of C++ code, with the dev task requiring modification or addition of within 100 lines throughout that solution.

Maybe the answer is simply a matter of trust but I wonder if there are technical precautions companies take to ensure no applicants can get malicious code running on the company's computers. I tagged virtualization and sandbox because Virtual Machines seem like a reasonable way to sandbox the code in question, but if testing the code requires the computer doing the tests to have extensive and expensive software installed, is this still the appropriate or only method? Are there any kind of anti-malware scans reliable in this case?

To a large degree, this is a problem that solves itself.  To understand why, we first must understand the goals of a test like this.   More specifically, running the code is not high on the list of priorities.  Understanding it, however, is.

The problems that will be addresses by the developer are well understood by interviewers, and the interviewers are going to have some expectation of how the problem will be solved, technically.  If it's a problem within an existing code base, the first thing that I'm going to do is diff the initial code base and the developers solution to see every single change they've made, and changes that I'm not expecting are going to stand out, and get extra attention.  Even the changes I am expecting are going to get a significant level of scrutiny as I make sure I've understood what the developer has done and assess the quality of the work.

So, aside from the fact that if you wanted to do something malicious you have to hide it in plain sight in a changeset that will be comprehensively code reviewed by people who are both very good at it, and also already know exactly what they're expecting to see, but there is the challenge of opportunity.  As an attacker, you would have to gain an interview at a company you want to attack, for a position that allows you to do a coding test, and the coding test has to be of sufficient complexity and allow you sufficiently leeway to both insert and hide your attack.  And then they reviewers have to actually choose to compile and run it in order to execute the attack.  And the environment it is run in, has to allow for whatever the end-goal of your payload is to be accomplished.  Ultimately, this requires a lot of stars to be perfectly aligned, and there's almost certainly an easier, less risky way. It just doesn't make a ton of sense as an attack vector.


Dual Router Configuration I have a home network that was hacked into recently. The people that got into my network actually accessed my personal files and although I cannot prove it, I think they might have stolen some of them.

Since this happened, I have been looking at various ways to stop this from ever happening to me again. It's very personal like someone has robbed you of your privacy.

In doing so, I found an article How do I set up a DMZ for safer home web hosting? about using two routers daisy chained to create a multiple firewall effect. My interpretation of this approach is that adding another layer of router firewall protection would make it almost impossible for a hacker to get into my home network.

So, in following the article, I have connected two routers together and made set the settings of each router as follows:

Router 1 - Netgear D6200 connected directly to ISP

Internet settings tab
Internet IP address - Get auto from ISP

DNS 1: 208.67.222.222 (Open DNS)
DNS 2: 208.67.220.220 (Open DNS)

NAT: Enabled

LAN setup:

IP address: 192.168.0.1
Subnet: 255.255.255.0

DHCP: Yes
IP Start: 192.168.0.2
IP End: 192.168.0.254

UPnP: Off

All radios on this device are OFF.

Router 2 - Linksys WRT1900AC

Internet settings tab
Internet connection type is set to - Auto Configuration DHCP

Local Network Tab
IP address: 192.168.1.1
Subnet: 255.255.255.0

DHCP: On
IP start: 192.168.1.51
IP end: 192.168.1.100

DNS 1: 8.8.8.8 (Google)
DNS 2: 8.8.4.4 (Google)

Advanced Routing Tab
NAT: Enabled
Dynamic routing (RIP): Disabled

Security Tab
Firewalls IPv4 IPv6:  ON

DMZ Tab
DMZ: OFF

Connectivity tab
UPnP: Disabled

My question is, how can I harden this configuration and optimize it for security?

there are 7 layers in the OSI reference Model. a Network Firewall can protect you against attacks upto Layer 4. there are still 3 more layers out there that are unprotected. so, no matter what you do with those two routers, there will still be a big gap in securing your infrastructure.

Also, Since you believe that you were already hacked, the attackers may have left a back door too.


Encryption key token How to securely store an encryption key in USB drive? Here is my idea. I would like to write a program (let's say PC) and it will store data to a database encrypted at the record level or field level, not in the file level. And also I want to keep the encryption key out of the computer. It is simply keeping the key in the USB device. So physically, the key will be secure. Is there any USB device in the market? What I found are mostly security tokens.

I'm having a little trouble following you, but here are my initial thoughts: Storing on Flash media has a slightly higher risk due to memory/erase issues. That said, it sounds like you want to secure a container on the usb device rather than use something like an IronKey or Data Traveler. I assume the objection would be with leaving the drive unlocked once mounted since this increases the ability for the key to be compromised?

At the software level, there are two option I would recommend.

Truecrypt: Use Truecryt in traveler mode and store your private keys in a encrypted container you can mount and unmount as you please. You still run the risk of having the stored key exposed unsecured for a given period of time.
Use KeePass or similar. KeePass is a password database, but if you are using the 2.0 branch or a community versions which support attachments, you can use it to store each of your private keys with one database which you take with you on your usb drive. You can then access and cut and paste your keys as necessary. The advantage here is that keepass will timeout and lock up if you configure it to do so. The disadvantage is that you are no longer dealing with a file that is just "sitting there" ready to use. You either need to extract it or cut and paste when its needed.

If you are asking something different let us know and I will adjust my response accordingly.

Update
Based on your comments, I'm not sure if you could get a single devices - maybe you can combine a phone/sms based OTP solution with some sort of physical token / smart card.

Update 2
This post seems similar, I checked through the comments and they are talking about a lot of different options for secure token/card hardware, figured I would just link instead of re-posting so you can determine which options are most useful for you.


What is a login flow method to prevent account jacking when your website has Email/Password sign in AND Google Sign in? For example, my website has Email/Password login and the "sign in with Google" button. If a user creates an account with their email and a password, then decides to sign in using the "sign in with Google" button, but using the same email as their email/password account, should we let them into their account? Or should the sign in attempt be blocked and the user redirected to the email/password login form?

Email/Password Account Email: example@gmail.com
Google Account Login Attempt: example@gmail.com

Thanks!

This is an interesting problem. I would expect that in most cases the user does not remember that they had created a "real" (locally managed) account or that they want to switch to single-sign-on using their Google account.

I don't really see this as a potential attack vector since the attacker would need to have access to the Google account already which likely means that they have access to the users email too.

That's why I would suggest to provide the user with the information, that there is already a "real" account with this email and offer to switch this account to a single-sign-on using Google. If the user agrees a proper verification that the user has access to the email should be done anyways, similar on how this is done with a password reset with locally managed accounts.  If the user instead does not want to switch the existing account they should be presented with the normal login option, i.e. logging into an account which is still locally managed with Google SSO should not be possible in this case.


Can someone use IP spoofing to access your facebook profile as an administrator? Do any IP addresses have security so they cannot be used by a hacker to access secure pages? For example, could a hacker spoof a Facebook IP address to enter someones profile page and make changes as an administrator?

My facebook profile was hacked twice and the IP addresses both came from the Facebook office in Singapore. I'm wondering if someone hijacked these IP Addresses so they could access my account and make administrative changes to my profile, which is what occurred.

I was under the impression that companies like Facebook would have strong security restrictions to prevent people from hijacking their identity.

We don't know what security measures Facebook exactly provides but spoofing the source IP of a TCP connection (which is used when accessing a web site) and still doing something useful with the connection is impossible in practice.

This means that it is more likely that the site was really accessed from the shown IP address (no spoofing), that the database records tracking the IP address were tampered with or that you've interpreted the information wrong. If any of these happened or something else can not be inferred from the provided information, but I'm pretty sure that no IP address spoofing was done by an attacker when connecting to Facebook.


Methods for backing up key on paper What are the methods to backup a key to paper?

The idea is to have reasonable protection and the ability to restore the key in case of the digital backup is lost.

Are there things that convert a standard PKCS key into a easy paper representation?
(Example take a key and output a words or QR code maybe?)

Intent:

The intended use is for less technical people to have a easy way of backing up their keys e.g. filing the paper somewhere.
It should also be reasonably easy to restore.

This RSqueezA sounds okay to provide QR Codes and read from them to a key file.

But: In my company non-technical people get a long (about 32 random characters) key phrase printed as-is. And then the paper will be stored in a (fire-proof) safe.
Reading and typing all the characters is good and fast enough for them.

For all the other people without a safe I recommend a password manager and store the password the same way but at home at a non-work-related place. (no one would guess it's the password for their work).


Is OpenVPN actually forwarded over TLS? I'm investigating behavior of SSL decryptors on OpenVPN connections to port 443 and I noticed that device I use as decryption proxy doesn't recognize OpenVPN connections as TLS thus doesn't decrypt them. The question is then - how does OpenVPN protocol differ from standard TLS?

Openvpn uses TLS for authentication and key exchange but it does not use it for the actual data encyption. When running on UDP openvpn runs the TLS session on top of a custom "reliability layer", i'm not sure what it does when running on TCP.

Furthermore an openVPN network uses it's own CA to authenticate both server and client certificates. So you can't subvert the certificate process by loading a cert into the OS certificate store.


What's the Security equivalent to SICP? For those of you who don't know any developers and/or didn't go to MIT, The Structure and Interpretation of Computer Programs is the Canonical reference on it's title subject. It is often used as the text in begining comp sci classes.

What, if anything, is the equivalent book in information security (please don't respond with anything that contains CISSP in the title)

Edit: As I responded below, I'm really looking more for a book (or collection of books) to give to neophytes (think college intern) to help them achieve the correct mindset. You may have noticed we don't really think about the world the same way most people do...

I recommend Bruce Schneiers Secrets and Lies, which I read recently.  It's a good introduction, but not the same way SICP is an introduction to programming.  It does a good job with teaching mentality though.


LogJam hardening OpenSSH and testing it I would like to harden my OpenSSH (clientsite) after the LogJam attack.

I read this article https://weakdh.org/sysadmin.html and there is one paragraph, which says how to do that. Is this enough and how can I test if that is good enough? How can I hardening it if I am using OpenSSH lower than 6.5?

Throw out < 2048 bit builtin moduli
On the server: Have a look at your sshd_config and throw out the diffie-hellman-group1-sha1 if it appears in the KexAlgorithms section.
And restart SSHD.
Check with Nmap

how can I test if that is good enough?

Get Nmap and run the `ssh2-enum-algos' script against the SSH server.
The diffie-hellman-group1-sha1 must not appear. It only has 1024 bit.
Throw out < 2048 bit custom moduli
On the server: throw out DH-moduli less than 2048 bits.
Here's some code. It' adapted from a ServerFault question:
awk '$5 >= 2048' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

And restart SSHD.
Check With SSH-Weak-DH Tool
Get, compile, and run the SSH weak Diffie-Hellman group identification tool.
The tool uses a patched OpenSSH client that attempts various times to connect to the server using different DH group parameters for the DH key exchange protocol, thereby determining whether the server has weak DH groups enabled. GDSSecurity explains how the tool works on their blog.
Check with WireShark
I don't really know how to check for this.
Some ideas below:
Sniff the Handshake on the client with WireShark.
Filter for ssh. Find the Server: Diffie-Hellman Key Exchange Reply, New Keys line.
Or quicker yet: Filter directly for ssh.message_code == 31.
Look inside the SSH Protocol | SSH Version 2 | Key Exchange | KEX DH host key section. There is human readable ASCII text in there that will tell you what Key Exchange mechanism the server has selected. If it's something that starts with ecdsa- then you're safe from LogJam. Otherwise you'll have to have to count bytes again. And there'll have to be at least 256. (256 x 8 bits == 2048 bits. Which is what we want as a minimum key length.)
Further reading:

Jethro Beekman, 2015-05-20, On OpenSSH and Logjam (Archived here.)
stribika, 2015-01-04, Secure Secure Shell (Archived here.)


How is "something you have" typically defined for "two-factor" authentication? A wide range of products claim to offer "two-factor authentication" (c.v. Two-factor authentication - Wikipedia).  Most are deployed as "something you have" to be used in addition to a normal password ("something you know").  Some of these "second factors" are as simple as providing a piece of paper with either one-time-passwords or information needed to respond to a simple challenge-response protocol.  Others range all the way up to “hard” cryptographic tokens which cannot readily be copied.  The latter is e.g. required for the NIST 800-63 (Electronic Authentication Guideline) "Level Of Assurance 4" (aka LOA 4).

For example, would a one-time-password via paper meet NIST's "LOA 3" requirements?  How about the various recommendations for banking (e.g. FFIEC), or related requirements from other entities?

I started to ask this question to get input before discovering the one. In light of a Magistrate Judge's recommended judgement on PATCO v. People's United (which implies a horrible theory regarding multifactor authentication), I define something you have as this:

What you have must only be compromised by an attacker having physical access to what you have. This excludes:

A password written on a piece of paper (once somebody sees it, they know it)
A cookie stored on your computer
"Security questions" (They are just another password)
Your PGP key kept on a thumb drive if you plug it into a machine that has network access

That said, I would consider a paper list of 100 passwords that have no relation and are each used only once would be considered something you have. A paper list of 100 passwords that might be asked for more than once would not qualify as an attacker would be able to pretend to have access to that credential by monitoring.

Something you have must be something whose integrity can be secured by physical control. Attacks on the other side of the channel such as stealing their authentication database or breaking a cryptographic protocol don't count. If it can be compromised without an attacker's physical interference (or breaking an encryption algorithm as they are integral to demonstrating possession remotely), it is not something you have. ATM cards are a bit fuzzy that way -- a compromised ATM could provide all the track data, though what we usually see are skimmers (physical access). RSA tokens are another that I would consider something you have.

I like smartcards best because placing them in a reader won't expose their secrets, nor would compromise of the authentication database.


What's a least-privilege way to allow node.js to access network adapters on Linux? Linux naturally restricts all but superuser from pulling traffic directly from network adapters. In the case of Wireshark/dumpcap, setuid root is used ONLY for dumpcap, restricting the privileges needed for Wireshark run by the user:

  Wireshark has implemented Privilege Separation which means that the Wireshark GUI (or the tshark CLI) can run as a normal user while the dumpcap capture utility runs as root. This can be achieved by installing dumpcap setuid root. The advantage of this solution is that while dumpcap is run as root the vast majority of Wireshark's code is run as a normal user (where it can do much less damage).

In the case of node_pcap, a similar issue occurs: the node.js process needs superuser to listen to the adapter, but that's a poor choice.

What's a sensible way to give a node process just enough privilege to capture packets and nothing else outside of the account running it?

Based on a recipe by Jeremy Stretch from Packetlife:

Ingredients

setcap (usually comes with the libpcap2-bin package) - it will allow you to set the special kernel permission/capabilities that node needs when running as a regular user account.

Cooking

A. Give node capture capabilities:

setcap 'cap_net_raw,cap_net_admin=eip' /usr/loca/bin/node

B. Report on success.

C. ???

D. Profit.

Hope this helps!


Can I trust opera browser free VPN? When  traffic leaves the VPN, the operator of the VPN server can see the websites I'm accessing. Opera browser has a free VPN. Can I trust this VPN?
https://www.opera.com/features/free-vpn

It is impossible to say if a VPN provider and infrastructure is actually trustable for an unknown purpose (the only information about the purpose were "can I trust"). It is even impossible to evaluate the specific VPN if your purpose was actually more clear. Apart from developing a threat model for your purpose a proper evaluation would then likely involve checking the code involved at the client and server side against accidental bugs and deliberate backdoors, checking the infrastructure and how well it is protected against unauthorized access, and and and ...
In other words: No, it is not fully trustable. Nothing is. It might still be trustable enough to reduce risks which you have when using an open hotspot. But you are still relying on a third party for code and infrastructure. Running your own VPN instead is likely more trustable, but even in this case you usually rely on code which you don't fully understand and control and run your VPN endpoint in an infrastructure you don't fully control either.


how to detect the origin of a hacker attempting to breach or who has sucesfully breached a network or system In the case of detecting that a system is infected with a root-kit, what if any thing can be done to trace route the origins of the remote out going packets to attempt to find out where the attacker was logging in from? I ask this question as more of a curiosity and as a wonder how in the professional world a hacker would be caught. I see a lot of articles stating that the attacker has been caught, but what is the procedure?

As a rule, this is a fruitless endeavor.

It is very uncommon for a hacker to log in from his home IP or from any server directly traceable back to him. It's far more common for hackers to use previously-hacked targets as jump-off points for future attacks. Often attackers will also use other relays (such as IRC bouncers or public IRC networks) to relay commands to infected servers.

You can often trace the attack back to the server from which the attack was launched, but that almost certainly will not belong to the perpetrator. Theoretically you can get the logs from that server and attempt to trace the attack hop-by-hop. But in practice, this never happens. Often the attacks cross political borders making this sort of cooperation effectively impossible. Furthermore, even if you can trace his original IP, it will many times belong to a location not directly traceable to him, such as a coffee shop or an internet cafe.

But if you have the logs, it can be helpful to get the IP address of the last hop primarily because you can then analyze all traffic logs relating to that IP to see how and when the attack happened, and to help you identify additional attack components that you may have missed.

As for how these hackers get caught
Very rarely is the attack actually traced directly back to the perpetrator, as covering your tracks is reasonably simple. Instead, attackers are found by other means. For example: tracking someone bragging about the attack on IRC, analyzing the use of stolen information, identifying the twitter account of someone who took credit for the attack, or plain old snitching by ex-friends or informants.


Can a man engaged in phishing be prosecuted if I know his IP? My familiar received some emails from a man she meets at dating site. The man sent her his photos by email. In them he made some attempts that looked like phishing so I decided to lookup more information about him. I found that those photos are easily accessible in Facebook and belong to a man with a quiet good reputation living in US. All emails came from different IP addresses but some of them are located in Ghana:

197.251.136.205
197.251.164.116
197.251.140.152

and other one in Nigeria:

41.184.75.187

and the last is known to be used by spammers.

Is there a way this man can be prosecuted?

Theoretically speaking: maybe, at the moment you just have a possibility and no actual proof. (Just IP addresses aren't enough they are circumstantial, the police will need to at least find proof on his computer (which in most cases is also, at most, considered circumstantial))

Realistically: Not a chance. It's Ghana, the chance you will get anything done there within a reasonal time span and without spending money is smaller than the probability easter and christmas happening on the same day. In those type of countries bribes are often more common than justice. This may sound rude, but it's unfortunately the truth.

There's a nice paper about cybercrime in Ghana here.


Why is FIDO U2F an entirely different standard from FIDO UAF instead of just a subset? As you may already be aware, the Universal 2nd Factor (U2F) standard is a standard for 2nd-factor authentication which allows users to authenticate to web applications using a USB hardware token.

While reading up on this standard, I discovered that the Fast IDentity Online (FIDO) Alliance, which created the U2F standard, also has another standard they created around the same time called the Universal Authentication Framework (UAF), which seems very similar to U2F:

(Source)

These standards seem very similar, with the only significant difference being what authentication mechanism is used in step 2. However, further reading suggests that UAF allows for multiple different authentication mechanisms in step 2:

  The passwordless FIDO experience is supported by the Universal Authentication Framework (UAF) protocol. In this experience, the user registers their device to the online service by selecting a local authentication mechanism such as swiping a finger, looking at the camera, speaking into the mic, entering a PIN, etc. The UAF protocol allows the service to select which mechanisms are presented to the user.

With this in mind, why is U2F even a separate standard from UAF in the first place? What's so different about U2F that warrants it being an entirely different standard rather than just another authentication mechanism for UAF?

From a technical point of view, your question totally makes sense.

U2F and UAF were pushed by very different actors/players. UAF was backed (cough plagued cough) by biometrics companies and never took off for many reasons. U2F is a simpler no-nonsense solution that is now largely adopted by major web services providers like Facebook, Google services (including Gmail, Youtube, Google Ad, etc.), Github, Dropbox, FastMail, Dashlane, Salesforce, etc.

At first, there were no real all-in-on perspectives, but it may be different now. In fact, in the current draft of the next FIDO standard called "WebAuthN" (that used to be called FIDO 2.0 too) we can see as a non-messy UAF successor, FIDO U2F can be used as an "Attestation Statement Format" as you can see here: https://www.w3.org/TR/2017/WD-webauthn-20170216/

So your question makes sense and hopefully, in the future we are following this path.


Can someone track my location if I clicked on a link to Google Maps? I was using a dating app, and this person sent a link. When I clicked on it, it led me to Google Maps and I exited immediately, without seeing which location it was showing.
I'm scared the person now knows my home address/ip address or some other personal info. I don't know whether the guy was sharing his location, or whether it was some trick. Please help?

I would not worry to much about this.
It is possible the person who sent the link now knows your IP address. However, that doesn't give them very much information. It can be used to figure out roughly what city you probably are in, but it won't get any more precise than that.
Unless they discovered some major vulnerability in your browser, your device or in Google Maps, they can't figure out where you are just because you click a link. This is not very likely and not something I would worry about in a situation like this.
If you gave the website some extra permissions, if you downloaded something, entered some information or did something else on the site than just merely visiting it, there would be bigger risks involved.


Is authentication using Facebook/Google considered good practice? A lot of services, sites, and applications offer the 'login with Facebook' or 'login with Google' option. For many sites, the browser opens a separate window in which you can enter your username and password. This way, you can check the URL and convince yourself that the origin really is Google/Facebook/whatever. Logging in in this window should be safe, and there is no reason to worry (apart from any privacy concerns you might have).

However, this is not always the case. Though I can not find them now, I am quite sure that there are some sites which require you to login with your Facebook/Google account on their site (so the URL shown is not Facebook/Google). I am sure there are some desktop application which do this as well. One example I can give is Nvidia's GeForce experience. Apart from the ridiculousness of having to sign in on Google or Facebook to update a driver, this does not seem to be good practice, since I can't check if I actually login on Google or that the login window is spoofed.

I have read a couple of times that using other services to login is considered good practice. Is this true? I can see some serious problems with it.

I am quite sure that there are some sites which require you to login with your facebook/google account on their site (so the URL shown is not facebook/google). I am sure there are some desktop application which do this as well.

This is very bad practice for websites, because OAuth / OpenID (which are protocols used to delegate authentication)  is designed to work around that exact use case. But there is no other way to do it in desktop applications, because desktop applications don't have redirect functionality.

A web page can forward you to the google or facebook authentication, where you can enter your credentials, and then when you authenticate successfully, Google / Facebook can redirect you back to where you came from.

This is impossible to do in a desktop application. One way around it is for the desktop application to open a web browser where you authenticate with your auth provider (Google / Facebook), and some magic happening behind the scenes can then authenticate you to the desktop application. But by and large this is an unsolved problem - you'll simply have to trust the desktop application to not steal your credentials. In fact opening a web browser doesn't really solve the problem either; now you're just trusting the browser to not steal your credentials (The browser is a desktop application, too!)

  I have read a couple of times that using other services to login is considered good practice. Is this true?

It's considered good practice because

It's user friendly - users don't have to remember a hundred different credentials
On the whole it offers better security - you don't have to trust a hundred different implementations and hope every site is bug-free and stores your password safely - you only have to trust Google, or Facebook, to take care of security. And they're much more capable to do so than your teen-aged nephew who wrote yet another login system for his new site.

Of course, it also means you're now putting all your eggs in one basket. If someone breaches your Google / Facebook account, you're in much bigger trouble if you use that account to authenticate on a hundred other sites. Also, there are privacy issues in letting your auth provider know which sites you visit and with what frequency you sign in.


Heartbleed: hackers have already used the vulnerability? Read about the vulnerability and decided to check out the site. Receiving a response from the php code was surprised. Look at the screenshot.

Perl-script: http://pastebin.com/rL0XkewP

Hackers have already got down to business?

What's your question?  Yes, its been widely described and the attack is trivial to do once it was disclosed that heartbeats were flawed and you looked at the patched section of OpenSSL.  You change the payload_length of a heartbeats request to something like ffff to get 64K back; or something else bigger than the payload.
More interesting is that the heartbleed attack was apparently used in the wild last year from IP addresses associated with a botnet that appears to systematically log IRC:

The second log seems much more troubling. We have spoken to Ars Technica's second source, Terrence Koeman, who reports finding some inbound packets, immediately following the setup and termination of a normal handshake, containing another Client Hello message followed by the TCP payload bytes 18 03 02 00 03 01 40 00 in ingress packet logs from November 2013. These bytes are a TLS Heartbeat with contradictory length fields, and are the same as those in the widely circulated proof-of-concept exploit.
Koeman's logs had been stored on magnetic tape in a vault. The source IP addresses for the attack were 193.104.110.12 and 193.104.110.20. Interestingly, those two IP addresses appear to be part of a larger botnet that has been systematically attempting to record most or all of the conversations on Freenode and a number of other IRC networks. This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers.


How can my .exe become infected? I want to have a simple application that is in .exe (executable) format hosted on a secure domain that, on my website, a user can click to download and run. However, I'm aware that many annoying viruses are in the form of a harmless-looking executable, so I naturally would want to also put, as a small notice for that download, something like "Not a virus - trust me at your own will". But this leads me to a certain concern.

How, if possible, could that executable become infected? Is what I'm thinking of doing stupid? If so, what is a better alternative? What precautions should I take?

The last thing I want is for a file of mine to become infectiously corrupted and to have the possibility of it messing with others (though Linux users are more or less safe).

You can and should sign Windows applications : see http://msdn.microsoft.com/en-us/library/ie/ms537361(v=vs.85).aspx


Checking a locally stored string for tamper I'm working on a multiplayer game using WebSockets. I've decided all user data will be stored on the client, eliminating the need for authentication using passwords etc.

LocalStorage
'save' -> '{"key":"value", "key2":"value2"}'
'hash' -> '<hash of save>'

The idea is to store the user data in plain text but to also store a hash which can only be calculated by the server (running Node.JS). The client will send both save and hash to the server to be checked and loaded into memory for this session.

Now, my question is:

If I use SHA256 to hash all the save data, how can I prevent a user from generating their own hash for the data?
Then, (assuming the answer to part 1 is 'salt',) will using salt keep me safe or can this be calculated? (I can make the salt partly different for each user)

What you want is something that ensures integrity of your data.

The most common solution for this is to use an HMAC, that is a keyed digest. NodeJS has an API that calculates HMACs. Compared to a "salted" hash, where you would keep the salt private, HMACs are designed to be secure even against some additional attacks, such as length extension attacks.

As long as you keep the key private (and large enough), you should be able to use the same key for all users.

Be aware that this won't prevent people from sending you a previous version of the data. All this does is guarantee that the data was valid at some point. If you want to be sure they're sending you the latest version, you would need some server side storage to store either a version number, a timestamp or the last data digest. If you choose to store the last digest, a normal hash will suffice, you won't need to send the hash or a HMAC to the client.


Configuration of Burpsuite (Forwarding request) I am unable to configure burp suite through proxy 127.0.0.1:8080 with browser proxy (127.0.0.1:8080).
Everytime when I run Burpsuite and forward the request (while intercept is On),
nothing happens only "Insecure Connection" appears. What should I do?

Kindly help me to figure it out.

If you surf through pure http (without SSL) pages you should have no problem. But to surf through https (using SSL) websites, as Arminius said in a comment, you must to install Burp's certificate. Burp needs to perform a man in the middle to serve ssl pages to you using it's certificate.

Open your browser and open http://127.0.0.1:8080 to access to burp's page. Download Burp's certificate clicking on CA Certificate, is on the top right side of the screen. Once downloaded, install it on your browser. the installation steps may vary depending of your browser. Then you'll have no problems surfing ssl sites and you'll see https requests on your Burp's proxy HTTP history.


Is it possible to be infected with malware/virus via a proxy? I'm curious as to whether you can be infected with malware by using a proxy? I currently process data using Python but occasionally I encounter recaptcha, so I'm looking to implement proxy support.

The data processing is simply an experimental project. So of course my priority is the state of my computer and so I want to get a better insight of malware via proxies before I establish a connection with one via python, the connection would be made via TCP.

Also I'm not necessarily looking for a in-depth answer as I assume if this is possible there's multiple scenarios, so just a simple yes/no and brief explanation would be great.

A proxy forwards all traffic and therefore has the possibility to also modify the traffic and thus also to modify the traffic in a malicious way, including making the client download malware or exploiting bugs in the client processing the traffic. This is definitely true for plain HTTP but is also true for HTTPS if the client does not properly check the certificate. The latter is often true for web scraping programs (like your project) which often explicitly ignore certificate errors in order to get to the content.

If this is a trusted proxy you control yourself this is likely not an issue. If you instead use an untrusted third-party proxy (which seems to be the case here) then the chance is much higher that the proxy will be malicious. If you treat all data you get as strictly untrusted and potentially malicious and thus properly sanitize these before doing any actions on these this might not be a problem though.


Anonymity while "attacking" a target I'm very interested to the security topic, but sometimes I fail in understanding how a hacker would be successful like for example a group that recently claimed they got data from FBI.

I wonder while they engage in such a hacking the target's logs will be telling everything you are doing, specially engaging against the government which is very rich in resources to trace and go against anyone who would attack and get data from their servers... My biggest doubt is regarding the networking perspective.

How the anonymity is done right. It is probably the hardest thing to do I guess, you would have to bypass firewalls, IDS, and a bunch of other security measures without letting a track of your location...

I know about IP spoofing, Tor, VPNs, passive attacks and Zombie machines, but is there other way to be invisible in such a good way or is it a well done combination of the options I mentioned?

How would someone be able to get maximum "invisibility" in the networking context? Sorry for my noobness :-/

This is very complicated. You can have all sorts of recipes for hiding your IP but everything depends on the willingness and capacity of your target to go after you.

The story of the fall of Silk Road's owner (Ross William Ulbricht) is a prime example of things which can go wrong when trying to hide.

The "capacity" part is a key point: local authorities for the attack target must have the legal possibility to go after a criminal. The James Bond (or any other well known case you can think of) version is that they can send hords of spies to get you but it is not likely to happen. If the attack comes from a not-so-friendly country then the forensics analysis will provide an information and then hit a wall (the entrance to that country).


Are different hash algorithms ever used together? I was wondering if different hashes (e.g. md5(sha1($data)) ) are ever used together for data security and if there was any reason for it (either positive or negative answer).

Using two hash functions together, as an extra safety against a breach of one of the functions, is delicate. Concatenation (the data is hashed with both hash functions, the results are concatenated) yields a collision resistance equivalent to at least that of the strongest of the two functions (and, surprisingly, not really better than that); on the other hand, concatenation makes preimage resistance no better than the weakest of the two functions. Composition (the data is hashed with one function, and the result is hashed with the other function) offers the opposite: preimage resistance is at least as good as the strongest of the two functions (subject to some definition subtleties, depending on whether you want resistance against recovering the data which was used, or just any message which yields the same output), but for collisions the weakest function defines the overall resistance.

So combining two hash functions together is, at best, a mixed blessing. SSL/TLS, up to TLS 1.1, combines MD5 and SHA-1 into its internal "PRF", which is notably used as a key derivation function (to extend the negotiated secret into keys for symmetric encryption and integrity control); both functions are used in HMAC and then turned into custom PRNG, and the two generated streams are XORed together. The intent was to have a key derivation function which resists cryptanalytic breaks of either MD5 or SHA-1 (whether this really works has not been formally proven; it really depends on the nature of the "break"). It is interesting to note that TLS 1.2 reverts to using a single (configurable) hash function. Combining two hash functions together means that you have to implement both, which is a problem for embedded systems which often have hard constraints on code size.

So the usual advice is: do not do it. It is hard to get it right, and even if you do not introduce any weakness, it is unclear whether you actually gain anything that way, security-wise. On the other hand, there are clear operational costs. It seems better to use a single, better hash function (which means: ditch MD5 and SHA-1, just use SHA-256 instead), with algorithm agility (make the hash function configurable, so that you could change it later on).


Resetting passwords howto I am currently in the process of designing a registration form for the users to register accounts. The accounts will contain a lot of personal information, so I want to ensure highest possible security. The biggest flaw/problem in the requirement is that username must be first letter of the user followed by his last name, and thereby finding username is an easy task. Due to that I ensure to enforce minimum 12 character passwords that include numbers and capital and lower case letters.

However I was wondering if a user goes on vacation or has a child or takes some long leave and then comes back not remembering the password. What means would there be for him to retrieve/reset his password?

I found issues in any approach I can think of.

Asking security questions doesn't seem like a good choice, since that seems to defeat the purpose of enforcing long passwords. Nowadays many people are not too smart and therefore answers to many security questions can be found easily online by doing some research.

Simply sending reset link or new temporary password to the user's email without doing some authentication also seems pointless because what if the user has a very weak password on their email then the attacker will just try cracking their email instead of their account.

And pretty much any other reset/retrieve password means I can think of seems to defeat the purpose of ensuring a user has long password.

What authentication/reset method would you recommend for this?

Any help will be greatly appreciated.

In some very secure scenarios (I don't know if you really need to do this way) I have seen the following configurations:

Send the password by letter (not the securest way, but...).
Send half of the password by phone and the other half by e-mail.
Two different telephone operator spells parts of the temporary key.

I believe the second way is the best, but I believe the best secure/usability way of doing would be "resetting link" + "sms to the mobile number" (something the user have). You can always ask some data regarding the account if you want to add to the security "something the user know". Always, when giving a way to restore the key providing one you must oblige the user to change it the first time he uses it.

I am sure you can make up a solution starting from these points, but, as always, do not overkill if it is not necessary, most of the people tend to think his application needs to be NSA-LIKE-EXTRA-SUPER SECURE".