What should a security audit report include? Background

I'm in charge of auditing a medium-scale web application. I have audited web applications several times before, but I've always written a short PDF quickly explaining what I encountered and usually I'm the one who's gonna be fixing those vulnerabilities so I never cared for the actual content of the report.

In my current job things are done in a more organized fashion. First I have to write the report, then the project manager will review it, then he'll decide whether I'll be the one to fix the issues or someone else.

Question

What should such report contain? I'm looking for a general outline of how it should be organized.

Update: Because I couldn't find anything here on Security.SE about audit reports, I decided to make this question a bit broader and include any kind of security audit rather than just web applications. I think it'll be useful to more people in this case.

There's a couple of ways that I've seen this done, each has it's pros and cons.

As noted by @RoryAlsop below a common point for both approaches is that the executive summary should, as much as possible, be written for a business audience (assuming that it's a test you're doing for a 3rd party or the report will be passed to management).

Reporting by finding.  Here you list the findings, usually ranked by severity (e.g. CVSS score or some other scale like severity/likelihood).  You then list out the technical details of the finding and potential mitigations if you have that information.  This kind of report gets to the point quite quickly and plays well with tool output.
Reporting by methodology.  Assuming here that you're following a defined testing methodology, the report is structured along the lines of the methodology and includes a section for each area of the review.  The sections detail what testing was done and the outcome (e.g. either a finding or the fact that there was no finding in this section).  The advantage here is that you're showing your workings and that someone reading the report can get a good idea that you've actually tested something and it was ok rather than you just having missed it out.  The downside is that it tends to be a longer report and harder to automate.  One other gotcha is that you need to make sure that the testers don't just follow the methodology and they actually engage brain to look for other things.

In terms of format for the findings, I usually include the following

Title (descriptive gets used in the table and linked to the detail)
Description - technical description of what the issue is and importantly under what circumstances it is likely to cause a security issue (e.g. for Cross-Site Scripting one of the potential issues is use to grab session tokens which could allow an attacker to get unauthorised access to the application)
Recommendations - How the issue should be resolved, where possible include specific details on vendor guidance to fix it (e.g. things like removing web server versions from headers have specific instructions for Apache/IIS etc)
References - Any links to additional information that's relevant to the finding (e.g. links to the relevant OWASP page for Web app. issues)
Severity.  As I mentioned above this could be CVSS or something more general like High/Medium/Low based on impact and likelihood.
Other classification as needed by the client.  For instance some client might need things lined up against a standard or policy or something like OWASP Top 10.

One other point to make is that if your do a lot of tests it's well worth having a database of previous findings to avoid having to look up references repeatedly and to make sure that severities are consistent.


distribution mechanisms for CRLs From the X.509 RFC:

DistributionPoint ::= SEQUENCE {
     distributionPoint       [0]     DistributionPointName OPTIONAL,
     reasons                 [1]     ReasonFlags OPTIONAL,
     cRLIssuer               [2]     GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
     fullName                [0]     GeneralNames,
     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                       [0]     AnotherName,
     rfc822Name                      [1]     IA5String,
     dNSName                         [2]     IA5String,
     x400Address                     [3]     ORAddress,
     directoryName                   [4]     Name,
     ediPartyName                    [5]     EDIPartyName,
     uniformResourceIdentifier       [6]     IA5String,
     iPAddress                       [7]     OCTET STRING,
     registeredID                    [8]     OBJECT IDENTIFIER }

Also....

   If the DistributionPointName contains multiple values, each name
   describes a different mechanism to obtain the same CRL.  For example,
   the same CRL could be available for retrieval through both LDAP and
   HTTP.

My question is...  how do the distribution mechanisms work for each of those?  rfc822Name is email, I think, so what are you supposed to do?  Shoot the email address specified by that an email and expect it to auto-respond immediately with the CRL?

dNSName is for domain names so what do you do there?  Request the TXT record for www.domain.tld?  And what about ipAddress?  Am I supposed to use a particular protocol to get the CRL?

I have no idea what x400Address, ediPartyName or registeredID are supposed to be..

I guess directoryName is supposed to be another DN but I'm not really sure how that tells you how to get the CRL.  Maybe you're supposed to find a CA whose subject matches the certs CRL Distribution Point directory name and see if that contains a URI (or email address or whatever)?

In practice, what software can support is uniformResourceIdentifier. The extension then contains a URI which points to the CRL. http:// and ldap:// URL are rather common; https:// URL for CRL download raise interesting issues since the server certificate must then also be validated (so, in practice, it does not work well, or at all).

In situations where machines have a "natural" LDAP server to talk with (e.g. Windows systems in an Active Directory forest), a directoryName can conceivably be handled automatically, by looking at what exists in the LDAP server under that name. I have not seen it working in the wild, though.

For the other name types, well, some make little sense (e.g. dNSName) or would imply human intervention (rfc822Name). The root of the issue is that GeneralName is a really generic structure which is used in many places, and there is no guarantee that any specific GeneralName value makes sense when employed in a specific context, e.g. as part of a CRL distribution point.

If you are writing a generic validator and you just handle http:// URI for CRL download, then you will have already done better than most (most implementations of X.509 do not check revocation at all !). If you also support ldap:// URI, then the term "luxury" could apply. Realistically, the only reasonable thing you can do with the other name types is to totally ignore them.

That's for CRL download but CRL distribution points have another use, which is segmentation. This is what happens when the CRL Distribution Points extension is critical. In that case, you must match the distribution point name with the Issuing Distribution Point extension in the CRL (regardless of how you obtained said CRL). Segmentation is a way for CA to issue smaller CRL, which cover only a subset of the certificates they issued. To know whether you are using the right CRL, you must match the names between the certificate and the CRL. For that, handling the other name types could be necessary. However, this is not about interpreting these names, but just equality tests.


SMBRelay Attack - Mount Share instead of Code Execution Is it possible to execute an SMBRelay attack that mounts a share instead of execute code? The application I am testing uses a non-administrative user but has access to several SMB shares. Only NTLMv2 is allowed so pass-the-hash doesn't work.

Yes, but for mounting shares you only need to use the NTLM Relay aka NTLM Reflection attack, not the full SMB Relay code-execution attack.

Due to the fleeting nature of NET-NTLMv2 authentication, I suggest the use of the -- https://github.com/purpleteam/snarf -- tool because it will hold the connection to the server, unlike Responder.py or InveighRelay which will only grab the NET-NTLM credentials on the wire (while BunnyTap and Quickcreds only require physical access with a USB drive). However, NET-NTLMv2 creds can be compared to stored-NTLMv2 creds, although wdigest, warm-boot memory acquisition, and other factors can easily widen the capabilities of stored-password attacks.

There are quite a lot of tweaks to these attacks as well as defenses that come into play. Feel free to bring up issues you run into, but the snarf tool above is one of the best starting points.


Is it fine to store single-use beta keys plain-text? Is it okay to store single-use beta keys in plain-text in the database? I'll be pre-generating and storing about 2M keys. The keys get passed around so that people can sign up with it, rather than let random people sign up.

The only bad thing is that if someone could steal all the beta keys with a db dump, if that ever happens. Temporary protection could be hashing them using bcrypt, and then comparing the user's hashed input to the key hash (like a password), but then pre-generating 2M keys and hashing it all would be too slow.

In your question you have identified a potential threat. If you think this threat is real and it would have a sufficiently negative impact on your operations if it were exploited, you should take additional measures as you suggest in your question.

If you are saying the keys in this case are unique identifiers which you do not want exposed, you may need to employ hashing and encryption as needed. If you need to store the keys and need to use the same DB to assign them, you cannot hash them since you would have no way to reverse them in order to hand them out. You would need to encrypt them.

Does the benefit of pre-generation outweigh the risk of having them compromised and the cost of creating keys on the fly? It may make more sense to create them on demand and look at solutions for email verification tokens and how they are managed since it seems you are doing something similar.


Random accounts being created, why? I have a small business that provides an online service, like a CRM service for businesses.

Over the last few weeks, I've had 20 - 30 random accounts created. (this is unusual as I might get one or 2 a month).

They would create an account, then add a few random clients and do a few other bits.
I will then disable the account to stop it logging in.

I added a recaptcha to the site for signing up, but still, the accounts get created every day.

I'm logging the IP address when the account is created and the IP source is from two different countries (does not change that often, but always the same state).

Any ideas about what's going on? How I should handle this situation?

Well, remote diagnostics with a big portion of assumption on how your infrastructure looks like, would not produce results you can rely on, so I am writing in a more general-approach:

