What are the security implications of "Row Hammer" attack? I just found out about the Row Hammer attack. Based on the description, this sounds extremely dangerous, but I wonder what percentage of devices are actually affected by these. Are there any ways to protect oneself other than replacing RAM with one that supports ECC?

The basic security implication is that an unprivileged user can elevate their access to root/kernel level.

Google's Project Zero tested 29 different laptops manufactured between 2010-2014 inclusive, and found that 15 were vulnerable and 14 were not. They do warn that this sample size is not enough to be considered representative, but it is still suggestive that this is unlikely to be an isolated problem.

The original Flipping Bits in Memory Without Accessing Them paper suggests that the problem is much wider:

  Among 129 DRAM modules we analyzed (comprising 972 DRAM chips), we
  discovered disturbance errors in 110 modules (836 chips). In
  particular, all modules manufactured in the past two years (2012 and
  2013) were vulnerable

The only real way to mitigate the attack is to not run arbitrary binaries on your system, and to not allow anyone else to access your system if they might have hostile intentions. This is obviously a problem for shared computing resources e.g. universities, hosting facilities etc. Cloud providers could potentially be vulnerable (successful memory corruption from inside VMs has been reported, but it remains to be seen how exploitable this is).

Using ECC, whilst not a guarantee of security, might lower the probability of successful exploitation. The full mitigation is to update to a system that employs some defence - either a memory controller or DRAM that actively detects and avoids the exploit. Availability of such controllers or DRAM right now is unknown, but they are known to exist. Memory manufacturers have been aware of this problem for a while, and the specification for LPDDR4 includes mitigations, so future laptops will be protected.


To-dos when taking over an existing webserver I'm taking over as a system administrator on an existing LAMP server for a site with a number of individual applications.  The person I'm replacing has done a pretty good job with security as far as I know, but I'd like to take any preventative measures I can.

With the OWSAP top ten web vulnerabilities as a good place to start, what are critical things to check?  I'm looking for both high-level concepts as well as specific things to look for (e.g. file permissions, open ports).

Center for Internet Security (CIS) has extensive guides on how to secure Apache and MySQL. It include everything from file permissions, partition layout, log files best practices etc. For the OS hardening, you would find specific hardening advice for the specific OS as well. It doesn't mean like CIS is the end of the world but what it means is you will find a comprehensive list of security best practices that is not only high level but go on into as much detail as specific commands to run.

The good thing about CIS benchmarks is that once you implement the security settings, you can use many configuration bench-marking tools to audit the security settings against CIS configuration benchmarks. Nessus professional has such a service that I use regularly to audit my own servers.