I would suggest, that you do some kind of investigation first to better understand the motive of the potential hacker. Did you for example check about the IP reputation of the IP source, i.e. with OTX (https://otx.alienvault.com/)?

Another option could be to put an IDS and WAF in front of your Online Service, as that would help to gain more insights. If that is too complex, the most simple way would be to at least record the packets to replay them / analyze them with i.e. Wireshark.

In terms of IDS / WAF, you could consider the following technology as they are not only industry standard, but also Open Source:

https://suricata-ids.org/

https://www.bro.org/

https://www.modsecurity.org/

Last but not least it is always a good idea to pentest your setup to have a better understanding about the potential risks there. OWASP Zed Attack Proxy is a good start:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project


Is it possible to verify a PGP-signed and encrypted message without decrypting it? Let's assume I have a PGP message and I want to know who sent it, is it possible to do it if I have the RSA encrypted message, two possible senders (and their public keys that they signed and encrypted with) but I don't have the private keys? It isn't just a signature, the header says: --BEGIN PGP MESSAGE--.

If you happen to have random encrypted messages which were not encrypted with your public key (and therefore you cannot decrypt the message), then the answer is no.  Signatures must be contained within the encrypted data blob otherwise you have nothing credible to verify.  Here's why.

(First, let's make sure we're on the same page: you encrypt a message using a public key and sign with a private key.  You will never(!) have someone else's private keys because otherwise the entire protection mechanism falls apart.)

Encryption is protection from eavesdropping.  Signing is non-repudiation of sender meaning the sender cannot say they didn't send it.

To verify the sender of a signed and encrypted message (order matters here), you will need to first decrypt the message because the signature is part of the encrypted message.  Decrypting the message will not tell you anything about the sender since anyone can encrypt a message with your public key.

Once the message has been decrypted, you can extract the signature and verify it using the public keys you have for those possible senders.

However, what you cannot determine is whether the same person ACTUALLY signed and encrypted the message by virtue of the fact that one side of the process (encryption) uses entirely public information with no specific information about the sender.

If the sender's private key has fallen into wrong hands, then all bets are off.


Securing a REST api at the message level I'd like some feedback on the following authentication idea, does it makes sense, and is there a standard
way of doing this (or similar) so I can rely on a well tested implementation.

I've seen many answers here on how to secure the communication to the server, and most answers are to simply
use TLS properly. I'm looking for a solution that allows for encrypting and signing the messages themselves,
so the message stay safe as they go through the backend, until they reach the destination service.

Context

Mobile app for android 2.3+ and iOS 6+ built with phonegap (so libs used should be usable from Java/obj-c or js)
The app communicates with the server using a REST json api
Message content should stay confidential as it goes through the backend (no termination at proxy/load balancer)
Should support "remember me", so the user doesn't have to re-enter their passphrase all the time
All communication are done over ssl/tls

Authentication

the client collects the user credentials (username, passphrase and some extra security info)
the client generates a symmetric key
the client encrypts the credentials with the symmetric key
the client encrypts the symmetric key with the server public key (shipped with the client)
the client sends the encrypted message, key and nonce via https (validating the server cert)
the server proxy forwards the authentication request to the authentication service
the authentication service decrypts the symmetric key and message
if the credentials are valid, the service generates an authentication token
the token is associated to the symmetric key on the server, if credentials are invalid, the key is discarded after replying to the request
the token is returned to the user, encrypted with the symmetric key
the token and key are stored locally on the client, encrypted by a short password

I assume that these requests are safe from replay attacks if tls is used, so there is no risk of an attacker replaying the message to get a new token.

Other API calls

the client generates the request messages, encrypts it and sign the encrypted message
the client sends the encrypted message, nonce and signature with its auth token to the server
on reception the server looks up key associated with the received token, verifies the signature and decrypts the message before processing

Questions

is there any issue with reusing the same symmetric key?
what is a good choice of symmetric key?

What about AES-OCB or AES-CBC + HMAC signing?

how often should the symmetric key be changed?
What is the best way of updating the key/refreshing tokens? I was thinking of issuing a refresh token during
the authentication response and have the keys expire after a specific period, so if the user does't refresh their
key they have to login again.

Thanks

Unless I have missed something your solution looks awfully like a Security Token Service. For an STS the key is to have a party that is trusted to identify the initiating party to the relying party. In your case the trust broker and relying party appears to be the same entity.

If your goal is to have trust propagate to the final destination, just use SSL through the proxy, and use a client certificate to identify the end point. Assuming you want HTTP going through your proxy so that you inspect traffic, implement a standard STS.

As Xander has said, REST is great for lightweight service calls, but the moment you want to do security you should use SOAP, specifically the WS-Security extension. It really isn't that hard, especially if you control both ends as you do. See this stack overflow question for how to do this in Java on Android.

If you do go ahead with your home baked solution it is worth noting that the last three bullets in your Authentication look to be your weak point.


How to get this to buffer overflow? I'm trying to understand buffer overflow, and am working with a simple piece of code, as below.

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int bof(char *str)
{
    char buffer[12];
    strcpy(buffer,str);
    return 1;
}

int main(int argc, char **argv)
{
    char str[517];
    FILE *badfile;

    badfile = fopen("badfile", "r");
    fread(str, sizeof(char), 517, badfile);
    bof(str);
    printf("Returned Properly\n");
    return 1;
}

I understand I need to inject the shell code in "badfile", suppose I create a badfile like this:

char buffer[517];
FILE *badfile;
memset(&buffer, 0x90, 517);
badfile = fopen("./badfile", "w");
fwrite(buffer, 517, 1, badfile);

Do I inject it at index 12th of buffer[]? I'm facing a problem with that. But I believe that is because it's not the return position. Do I have to calculate the return position? Thanks.

No, not quite.

There are two things to focus on:

Overwriting the return address.  You need to figure out what bytes in the file will end up overwriting the return address.  Suppose these are bytes 20-23 of the file (for example).
The location of the shellcode.  You should put your shell code later in the file (say, near the end).  Then you need to predict what address your shell code will be loaded into memory at.  Suppose A is the address where the shellcode will be loaded into memory.  You need to know this address, because this is what you need to use to overwrite the return address.

Once you know both of these, you're good to go.  You store the value A into bytes 20-23 of the file, and the shell code later in the file where you decided to put it.

To work out these two things, you'll need to look at the stack layout.

First, find the offset between the location where the start of str appears on the stack and the location where return address appears.  This offset tells you what bytes in the file will end up overwriting the return address.  If this offset is, say, 20 bytes, then bytes 20-23 of the file will end up being written over the return address.  To make the attack work, 20 bytes into the file you need to put a value that is where you want the program to jump to (the address of the start of your shell code).  This value will overwrite the return address.  The value to put there is the address A mentioned above.
Second, put the shell code even later in the file, predict what address the shell code will be stored at in memory once the file is read into memory, and use that starting address as the value to overwrite the return address with.

I recommend that you read Smashing The Stack For Fun And Profit by Aleph One.  It has an excellent tutorial on learning how to do a stack-smashing buffer overrun exploit.  (Hint: on modern systems, make sure to manually disable ASLR and DEP first, so that your exploit will work.)


Device authentication mechanism I am doing a project that needs device authentication with a gateway. What are some of the best ways of doing that ? Whether a certificate based mechanism is feasible in this case ?

Yes, you could use a SSL client certificate for this.  Each device would receive its own SSL client certificate.  The device could authenticate to the gateway by connecting over SSL and authenticating using its client cert.  This would allow the gateway to allow access for authorized devices (those devices whose client cert is on an approved list, or those devices who cert is signed by an internal CA set up for this purpose).


Brotli compression for HTTPS It appears that Chrome, Firefox, and soon Edge, support the new Brotli compression algorithm over HTTPS only.

I can't find anything on whether this new compression algorithm is susceptible to the BREACH attack. The only relevant thing that I found was at the end of section 12 of RFC 7932:

  A possible attack against a system that sends compressed data over an
     encrypted channel is the following.  An attacker who can repeatedly
     mix arbitrary (attacker-supplied) data with secret data (passwords,
     cookies) and observe the length of the ciphertext can potentially
     reconstruct the secret data.  To protect against this kind of attack,
     applications should not mix sensitive data with non-sensitive,
     potentially attacker-supplied data in the same compressed stream.

From that paragraph it appears that Brotli is still susceptible to BREACH.  If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

In this case is it safe to use Brotli for HTTPS content? If not then why are browser vendors supporting it?

support the new Brotli compression algorithm over HTTPS only.

In theory yes. In practice Chrome will currently accept brotli compressed answers with plain HTTP too, even though it does not announce support for brotli in plain HTTP. Firefox only supports answers in HTTPS.

  If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

This is a wrong generalization. The BREACH attack only affects dynamic content which contains secret information like CSRF tokens which the attacker likes to guess. It works only if the attacker is able to reflect own data into the original content like in case of reflected data from filled in forms. The attacker must also be able to detect changes in the size of the compressed content, i.e. using passive sniffing of the connection (classic BREACH attack) or through timing (HEIST attack). It is still secure to compress content where no reflection is possible and of course content which contains no secrets the attacker likes to guess. This especially means that compressing static content is safe.
As for the CRIME attack it is enough to disable TLS level compression which current browsers have done already. CRIME has nothing to do with content compression in HTTPS.
See also Is gzipping content via TLS allowed.


Weird 8-character hash I'm investigating an application. In a XML file I came across:

<ScrambledPassword>U8P3J2N1</ScrambledPassword>

I ran it through a hash identification script which is telling me it's a CRC-32 or FCS-32 both of which seem unlikely to me.

Does anyone have an idea?

My first instinct is that it's some homebrew algorithm. It might be online somewhere, but there are a million of these homebrew algorithms. It's unlikely you could find it if it's something obscure, though you can try a few top google hits just to see.

Another idea is that it's encrypted and stored with some weird encoding (since I see letters but it's not base64). Or it might use some custom encryption.

It could be a fun challenge to crack this system but we'd probably need to be able to create our own hashes. For example if you have two users with the same password, do they have the same scrambled password? Does the algorithm do something funny when you pass it all zero bytes (0x00)? Etc.

I'm not sure what you need this for, but I'd look at ways around it. If you bought a website and it uses this, just replace the hashing algorithm with bcrypt or something. Or if you're looking at software to potentially buy, you can tell the vendor you're interested in the security of their product and ask details about the hashing algorithm. If they refuse to give it, that's a big red flag. Nobody who understands security evades or denies questions regarding their use of algorithms.


How to check browser extension behaviour? I would like to be know which ways are available to check the behaviour of a firefox extension.

While wikipedia states that any browser extension can have access to everything done by the browser, I would like to assure myself that an extension isn't making background HTTP requests and/or looks for everything I do on a webpage (while the second point is close to that question).

I am not talking about open source / verified add-ons.

You could run Wireshark  to check for such background activity while using the add-on.

Alternatively you can forward your traffic through a proxy like Burp or  Fiddler and analyse it there.


Best Option for SSL Certificate for 2 Domains + All Subdomains I am hosting multiple websites on my Mac Mini server (latest version).  For some reason OS X server does not support multiple SSL certificates well for websites, and after hours on the phone with Apple enterprise support, I have given up and I'm now looking to get this accomplished with one certificate, if possible.

I have two domains:

example.com
phl.anotherexample.network

I would like to, with one certificate, secure:

example.com
*.example.com
phl.anotherexample.network
*.phl.anotherexample.network

I am assuming I need some sort of a multi domain wildcard certificate?

You can place wildcards into the Subject Alternative Name (SAN) field of a certificate, so it's entirely possible to wildcard multiple domains.  There are many CAs that will issue this under a name like "multiple domain certificate".


How exploit this open redirect vulnerability in browser? I have a problem. I found open redirect vulnerability by burp. Request by server look like here:

GET /user/settings/ HTTP/1.1
Host: domain.com
User-Agent: etc

So i decided to find open redirect here, first i try this:

GET /http://google.com HTTP/1.1
Host: domain.com
User-Agent: etc

Unfortunately 404 error. So i cut slash before http://google.com and bingo:

GET http://google.com HTTP/1.1
Host: domain.com
User-Agent: etc

Response:
HTTP/1.1 302 found

You are redirected to http://google.com

But i wanna exploit this vulnerability in browser, because now this bug is useless.

I can't use slash "\"(404 error) like:
domain.com/http://google.com

I can't enter address without slash(domain.comhttp://google.com), cause it's not working.

Someone has any ideas to exploit this in browser?

You cannot exploit this vulnerability from a browser. For non-proxy requests browsers always put the absolute path into the request which means that it will start with a slash.

The request you've sent to the site is actually a HTTP proxy requests (which would in theory also be a valid HTTP/1.1 non-proxy requests, but no browser sends it this way). The browser will send such a request to the site only if the site is configured as HTTP proxy in the browser. But even if you could somehow reconfigure the users browser to use the vulnerable site domain.com as a proxy the open redirect would not work because the user would need to actually click on the real link http://google.com in order be be redirected to again http://google.com and since the user keeps using the proxy it will just end up as a endless redirect.


Determine if a server is asking for a client certificate using openssl s_client I am using openssl to connect to servers to detect if they require a client certificate.

Currently I am using this command:

openssl s_client -connect pokyloky.com:5222 -state 2>&1 | grep 'server certificate request'

SSL_connect:SSLv3 read server certificate request A

I am surprised that simply using:

openssl s_client -connect pokyloky.com:5222

doesn't indicate directly that a client certificate has been requested. There is a handshake error:

139843101763232:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1262:SSL alert number 40
139843101763232:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

But it doesn't explicitly state why the handshake has failed.

Why does openssl s_connect not indicate clearly that the server requested a certificate and the handshake has failed because of this?

That behaviour is not part of TLS v1.2

But it doesn't explicitly state why the handshake has failed.

It can't. It's not defined as part of the (TLS v1.2) protocol.
When the server or client decides to abort a connection, they can choose from one out of several alert messages.
An Alert message looks like this:
struct {
      AlertLevel level;
      AlertDescription description;
} Alert;

AlertLevel is one byte wide and only has two states:
enum { warning(1), fatal(2), (255) } AlertLevel;

And AlertDescription is one byte wide as well. But out of the 256 possible reason codes only about 30 are assigned and used. And of these 30, there simply is none, that fits the "Hey, I told you I wanted a client certificate, why didn't you give me one?!?"-bill.
(And although it sounds like it might fit, no_certificate_RESERVED(41) was used for something else. Namely in SSLv3.0 it was used for the other direction: for the CLIENT to tell the server "Sorry, I can't give you a client certificate.")
Now for the deeper question "Wouldn't it make sense to define such a reason code if there are plenty unused code points left? Instead of just hard, largely unexplained failure?" my answer is simply: "I don't know."
I don't see how having such an alert could make the protocol weaker, but crypto is tricky, and I'm not sure.
Loadbalancer to give friendly error message
But what if you want to give a friendly error message?
AFAIK, then you must do somewhat complicated things with loadbalancer like logic and just initially allow the clientcert-less connection, but then immediately redirect to an error page. Apache can do such a thing with a rule similar to this:
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
RewriteRule .* /help/ssl-client-auth-required.html [L]

IIS defines a HTTP eror message called 403.7 Forbidden: Client Certificate Required. I think this is a smart move (better than just failing, at least), even though the .7 of 403.7 is non-standard and I think the error message belongs on the TLS layer and not the HTTP layer.


Is there any asymmetrically encrypted file system? Is there a file system providing a directory where everybody can write, but only the directory owner can read the files? In theory it could be done by encrypting using the public key while writing, but I see that it's much more complicated than symmetric disk encryption. The purpose is to allow everybody to have their own directory where everybody else can put files into, i.e., a sort of secure messaging system, just at the file system level.

Nobody (not even root) but the owner should be allowed to read the files, so access rights don't help. Let's assume the system is secured against keyloggers, etc.

Short concise answer
To the best of my knowledge, such a scheme is not available in a general purpose filesystem in a general purpose operating system using full block level RSA-only non-hybrid crypto. This is because operations like RSA in software are generally slower than their symmetric counterparts and require a lot of implementation extras, which are considered unnecessary when userland applications more than suffice for this purpose. The linux kernel and other kernels are concerned with supporting a wide range of general purpose applications in user space, so any non-necessary to your average general purpose user feature doesn't generally get included. However, this is not to say you cannot do it. People have implemented web servers in kernel space. You could do this if you wanted to.
Just to cover all my bases; obviously the kernel optionally supports a lot of hardware including some which may provide hardware assisted cryptography. In this case, your life is made considerably easier.
A hybrid scheme which PGP/TLS etc implement has a weakness in that the symmetric key is by nature read-write on the encrypted data. If you can intercept this, you can read the data. This is hard to do, no doubt, but possible. In a filesystem, your life is made easier because the read/write system calls will contain that unencrypted data in their buffer, which you can intercept, if you are root.
Long winded answer
I believe you're asking why on earth given that public key cryptography allows you to technically implement this form of access control (write in, no read out) why on earth it hasn't been done. Yes, I am trying to answer why you don't do block-by-block RSA. So, in two sections:
On why RSA hasn't been included in the kernel
You might be surprised to know there isn't an implementation of RSA in your linux kernel (or probably in the Windows kernel - I'd bet that it is in userspace).
Firstly, let's look at what is in the kernel: here's the crypto folder from Linus's main tree. Not an asymmetric algorithm in sight. Remember, we're still discussing filesystems here.
Next step, how do we implement RSA. At a register level, a x64 (as in, AMD64/EM64T compatible) processor can hold exactly 64 bits per register. This is why you have types like uint32_t and uint64_t in stdint.h and why integer overflow occurs.
If you're not quite following why this is at all relevant, well, an RSA key requires that you produce a modulus of a certain bit length; 2048 is recommended I believe although factoring 1024 is going to be hard enough (search Thomas Pornin's posts for a discussion on factoring both here and on crypto). So let's say 2048 bits. You might have noticed that in a single register, there's no way we can actually store that number. So we're a little stuffed for loading it into a register and manipulating it then, aren't we?
Ok so how then do we process integers of such a size as we require for RSA. Chain lots of 64-bit blocks together is basically the answer. x86 processors support operations such as adc which is short for add with carry. What happens when you add two registers who have the most significant bit set together and will therefore overflow is that the carry flag is set and the next adc you run will have an additional 1 added to the least significant bit.
This very fact allows us to start approaching arbitrary precision arithmetic. Now, all we need is 32 64-bit blocks of memory to store one side of our multiplication and the result and a further x lots of 64-bit for the other number. That gets us to actually generating our modulus.
Let's speed this theory up a bit or we'll be here all night. Addition is basically O(N) whichever way you look at it in a bignum library. Things like multiplication and exponentiation can be reduced to O(N) if one of the operators is only a single limb (64-bit chunk; limb is the bignum term for it); however, for two arbitrary numbers operations such as multiplication and division are always worse. Monumental effort has gone into speeding that up. The best summary that I know of of algorithms and their runtimes is available here: Modern Computer Arithmetic. However, I'd say it's actually highly theoretical, algorithm-listy and that Seminumerical Algorithms by Don Knuth contains a more accessible introduction.
Now, bignum operations are fast. Not just fast, like stupidly fast. Amazingly fast. Loop-unrolled hand optimised per platform assembly fast. GNU MP is widely regarded as the fastest general purpose bignum library on the planet and is used by Mathematica, Maple, Pari/GP and everyone else who does arbitrary precision arithmetic. It turns out neither GPG or OpenSSL use this in favour of their own bignum implementations, but that's their choice.
In contrast, AES, once you expand the SBox and the key expansion, is really two things: a hash table you never add to (the SBox)(and is therefore always O(1)) and a lookup table for the key expansion (also O(1)) and some xor-ing.
So, I think it's fair to say relative to AES, RSA is pretty slow, right? It's more computationally expensive per operation.
Edit I've just woken up with another reason in my mind as to why you don't do this. See this link for this:

Linux kernel code and data are not swappable and are never moved to
swap.

So now you're forcing physical memory to always contain your bignum, RSA implementation and keys, leaving you less room for userland applications, forcing more swapping.
These are huge problems for the kernel. The kernel's job is to be as efficient as it can be. Very simple. This actually adds several other restrictions to kernel development, like having a fixed stack size and the fact that most of libc is considered excessive for kernel space. You also shouldn't use floating point operations in the kernel either. Let's be clear on what I'm saying: it is entirely technically possible to implement RSA in the kernel, but on a practical level, nobody does it because it is better off in userland, for which all these efficiency saving sacrifices are ultimately made.
RSA is also poorly suited to a block layer storage - before anyone starts, it is not obvious necessarily that this is a bad idea. Let's actually read the discussion I linked to last time. Directly quoting Thomas's answer there:

Nobody in their right frame of mind does such RSA-with-CBC encryption. Among the reasons are:

the construction has not received sufficient scrutiny to be deemed secure;
the size overhead implies that the encrypted message will be about 9.4% longer than the plaintext message;
RSA encryption is not very fast (a modern CPU would still succeed in encrypting, say, 2 MBytes worth of data per second that way).

This last reason is the most often quoted, but, in my opinion, the least compelling of the three.

I have dealt mainly with the last issue because that's the most obvious drawback, but assuming that's not a problem and you're happy with being relatively slow on a block level, then you've also got the fact that there's a large overhead per byte you want to store. Not a massively efficient use of your storage device.
I caveat all of this with if you want to do it, it is technically possible. There is nothing stopping you doing this at all. I'm only trying to actually explain why it hasn't been done.
So, that's RSA-per-block out of the way. As everyone else has got around to yelling, the alternative is to use RSA for the small amount of really valuable data - an AES or other symmetric key. This works. This is how TLS works. This is how PGP/GPG/OpenPGP and just about every other cryptographic protocol on the internet works. The idea is that you use slow RSA to encrypt the key, transmit it to the recipient (the only person who can decrypt it) and then you both have the symmetric key and can do high volume data transfer with a significantly reduced overhead, assuming correct usage of all the algorithms.
On why crypto and keys on the same OS is ok, but not perfectly safe
So, now let's talk about operating systems. Your computer is like a house with housemates in it and a live in landlord. The landlord is the kernel, the housemates are programs. Now, to achieve your system, Bob is you and wants to make sure this happens. So, he buys two safes and instructs Alice and Carroll to manufacture padlocks and also buy a safe each. He, meanwhile, invents a combination for one of his safes, sets it and puts the safe in the hallway. Now, to protect that combination, he writes it down and asks each of Alice, Carroll (and himself) to put a copy of that combination in their own safe and lock each of their own safe with their own padlock. So, to open the safe in the hallway, Alice must first open her own safe, to which only she has the key, then read the combination, lock her safe and go and open the safe in the hallway.
Eve is an evil housemate and is very angry nobody has told her what's in the safe. She can't enter anyone else's room, but she can persuade the landlord to do it, because he can go anywhere. She only needs to:

Observe the making of one of those padlocks.
Observe the code being written down for the safe in the hallway.
Observe said code being used, or whatever is in the safe.

Simple as that. The best bit from my original answer was this:

The battle for your OS is theoretically lost as soon as someone can get to root, or Administrator, simple as that

Now, by contrast, a network service works like this. Bob wants to post a message to George. So, he gets George to send him a padlock in the post. George lives with a landlord they both trust totally. So Bob sets the combination for the safe in the hallway and writes it down, puts it in his safe, puts Goerge's padlock on it and gives both to the postman. He doesn't trust the postman one bit, but he's not going to invite the postman in any time soon, just up to the door. Unless something he does on the doorstep gives him away, or unless there's a problem with the safe or the padlock, or unless the postman can persuade him to reveal anything, his message should get to George safely.
That is what I was trying to get to. Even if you use GPG, or a userland-based filesystem such as FUSE (totally possible) you must still trust the system you're making those keys and doing that encryption on. Otherwise, the best you can hope for is fairly hard to intercept.  You can use public key cryptography and symmetric cryptography together but they're not achieving what you think they are - even disk encryption as access control is worthless vs someone with physical access to your system; the only reason to use it is because it makes forensic analysis of your hard disk 6 months after you've chucked it away a lot harder.
Cryptography only works so long as the key and the data are separate. It's that simple. Which is why TLS across the internet works (because an attacker doesn't have the key) but crypto locally, where the key is going, at some point, to touch the system, doesn't. So, by all means implement an encrypted filesystem and protect the keys used to encrypt it with asymmetric keys. This is the most secure you can get with such a scheme, but:

Your requirement for write in all, read out one user will be enforced by the OS in terms of access control. There exists no current cryptography capable of doing this unless you do everything block-by-block RSA, which is slow and intensive relative to the hybrid implementation.
Nothing you can possibly do will ever be totally, 100% immune to root/Administrator/the guy who walks by your desk every day.


Is a passphrase-protected SSH private key susceptible to a dictionary attack? If I have a passphrase-protected SSH private key,

AND

if this passphrase is sufficiently random and long (say, 20-, 30-, 40-characters long, or even more!),

AND

if I make this private key of mine publicly available on the Net

THEN,

will it be practically possible for someone to be able to decrypt my private key from its corresponding public key (the latter being publicly available anyway).

My guess the answer is most likely going to be:

  "The decryption effort and time taken will be totally dependent on the
  length and randomness of the passphrase chosen, and there is nothing
  inherent in SSH authentication algorithms/protocols that would speed
  up or slow down the decryption effort. Thus, in the current
  state-of-decryption-art, a 20+ characters long passphrase should be
  sufficient enough.  Even Gmail et al are recommending passphrases much
  smaller in length."

But I'm not sure if this is the right answer, or if there are any other aspects to it that I need to worry about, etc.