CIS Apache Benchmark CIS
MySQL Benchmark CIS
Rehat Enterprise Benchmark (if you are using a base OS different than
Redhat, there are others as well.


How secure is PKCS #12 I need to move user cryptographic identity between several user devices. In the operating system I have only one option: use password-protected PKCS #12 to import the identity to the OS secure store.

I’m wondering how secure PKCS #12 is. Can the p12 file be distributed over the insecure channel? How secure is it compared to the solution where a fixed password is used for the p12 (just because the API requires that), but then the result is encrypted using the combination of PBKDF2 + AES-256 in CBC + HMAC.

PKCS#12 is an extremely flexible format, so any answer to your question is relative to what the archive producer decided to do: which algorithms, which parameters...

Normally, when doing password-based encryption, you will end up with 3DES or AES, and the key derivation algorithm is PBKDF2 with a cost parameter that you do not get to choose. To make the story short, this will be as safe as these things can be IF (and that's a big "if") the used password is strong.

For a specialized use case, you can generate the "password" as an actual big key: take your favourite cryptographically secure PRNG (e.g. /dev/urandom on Linux and MacOS X) and use it to produce a sequence of 24 random hexadecimal digits. This will offer 96 bits of entropy, and things will be fine. The confidentiality of the private key in the PKCS#12 file will be maintained, and the integrity will be reliably verified.

A simple way to generate such a random "password" on a Linux system is:

(dd if=/dev/urandom bs=16 count=1 2>/dev/null) | sha1sum | cut -b 1-24

On Windows you can use PowerShell:

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
([System.BitConverter]::ToString($buf) -replace "-", "").ToLowerInvariant()

If you really want to add an extra layer, the reasonable way is not to assemble a symmetric encryption algorithm and a MAC yourself: these things are deceptively hard, meaning that it is easy to make something which works, much harder to make something which is strong, and very much harder to make something that can be ascertained to be strong. Instead, use an existing protocol which is supported by an existing, well-vetted implementation. I suggest GnuPG (the OpenPGP format implemented by GnuPG supports both symmetric and asymmetric encryption).


Double-hashing authentication scheme Rate my authentication scheme? (This feels simple enough to be a duplicate, but it's really hard to search for these types of questions. Sorry if it is a duplicate.)

When a password is set, it's immediately hashed with a random salt S1 and stored as H1.

When a user tries to authenticate, they are sent S1 and a random value S2. They then hash their password with S1 to get H1, then hash that with S2 to get H2. H2 is then sent to the server.

The server simply computes H2 the same way, then compares the values. The server then generates a random 64-bit value C and sends it to the user.

All further communications with the server contain C as an authentication token.

The point here is to ensure that the password is never sent in cleartext; the communication channel between the user and server is assumed to be "reasonably" secure, in that this scheme is for an extremely low-value target; the user's most common passwords are likely to be the most valuable information present.

The protocol should defend against:

Determination of the password by a passive or active attacker
Impersonation of the user by a third-party without eavesdropping capabilities

EDITS

I'm not using TLS because this is for a video game; I'm trying to minimize latency as much as possible.
The user's password is set via a TLS-protected webapp.
I don't care (much ☺) about the NSA hijacking a user's account so much as 1337Kid__1 hijacking OtherPlayer's account, or an attacker intercepting passwords.

I'm making the assumption in the above that eavesdropping on another user's traffic is hard to do (for someone who isn't the NSA) without being on the same network segment as them; if this is a notion I should be disabused of, let me know.

When a password is set, it's immediately hashed with a random salt S1 and stored as H1.

Hashed on the client side? If not, the password must be sent at least once in cleartext.

  The point here is to ensure that the password is never sent in cleartext; the communication channel between the user and server is assumed to be "reasonably" secure,

Why not use encrypted traffic, such as TLS?


is it easier to get the original password if you have multiple hashes of it? Most users tipically use the same password for multiple applications. Let's say all of these applications hash the password in some way. Would it be easier for an attacker to get the original password if it got access to all the different hashes? Of course the attacker probably looking at the hashes may know which is the weaker one and only try to bruteforce this, but has he gained anything having access to other hashes of the same password? Also assuming the attacker does not have any rainbow table containing any of these hashes.

So, if an attacker has access to all these hashes of the same password, can he be faster in breaking it than just try to bruteforce one of the md5 hashes (as in this case is the weaker link)?

33c38d9db9759da0d0a813968bc3c1fb
7b8758cf3cb6e540d60b3e9999c48fbef0502ac6
faa81286aa90907253a58acfd83d2d89e58120031630d60dc05d0cd365b6df8d
$1$NPeNiNCA$AwpOWKuur2LZvXiJxNM6U1
$5$VHVZwDnI4aAEUG2m$ZhSJ537JmYJ5ISDxPQ6doWxPOrz9AMjyvxYxecViK23
$5$3bRXBWCpG9GEHdm$a2xIBbgK.fyr5k26BhUGo2QCvl25yQU1I9mwFp7mmh5p
$6$Hcdqud1hDgz$5MOEbgtOdxfF289OSXrmIevt7NnZBLaQkNGKeijR/X09ZDEbQ/ZfObJjNo0J64t4haSSqihRhfPe4z8l.ptro1
$6$hqaQ3RzX$bk8dgMsAlmDPpOX0IWWIrJ9T3awblvI.PCipeqJDdJZSVDQJgCRsQRX8pKpFU2XNcvRr56e3MARcTQR5oJ94V/
$2a$13$Hdz8T8vlEqwCvhixyu4rlel2cjj.TfA1qXEZ2dXhabogN35Idd8Je
$2a$15$hLPoYhbVJNA48A/Wmv1I5.5XBv/G/1s8BGfDLU7mt37ojGhNjETd2

btw, the original password is hello12345world12345, I'm not trying to (make you) crack someone's password ;-)

In theory, having several hashes may help; in practice, not so much.

The Theory

Let's consider SHA-256. From this function, we can define another hash function, which we will call SHB-256, such that SHB-256(m) = SHA-256(m) XOR m. In simple words, I compute the XOR of the SHA-256 and the first 256 bits of m.

This "SHB-256" is as good a cryptographic hash function as SHA-256: it is similarly resistant to collisions, preimages and second preimages. However, if I give you both SHA-256(m) and SHB-256(m), then a simple XOR of both value will yield the first 256 bits of m.

The Practice

Taking advantage of several hashes computed with the same password then relies on how "similar" the hash functions are, so as to allow "canceling" each other. This is a very ill-defined property, and (as yet) not thoroughly investigated. To my knowledge, no such shortcut is known with existing hash functions. There are a lot of details to mind; iterated functions and usage of salts make the matter even more complex.

What a realistic attacker can do when faced with multiple hashes is to use the one which will be easiest for him to attack, and ignore the others. If one of them is unsalted, then the attacker will target that one, which allows for simultaneous attack of several hashed passwords and usage of precomputed (rainbow) tables. Otherwise, he will use the function which will be most efficient when implemented on his hardware (e.g. if faced with PBKDF2 and Bcrypt, the attacker will target PBKDF2, which is easier to implement on a GPU). As @Polynomial puts it, your hashes will be as strong as the weakest of them.

An extra indirect effect is about your CPU budget. When doing registration, you will hash the user's password with all the hash functions. For the hash functions which are "configurably slow", like bcrypt or PBKDF2, this may incite you to configure them to be "a bit faster" than what you would have done if you had used only one, so as to keep your own costs within tolerable limits. This correspondingly lowers the attacker's efforts, since he has just to crack one hashes, not all of them.


How to check if a connection between a server and an app is encrypted? I have a Corona SDK sample project that contains only the following code:

-- The following sample code contacts Google's encrypted search over SSL
-- and prints the response (in this case, the HTML source of the home page)
-- to the Corona terminal.

local function networkListener( event )

    if ( event.isError ) then
        print( "Network error: ", event.response )
    else
        print ( "RESPONSE: " .. event.response )
    end
end

-- Access Google over SSL:
network.request( "https://encrypted.google.com", "GET", networkListener )

The code has been copied directly from Corona SDK's documentation.

Once the network request completes, the console will output the requested HTML source. However, my question is, how can I verify that the network request and all information that was exchanged was actually encrypted and not clearly legible as it is in the console output?

I am planning on creating an app that will communicate with a PHP file on my server over SSL and being able to verify that the traffic between the server and the Corona made app is actually encrypted is essential since I'd be sending over passwords and other confidential (but not personally identifiable) information.

Steffen Ullrich's answer correctly describes how you can check if a communication was encrypted or not.

However, you have another option to ensure that TLS communication is indeed encrypted. First of all, I am going to assume that you control the client, and that you will be acting in good faith (aka. not attempt to compromise yourself).

TLS works by having both the client announce the ciphers they support. The server then either responds with a cipher from that list, or in case the server supports none of them, an error message.

What this means is that you, as the client, can send a list of secure ciphers you would like to use, and expect the server to pick one of those it supports. Once the handshake has succeeded, your client will use that cipher for all following communication, and you can be certain that the encryption will happen exactly as specified. Otherwise, the server would not be able to communicate with the client.

Can TLS ever be not encrypted?

Glad that you asked! Yes, TLS does not require encryption! For instance, the ciphersuite TLS_RSA_WITH_NULL_SHA do not include any encryption at all. This means that the transported payload has no confidentiality whatsoever.

This was mainly used for when the payload was already encrypted, so encrypting it twice (once in the application layer, once on the transport layer), would not be a good idea. At least, that was the idea behind it.


If a web site shows me what my password was changed to, is it stored as plain text? I just changed the password on a school-related web site.  After completing the change successfully, the next page showed what the password was changed to.  Can I conclude from this that the password is not being stored only as a hash?

No, you cannot conclude that.

The password can be hashed on the server-side only, which implies that the password is sent in plain text to the server and stored in a variable. Then, nothing stops the Web application from displaying the sent password to the user, in the case where the very same script that has received the password is giving you the feedback about the password change.

On the other hand, if a whole other module gives you the password in plain text (perhaps a password recovery function), then you could conclude that it is not hashed.

Edit: To avoid any confusion, in this case "plain text" does not refer to SSL in any way, it simply suggests that the password is not sent pre-hashed to the server.


What parameters can be used to configure context-sensitive authorisation? I recognise that context-sensitive authorisation to applications is a good security control however I can currently only think of location being an example of a sensitive context.

I don't consider time being a sensitive context so are there any other examples?

Context-sensative in this case just means that the context is take into account. It has nothing to do with location being a "sensative" or "secret" attribute.

There's a lot of potential contexts which can be used to aid in authorization.

Location and time are by far the most common.

E.X.

Is the request coming from the corporate network?
Is the user VPNed in?
What is the GPS location of the user?
Is this normal business hours?
How many of these requests have been made in the last N hours?

Context authorization usually also includes roles, which can be implemented using RBAC.


Pre-shared key authentication between webservers for some security I have a front-end web server that's calling an API on another web server using GET requests (both hosted by me). It's not critical that outsiders cannot use the API, but I would like to make it slightly more difficult as currently anyone could with minimal effort spam the API with requests.

In Authentication between web services within the same project one of the answers mentioned using a pre-shared key to authenticate the connection between the servers. What are best practices for doing this? Are there any practical guide for how to do this?

I'm fine with being vulnerable to man-in-the-middle attacks etc. as the API does not contain any important information. It's more a matter of saving computing resources in case someone easily finds out how to spam the API.

Edit: Alternatively, would it make sense to use an encoded passphrase that's continuously changing based on the time of day? For instance, encoding using a function that takes as input the minute of the day. Some slack could be given such that the servers can have a mismatch in time of up to 10 minutes or so.

Edit2: Note that the servers run using Python based on variations of SimpleHTTPServer so they sadly don't have that much fancy functionality.

There are several ways to do this, depending upon how complex you want to get. For example, you could go all the way of implementing an OAuth2 service and having your servers authenticate with each other, but that would probably be overkill. Given the description you gave of your situation, something simple would probably work well, in my opinion.

Essentially, what you need is a way of modifying the request, so that each server can be reasonably certain that the connection coming in is from a trusted/authorized source: your other server(s). There are many ways to do this. One straight forward way would be to simply inspect all connections and only accept connections from a given list of IP addresses, but this doesn't provide any authentication guarantee (anyone on that IP is given access), and is also vulnerable to IP Spoofing, but depending upon how much you care about things like that, that might be enough for you.

One way of doing the shared key thing you asked about is just to have a big random string/number (essentially acts as a token/API Key), and add it to all requests as a header (or URL parameter), and the receiving server can just extract the header and do a basic check on the string to see if the string is an exact match. If the "password" header is exactly the same as the password on the receiving server, it assumes that the request is valid, and processes the request. If not, it simply aborts and drops the request. However, if someone intercepts the request and manages to find your password, they can submit their own requests by simply passing the same password. I don't think you mentioned what language/frameworks you are using, but if you're using Java & the Spring framework, you can create Interceptors & Security Filters which automatically catch all requests as they come into the server before they're processed, which allows you to handle things like this, so you don't have to do it over and over again in every controller mapping. Other frameworks have similar features, but I have most experience with Spring.

If you wanted to get a little more fancy, you could go with a JSON Web Token (JWT) using a shared key, and append it to each request in the header. Then, just like before, you can inspect the request headers to extract the Token, validate it, and then process the request. JWT's have the added benefit of built-in validation & tamper protection, as well as allowing custom data fields to the token, so you could start to add more information to the token, like timestamps, types of requests, levels of clearance, user ids, etc. and they would all be encapsulated in the token, and protected by it's validation & tamper protection. If you're using Java, there is a pre-built, very easy to use JWT library called JJWT (i.e. Java JWT). Here is a video on it:

Starts @31:36

https://www.youtube.com/watch?v=sv0TUiYVimw

Here's the maven Dependency:

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.7.0</version>
</dependency>

As for the rolling (i.e. constantly variable) password, you could do that pretty easily. Something as simple as Encrypting a timestamp with a shared key, and sending it in a header on the request (or adding it to the JWT). Then the receiving server would just decrypt the header and check the timestamp. If the timestamp is older than 1-5 seconds (depending upon the latency between the servers and variance in clock times) the receiving server just aborts & drops the request; you could respond with an HTTP status code of "Unauthorized". If the server tries to decrypt the timestamp but fails due to corrupt data (or someone trying to spoof the header) or if the header is empty, the server should also abort, and drop the request.

Not to sound like a broken record, but if you're looking for a simple encryption API, Spring also has an easy one in their Crypto package, but it defaults to AES-256, which requires the unlimited strength encryption Policy files installed on your JRE. They're free & easy to install (just download from oracle, and paste them into the right directory), but it's something to be aware of. Without the policy files, it will throw an error: "Invalid key length" or something like that. It just means that it's trying to use encryption that's too strong for what the JRE allows; it has to do with US export control laws. But the short of it is that any American Citizen can download them for free.

What you're trying to do basically sounds like a small scale micro-service. You might be interested in these talks:

https://www.youtube.com/watch?v=ZyK5QrKCbwM

https://www.youtube.com/watch?v=rqQOSG0DWPY

https://www.youtube.com/watch?v=sbPSjI4tt10

https://www.youtube.com/watch?v=saiwZzE5IYg

Hope this helps.

-Yurelle

Edit: Also, you mentioned that one of your main concerns was the performance issues with people spamming your API. You're essentially referring to a small-scale Denial of Service attack. From your minimal concern with security, I get the impression that the project you're working on is somewhat small scale and you're not expecting to be the target of any serious attacks; and that it's more of a Better-Safe-Than-Sorry precaution, which is always good, I'm certainly not faulting you. However, if you ever do expand into the territory of being in serious danger of such attacks, there is one type of attack that many people often forget about; It's called a "Slow Loris Attack". It's very simple to pull off, and it's extremely effective given the resources necessary to run such an attack, and, to my knowledge, the only reliable defense is a non-blocking web server framework (often called "reactive" or "event-based"/"event-driven" frameworks). Again, probably not something you need to worry about, but since you brought it up, I thought I'd mention it.

Here's a video on it, if you're interested:

https://www.youtube.com/watch?v=XiFkyR35v2Y


CSRF protection with custom headers (and without validating token) For a REST-api it seems that it is sufficient to check the presence of a custom header to protect against CSRF attacks, e.g. client sends

"X-Requested-By: whatever"

and the server checks the presence of "X-Requested-By" and drops the request if the header isn't found. The value of the header is irrelevant. This is how Jersey 1.9's CsrfProtectionFilter works and it is described in this blog post: http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/. The blog post also links to NSA and Stanford papers stating that the custom header itself is sufficient protection:

  The first method involves setting custom headers for each REST request
  such as  X-XSRF-Header. The value of this header does not matter;
  simply the presence  should prevent CSRF attacks. If a request comes
  into a REST endpoint without the  custom header then the request
  should be dropped.

  HTTP requests from a web browser performed via form, image, iframe,
  etc are  unable to set custom HTTP headers. The only way to create a
  HTTP request from a  browser with a custom HTTP header is to use a
  technology such as Javascript  XMLHttpRequest or Flash. These
  technologies can set custom HTTP headers, but  have security policies
  built in to prevent web sites from sending requests to each other
  unless specifically allowed by policy. This means that a website
  www.bad.com cannot send a request to http://bank.example.com with the
  custom header X-XSRFHeader unless they use a technology such as a
  XMLHttpRequest. That technology  would prevent such a request from
  being made unless the bank.example.com domain  specifically allowed
  it. This then results in a REST endpoint that can only be called  via
  XMLHttpRequest (or similar technology).

  It is important to note that this method also prevents any direct
  access from a web  browser to that REST endpoint. Web applications
  using this approach will need to  interface with their REST endpoints
  via XMLHttpRequest or similar technology.

Source: Guidelines for implementing REST

It seems however, that most other approaches suggest that you should generate a token and also validate this on the server. Is this over-engineering? When would a "presence of" approach be secure, and when is also token validation required?

Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future attack vectors. Using a per-request token also helps limit the damage done by an XSS vulnerability, since the attacker needs a way to steal a new token for every request they make.

This is the same reasoning used in modern cryptographic algorithms, where n rounds are considered a minimum for safety, but 2n+1 rounds (for example) are chosen in the official implementation to ensure a decent security margin.

Further reading:

CSRF with JSON POST
Why refresh CSRF token per form request?


Can Tor browser bundle be attacked like this? When using the Tor browser bundle, you load the check.torproject.org on start. It tells you when there is a security update to downloads, and let's you click a link to get it.

The way for users to know it's a legit site is to 'check for the hang lock'. It's there and green, and the certificate info is correct, so the user clicks the link and downloads the browser bundle.

If and NSA runs an exit node, they can by the power of law (may be secret or not yet exist) create fake certificates and bypass browser security. Can they then redirect the data from their own server instead of the one run by the tor project? If so, why can't they secretly serve a Tor browser bundle binary with malicious code and a key logger?

The Tor Browser Bundle doesn't pin* the check.torproject.org certificate. So, yes, this is very possible.

But, Martin Martin Martin, the NSA doesn't really need to do that. You already download get your TrueCrypt download link from the official TrueCrypt site via HTTP, same goes for KeePass and tens of other security tools. Actually, they don't even need to do that. They can just intercept your connection when you do your Microsoft updates, or when you run sudo apt-get upgrade, or.. or.. or.

This is how it is. You have to accept it and live with it. Unless you create your own MartinOS and run your own MartinNet, then there's pretty much nothing you can do about it. If they want you, they can have you. Period.

* What is certificiate pinning?


Is it secure to transfer an RSA public key by email? I've set up my VPS'ssh server to accept only key-based identification: I disabled password-based connection.

As a consequence I am connecting from home with an RSA key generated prior to password disabling on my VPS. Of course I've copied the public key into the ~/.ssh/authorized file before that.

Now I want to do the same thing from work, generating a new key pair (I've read it is clearly better to generate a new key pair, one for each source of connection). I guess the best thing to do is to generate the key from my workplace. But then I am facing the issue of transferring the public key from my workplace to the VPS.

Since I disabled the password-based connection, I won't be able to transfer it directly from work.

I could re-enable password authentication just before returning to my workplace. And disable it from my workplace once I am able to connect into my VPS.

But then I would like to know: is it secure to send the public key by email to myself?

The public key is public, meaning that everybody can know it without endangering security. No problem in putting it in an email, then.

The potential issue would be an active attacker modifying the email while in transit, to replace your public key with his public key. To guard yourself against such attacks, compute a fingerprint of the file you are about to send by email (use the ubiquitous md5sum utility on it), and write the hash value on a piece of paper (which you keep in your wallet). When you are back at home, recompute the hash over the received file, and compare it with the value on the paper. If they match, then everything is fine.


Share Document within user group I would like to share documents within groups and make sure that the member of each group can only access the documents shared in his/her group.

Situation:

There are 5 participants (A, B, C, D). There are two groups (blue: A, B, D, red: D, C). A and B can only see blue documents (like Document_1) and C can only see red documents (like Document_2). D can see documents shared in both groups.

Approach:
The following approach is close to the approach in Tom Leeks answer and is close to OpenPGP. This approach is taken, because it scales to groups with many users.

Example for blue group:

A generates a key pair. Public key: pk_a. Private/secret key: sk_a
B generates key pair pk_b, sk_b
C generates key pair pk_c, sk_c
pk_a, pk_b, pk_c are posted to a key server, visible to the public
A (or any member of the blue group) generates a synchronous key s1
A calculates pk_b(s1) (s1 encrypted with pk_b) and pk_c(s1).
A posts pk_b(s1) and pk_c(s1) to the server
B and C can now take those values and decrypt them using theis sk
A, B, C now know S1 and can share data within the blue group
If they are posting data in the blue group, they can use their sk to indicate to the others that it was really send by them
we do the same for the red group with the synchronous key S2

This approach was simplified. In reality we would also make sure that each of the users indeed received the correct synchronous key (consider that A could be compromised and try to exclude B from the blue group)

Problem:
D has the S1 and S2. D can communicate both in the red and the blue group. How can we make sure that D is not giving S1 to C?

You can't.

Any time you give D access to a document you're trusting D not to copy/share that document. Giving D access to S1 requires that same trust.


How to verify PGP signature with signing key I have to download a program with a PGP signature and a signing key (Public Key)

How do I check the program with signing key?

Assuming you have GPG installed:

gpg --import signing_key.pub
gpg --verify signed_file.sig

Where signing_key.pub is the public key, and signed_file.sig is the detached signature for the file (in the same directory as the signed file).


Does setting a default DROP policy actually improve security? It seems that the status quo at the moment is to configure firewalls to drop any packets that aren't destined for specifically-opened ports. Many defensive port scanners (such as ShieldsUP!) seem to praise you for every port that has a DROP policy. If you were to port-scan any of the top domains in the world, almost all of them would show that their default policy is DROP except on needed ports such as 80 and 443.

What is the mentality behind this? It can't be for stealth, because if ports 80 and 443 respond then it would be extremely trivial to see that the host is up. It can't be for defense against SYN floods either, since you could just direct the packets to the ports that ARE open. The only thing that I can think of is that there are other services running on the outward-facing interface, but instead of taking the time to properly configure these services, admins just throw a firewall in front of it. Still, one would think that the top websites in the world would have their act together enough to properly configure their servers.

Am I missing something here? Does setting a default DROP policy really do anything to improve security on a properly configured server?

Edit:

I just want to clarify my question a bit. What I don't understand is why people feel a need to put a layer up that drops packets instead of letting them through and letting the networking stack do its job. (Putting up a layer that responds artificially with RSTs would be essentially the same thing and it raises the same questions.)

I'm not trying to imply that a firewall is useless, but it seems as though people don't trust the networking stack to the point that they forbid direct contact with it except on allowed ports. What is the real harm in exposing it and interfering with it as little as possible?

Employing a default DROP rule for all ports except the ones originally intended(for a website these are 80/443) reduces the attack surface of the given stations on the network. It's much more convenient(and cheaper) to drop packets instead of configuring a service so that it is secure with regards to a given policy.


How to tie encryption key to login if there are multiple users Scenario:

User A, B, C need to access an encrypted data from a web application. They all access the same data.

The encryption key must be tied to their login so that it's not stored in the server.

Question: Is it possible to tie the key to their login details even if they all have different username/passwords? What's the best approach in this scenario?

In general, solutions that do this work something like the following. You should find a trusted system that already does this and use it, rather than trying to build one yourself.

First, generate a symmetric key. This is the Master Key and no user will ever see it directly. Do not store this key (in plain text) anywhere an attacker could potentially reach it.
Use the Master Key to encrypt the data, and ideally also HMAC it for integrity (or use some other way of ensuring integrity, such as using AES in GCM mode).
Run the user's password through a Key Derivation Function (like PBKDF2 or scrypt) using different parameters (such as a different salt) than is used for the password verifier. Do not store these Password-Derived Keys anywhere at all.
Encrypt the Master Key once with each user's Password-Derived Key. Store these encrypted copies of the Master Key with each relevant user's account data.

To access the data:

Authenticate the user. (This typically means retrieving the password verifier parameters for their account, running their password through the key derivation function that uses those parameters to produce a password verifier, and then checking whether that password verifier matches the one stored for that user.)
Get the Password-Derived Key for the user. (Retrieve the second set of KDF parameters, and pass the password into your KDF using those parameters; we already know the password is correct so you can expect that the re-derived key is correct without checking it against anything.)
Using the Password-Derived Key, decrypt the Master Key. Purge the Password-Derived Key from memory as soon as possible after doing this.
Using the decrypted Master Key, verify the data's HMAC (or otherwise ensure its integrity) and then decrypt the data.
Either purge the decrypted Master Key from memory and then access the data (in which case you'll need to repeat steps 2-4 if you want to modify the data and save the changes), or hold onto the decrypted Master Key in as secure of memory as you can arrange.
Purge the decrypted Master Key, and the decrypted data, from memory as soon as possible.

To change a user's password:

If the user has their old password (password rotation), verify the old password and then use it to generate the user's current Password-Derived Key and with that, decrypt the Master Key. Using the new password, generate the user's new Password-Derived Key and re-encrypt the Master Key with it. Replace the old encrypted Master Key with the new one (in the user's account info).
If the user has forgotten their old password, have an administrator verify the user's identity through some other means, and have the user select a new password. Then have the administrator get the decrypted Master Key by entering their own password, deriving their own Password-Derived Key, and using it on their own copy of the encrypted Master Key. Using the user's new password, generate the user's new Password-Derived Key and use it to encrypt the Master Key. Place the encrypted-with-the-new-key Master Key in the user's account information, replacing the one that was encrypted using the key derived from the old (forgotten) password.

To manage users:

For new users, basically just follow the "forgotten password" flow above.
To delete a user, or even just revoke their access to the data, delete the copy of the Master Key encrypted using that user's Password-Derived Key. This makes it impossible for the user to use their own password to get the Master Key by any means.

Despite the detail (which is only present to help you understand the system), PLEASE do not attempt to implement this yourself. There are numerous additional critical details that are either missing or mentioned only in passing. For example, it is vital that the user never directly see the Master Key (otherwise they can store a copy of it, removing your ability to effectively revoke their access without regenerating the entire key structure and re-encrypting the data). Many of these details (such as secure key storage in memory) will be platform-dependent.

Additionally, there are many ways to screw up the crypto itself, even if using library implementations of the cryptographic primitives; if you generate your keys or key derivation parameters incorrectly, and choose the wrong primitives, or implement any of the steps in a way vulnerable to side-channel attacks, your whole scheme could be compromised. Don't try to figure this stuff out on your own; go with something that somebody knowledgeable about crypto implementation has already put together, and that somebody else knowledgeable has reviewed.


Is there any way to safely examine the contents of an SD card? I saw this question about reading a USB stick safely, and it made me wonder about SD and microSD cards. I've been told that SD/microSD cards are safer, and that I needn't worry as much about just plugging one in as I would a USB stick. Is this true? What sorts of vulnerabilities do SD/microSD cards have the USB sticks don't, and vice versa? Also, given a particular SD/microSD card, will formatting it make it safe to use again?

Define "safely".

The core SD data protocol can only expose itself as a mass storage device, which prevents a lot of the fun badUSB style attacks. If your host supports SDIO, the attack surface grows massively.

The card also contains a full MCU, typically ARM/8051, which can (at minimum) lie to you about the contents of flash a la IRATEMONK. See https://www.bunniestudios.com/blog/?p=3554. Formatting the card is thus NOT sufficient to "clean" it. Given the price of SD cards, if you're at all concerned about its provenance it's better to just chuck it and buy a new one from a trusted source.

TL;DR probability of RCE is lower than with USB, but there are definitely still nasty things possible.


MAC Timing Attack Xbox 360 I was reading my textbook, Katz and Lindell's Intro to Modern Cryptography in the section about Message Authentication Codes.  They were talking about timing attacks in general and brought up an example (page 116):

  One might wonder whether this attack is realistic, as it requires access to a verification oracle as well as the ability to measure the difference in time taken to compare i vs. i + 1 bytes. In fact, exactly such attacks have been carried out against real systems! As just one example, MACs were used to verify code updates in the Xbox 360, and the implementation of MAC verification used there had a difference of 2.2 milliseconds between rejection times. Attackers were able to exploit this and load pirated games onto the hardware.

That struck me as really interesting, and I wanted to learn more, but I couldn't find any citation in the references, nor did I find anything online.  Is there any more detail about how this attack worked?

I knew nothing of this before reading your question, and decided to go and try to find an answer myself. Thanks!

It seems the particular attack you're probably referring to is one piece in an exploit chain that is used to install custom software onto an Xbox 360.

A full description of the attack is available here.

Essentially, an older version of the Xbox kernel had a flaw where memcmp was used to check the HMAC value. Downgrading to the older kernel version allowed an attacker to provide bogus hashes and measure the difference between a valid byte and invalid one - the attack described in the book.

Thanks for the interesting question; reading about the attack was very interesting, and I have a new book on my wishlist.


Why we use GPG signatures for file verification instead of hash values? for example here they put a gpg signature to verify what you download is what they really made. but why they just don't put a SHA256 hash value ? because its much more faster to check it and sometimes gpg may not be installed on our machine but SHA is something everywhere available also you even can upload the file on virustotal.com and it give you the hash !

if hash is secure why they use gpg if is not secure why we use hash values for everything ?

When you check the hash value, you have to check it against a reference hash value: this does not solve the problem, just moves it around. You still have to make sure that you got the correct hash value. If the hash value is obtained through the same channel as the software package (i.e. you both got them from a HTTPS Web page), then you have gained nothing against attackers: if the attacker could alter the package, then he could also recompute the hash and alter the hash value you obtain so that you would not see any problem. Typically, someone who hijacks the download server itself.

Hash values "alone" are good at detecting random transmission errors (e.g. a router with bad RAM), not intentional alterations.

Digital signatures offer an enhanced service: they link the package to the individual who produced it, regardless of intermediate servers. With a GPG signature, you can download the package from a shady mirror site and still do not have to fear the package being bugged.

As for performance, know that signature verification will have the same cost as computing a hash, plus an extra mathematical operation which even an asthmatic PC should be able to do within a few milliseconds. I seriously doubt you could actually observe that extra cost.


Adding network drive to trusted intranet sites security hole? We have a shared network drive that is mapped, and when we open certain files we get a dialog like

I found this site which explains that adding the network path to Local Intranet trusted sites for all users allows opening of such files without the Warning.

A colleague is concerned that this opens us up to security risks, but currently, a user would just click run or open in the dialog box and the files in question would run or open.

What security risks does putting the drive into the local intranet sites open us up to if any? Is it safe to do this or a bad idea?

Edit: I found some superuser questions with answers saying to do this but no discussion of risks

This error dialog is there to make users aware of the potentially dangerous source from where the file comes.

When you say

  [B]ut currently, a user would just click run or open in the dialog box and the files in question would run or open.

this defies the reason for that warning to appear, so adding this as a trusted source is not decreasing security if what you say is true for all users.

Nonetheless, there are some assumptions that come with your setup:

all people with access are trustworthy and
the fileserver is sufficiently secured

If a rogue employee drops malicious code, no one gets a warning beforehand, so users might be inclined to execute macros, for example.

If an external attacker gains access to this file server (for example pivoting from an compromised endpoint), this would defy network segregation if the fileserver serves multiple segments (for example because it is the share for exchange between divisions).

Additionally, there might be implications for the endpoint security solution you are using - a trusted source might not be scanned. This depends on the actual product and settings, though.

You might also want to consider not having the share active all the time to contain ransomware damages to the local, infected, endpoint - even with a good backup strategy, there is cost to restoring from a backup.


Security Risk of Open RDP (3389) I have often been told that allowing RDP access over the internet is a security risk - my understanding is that this logic stems from the idea that a potential hacker would brute-force the username and password in order to gain access. For instance, see this article.

Recently I had a call with Microsoft and they told me that this is not actually a security risk because the RDP protocol has a built-in protection against brute force and will automatically disable itself if too many attempts are made to access it (although I have not been able to independently verify that this is actually the case). Regardless, we can assume that any server who can be accessed via RDP over the internet has an account lockout policy (which will lock-out an account after 20 failed attempts).

Assuming that all users have a extremely strong, randomly generated passwords, where is the vulnerability of accessing a server using RDP over the internet? And how is this less secure than having a VPN which authenticates via a RADIUS server using Active Directory (aka the same user-store as we are using to RDP into a specific server).

p.s. Some people have suggested that changing the RDP port may increase security - but would this even be necessary given the above? If there is a security risk, couldn't a potential hacker user a port scanner to determine which port IS being used for RDP?

It all depends on your risk scenario and what you want to protect against.

RDP has had some security issues, and leaving this exposed is just expanding your threat surface. But that might not be a problem for you.

The other problem is about those pesky AD account passwords. You are correct about every point you made. There are default account lockouts and you can have a password policy that enforces strong passwords, and these things enforce a strong security posture.

But passwords are used by people. By using RDP and the same credentials externally as internally, once you get one credential, you get access to both areas (external access and internal access). By splitting up the credentials and/or the technology to enter them, you provide defence-in-depth.

This way, if someone is phished for their credentials, for example, the attackers do not get automatic external access: they have another barrier to breach and do not have an all-access pass.

So, yes, from a general best-practice perspective, putting an additional authentication layer on top of your RDP access makes sense.


Does embedding (concatenating) a user ID in a session token for logging have any security implications? Assuming there's a user with ID 123456 logging into a web application where the randomly generated session identifier to be stored in the cookie looks like this 123456zXRL9DWpPtaAhkPzhemQZE5P5F (that is, prefixed with the user ID ******zXRL9DWpPtaAhkPzhemQZE5P5F), what are the potential security implications?

This would be to generate user identifiable access logs throughout various hops in a system, web servers, proxies etc. without the need to come up with schemes to pass around the user IDs.

Thanks

It can have potentially serious implications. If the user authentication process use that User ID, an attacker can do a DOS attack sending wrong authentications data and locking User ID account.

If the User ID is not directly consistent to user personal informations (e.g. anonymization)  it is not considered personal data.


Firewall Migration: NetScreen NS500 to FortiGate I have recently been tasked with doing a firewall migration from an old NetScreen NS500 box to a FortiGate device (I believe it will be a 60C). I am sure most of you aware that NetScreen boxes are no longer sold since Juniper took over, so finding documentation has been a little difficult for me. Basically, I am wondering if anyone has any advice or possibly tools to help with this migration process. Doing this manually is proving to be a nightmare!

Note that I have tried https://convert.fortinet.com however it does not support this old NetScreen config, but it does support the newer Juniper configs. If there was someway of going NetScreen -> Juniper that would allow me to use the FortiConverter, but that also means another step which inherently means that I will incur more variation/errors in the migration process.

Let me know what you guys think, really any advice at all would be good at this point.

If I were you, I'd try posting in the Juniper forums and the Fortinet forums.

When you running old, unsupported versions, the vendor usually doesn't want to know, especially when you're moving from them. However, if you have a support contract with Fortinet (sorry I'm not familiar with them much), I'd have thought that your Account Manager would've been helpful?

Regarding general firewall migrations, 9 times out of 10, I found manual to be better, although more tedious. When the upgrade was version upgrade within the same product line, it was much easier and straight-forward with the latest version/package from the vendor. Otherwise it was more painful and required copying each rule over (taking notes for the 5-tuple and any other information).

Good luck!


Can iptables be hacked / circumvented We currently have a server that blocks all connections using iptables, and we have to whitelist an IP expressly in order to be able to access the server remotely.

Essentially, the first rule allows the whitelisted IPs (including localhost interface) to progress further to the other chains on the firewall, while rejecting any IP that is not on the list.

Is it possible for an attacker to somehow circumvent the iptables rules to gain access to the server?

Sample rules follow below:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
1507K  136M ALLOW      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain ALLOW (1 references)
 pkts bytes target     prot opt in     out     source               destination
 183K   36M next_chain  all  --  *      *       198.###.##.###       0.0.0.0/0
3053K  237M ACCEPT      all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 116K 5859K REJECT      all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Your INPUT chain is largely useless as it forwards all packets from all interfaces to the ALLOW chain anyway - you could've just implemented the ALLOW chain rules in the INPUT chain.

With the rules you have there, UDP and ICMP traffic can be sent to the server by spoofing the source IP address. Response packets would not be received by the attacker, but this may not be necessary for certain attack types.

TCP packets (e.g. SYN) can also reach the server in the same way, but a connection cannot be created as the attacker could not construct a full TCP handshake.

Of course, the attacker would need to know which source IPs are accepted in order to spoof it.

Other than that the rules look alright.


What tricks can be used to prevent debugging? What tricks can be used to prevent or hinder debugging?

Examples:

IsDebuggerPresent API on Windows
Exception handlers used for program flow.
GetTickCount / rdtsc checks.

Are there any good resources on this kind of thing?

You could begin looking at Symantec: http://www.symantec.com/connect/articles/windows-anti-debug-reference

And there is a question in Stackoverflow about anti-debugging tricks.


Secure Communication between Swarm Worker Nodes I have a Swarm Cluster and want to communicate securely between Windows Worker Nodes. The official Docker Documentation (https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/) states:

  The nodes in a swarm use mutual Transport Layer Security (TLS) to authenticate, authorize, and encrypt the communications with other nodes in the swarm.

Looking at the image further down the documentation page, I suspect that actually only management plane communication

between Manager Nodes themselves and
between Manager Nodes and Worker Nodes

is secured. This would mean that I have to secure my communication by other means. Other sources (https://medium.com/lucjuggery/create-a-swarm-cluster-with-docker-1-12-swarm-mode-541449114c27, https://www.dasher.com/containers-os-virtualization-to-workload-virtualization/, https://collabnix.com/docker-1-12-swarm-mode-under-the-hood/, https://upcloud.com/community/tutorials/docker-swarm-orchestration/) say that communication between Worker Nodes is mutual TLS secured by default too. However, I can't see where these sources base this information on. To me it appears unfounded.

This leads me to the following questions: Is mutual TLS between nodes

limited to management plane communication or
is all communication between Worker Nodes secured too?

If 1., are there other means to easily secure my communication except building mutual TLS into my containers by myself?

You are correct that it is only the management traffic that is encrypted by default.

There is an option with the overlay networks to enable IPSEC for application traffic, but it is not supported by windows nodes.

https://docs.docker.com/network/overlay/


Does setting up a DMZ for a home consumer "cloud" appliance make sense? Some of you may have seen/hard of Western Digital's MyCloud NAS solution for home networks.  This comes with a proprietary app suite for mobile devices and workstations alike. This allows the consumer a "dropbox"-like experience with a storage medium they themselves privately own and operate.

I've been toying with this idea, simply to get around the storage limitations hosted solutions impose at which point you'd start paying subscription fees.  Not to mention the ability to take responsibility for my own security and off the hands of a third party.

But given that this device is intended to be accessed from the Internet, would it make sense to design and implement a DMZ-based home network for additional protection?

How would you securely store/access your data in this way?

Of course, assume the drive is encrypted, or at least, storing Truecrypt-protected volumes.

Thanks.

While this makes some sense, I wouldn't do it myself.

I presume you already have an internal home network with your laptops, desktops, tablets, internal NAS, etc. The normal way to setup at DMZ is that it's a separate network, with firewall rules that allow specific ports. So, if the MyCloud NAS uses port 443, you'd probably allow port 443 from the internet to the NAS, and also port 443 from the internal network to the NAS.

The benefit of this is that if the NAS is hacked then the hacker doesn't get access to your internal network. It doesn't help protect data on your NAS: if the NAS is hacked then the attacker will be able to get all the data; using a DMZ does not help you.

Three questions to ask yourself to help make a decision:

Is protecting your internal network an important benefit? On my home network I don't greatly mind untrusted devices being on the network. The laptops have a personal firewall - it's needed when I connect the laptops to untrusted hotspots. And the NAS and router are password protected. So, simply being on my internal network does not gain a hacker much. I prefer things this way, as visitors often ask for the WiFi password.

How likely is the NAS to be hacked? Many of these kinds of devices have had vulnerabilities, but if you apply security updates as they are released, and use strong passwords, then your risk is limited. If you have Windows laptops that you connect to the Internet, they are at higher risk.

How much will it cost to implement a DMZ? Most home routers do not have DMZ capability. If yours does and the port is currently unused, then it's cheap for you to implement the DMZ. But if you need to buy a new router, maybe it's not worth it.


using "mount -o bind" in chroot I have to provide a few, reasonably complete, chrooted ssh accesses to a very small system where disk space is at a premium.

I was considering doing something along the lines:

mkdir -p newroot/usr newroot/home/user newroot/lib newroot/bin newroot/var
mount -o bind,ro /bin newroot/bin
mount -o bind,ro /lib newroot/lib
mount -o bind,ro /usr newroot/usr

instead of the more traditional copy.

Is that an acceptable practice or am I opening exploitation avenues?

The main things to be mindful of:
 - If you mount full directories, you effectively give chrooted user access to all those resources (most notably binaries). It would be more secure to only put required binaries into chroot (i.e. in one case I had to provide access to ls and scp only, but nothing else). This will potentially limit attack surface, as there would be fewer executables to exploit.
 - On the other hand, mounting those directories allows to keep chrooted resources up to date, potentially limiting explotable vulnerabilities. But this can be achieved by updating chrooted resources manually or via scheduled script.

Overall, keeping chrooted environment fully separate is considered more secure. But it all ultimately depends on your level of paranoia, criticality of this system and other security controls you might have in place.


Do CSPRNGs have a maximum input seed length to output length ratio? Using what may be considered today's "best" or "most secure" CSPRNGs, how much maximum data N can you read from a CSPRNG given seed input of length n before the output starts becoming predictable (without reseeding)? Can one read from it indefinitely and still get unpredictable output?
More concretely: can I generate 20kb of data from a hardware random number device, feed that to a stateful CSPRNG, get rid of the hardware random number generator, and indefinitely use the data from the CSPRNG for cryptographic purposes?

Note: I realize "length" may be problematic, so this question may be answered in terms of entropy quality.

This is exactly what /dev/urandom does, actually.

A PRNG with a seed of length N bits will have a period (repetition length) of 2^N bits, due to the pigeonhole principle. So as long as your CSPRNG is perfectly secure and has a seed length of, say, 256 bits, you don't have to worry about ever repeating before the heat death of the universe. (Note that seeds are of fixed lengths.)

The reason this is considered dangerous is because if for any reason your PRNG leaks state, say because an attacker uses a kernel info-disclosure bug, all the "random" data is compromised until the next reseed. OTOH, fetching "real" randomness when you need it provides perfect forward security.


IT Security Learning Path Possible Duplicate:
  What are the career paths in the computer security field?

I am a software developer. Currently I am interested in IT security, but I have difficulties about learning pathways to IT security.

Is there a learning path for IT security such as for example the path to learn the Java programming language that existed at this link:

http://download.oracle.com/javase/tutorial/tutorialLearningPaths.html

Thank you: D

A lot of the security field is devoted to cryptography which is a beautiful field (of which I am far too ignorant) but crypto is often much easier to misuse than to use correctly.  Unless you've got a really strong math/stats background, I'd put off diving into crypto until you've got into the attacker mindset a bit.

If you're already comfortable as a coder, then you can probably learn a lot by reviewing code, including exploits, vulnerable code, and code designed for security.

"OWASP Code Review" might help you learn by example.  It'll introduce you to a bunch of practical attacks, and get you thinking like an attacker.

  The combination of a book on secure code review and tools to support such an activity is very powerful as it gives the developer community a place to start regarding secure application development.

The same OWASP organization has How-to pages that might be good starting points as well.

Other accessible resources include Scheier's blog which often discusses topics related to threat perception, the way social dynamics affect security, and what security means/should mean in various scenarios.


Can Silicon Secured Memory prevent buffer overruns? Oracle have recently announced the new SPARC M7 chip. It has an interesting feature called Silicon Secured Memory which claims to prevent memory corruption bugs like Heartbleed and Venom.

The idea is to add a "colour" to each pointer and 64-byte chunk of memory. On each memory access the colour is checked, and if they don't match, the program is aborted. There is a picture and some more detailed information online.

The idea sounds promising. However, earlier attempts to solve buffer overruns (e.g. DEP) turned out to be less effective than hoped. Can SSM reliably prevent buffer overruns? What are potential attacks against the feature?

Can SSM reliably prevent buffer overruns?

It does not claim to offer 100% prevention but it definitely offers more granular protection compared to previous hardware based solution (which had usually page granularity) and much better performance than software based protections with a similar granularity. There are some limitations like

Your code has to actually make use of it. This can be as simple as using the provided malloc, but custom memory allocations like done in OpenSSL need to be changed. And I don't know if the compiler will add such protection to the stack too or if this is only possible for data allocated on the heap.
The memory must be aligned to 64 byte. Thus it will not detect when you overflow an allocation of 32 byte only.
There are only 16 colors (4 bit) available for each 64 byte region. Thus the chance that some random pointer has the same color as the protected memory region is still 6%.

Thus it is not perfect but the chance to catch problems early and thus prevent attacks are much higher than with existing solutions, at least with solutions in the same performance class.

  earlier attempts to solve buffer overruns (e.g. DEP)

In my opinion DEP does not protect against buffer overruns at all but only makes sure that one can't simply execute code which was written to the stack or heap. Thus it only deals with some of the possible ways to make use of a successful buffer overflow, whereas SSM can help to prevent the overflow itself.


What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains? I get that I don't want a page loaded from stackoverflow.com to be able to request gmail.com on my behalf and read my email--but this seems to be simply a cookie issue.

Since JSONP bypasses same-origin entirely, I want to know why, instead of making XMLHTTPRequest conform to same-origin, the browser doesn't just apply same-origin to cookies. In other words, if the page was loaded from stackoverflow.com, the browser will only send cookies to XHRs to stackoverflow.com. An XHR to Facebook would be prevented from sending the user's cookies and yield the logged-out view of Facebook.

At first I was thinking it's just an "extra layer" of security, "just in case" somebody has compromised one site already by putting in a script that ajaxes your password/bank account number out to "malicioushacker.ru". However since you could use JSONP in that case, or even just make an <img src="http://malicious.example/steal?creditcard=1234123412341234"> tag, this isn't what's being prevented.

Your premise is wrong.  Script tags and JSON don't bypass the same-origin policy.

The same-origin policy says that evil.com should not be able to read the responses for arbitrary resources on victim.com.  Note that Javascript from evil.com can trigger nearly arbitrary requests to be sent to victim.com (e.g., by creating an IFRAME pointing to http://victim.com/whatever.html).  However, the Javascript from evil.com cannot read the contents of that document: i.e., it cannot read the response to that request.

Now perhaps what you are thinking of is that evil.com can ask the browser to load arbitrary code from anywhere on victim.com and then execute it with all of evil.com's permissions.  That's not a bypass of the same-origin policy.  (Note also that it tends to be a security risk, for the party who is loading Javascript from third-party sites.)

XHRs have to be restricted, because XHR allows Javascript to not only trigger a request to be sent, but also allows Javascript to read the response.  The same-origin policy forbids that, for cross-origin requests.  The same-origin policy says that reading the response is something that should only be allowed if the request is to the same origin as the origin of the Javascript code.  Thus, Javascript from evil.com is allowed to issue a XHR to http://evil.com/doit and read the response, but it is not allowed to issue a XHR to http://victim.com/doit and read the response.

If you want to issue cross-origin XHRs, then the target domain will need to authorize you to send it cross-origin XHRs.  Look into CORS for ways to do that.


Google Password Manager or Dedicated Password Manager Is it better to use Google Password Manager to store all my passwords or a dedicated Password Manager such as Bitwarden? I have been using the former for years and am wondering if I should make the switch now that it is 2019.

There is no right or wrong answer to this as "better" is a subjective term.
Things you should consider though:

Google Password Manager is not open source: This means it can not be audited by anyone outside of Google (are they stealing your passwords?... probably not, but who knows).
Bitwarden is open source: This means that members of the security community can audit it (does this ensure there is no vulnerabilities? no, but you can find them if you like).


Sensitive issue regarding windows 8 password Although I know this sort of request probably isn't exactly what stackoverflow is for, I am desperately seeking help. One of my best friends recently passed away and his parents asked me if I knew a way to acces his laptop. The contents of his laptop (foto's etc) would be a slight comfort in their grief.

The laptop has a Windows 8 operating system and his account is linked to his @live account. I already checked with Microsoft, but their policy states that they are not allowed to arrange some sort of password reset for the next of kin.

I already did some prior research and came across some sort of portable usb linux client that had a program that tried a brute force attack. This however was unsuccesful.

I sincerely hope one of you is able to provide me with some information on how to proceed with this problem.

Sincerely,

Cees

Looks like the photos are stored in hard disk. If you can find a way to remove the hard disk and connect it via USB, then possibly you can find the files you are looking for.


In what case should one encrypt cookies? I am curious how one decides whether to encrypt cookies or not? And if so when should one use public private key over symmetric encryption?

If they contain sensitive information and you have no other solution than sending it in a cookie (you very likely don't). The pub/priv key model would not work easily within a browser, and would most likely not accomplish what you're trying to do.

Really you should not include any sensitive information in a cookie, and ones that do contain state data which you do not want modified should be signed using something like HMAC using a secret known only to the server.


Why are SSL certificates valid only from a certain date? Each SSL certificate is valid starting from a specific date and up to the expiration date.

What's the point in that "valid from" date? Why do we want a certificate to only be valid after a specific date?

Historically, certificates have a start-of-validity date mostly for symmetry: they have an end-of-validity, so the original designers found it appropriate, for unspecified reasons, to include a start-of-validity date as well.

Nowadays, such dates have found a usage, which is past validation. That's what you do when you verify a signature several months/years after the deed. This is a complicated game with time stamps and projecting yourself in the past. The start-of-validity date then plays an important role (although hard to explain in a few paragraphs).

Of course, past validation is not at all the same context as a SSL connection, but they use the same format for certificates (X.509), and the start-of-validity field must be set. Usual CA set the start-of-validity at a few minutes or hours before the issuance date.


How to generate cryptographically strong pseudorandom data very rapidly? What's the best way to go about generating a fast stream of cryptographically strong pseudorandom data without installing uncommon packages?  Drawing from /dev/urandom is far too slow.

I had an idea from reading the 'wipe' manpage:

  will use the fresh RC6 algorythm as a PRNG; RC6 is keyed with the 128-bit seed, and then a null block is repeatedly encrypted to get the pseudo-random stream.

Encrypting a null block with only a single key is probably not the best idea, especially when large amounts of pseudorandom data are required, so I quickly made this in bash:

while dd if=/dev/zero bs=$(shuf -n 1 -i 1024-67108864) count=1 2>/dev/null | openssl aes-256-cbc -nosalt -k "$(head -c 32 < /dev/random)"; do :; done > [whateverneedsrandomness]

This encrypts a stream of zeros with a random 32 byte seed.  The stream is reseeded on average every 32 MB (the range is between 1 KB and 64 MB with a resolution of one byte).  The reseed interval is random to prevent anyone from guessing where a new key is used.  I purposefully chose CBC as the block mode instead of CTR even though it's faster because I've read that CTR is only good for constant streams, and my very limited cryptographic knowledge tells me that a repeating counter that restarts all the time isn't a good idea when the "stream" will only be a few MB long, although I really don't know for sure.

One worry I have is whether or not the stream leaving openssl is fully encrypted.  If the input is not evenly divisible by the block size, would openssl leave the extra data blank (leaving "gaps" of 0s scattered throughout the resulting stream)?  Does padding have anything to do with that?

So my question is, is this a good way to create fast random data?  And is there anything I missed/overlooked, etc, such as using the wrong blockmode?

Edit: The obviousness was blinding so I missed it. OpenSSL already offers an interface to its own internal PRNG, which is seeded with the machine's /dev/urandom, but then extends it with its own crypto. Just do this:

openssl rand 10000000

to produce 10 millions of pseudo-random bytes. On my laptop, this appears to be about 3 times faster than /dev/urandom, i.e. 11 MByte/s or so. If this is not fast enough for you, read on.

Original response:

It really depends on the involved hardware and context. Since you are talking about a bash script, /dev/urandom and OpenSSL, I suppose that:

You use Linux.
You want to produce a big file full of pseudorandom bytes.
You want a solution which is a scripted assembly of existing, "normal" packages, not a programmatic solution.

Indeed, if you could write your own C code, your best options would be either AES encryption in CTR mode with the AES-NI instructions (on recent PC which offer these instruction), or a dedicated stream cipher (e.g. one of these). On a 2.4 GHz Core2 CPU, I could get 700 MByte/s of pseudorandom bytes out of Sosemanuk. I hereafter suppose that you are limited to scripts.

Using OpenSSL encryption is not a bad idea, but there are details:

Randomizing the length of each chunk is a useless complication.
There is no need to go to AES-256; AES-128 is already fine. AES-256 is 40% slower than AES-128, and adds no practical improvement in security.
When encrypting a long sequence of zeros with CBC, you are actually running the block cipher in OFB mode (encrypt a block, encrypt it again, and again, and again). This is reasonable as long as you remain below the 2n/2 limit, meaning that with AES (128-bit blocks) you don't use a chunk longer than 264 16-byte blocks, i.e. 250 millions of terabytes. Chances are that you won't reach it anyway. In that sense, the "reseeding" is not really needed.
When you "reseed" (if you decide to maintain this feature, which is not necessary), use /dev/urandom, not /dev/random. /dev/urandom is fine for cryptography (the OS boot scripts ensure that the internal PRNG is properly seeded), despite the misguided paranoid qualms of the /dev/random implementation. On the other hand, /dev/random may block, and thus be really slow (nothing is slower than a blocked process).
Beware of strings. bash uses character strings; /dev/random and /dev/urandom return bytes, including bytes of value 0. This may result in an artificially truncated key, and lowered security. This is bad. Instead, you should encode the bytes in hexadecimal and the the -K and -iv command-line arguments with openssl.
OpenSSL may add a header which begins with 8 fixed bytes (thus totally non-random). It does not do so if you use -K and -iv.
OpenSSL will also use some padding so you will get an extra 16-byte block at the end (this is not a problem; the padding is on the cleartext, and encryption "randomizes" it).

This leads to the following script:

#!/bin/sh
key=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum | cut -d' ' -f1)
iv=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum | cut -d' ' -f1)
dd if=/dev/zero bs=65536 count=8192 2>/dev/null | openssl aes-128-cbc -K $key -iv $iv

When invoked, this script outputs a sequence of exactly 536870928 pseudorandom bytes, which are fit for cryptographic purposes. Feel free to modify the bs and count parameters, but remember that dd will allocate a RAM buffer of size bs, so you usually want to keep bs small, but not too small to avoid too many roundtrips into the kernel (8192 to 65536 are usually good values).

I use MD5 here only for the convenience of the bytes-to-hexadecimal conversion (the known shortcomings of MD5 have no influence whatsoever on the security in this case).

This script should work on any decent Linux installation. It uses only packages which should be there by default. On my not-very-powerful laptop, this script produces pseudorandom bytes at the rate of 73 MBytes per second, which is not bad and probably enough for your purposes (if that is not enough, then you will probably have other issues with I/O bottlenecks).


Periodic password change needed when using 2-step verification? I know that it's considered good online security hygiene to change one's login passwords every 6 months or so.  Is that needed on sites with 2-step verification?  Isn't the 2nd step what will keep my account secure regardless if someone has the password or not?  Indeed, are passwords needed at all in a world of 2-step verification?

Indeed, two factor authentication (2FA) will prevent anyone from accessing an account without having both authentication factors.

That being said, the typical implementation of 2FA online is a password paired with a short code, either on a keyfob or sent via SMS.  The standard RSA SecurID keyfobs that have been around for a couple decades now and Google's 2 step verification program, as a couple examples, both use 6 digit numeric codes as the second factor.  With only 1 million possibilities, that's a fraction of a second to brute-force on even obsolete computing devices.  Granted, there are other security measures in place (like account lockouts and time restrictions) that offer protection against brute force attacks on the second authentication factor, but it's such a small number of possibilities that it's probably feasible to overcome with just a little effort and ingenuity.  For example, renting a botnet (which can be done for literally several dollars) and using a modified "low and slow" brute force attack against the second factor, if the password is known.  As pointed out in the comments, if we assume 3 guesses at one in a million odds per "attack", before the code resets, we get a ~3 in one million chance of succeeding per attack. Assuming we were able to launch one of these treble attacks against the second factor every 30 seconds, we could get a 26% chance of succeeding do in a couple weeks or so (100,000 attacks, 1- 0.999997100000), and better than 50% chance of success in approximately a month (250,000 attacks, 1- 0.999997250000).

And bear in mind that brute-force attacks are not the only possible attack against the second factor or the best, or most likely... they're probably about the worst way to attack this second factor, and they're likely to be at least somewhat feasible.  It's not that difficult to con a cellular service provider into giving over control of an account/phone number (to receive the 2FA SMS message themselves), or steal a keyfob, or exploit vulnerabilities in the 2FA system itself, and so on.

At a high level, 2FA is about verifying someone as an authorized user in two different ways.  "Something you know, and something you have."  People are bad at generating unguessable secrets (something you know), as well as being bad at keeping them secret, and people are also not great at keeping control over physical things (something you have)... but they're much more likely to be able to do one or the other at any given time. As long as I can do one or the other, 2FA will keep my account [relatively] secure.  On its own, that 2nd factor is little more than a very, very weak password, (at least as implemented by most websites/webservices) and people protecting their accounts with very, very weak passwords is one of the reasons that 2FA exists in the consumer space today.

So yes, passwords are still needed with most 2FA, and occasional password changing is still a wise precaution. The relative weakness of the second factor in typical implementations means that it's not secure enough to stand on its own, without the secrecy of a good password for the first authentication factor.  And because a good password as a first factor is still required, that does mean following good password practices (strong password, not re-using it, changing it occasionally).


What is an SNI Hole? Earlier today, Lone Learner asked Why is there no certificate error while visiting google.net although it presents a certificate issued to google.com?

The accepted answer explains that the issue was caused by an SNI Hole.

  You've fallen into a "SNI hole". Google will present a different certificate if there is no "Server Name Indication" given in the client's TLS handshake part.
  -StackzOfZtuff

The top search result for "What is an SNI Hole" is the question page for What are the security implications of enabling a SNI-hole on a web server?, which isn't much help for those unfamiliar with the term.

What exactly is an SNI Hole?

SNI (Server Name Indication) is a TLS (Transport Layer Security) extension in which the client presents the server the domain name for the target it wants to access within the TLS handshake. It is used in cases where there are multiple virtual servers with different certificates on the same IP address, so that the server can present the correct certificate.

Insofar it is similar to the HTTP host header in the HTTP request, which is used to select the matching virtual host configuration - only the Host header cannot be used to select the certificate since it is sent inside the HTTP request. (i.e. after the TLS handshake is already done).

Since the SNI TLS extension is optional, some clients may not send this extension. This is the case with openssl s_client without the -servername argument, but also with many TLS libraries in different programming languages. And while all modern browsers use SNI, older browsers like IE8 on XP do not use it.

If such a client connects to a server which has multiple certificates, the server does not know which certificate the client actually needs, i.e. the client falls into the "SNI hole" by not using the SNI extension. In this case the server usually either sends an error back (or sometimes just closes the connection) or uses a default certificate explicitly or implicitly configured for this purpose.


How does a Registrar/Domain Lock increase security? I have all of my domains locked, so that they cannot be transferred without first unlocking. However, I can't think of any scenario where this lock increases security.

In order to transfer, one must obtain an authorization code. To do this, you have to log into the domain account. If someone can login to get this auth code, they can also log in to remove the domain lock. And the unlock is instantaneous, so it doesn't delay the transfer ability of a hacked login.

When did this lock become standard with registrars, and why does it exist? Is there some way a person could obtain a transfer code without logging in?

Domain locking is meant reduce domain hijacking. That said, it is not clear that all implementations provide protection. Especially being that many domain hijacking attacks occur via social engineering targeted to the support personnel of registrars.


Would using a QWERTY keyboard with DVORAK output cause keylogger to log DVORAK? I have QWERT keyboard, but I have set the keyboard settings in Windows to DVORAK. So if I type "test" it comes out as "y.oy". Would the key logger log "test" or "y.oy" in its records?

Ultimately ... It wouldn't matter

at best this key substitution would equiv to a Caesar cipher ... which can be easily broken.

Qwerty

  The quick brown fox jumped over the lazy dog

Dvorak

  Yd. 'gcjt xpr,b urq hgml.e rk.p yd. na;f eri

online translator


Digital Signature: Class 2 vs Class 3 On an official Indian Government webpage I find several classes of digital signatures explained:

http://cca.gov.in/cca/?q=node/45

Are these just an India-specific quirk or is there an internationally recognized classification?

Also, are the certifying authorities that someone will recognize generic or does one have to verify for each intended use / locale which CA's the counter-party will accept for a digital signature?

i.e. Can I buy a personal digital signature from a reputed CA like Symantec & be fairly certain that most applications that need digitally signed documents will accept it? Or does one have to deal with each application individually?

Warning: half-knowledge ahead.

If you look at any given certificate, you see that it contains various fields that could in theory be checked by an application. For example, an application might reject a certificate that used weak cryptography (Google chrome does this). Certificates can also be given a specific purpose (such as: only use this for client authentication). So it's possible that an application that expected some kind of specific certificate might reject a "non-classified"-one.

Also, in theory, an application could be picky about which cert authorities it trusted (e.g. just the ones in india...). Usually such lists are distributed as a part of the operating system or the operating system's SSL libraries, and browsers come (I think) with their own additional lists of trusted cert authorities.

Now, since most applications don't roll their own crypto and don't keep their own list of trusted cert authorities, and instead use software libraries to check signatures, I'd guess that you should be okay with using a non-indian cert. Think about what would happen to interoperability if every other application used different rules on which certificates to accept.

An exception would be if you were dealing with specific software written by the indian government, which might have strict restrictions on which certificates to accept.

But really I don't think there's any way to tell for sure. This answer is mostly guesswork.


security issue on storing keys and certificate on token I'm creating a sample USB token with Atmega64. As I have to store both the public and private key and the certificate on my token is there any important security issue that I should worry about, except making EEPROM read-only?
I also want to implement PKCS11 DLL for my token. Is there any pattern I should follow on storing my public and private keys for the PKCS11 standard.

Simply storing a secret on a piece of hardware doesn't help secure anything,  (god forbid) we have USB sticks for that.  The secret must never leave the piece of hardware in order for it to be effective.  A device like a smart card is effective in two-factor authentication because it handles the challenge response.

If your device is as effective as a smart card,  then it will have to confront a lot of the same challenges,  Such as Side Channel Attacks and other physical attacks.


What can an locally injected javascript file do? I was doing some pentesting on my little forum project. I found out, that it is possible to inject a javascript file through a little security hole. So basicly, the hacker can inject any javascript code he wants. Now, on the contrary to well known security issues, this hack is only working on the hackers side, because there is no data shown to other users, except the hacker himself.

The hack works in the user settings page where each user has access to his own settings only. So an alert would be shown only at the hackers computer.

I have fixed this already, but:

I am still curious about if this hack still could be dangerous for the project itself. Can a hacker do more damage with it than I think?

If you are really sure that the injected code can only be executed by the same person who injected it, then it could indeed be classified as "self-XSS", as mentioned in a comment to your question. Apparently to exploit that an attacker needs to rely on social engineering, trying to trick other users into injecting the code themselves and execute it.

EDITED TO ADD CSRF SCENARIO

Anders's answer suggests a CSRF scenario but I don't agree with that (and I don't have enough reputation to comment there yet). However I just realized that a CSRF vulnerability can actually help the attacker to exploit your XSS. Anders's suggested using CSRF to log you in as the attacker and redirect to their page that had been previously infected. This way you'll find yourself executing arbitrary js, but you are logged in as the attacker and executing js on the attacker's private page. That seems pointless to me. The supposedly right option would be to use CSRF to inject the malicious code directly in the victim's page. It would work this way:

the victim is currently logged in on your website
the victim visits a malicious website that uses CSRF to inject the XSS in their own private page (for example a POST request to a form that changes their profile settings and put js in the vulnerable field)
the victim visits their own private page and... now there's injected js there

This of course requires that the form on your website used to inject js is vulnerable to CSRF (for example because the form doesn't require a hidden secret token), so an attacker can force the victim to make a request to your website with serious consequences without the victim's consent, for example changing settings, passwords, or in this specific case injecting js. Read up on CSRF if you need to understand more.


Beginners materials for web security Possible Duplicate:
  Resources to learn about security

What materials can I study to learn web development security. I'm a web developer, I use ASP.NET, Java, PHP, and JavaScript. I want to learn how to build strong and robust web sites that are not vulnerable. I want to protect my backend database.

I would strongly recommend these OWASP materials:

Application Security Verification Project at https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Development Guide at https://www.owasp.org/index.php/Guide_Table_of_Contents

Testing Guide at https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents

and Code Review Guide at https://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents


Edit Ettercap password sniffer engine? I'm using Ettercap as MITM for testing on sniffing password but I'm not getting some POST request data containing "usuario" (user in spanish) and "clave" (password in spanish).

I'd like to know if there's some editing file in order to add those fields into the sniffing engine.

I'm away from my laptop right now but I remember that the ettercap configuration file is called etter.conf. I frequently use ettercap with arpspoof as a MITM attack and it always outputs any cleartext unencrypted HTTP POSTs. I would make sure that the login page you are trying to sniff isn't HTTPS or if it is unencrypted, that it doesn't post to HTTPS.

Edit: I only glanced over the question and didn't notice the spanish comment. Yes, it's likely ettercap is skipping it because of the form name.  Follow JayfromA's advice.


OpenBSD-based LiveCD/LiveDVD - is it secure? is it offical? Does the OpenBSD LiveCD/LiveDVD get deeply audited like the original OpenBSD?

Is it an official "port"?

Experiences with it?

One security problem with a LiveCD is that its static and there for cannot be updated.  The SQL Slammer worm was memory resident, it doesn't matter if you have a disk drive.  You can install live cd's onto usb drives using LiveUSB Creator.

Check out the new Debian GNU/kFreeBSD distribution.   You have all the power of apt and its built on a FreeBSD kernel.


Cryptographic Hash vs. MAC (or, why hash alone is insufficient) There are already a couple of questions raised comparing Hash and MAC, but I searched and did not find answer to my question.

Usually we send "Encrypt(M, k) || MAC(M, K)" so that the receiver can check the message integrity and authentication.

But it seems that "Encrypt(M,k) || Hash(M)" works the same. Is this scheme for message authentication vulnerable?

Just as you added the authentication tag to your question, that is actually the answer to it.  The MAC involves a piece of information that should be known only to the parties that are communicating: the key.  When paired with encryption (as in your questions), MACs are used with symmetric encryption, therefore the key shall be the same and known only to the two parties communicating.

Contrary to a simple hash (which provides integrity) a MAC also provides authentication.

(In asymmetric encryption digital signatures provide these features.)

This is not extremely important when performing encryption since an attacker would need the decrypted message to generate the hash anyway.  The authentication part of the MAC is much more important in not encrypted communication.

Hell, assuming that K is key of a block cypher and M the plaintext then:

Encrypt(M, K) || MAC(M, K)
Encrypt(M, K) || Hash(M || K)

Are equivalent on high level meaning.  Since a cryptographic hash that receives a secret key as the input is a valid way of generating a MAC.


Using a Public-Key-Encryption browser side to avoid PCI compliance We're developing a web application in which certain not logged users (clients) need to send their credit card details to other users (merchants) - which, we'll assume, are PCI compliant.

We are looking into getting PCI compliance, but the process will surely needs a lot of time.
Therefore we are investigating other solutions which don't require us getting a certification and protect us from getting sensible data stolen.

Our plan is to:

Make the merchant generate a private and a public key
Store the private key inside his browser using localstorage (and provide a mean to backup it)
Provide the public key on the form used by a client
Before the client send the data, encrypt everything with the merchant public key
Store the encrypted data in our server
Provide the encrypted data to the merchant
Make the merchant decrypt the data in his browser using his private key

The idea was to use JavaScript and the library jsencrypt.

Do you see security issues in this workflow? Do you think we still need PCI compliance when employing a system like that?
The reasoning is that, for anyone without the private key, those are just random bytes.

The only attack I can think of is someone compromising the server and replacing a merchant public key with his own key. But he could as well steal a token for another payment gateway and fake the communication needed to do something nasty.

We know about services like Paymill, Braintree and Stripe (which offer pretty good client side libraries) but they're not fitting for our solution (or better: they're alternative we'll make available for merchants - but it should be up to them to decide).

Thank you in advance

EDIT: I totally agree with you guys and I'd rather work with thirdy party solutions.

The problem is that we're working in a market in which most of our competitors are small companies working without PCI compliance (and most of them even without HTTPS!!). Our competitors simply receive CC data, store them and give access to the users.

We know about the risks of such approach, but the users don't and they prefer their solutions to ours because they'd rather have the whole CC data, instead of just having buttons to execute actions.

(Disclosure, I work at Braintree)

If a server is providing a form that customers will enter credit card numbers into then that server falls within PCI scope. This is regardless of if you encrypt the data in the browser. The reasoning here is that an attacker can modify the page that is sent to the browser to siphon credit card data out of the page DOM before encryption.

You would need to work with a qualified security accessor (QSA) or your merchant account provider to know what your PCI process will look like. If you're processing under 1 million transactions then it would likely be a self-assessment process. The determination of which self-assessment questionnaire (SAQ) to fill out is based on how much access to the cardholder data you have and if you store it.


is there any way to exit meterpreter without exit the process? I have a target process I'm injecting meterpreter shellcode (windows/meterpreter/reverse_tcp) into, I manage to get a shell but when I exit it, the process exits as well.
Is there any easy way to make the process survive the meterpreter exit besides debugging the process and changing to shellcode manually?

I've added registers saving instructions (pushad, pushfd) at the beginning of the shellcode and registers restoring instructions followed by a trampoline at the end of the shellcode where the opcodes are instructing the process to jump back to some address, but the execution flow never reaches the end of the meterpreter shellcode and the process exits when I exit the meterpreter session.

Have you tried changing the meterpreter option EXITFUNC to thread when generating the meterpreter payload?


Why does my Amazon-issued certificate not show up in the certificate transparency logs? I have an Amazon-issued certificate (via AWS Certificate Manager) for a number of subdomains (CN = *.aws.jamymahabier.nl). However, it is not showing up in the logs at crt.sh (only the Let's Encrypt-issued certificate for my main domain, jamymahabier.nl, is).

Why is this the case? Shouldn't all certificates show up in the CT logs?

Without seeing the exact certificate its not possible to check that there definitely isn't transparency for that certificate - there are numerous logs and I do not know which crt.sh searches.

However CT is still optional and most clients do not enforce it yet. Chrome requires it for EV certificates and all certificates issued by Symantec after 1st June 2016 - so it is possible Amazon have chosen not yet to implement it for AWS Certificate Manager.

*https://transparencyreport.google.com/https/certificates does not show the certificate - which suggests to me Amazon have chosen not to implement it.


Is bypassing my VPN and seeking my IP address hacking? I used VPN service to hide my location. Program noticed that another program included inside the mediawiki I was editing is trying to bypass it and read my IP address. Is that allowed or is it hacking?

If it's illegal, where do I report that if webpage and wiki is in US and owned by US citizen?

You used a VPN. You hoped that the effect would be that you could hide your location and IP. There are lots of ways that websites can determine your real IP, and they are not considered hacking.

What you need to do is to harden your setup to make it harder for these "de-anonymizing" techniques to work.


What are RealVNC 5.0 Authentication Protocol Security Limitations? In the old version of RealVNC, the password length was limited to 8 characters which was easier to be cracked. They have now increased the password length by 255 characters, will this make Realvnc authentication more secure now?

Having a long password doesn't mean it's secure - the VNC client might still have vulnerabilities, such as the authentication bypass bug in versions 4.0 to 4.2.2. However, a limit of 255 characters is certainly better than a limit of 8 characters, since you can at least rule out a brute force.