If this SSH private key is really not practically decryptable, then I intend to protect it with a VERY long passphrase and then forget all about securing the key itself. I, for example, could store it in my Gmail inbox (letting even Gmail team see it), or even upload it on my personal website for my easy retrieval (say, when I'm travelling). Etc.

It is not the length of the passphrase which matters, but its randomness; namely, how much different it could have been. Length makes room for randomness, but does not generate it.

Symmetric encryption of SSH private keys is not very well designed; it relies on some old features of OpenSSL, which date from before password hashing was a properly understood problem. See this answer for a detailed analysis. Bottom-line is that attackers will be able to try potential passwords by the billion per second, unless you invest some effort into wrapping your key in a PKCS#8 object with PBKDF2 and enough rounds.

If you generate your passphrase as a sequence of letters, each chosen randomly and uniformly, you will get 4.7 bits of entropy per letter (because 26 is approximately equal to 24.7). To reach a decent protection level (say, 100 bits), you will need 22 letters... If you prefer to generate meaningful words, say among a list of 2048 "common words", then you will get 11 bits per word, and 9 words will get you to 99 bits of entropy. There again, each word must be chosen randomly, uniformly, and independently of the other words.

With PKCS#8 + PBKDF2 and one million rounds (OpenSSL would need some coaxing to produce that), you gain 20 bits (because 220 is approximately equal to one million).

Remember that remembering, indeed, can be tricky. You will remember a very long passphrase, but only if you type it often enough. If you don't, then forgetfulness is almost guaranteed. I suggest that you print your very long passphrase and store it in a bank safe (print with a laser printer, not an inkjet printer: ink from the latter can fade away rather quick). Or, simpler, cut the middle man and print the key itself on the paper which you put in the bank safe.

(*) Note: printing systems may keep a cached copy of past printing jobs. Removing all traces can be tricky. You could use a "manual printing" process with a pen and your hand... for really long-time storage, consider engraving on stone or some rust-resistant metal.


Absolute Software vs Virtual Machine If a laptop has Computrace/Absolute software installed and I host a VM there, would the Computrace/Absolute software be able to track whatever they track on the VM?

according to the press release: https://www.absolute.com/company/press-releases/2009/computrace-by-absolute-software-now-supported-in-firmware-of-getac-computers/

Computrace software is embedded in the firmware of computers right at the factory for tamper-resistance.2 The stealthy Computrace Agent is capable of surviving operating system re-installations as well as hard-drive reformats, replacements and re-imaging.

Absolute Monitoring Center, allowing the Absolute Theft Recovery Team to forensically mine the computer using a variety of procedures including key captures, registry scanning, file scanning, geolocation, and other investigative techniques to determine who has the computer and how it is being used.

Yes, it would have access to:

VM's virtual harddrive file
Dump of the computers memory ... which would contain the VMs memory
All Network traffic from either the Physical or VM

They might have to jump through a few hoops to do some of this ... but it wouldn't be far fetched for all of this to be possible if they are tapping the firmware itself.


How is a website determining my location even via VPN? I'm currently in China, and accessing the Internet via a VPN in the USA. When I access Google maps or other location-based web services, they all show my location as that of the VPN server. However, when I accessed a web site - http://www.ikea.com - the site redirected me to the local China site.

I've installed NoScript, Ghostery, set enable.geolocation=false, cleared all history and cookies, and verified that all traffic is sent via the VPN gateway, but despite all this, I'm always routed to the local site.

How is this being done??

Something isn't adding up here. I've tried so many combinations and I wasn't able to reproduce your situation. This leads me to believe that your VPN provider is leaking your original IP address.

1. I opened ikea.com using a clean browser (fresh portable Firefox). It took me to to the default locale selection page.

2. Using another clean browser, I opened ikea.com using a Chinese proxy, I was redirected to ikea.com/cn/en

3. Using the same browser from step #2 (to ensure that any detection cookies or configurations are preserved) I went to ikea.com using my normal connection. I was taken to the default locale selection page.

4. Again, I used another Chinese proxy and I was redirected to ikea.com/cn/en.

5. Finally, I tried a U.S. proxy, and I was taken to the same locale selection page.

You're either falsifying or withholding some information, or your VPN provider is somehow revealing your IP.

In all cases I used the same browser language configurations you're using

  My browser (Firefox) shows 2 languages: en-US and en.

Update:

I've just performed another test. Using my normal connection, I've disabled JavaScript to make sure that there's no JavaScript hocus pocus going on. Then I modified the HTTP Accept-Language header to zh-CN,zh. I was still taken to the locale selection page.

It's safe to assume that IKEA website is pretty dumb and it's only using the IP address to determine the locale.


Difference between stateful and stateless firewall filters Stateful filters keep a "list" of already established connections, and if the connection is being established, what step of the TCP handshake we are on (SYN, SYN ACK etc.). Stateful is supposed better at detecting faked packets.

Stateless filters don't keep a list. Every packet is processed in isolation, with no regard to the previous packets. Stateless is supposed to be better for processing packets faster.

How do they process UDP connections? I read somewhere that stateless filters can either be set up to block all UDP connections or let all of them through, which could be a major security flaw.

Can someone please tell me the major differences between the two?

You are right about the difference between stateful and stateless filters. As for UDP packets: this fully depends on the filter rules, i.e. they might be blocked or let thru depending on the rules.

But stateful firewalls also keep a state for the seemingly stateless UDP protocol: this state is only based on source and destination IP address and port and will time out after a while since UDP does not contain an explicit connection start and end. This state makes it possible to associate incoming UDP packets with outgoing packets and thus let incoming packets belonging to an outgoing state through. An example for this are outgoing DNS queries followed by the incoming DNS reply: a stateful packet filter can require incoming UDP packets to match outgoing packets while a stateless filter has no such information and thus cannot do such granular filtering.


Does Chrome OS Allow Executable Files? My company has some real security issues and I am wondering if using Chrome OS can be some solution to my problem. Typical Windows computers seems all to vulnerable to attacks from malicious images and websites which download keylogger software and remote access systems.

From my understanding, Chrome OS does not allow executable files. Am I correct? Will using Chrome OS computers help against attacks like those mentioned above (see bold).

By executable, you probably mean the .exe "executable" format that Windows uses to denote anything that contains a program. (Note that other extensions such as .com may also be executable, and it are not only executables that can get you infected; a malicious PDF does the job just as well.)

Any OS allows the execution of files, or else you can't do things like starting Powerpoint. You are right though that Chrome OS can't (by default) execute Windows' .exe files, but it's just as easy to make "binaries" (a more general term for executable files) for Chrome OS.

Chrome OS is based on Linux, making it vulnerable for pretty much any attacks that work on Linux computers, though it seems some things are sandboxed more than most other Linux distributions would do (see rakslice's comment). Many things in Chrome OS are done in the browser which makes it more secure, but this still doesn't eliminate all exploits. Migrating to Chrome OS would at least temporarily solve your problem since any attackers need to rethink their strategy, but it won't take very long. Windows, when used correctly, is a reasonably safe OS to use. The fact that you have real security issues (as you put it) hints at an underlying problem such as incompetence of employees (opening untrusted email attachments), bad patching, or something else.

If the attacks are by chance, e.g. when a user visits a website that happens to be infected, moving to Chrome OS (or any other Linux system) will solve your problem. In small organisations this might be an option, though in general I wouldn't advise to change the OS just because some employees happened to visit an infected website. Better install good anti-virus software, monitor workstations, limit permissions as much as possible, and setup a plan to perform when infections do occur. Something like: the computer will be taken off the network, the harddrive will be inspected and scanned in a safe environment, when the malicious part is found other computers will be scanned to see whether they have the same, and any infected computers will get a complete reinstall (shouldn't be too much work with system images and adequate backups).

If the attacks are targeted at your company specifically, you're in bigger trouble. Get someone on board with real knowledge of security, at least temporarily to get things under control. Targeted hacking attacks by professionals are hard to defeat and usually beyond the control of most sysadmins.


Evaluating hosting providers for CC development environment An organization that develops software that may be subject to security evaluations such as Common Criteria is looking to externalize part of its IT infrastructure, including critical components such as source control management (i.e. internal services, we aren't talking about a merchant website here). Or not, depending on whether an external provider can provide the desired security (for a reasonable price).

How can we evaluate whether a hosting provider would meet our security requirements? What questions should we ask, both regarding the security of their offer and what documentation they can provide that our use of their services would meet CC requirements? Are there any official or reputable guidelines for requirements on IT infrastructure at various EALs?

The "real" answer depends on where you intend to get your CC evaluations performed.  There has been a recent upheaval in the CC evaluations world with US and Canada (and Australia) in one camp, and most of Europe in another camp.  (I see from your uid that you may be in France.)  Specific schemes may have specific requirements.  You will need to contract with an evaluation facility anyway, so you might as well get that ball rolling.

The reason why the location is important is that the US/CAN market is moving to assurances at EAL2 and lower (and then they are going to get rid of assurance levels altogether).  At EAL2, the only two things in scope for "infrastructure" purposes are the configuration management system and secure delivery/supply chain.

The requirements for EAL2 are pretty modest and basically say that you NEED to have a CM system and the product and documentation has to be controlled within the CM system.  However, no demands are made on specific functionality other than to show that it is controlled (it doesn't even need to be automated for EAL2).

Now, in France, if I've correctly translated, the CC scheme (ANSSI: Agence Nationale de la Sécurité des Systèmes d'Information) appears to be continuing down the path of medium-to-high assurance certifications (eg. EAL4 and up).  At EAL4, there are significant security requirements levied on the development environment, tools, and the CM system.

The key, however, is that the CC is not prescriptive: it doesn't tell you what security functions you must have, only what the end result is (eg. it must protect the confidentiality and integrity of the product).  One of the key things to remember is that where the developer's measures are deemed less than adequate by the evaluator, a clear justification must be provided based on the potential for an exploitable vulnerability.

I suggest you first look at what level of assurance you are looking to achieve (usually a marketing decision more than anything else). Use this decision to determine which assurance components are going to be included (dependent on the scheme, of course): this grid is found on page 231 (table 24) in Appendix E of CC Part 3.  (For your situation, you are only interested in the ALC (Lifecycle) assurance class.)  Then, look up these assurance components in the body of the same document.  You are looking for the "Developer action elements" and "Content and presentation elements" such as ALC_CMC.2.1D and ALC_CMC.2.1C.  It helps to know what an evaluator will be looking for, so I urge you to read the Common Evaluation Methodology (CEM) for the same assurance components. Based on what you find, you'll be in a better position to formulate the right set of questions.  Many of these questions will be directed to your internal integration team, some will be questions about product features.  As an example, at EAL4, you need to have automated access control and build integration (eg. ALC_CMC.4.4C and ALC_CMC.4.5C) in your CM system.  However, you will also need an extensive "CM plan" describing how your development environment uses the CM system (ALC_CMC.4.6C).  This will be developed internally.

I would find it highly unlikely that you'll find a list of products that are "CC Ready(tm)!".  The reason is because CC is more concerned about the end result rather than how you get there.  Therefore, a spreadsheet might be an acceptable form of configuration management system for EAL2 as long as there are policies and procedures in place to ensure it is enforced.  This would not fly at EAL4.  Conversely, just because you use the Bells and Whistles Source Control Management System(tm) doesn't mean you will pass at EAL2, either because you might not track all of the necessary items.


My credit union is reducing its maximum password length to 10 characters I just received an email from my credit union saying they are redesigning their online banking service and that I will need to change my password by October 22 to conform to the new limit of 10 characters. The current limit is 20 characters.

This reduces the maximum password entropy from 125 to 54 bits (according to KeePass), compromising the security of passwords. More importantly, though, I fear that this is evidence the web architects behind this redesign are clueless about security.

Questions:

Am I getting worked up over nothing? Is 10 characters actually enough even if you are limited to letters and numbers?
If not, are there any regulations specifying or recommending a maximum password length for online banking services?
Can you recommend a reference on website security best practices I can send my credit union to bolster my case that 10 characters is inadequate?

Update

I contacted my credit union today (a Saturday) about their security practices, and someone actually responded to the email same day. Judging from the replies, it sounds like they have offsite vendors that handle passwords, the security question system, and the like, and passwords are encrypted and never stored as plain text. Also, they are now allowing passwords to contain symbols rather than just letters/numbers, so that slightly improves the maximum strength of a password over what I thought (though it's still a reduction from the original requirements). So, while I'm not entirely convinced that site security is optimal, it doesn't sound like a complete disaster. Thanks for all the advice and feedback.

WARNING: Do not change your password!

This seems exactly what scammers would do to trick you into giving them your password.
Do you really think your bank would send a message like this on Friday with a deadline just over the weekend so there is no chance for you to call them for verification?


How to backup my new laptop after I caught a hacker/identity theft in action without losing all of the evidence when I erase to factory default How can I backup my new laptop after I caught a hacker/identity theft in action without losing all of the evidence when I erase to factory default.

I literally just bought the laptop. I can not afford it because of an identity theft has taken everything from me and it took me one day to catch them already getting in just as they have all my phones , etc. I need to restore the PC to factory default and return it immediately so I can live a while being able to provide the authorities with information of the attacker?

Magic-sudo's idea of making a 1:1 copy of the hard drive is good and basically feasible - this is what a digital forensic analyst would probably do as a first step in order not to mess with the actual laptop. You can achieve this with a Linux live USB stick and the 'dd' command. The next thing he'd do is calculate the fingerprint of both the original laptop HD and the copy, to prove that they're identical.

BUT - if you then reset your laptop to factory default, YOU'VE LOST YOUR PRIMARY EVIDENCE. Digital forensic analysts go through all this trouble of copying the device data so they don't need to touch the actual evidence, which could corrupt the evidence otherwise. they need the original to remain untainted so any evidence they find can be independently verified by other analysts if necessary. If you wipe your laptop, you still have a digital copy of the hard drive, but it will be impossible to prove that this is a copy of the state your laptop hard drive was in right before you factory-reset everything if you don't get some kind of legal certification that it is, before you factory-reset. It might even be impossible to prove that the copy you made came from your laptop at all. Basically, you break the chain of evidence if you do anything else than turn your laptop over to the police as Terry suggests.

So you'll have to decide what's more important: Have a chance to bring your identity thief to justice (which will probably be very difficult, but depending on what evidence is on your laptop hard drive, it might be possible), or get back the use of your laptop immediately. If you turn it over to the police, you should probably forget about getting it back anytime soon.


How to update table with sqlmap and without stacked queries? down vote
favorite
I'm trying to use following code

sqlmap -u "http://exp.com/portal/pd.jsp action=edit&info=products&sub_info=price"
--cookie="JSESSIONID....." --dbms Oracle -D PRODUCTS -T PRICE --threads 10
--sql-query="UPDATE PRICE SET PRICE ='100' WHERE PRODUCTID LIKE '7534' AND PRODUCTCODE = '73546'"

I checked this link before and it is injectable in info parameter (boolean-based blind). the result of execution of above code is:

warning: "execution of custom SQL queries is only available when stacked queries are supported"

Is there any workaround in order to do this?

This website is running on Apache, JSP and Oracle.

No workaround here. You can usually dump the entire database with a boolean based sql injection vulnerability but you cant perform updates.

You can extract but cannot insert or modify existing data.


Why is public free Wi-Fi available even though many people say it's dangerous? There's a long dispute across the Internet community about the risks related to free public Wi-Fi. Some information security-related Web sites which look rather trustworthy even say that you should never use public WiFi because of the risks. But on the other hand, governments and companies like Facebook and Google are going about installing free WiFi nodes across the world, including in developing countries like India.

Is there a larger purpose to it? Are these WiFi spots capable of tracking people even if the WiFi on their phones are switched off? I remember when working in a company that required us to install a Blackberry BYOD software to disable phone cameras in the company, the WiFi on my phone used to get switched on automatically even if I switched it off. On officially questioning the company if they were monitoring us, I got no response, but the WiFi switching on behaviour stopped immediately.

So is a public WiFi inherently dangerous? And if it is, why is it being made available to people in the first place? And if it is not, then why?

The companies providing free WiFi are doing that usually for one reason: Profit. And that is usually done by

Make people stay at their place
Make their place attractive (for tech
users)
Create a modern image of themselves

And risk is not a big issue for the users as well as for the company, because the just are not aware.

And as the biggest risk is the access point itself (which is owned by the providing company) as it has the ability of a MitM, the company will perhaps not perceive it as a risk. (Because they trust themselves)

Organisations usually also overestimate their abilities. So there are also risks by poor configuration (e.g. network devices can communicate with each other; faulty encryption -> here even other users can interfere network packets).


Finding the company name by the AWS IP address Is there any way to find out company/domain name of the company name by a given AWS IP address owned by them?
nslookup and centralops.com will show only indicate the IP is on AWS.

With an IP alone it will be difficult.

What you can do is gauge the IP Range. If it's a company they might own a range of IP Address and not a single one, you can try to increment/decrement the IP you know and reverse lookup it. The goal is to fetch a domain name.

This approach is approximative, and you will never be 100% sure of the result.

Well, it's possible to push the IP investigation further, but that include the use of illegal techniques, so i will not recommend it nor state how to proceed.

On the other hand if the IP is attached to a domain name it can be done pretty easily with a bit of luck. In a legal way.

(Like @Schroeder stated, keep in mind that if it's a shared IP it will be nearly impossible.)


How do atom's apm and npm verify package integrity? Are there built in verification methods to make sure the packages contain the correct code? Do they use a hash of some sort?

According to npm issue #6886, there is a system for validating the contents of packages via any checksum or hashing system.

Quote from GitHub user othiym23:

  npm has included validation of the package tarballs, via their SHA-1
  digests, since pretty much the beginning. It's worth pointing out,
  though, that this is intended as a verification measure to ensure that
  the package tarball has been correctly downloaded from the registry;
  it's not meant to protect against substitution attacks.

So, while the data is verified to be the SAME data that came from the npm server, there is no way of validating whether or not the code being delivered from the server is the code you expect (e.g. no system in place for validating the package with your own trusted hash).

There appears to be some checking of validation in the source code, however, the source also reveals that there is NO integrity validation for Git repository based npm package fetches.

You can find the logic for this condition on line ~120 in this file.


Trust and signing: full public key or thumbprint? Imagine a B2B service where two parties need to set up a two-way trust relationship: Alice will only accept requests from Bob, and Bob wants to know his requests are only going to Alice.

When setting up this relationship, Alice and Bob need to exchange their public keys. But when it comes to verification, is it enough to verify that the certificate thumbprint matches? Or, should Alice and Bob exchange the full public key?

A public key is quite long, and a thumbprint is short, so the thumbprint is more convenient. But since it is shorter, does that mean it has a higher chance of collision?  How much safety is lost by only using the thumbprint to identify the caller rather than the full public key?

This page, for example, suggests that the thumbprint is fine for verifying. Can anyone confirm?

And if the thumbprint is enough, why do services like Github expect you to upload your full public key instead of just a thumbprint when establishing trust?

A hash of the public key is enough, provided it's long enough(I'd recommend 160 bits), and the hash function is resistant against second pre-images.

I guess github wants full public keys because their SSH library expects that. There are also some situations where it's useful to have the full key available. For example you can offline encrypt a message to a certain public key, but not to a hash.

The decision hash vs. public key isn't a decision based on security, but on which one is more convenient for a particular use.


How to configure Tiger security scanner I'm running an Arch linux machine and want to run a scan using this tool called Tiger. I saw this video where the guy teaches to install it and run. In the video it ran normally after installed. In my case, when I run it gives me the message:

  --ERROR-- [init002e] No 'config' file in `.'.

How to setup it? Thanks in advance.

I kinda solved the problem by reinstalling it from its repository instead of using arch linux package manager. First I uninstalled it then

git clone git://git.savannah.gnu.org/tiger.git
./configure
make
sudo make install

Then it created all the necessary files to run.


Network security from the inside Yesterday I heard some people talking about not allowing users to RDP into servers they shouldn't and such which got me thinking about my companies network and the security of it.

Can someone point me in the right direction in regards to best practices for isolating and locking down machines? Do you create access control lists and apply those to the VLAN?

Our server network comprises of 4 physical VMware hosts with about 60 VMs. Some web servers, some database servers, terminal servers, email, ... . All servers are on one VLAN, user workstations/devices on another VLAN, guest traffic on another VLAN, security system on another VLAN. Then each VLAN then has its own IP scheme that relates to the VLAN such as x.x.10.1/24, x.x.20.1/24, .... .

Is it better to separate servers based on what data is on the server such as all SQL servers in one VLAN, web servers in another. Then apply an access control list to that VLAN that only allows certain ports in/out?

The Good Practice Guide 13 (gpg13) recommends a number of  controls for baseline protective monitoring and information security measures. Also have a look at the link belows for some network security good practice guidelines.

These should provide a baseline to aim for. They will need to be tailored to your environment and compliance needs.You may want to look at hardening guides for servers and clients as well.

Have a look at these links. They both offer general primers and pointers in how to secure your network and the information flowing over it. Hope this suit your needs better.

Guidelines on general information Security;

10 security best practice guidelines for businesses

An article about network segmentation;

Improving Security via Proper Network Segmentation

  Regulatory Guidance and Best Practices

Standards such as PCI-DSS provide guidance on creating clear separation of data within the network – in the case of PCI, cardholder data should be isolated from the rest of the network, which contains less sensitive information. An example would be to ensure that  Point-of-Sale (PoS) systems and databases are completely separated from areas of the network where third parties have access. In this example a PCI Zone would be created with stringent constraints allowing connectivity for as few servers and applications as possible.

Routes to Achieve Proper Segmentation

Firewall and VLANs provide a route to partition the network into smaller zones, assuming you have defined and are enforcing a ruleset which controls the communication paths. A sound security policy entails segmenting the network into multiple zones with varying security requirements and enforcing a rigorous policy of what is allowed to move from zone to zone. Anything designated in the PCI zone, for example, should be isolated from the rest of the network as much as possible – without impacting the overall business.

Here are a few, but not an exhaustive list of tips to consider:

•   Implement controls at multiple layers within the network architecture. The more layers you can add at each level (e.g. data, application, etc.), the harder it is for a cybercriminal to gain unauthorized access to sensitive information. Of course this has to be manageable from an operations standpoint and it can’t be to the point where business processes come to a grinding halt.

•   Apply the rule of least privileged. For example, a third party vendor may need access to your network, but they most likely don’t need access to certain information. Access should only be provided to the user or system that is absolutely needed and nothing else.

•   Segment information access based on your security requirements. Define your different zones based on where your sensitive information resides. For example, you want to make sure that sensitive information isn’t easily accessible by a third party that has no need for this access. Take a step back when looking at your network architecture and determine if there’s unnecessary access or too restrictive access in different places. You may be surprised by what you see.

•   Leverage a whitelist or hybrid approach. Instead of trying to block all of the bad things out there, which puts you into a never-ending game of cat and mouse, define what you know to be acceptable communication paths and block everything else.

By Nimmy Reichenberg of securityweek.com


Is it true that encryption bit "strength", although numerically identical, may actually be different depending on the algorithm? I was reading recently that for AES, the encryption strength is actually the key size/length, so 128-, 192- or 256-bit. While, for SHA-2, the encryption strength is measured against the message digest hash. Is there some sort of an easy breakdown that lists for each algorithm and type, how the strength is measured or determined? It gets even more confusing when I read something like this on Wikipedia:

  For example, Triple DES has a key size of 168 bits but provides at
  most 112 bits of security...

The general point of cryptography and enciphering of information is to increase the difficulty for anyone other than the intended recipient to retrieve any part of the information (or data) in transit or in storage.  Increased difficulty makes it less likely that an adversary will be able to make sense of any part of the enciphered data.

What many people take for granted is how time influences the value of data.  Data (information, secret recipe, etc) generally loses value over time.  For example, corporate merger communication is generally seen as more valuable today than after the fact.  With that said, there are data that does not lose significant value over time.  In such cases, the relative strength of the cipher becomes another variable for consideration.

The strength of a symmetric cipher can be tied to several things.  Key size is one that most people understand.  For example, DES uses 56 bit keys, AES has several flavors (128, 192, 256).  However, key size is one component of the strength of a cipher.  The implementation of the cipher is also an important consideration.  Additionally, implementation details also factor in.  Block ciphers and stream ciphers are both modes of operation for a symmetric cipher and there are weaknesses that affect different modes of operation.  Additionally, adversaries can attack the implementation of a cipher and reduce its effectiveness.  TDES providing 112 bits of security is one such example.  AES 192 is another example due to the implementation of key expansion function.

A good illustration of a cipher where key size doesn't correlate to strength can be seen with asymmetric ciphers.  Most asymmetric ciphers are based on the RSA algorithm with common key sizes of 1024 and 2048 bits.  ECC is a newer cipher with much smaller key sizes than used with RSA.

So there's no one measure of the strength of a cipher and the passing of time usually renders ciphers less useful.  As time passes, there will likely be additional attacks against current ciphers that render them less useful.  However, even if no such attacks are successful, as technology improves, brute forcing the cipher becomes more affordable and a new round of algorithms to protect data will be developed.

Hashing is a completely different function than encryption.  With encryption, you want to be able to scramble the data but still have the ability to unscramble it at a later point.  Hash produces a fingerprint of the data and is used to demonstrate message integrity (i.e. contents have not been changed).  A hash of a data (SHAy, MDx) usually accompany the data itself.  An email message might come with a hash such that the recipient can validate the message has not been altered.  The message can be visible to anyone in-transit or in storage.  There are other uses for has values alone (DLP, AV, FIM), but adversaries are more interested in how to modify the source data to produce the same hash value - to bypass message integrity.

Though larger output bit sizes may increase the difficulty of a collision, it may become possible.  For example, if the email authorizes a contract at $100K but you're able to change the 'K' to an 'M' and still retain the same hash output, you've defeated the value of the hash (someone was able to tamper with the message and you weren't able to determine that someone did tamper with it).  As with encryption, an adversary can attack the hashing algorithm, or the passing of time and increases in technological sophistication may make collisions more common.  At which point, there will be a new round of algorithms.


How does "Microsoft domain authentication" prevent me from using passwort variants? I have read Sequential password updates and I am aware of a number of techniques to prevent users from using password variants. My question is, which of these techniques are actually used in user authentication in a Microsoft domain server? I am no expert in server software - what I mean is the (supposedly) common backend to user administration and authentication of login attempts to domain user accounts with Windows, Outlook, Outlook Web Access, which all seem (be able to) use the same data and enforce the same password rules, including prevention of re-use of substrings of historic passwords.

Is any hard information available from systematic tests? Has source code been leaked that drives this prevention of variations? Or what else is known? E.g., how many, or for how long back, are old password hashes stored? Which variants are pre-hashed and stored along a new password? What of that is fixed, and what is configurable by the administrators?

Background: I am an interested user fed up by having to change my password every 90 days without any reason. IT admins won't admit that's a nonsensical idea, despite recent NIST recommendations. It's not a terribly important account, so of course I resort to using password variants. I simply want to make my life easier by being able to predict which password variants are allowed - I typically spend 10-20 minutes in a quarter coming up with a new variant that's allowed.

Windows domain password complexity is enforced by group policy, full info on what the 'password complexity' requirement means in windows is available here:
https://technet.microsoft.com/en-us/library/hh994562(v=ws.11).aspx

but here's the highlights:

May not contain your username (the one you login with)
May not contain any part of your full name (There's a whole paragraph on the technet page defining what a 'part' means)
May not be one of X old passwords (the number X is configurable by admins)
Must be at least X characters long (number X is configurable by admins)
Must contain 3 out of 5 of the following categories

a-z (lowercase alphabet)
A-Z (uppercase alphabet)
0-9 (numerical)
symbols/non-alphanumeric characters (!@#$%^&*, etc.)
extended Unicode characters (Chinese/Japanese characters, etc.)

Unless they've implemented a third-party solution there's no 'substrings of old passwords' option. My recommendation if you're interested in using the NIST passphrase recommendation, I'd choose a new passphrase each quarter, and then add on an numeric/symbol end (which can stay the same quarter to quarter).

e.g.

q1 : Jumpingtheshark382##@

q2 : Talktothehand382##@

q3 : He'sgoingthedistance382##@

etc.


Web app with iframe and user - how to deal with session? We have application which will be in iframe. Partner sites can use our application - put iframe in their sites.

Partner site has users with money, who will use our application in iframe to buy items. Iframe needs communicate with partner site.

For example user buys item. Our app creates a record about sold item in database.

Then it sends request to partner app - so the partner would know that his user bought an item, and could reduce his money in the account.

User does not have to login to our app, it only has to login to partner application - parent site and use our iframe as logged in.

How is this done in secure way? I know there is site which does that without visible tokens in ajax requests, so there is probably some session in the child app. Session, not requiring username and password.

I would like to get some tutorials with schema. Tried to search but not even sure how to make keywords for such question.

Update

What about this, are you seeing what could be potentially insecure? :

When partner page is loaded, there is iframe and in get parameter token is passed to iframe, like <iframe src='www.shop.com?token=12345'><iframe>

Iframe on load in server side - requests new token from the partner site passing as parameter the token which is in url as $_GET parameter.

That way the token in the iframe url get parameter becomes invalid, so even when user see it, he cannot do anything.

New token which is received in iframes server is saved in session.

So now from client side - when client buys and item in iframe, he does not need to pass token in request, because it is in session.

Iframe server when receives request, does buy item and send request to partner server info about buying item, so the partner could reduce the money. In this request token is is passed to partner server from session.

Partner server recognizes the user by token and reduces his money in the account.

First, it's not a good idea as far as I know to put a secure application in an iframe because that expose you to security issue. The biggest one is probably clickjacking if all else is done correctly. This is why you want to use the header option X-FRAME-OPTIONS to block it from loading in an iframe.

Next, you want to communicate between the partner site and your own site, in the iframe. The communication between the 2 is very limited because of the same origin policy. If 2 websites, don't have the same base url, which means they don't have the same origin, can't directly talk together. Which is a very good thing or you would have big security issue.

  User does not have to login to our app, it only has to login to
  partner application - parent site and use our iframe as logged in.

This assume that you trust every partner site at 100% since they have all the information needed to log in to your site. Is it the case?

The type of login you are trying to do is similar to OAuth, where third party are granted partial access to your site in order to access some information. It's not exactly what you want to do, but I would look at how it's done.


Is there evidence of Shellshock being exploited before its public announcement? The Shellshock vulnerability was about 25 years old when it was publicly announced. Has there been any evidence of it being exploited in the wild before its "official" public announcement?

In summary, no, there are no official reports of shellshock being used prior to its disclosure. Although, that certainly doesn't confirm the negative.

From Sidney Morning Herald

  Whether intelligence agencies or others knew of  its existence remains
  unclear and is unlikely to be confirmed. But Ty Miller, of Sydney firm
  Threat Intelligence, noted reports that the US government allegedly
  knew about the Heartbleed vulnerability for many years before it was
  discovered.

  "I would be amazed if governments haven't known about and exploited
  systems with Shell Shock for years," he said.

From Heartbleed

  Can I detect if someone has exploited this against me?

  Exploitation of this bug does not leave any trace of anything abnormal happening to the logs.

  Has this been abused in the wild?

  We don't know. Security community should deploy TLS/DTLS honeypots
  that entrap attackers and to alert about exploitation attempts.

So, as far as I know, there is no evidence of the state using heartbleed before it's disclosure, even though it is widely known that they knew of its existence.

However, that the state may or may not have known about the vulnerability is where the comparison ends.
Shellshock does leave a log-trace However, once owned, logs are trivial to wipe.

Wikipedia Shellshock

  Within an hour of the announcement of the Bash vulnerability, there
  were reports of machines being compromised by the bug. By 25 September
  2014, botnets based on computers compromised with exploits based on
  the bug were being used by attackers for distributed denial-of-service
  (DDoS) attacks and vulnerability scanning

Obviously exploits were created after the release of CVE-2014-6271 (Shellshock), but is impossible to tell how much administrator-awareness contributed to shellshock's blame for their compromise. If I was malicious, and had a tool like shellshock in my hands, that is not something I would be using frivolously. It's not the kind of vulnerability that a malicious actor wants noticed. I would certainly wipe the logs. But if knowledge is already out there, and scripts and vulnerability scanners are widely available, covering tracks becomes less important...or maybe someone hasn't given them a script to do that.

But, Stephane Chazelas should have the last word:
How did you find shellshock?

  In any case, I didn't find the bug by observing exploits, I have no
  reason to believe it's been exploited before being disclosed (though
  of course I can't rule it out). I did not find it by looking at bash's
  code either.


Password protect an internal hard drive in a shared Windows PC where all users are administrators It is a laptop shared by my lab. Today I use it, another day one of my student takes it on a field trip. I have 3 hard drives. I wanna leave 2 hard drives for my students and 1 for myself. On my hard drive, I have all my stuff. Students have admin access since they need to install programs, run scripts, etc. Is there a way to password protect my internal hard drive so that none of my students (i.e. other administrators) can access my files if logged in on their account?
EXTRA INFO: My stuff is backed up on Dropbox so I do not care if they wipe the drive out. It is a Windows PC.

There's a concept in threat modelling called spheres of control. A sphere of control is effectively the things in a system that a particular actor has control over. Actors are usually people with different roles, such as unauthenticated users, logged in users, administrators, etc., and each of these has their own sphere of control. If you think about how these spheres overlap, or might overlap, you can better understand what resources each actor has access to (or at least should have access to) and use that to identify where your risks might be concentrated.
You have one sphere for everyone. You, the trusted user, have persistent admin access on an OS and they, the untrusted users, have exactly the same level of persistent access. No matter what control you put in place, they can circumvent it, because you have the same sphere of control as an untrusted user.
For the purposes of my answer here I'm going to ignore the potential for hardware modification. While they're technically possible, your students probably don't have sufficient motivation and resources to implement such attacks, and if I included them in the threat model my answer would be much more complicated and bleak.
What you need to do is create two separate spheres of control, and enforce the separation with a security boundary. If the students require administrative access on the OS, you cannot enforce separation between you and them on that OS. To demonstrate why this is the case, imagine the scenario in which you use full-disk encryption (FDE) such as BitLocker, LUKS, or VeraCrypt in order to encrypt the data on your drive. You hand the laptop off to a student, with your disk encrypted. They can't unlock the drive because they don't have your password, but they can install a keylogger on the system and steal your password the next time you unlock the disk.
One way around this is to install a second copy of the OS onto your hard disk, then use FDE to encrypt it, resulting in a multi-boot system where students get access to one "dirty" instance of the OS, and you get access to a "clean" instance of the OS. When the system boots, the POST or bootloader gives the user two options to boot from, and they cannot boot from your copy of the OS without knowing the FDE password. The FDE password entry is done outside of the OS, so it is outside of the students' control sphere. This creates two separate spheres of control with a strong security boundary that is (given certain caveats) outside their sphere of control.
You can improve the security of this approach if you use a TPM with your FDE, to prevent brute-force attacks, and enable Secure Boot to prevent manipulation of the bootloader and preboot authentication binaries. This is made more difficult to mess with if you apply a BIOS administrator password.

Regarding setting up FDE, you've got a few options. If you're using Windows 10 Pro you'll have access to BitLocker, which is the most convenient. Unfortunately it isn't available on Windows 10 Home edition.
To enable BitLocker on a data drive (i.e. a drive that the OS isn't installed on) you can just type BitLocker into the start menu search and then click "Turn BitLocker on" on the fixed data drive you want to encrypt. By default, when you start the computer the drive will be locked, and when you try to open it in Explorer it'll ask you for your password to unlock the drive. You can later right click the drive and lock it again. It's a manual process, although obviously it locks the drive automatically when you shut down the computer.
One important caveat is that when you unlock a drive, it is accessible by all users that are logged on. So if you're logged in and have unlocked the drive, then hand the laptop to a student who uses Switch User to also log in at the same time, they'll be able to read the unlocked disk. You should lock the disk manually or shut down before giving them the laptop.
It's worth noting that BitLocker may present you with an option to automatically unlock the drive on startup. This is usually used for situations where you want to have a data drive encrypted as well as your OS drive, but don't want the inconvenience of having to manually unlock the drive on startup. Unfortunately this cannot be done on a per-user basis, so you shouldn't choose this option in your situation.
If you don't have Windows 10 Pro, and therefore don't have BitLocker, you could use VeraCrypt instead. Launch VeraCrypt, click Create Volume, pick "Encrypt a non-system partition/drive", select "Standard VeraCrypt" volume, click "Select Device...", pick the partition associated with the drive you want to encrypt, then choose "Encrypt partition in place". You can then pick your password and encrypt the volume. When you want to unlock it later, you just launch VeraCrypt, pick the partition to mount, and unlock it with your password. The same precautions apply as with BitLocker in terms of giving students access to the laptop while the drive is unlocked.


VPN - Tor: can VPN provider see the data? If I switch VPN on, then use Tor browser, can the VPN provider still see what is passing through Tor?

I am thinking it can't, right? Because the Tor browser encrypts the data into the Onion layer before it sends to the first node?

Between your Tor client and the guard node, the communications are encrypted with three layers of AES128. The first layer is a key shared between you and the guard node. The second layer is a key shared between you and the middle node. The third layer is a key shared between you and the exit node. Each layer provides 2128 possible combinations of keys. Simple math dictates that 2128×3 equals 2131, so the three layers total up to the equivalent of 2131 possible keys.*
Assuming you are using Tor browser correctly so you are not leaking DNS, the VPN will only be able to see your IP, the IP of the guard node you are connecting to, and the encrypted communications between you and the guard. In order to break them, it would have to either brute force at most 2131 keys (on average half, or 2131/2 keys), or break the algorithm used to exchanged keys safely, called curve25519. This would require either a major breakthrough in mathematics, or a breakthrough in cryptoanalytic quantum computers. Neither seem likely to appear in the near future, and if they are, they are the kind of things which will be used by FVEY (NSA, GCHQ, etc), not by petty commercial VPN providers who want to snoop on your data.
To answer your literal question: no, the VPN cannot see your data. It only sees encrypted data between you and your guard node.
However, you should be aware that, while Tor is very secure, there are theoretical attacks against it which an actor between you and the guard node, or the guard node itself could pull off. Most of these are termed traffic analysis attacks, because, while they don't involve decrypting the data directly, they involve finding loopholes that end up discovering what the data is without actually finding the encryption key. Tor does have many defenses which makes this more difficult, far too many to name exhaustively, such as padding data into chunks of exactly 514 bytes (previously 512 bytes). However they are not perfect. It is very unlikely that your VPN will be able to pull any of these off, as they often require additional attacks against the entire Tor network.
* There's also a separate TLS connection between each node, which a VPN provider would also have to break.


How does the Whatsapp web client synchronize with the mobile application keeping all E2E? How is it possible to maintain an E2E communication while using the whatsapp web client? I've found different Q&A ( f.i. How does end to end encryption work with whatsapp web? ) but nobody completely resolved my doubts.

How does the web client synchronize itself with the mobile app? How are the messages sent to the browser session initially? What's going on when I write a message in the web client in order to maintain all the communication E2E?

It wouldn't make sense to make complete end to end encrypted system between two web clients because in that case the data encrypted/decrypted by web client will not be readable by the mobile client and vice versa.

To avoid this, there is a protected channel created between the mobile and web clients. The mobile clients will execute end to end encrypted chat service with each other and generate different key pairs to talk with the web clients. So the message can be read/generated by both (mobile and web) clients.

The answer that you are referring to already gives the technical ideas as to how it is implemented. I will just add a flow for you to understand.

Accordingly, say user A and B are communicating via whatsapp. Then the way the end to end encrypted chat will work is:

A's web client <-protected-> A's mobile client <-E2E-> B's mobile client <- Protected-> B's web client.

[Paraphrasing parts from the answer referred in the question]

  How the web client synchronizes itself with the mobile app?

Initial setup is done when the mobile client scans the QR code of the web client. After that, it is simple client server architecture where the mobile client acts as the server. All the messages are readable to the mobile client.

  How messages are sent to the browser session initially? What's going on when I write a message in the web client in order to maintain all the communication E2E?

Once a secure connection between the web and mobile client is established, that is used for all the communication. Again, it is not end to end encryption between the two web clients. The mobile clients can read all the messages. So the end to end encryption is between the mobile and web clients. Then there will be another end to end encrypted channel between the mobile and web clients.