Temporarily save failed logins password hashes for using against brute force attack My question is about online brute force attacks, that try to authenticate in the website.

1) For the first case if the requests are coming from the same ip, I think this are relatively easy as after some failed attempts we can block the ip for some time or show a captcha, or increase the delay between login attempts etc.

2) second case, lets consider the attacker is using proxy, making requests from different ip addresses, but targeting a specific account, not sure what is the best practice here, but maybe showing captcha only for this account if there were many failed attempts from different ips, or maybe considering the user's whitelisted ips. Also warning somehow the account owner as well, that were failed logins
https://www.owasp.org/index.php/Guide_to_Authentication#Architectural_Goals

3) Anyway, I think the above 2 attacks are more or less possible to find out. But for the third case if the attacker is using multiple ips(lets say thousands or more) targeting different accounts, but using the same password, as there is a higher possibility that at least one user would have that password. In this case if the attacker is making a few requests per IP during a reasonable time, perhaps he could check thousands of accounts for that chosen password without being noticed/blocked.

Now, what are the pros an cons of temporarily, lets say at the level of hours or days, save(in the database) the password hashes of failed login  attempts(with a single application - side salt), and if the password was requested a lot during the last x hours/days require a captcha or some other kind of defense, before even checking the password.

Also, lets consider that password policies are applied during registration, for example, min 6 or 8 characters long passwords, disallowing the usage of well known passwords. Also, for usual password hashing im using unique salt per user(and using either blowfish or sha512), but want to use single salt for failed passwords and sha 256 or 384 to be faster.

thanks

The answer will completely depend on how you define your threat model and what your risk appetite allows.

Since you already went so far as to identify the potential attacks in a fair amount of detail I'd assume that you believe these are credible and possible threats that you face. If it is not the case then there should be no reason to try and protect against a them.

Pros

As you correctly point out, temporarily storing the hashes of failed
password attempts could potentially give you the necessary data to
more effectively detect an attack as described in scenario 3. If this
process can then require a captcha prompt or some second factor of
authentication you will most certainly hinder the attempts of the
attacker enough to make the attack impractical.
You could potentially learn a lot about the nature of these attacks from the data gathered, like the type of passwords the the attackers attempt and how they cycle through them (simple brute force vs. dictionary attacks). This however is more an academic gain than it is directly related to the security of your system, although you could identify long term trends that could result in better identification techniques in future.

Cons

The main consideration you will have to make here is if the tradeoff of increased security vs. extra resources and processing required is worth your while. This is due to the fact that comparisons you intend to make can be very computationally expensive and could require a significant amount of extra resources (depending of the size of the system and the amount of log in attempts you expect to receive).
I suspect the comparison you intend to make in order to identify these attacks outlined in scenario 3 in not as straight forward and simple as it seems at first. Firstly, as stated before, you might need some more resources in order to store and compare the hashes of passwords. In your description of scenario 3 you assume that the request coming from various IP's will all attempt the same password across as may accounts as possible at a time. This will mean that you won't be able to process each log in request in its own right but rather that you will have to evaluate the the log in attempts as a batch to be able to see that there are multiple log in attempts on various accounts using the same exact password. Remember that a legitimate user might be attempting to log in coinciding with the attack and that the whole batch of log in attempts will have to be queried if fowl play is suspected. This could lead to a degraded experience form the user perspective if it happens often. It will also be difficult in determining how long a specific hash will need to be stored after it was flagged as an artifact of a specific suspected attack. You cannot keep the hash in there indefinitely since it could be the hash of a legitimate user's password that will then continually be queried and this could lead to you in essence "DDoS'ing" your own system. If you do decide to implement a system like this only trail and error over time will be able to indicate how it should be configured in order to work effectively without being too much of a burden.

If your aim is to protect your users and their data on your system rather than specifically identifying these attacks, I'd suggest you look at rather implementing (possibly even requiring) a multi-factor authentication mechanism. Educating your users as to the threats you face and the benefits of using multi-factor authentication to protect them could be a much better approach to securing the system with much less friction and effort from your side.


How to convert http site to full https? I have a site running only with http. I have decided I want to go full https, but I have no idea how to do this.

Do I have to buy that certificate somewhere? Where, how much does it cost?
Does it involve changes in my actual code? Forms, ajax, etc..
Do I have to change something in my server config? What, how, where?

I'm running PHP, I have ftp access to files on server, I can use Parallels environment in browser to change some things on servers...

You can get a free class-1 certificate from https://startssl.com (I have no affiliation with them other than using them for my free SSL certificates).  It's not the most user friendly experience, but it gets the job done for free -- note the free certificate will only last a year (and doesn't offer features like wildcard certificates for free).  There are plenty of other sites that offer more features at other price points.
Not really, with a few exceptions.  If you ever hard code a link as http:// in your site you need to change it to https:// or just have it as a relative link or use //www.example.com (which will be equivalent to http://www.example.com if you are on an http page, and https://www.example.com from an HTTPS page.  This also applies to things you may forget, like embedded content - images or CSS or JS files loaded off of a CDN.  You also probably want session cookies to have the secure flag enabled.
Yes.  Will depend on your webserver.  Will have to enable SSL running on port 443, select the ciphers you want to allow, point your webserver to your CA-signed certificate as well as the associated private SSL key.  You may need to add the intermediate SSL certificates to your chained SSL certificate.  There are plenty of guides and tutorials out there; e.g., here's one for nginx.  You will want to find a good selection of ciphers and SSL/TLS to allow.  Mozilla maintains a list of recommended ciphers here, I suggest you use it.  A good way to test your configuration is this SSL testing tool.  You also may want to turn on HSTS (if your site will only be served over HTTPS in the future; this prevents it from being served via HTTP in a MITM attack).  You also should set it up that when tries to go to http://www.example.com/some/path that it automatically redirects to https://www.example.com/some/path as appropriate (and should choose whether this is a permanent redirect or temporary one).


Do I always have to overwrite EIP to get to write on the stack in a buffer overflow? Do I always have to overwrite EIP to get to write on the stack in a buffer overflow? How's the memory organized? I can't find a proper graph with google

You don't always have to overwrite the return address in order to exploit a stack based buffer overflow (also has a great diagram of the stack layout).  With a stack based buffer overflow you can corrupt other variables declared in the local scope of the function which can produce interesting results.

For instance lets say there is an authentication funcation:

//I like to think of the return address as sitting on top of every function.
//void * ret;
boolean login(char * password){
  boolean is_logged_in=False;
  char buf[5];
  strcpy(buf,password);
  if(strmp(buf, MASTER_PASSWORD)==0){
     is_Logged_int=True;
  }
  return is_logged_in;
}

The stack layout is such that is_logged_in is above buf.  The stack frame,  which contains the return address is somewhere above is_logged_in.   The return address will become the EIP only when the function returns.  But it isn't necessary for the attacker to corrupt the stack frame in order for the attacker to take advantage of this buffer overflow.  Simply overwriting the value of is_logged_in with a value that equals True will allow the attacker to authenticate without knowing the value of MASTER_PASSWORD.

In this buffer overflow vulnerability, the use of: ASLR,  NX Zones, and Stack Canaries does not prevent exploitation.  In fact it is also likely that the same exact exploit will work regardless of platform (windows/linux/arm/x86...).

(Disclaimer:  I think I read about this exploitation method in "Hacking: The Art of Exploitation")


OpenVas remediation cipher suites This is my first time running a vulnerability scan software like OpenVas. It is really a great tool to found out about vulnerabilities in the network.
I have found difficult to troubleshoot the vulnerabilities related to weak cipher suites and protocols. For example, the OpenVas reports:

2.6.2 Medium 48004/tcp
Medium (CVSS: 4.3)
NVT: SSL/TLS: SSLv3 Protocol CBC Cipher Suites Information Disclosure Vulnerability (POODLE)

Summary
This host is prone to an information disclosure vulnerability.

However, when I scan the same server with Qualys SSL Labs online test, I get:

Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3   No
SSL 2   No
For TLS 1.3 tests, we currently support draft version 18.

I remember using IISCrypto in this machine to disable obsolete protocols and cipher suites.

Can a server have cipher suites enable/disable in some ports?  Can my Windows Server have SSL3 enable in port 48004, but disable on port 443?

Thanks

Can a server have cipher suites enable/disable in some ports? Can my Windows Server have SSL3 enable in port 48004, but disable on port 443?

Yes. The actual application bound to a specific port may be different or may have a different configuration. For example, you could run apache on 443 and nginx on port 8000. You may be running some other app or DB which has a web service on 48004, possibly nimbusdb.

I would check what app is actually running and see what webserver application is actually being used and how to properly configure it.

As @StackzOfZtuff noted in his comments, Qualys is only scanning 443 and does not scan other ports, so its not telling you anything about port 48004.


how can i bypass close_notify in ssl in firefox? i am trying to login to my yahoo mail, but no avail. i recently discovered after monitoring some traffic that the dumb yahoo server doesn't send a close_notify response but just acts ignorantly and closes the ssl session. i know if i do this i may be vulnerable to truncation attacks, but i will disable it as soon as i import everything i have from yahoo and then delete my yahoo account. i want to bypass the close_notify verification in firefox (or iceweasel as you want to call it). thanks.

i'll also quote a comment that has been made in the pidgin support board. it's down here:

  Both GnuTLS and CDSA (Adium's SSL plugin) check whether a TLS
  connection  has been closed properly by checking if the server sent a
  close_notify  alert first.
  [https://bugzilla.mozilla.org/show_bug.cgi?id=508698 NSS  doesn't]. If
  that alert wasn't sent, GnuTLS and CDSA consider it a fatal  error,
  which for the HTTPS handler means the response is completely
  discarded. That's what's happening here with Yahoo: their HTTPS server
  closes the connection without sending close_notify first.

  The danger of not checking for that alert is that any MitM may cause
  a  response to be truncated, yet we'd be unable to tell that it is.

  Is it really an error condition libpurple should consider fatal? I'm
  not  entirely sure.

To make a SSL implementation not complain about the lack of close_notify, the direct method is to download the source code, modify it, then recompile it. This may imply a substantial amount of work. If your OS is some Linux flavour, then the package manager may provide a way to obtain a source tree already configured for proper integration with your system (with apt-get source on Debian-like distributions).

Alternatively, you might try to fiddle with iptables so as to block the "FIN" flag from Yahoo -- thus emulating an absence of connection closure, which would then explain the lack of close_notify; from the point of view of the client, things would remain open. If the HTTP response include a Content-Length header, or use chunked transfer encoding, then this as a good chance of working. Notably, the lack of close_notify is a security issue only for protocols which rely on connection closure to convey semantic information, e.g. HTTP 0.9, but not "modern" HTTP.

If that's a one shot, you may find it simpler to temporarily use another browser which would be less picky about the close_notify when doing HTTP (and that would not be really wrong, as long as the HTTP response are self-terminated). Try chromium.


AWS S3 Server-side Encryption - Client Provided Keys PHP It is a bit strange to me this isn't a commonly discussed topic yet but I am working with an AWS S3 storage server trying to implement server-side encryption using the option of a client provided key (SSE-C).

More Information Here: http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html

I have the encryption method working great when attempting to use the AWS Key Management Service (KMS). The issue I personally have is I want to hold the keys, thus leading me to want the SSE-C method.

Documentation for PHP (for whatever reason) is scarce under this subject but I have managed to get it working using the seemingly most recent composer build of version3 for S3.

My connection code and put object to the system is as follows. Files are properly uploaded to the system. Code is as follows:

//connect is successful
$client = Aws\S3\S3Client::factory([
    'version' => "2006-03-01",
    'region' => "us-west-1",
    'credentials' => [
        'key'    => "mykey",
        'secret' => "mysecret"
    ]
]);

//upload is successful
$somerandom32bitkey="48wk86271sDb23pY23zT5rZJ7q55R7eE";
$result = $client->putObject([
                'Bucket' => 'mybucketname',
                'Key'    => 'myfilename',
                'Body'   => 'some body of the file',
                'SSECustomerAlgorithm' => 'AES256',
                'SSECustomerKey'       => $somerandom32bitkey,
                'SSECustomerKeyMD5'    => md5($somerandom32bitkey,true),
            ]);

My issue arises when attempting to get a pre-signed url. I cannot seem to find any documentation on how to actually do this part which is pretty important. The code is as follows:

$somerandom32bitkey="48wk86271sDb23pY23zT5rZJ7q55R7eE";
    $cmd = $client->getCommand('GetObject', array(
                    'Bucket' => 'mybucketname',
                    'Key'    => 'myfilename',
                    'SSECustomerAlgorithm' => 'AES256',
                    'SSECustomerKey'       => $somerandom32bitkey,
                    'SSECustomerKeyMD5'    => md5($somerandom32bitkey,true),
                ));

    $request = $client->createPresignedRequest($cmd, '+10 minutes');
    $presignedUrl = (string) $request->getUri();

The link generated looks like this:

https://s3-us-west-1.amazonaws.com/mybucketname/test.txt?x-amz-server-side-encryption-customer-algorithm=AES256&x-amz-server-side-encryption-customer-key=NDh3azg2Mjcxc0RiMjNwWTIzelQ1clpKN3E1NVI3ZUU%3D&x-amz-server-side-encryption-customer-key-MD5=sJFeofwx%2FqqLd0B4Gc0TKA%3D%3D&X-Amz-Content-Sha256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIQZMPABWF7ZC57ZQ%2F20160120%2Fus-west-1%2Fs3%2Faws4_request&X-Amz-Date=20160120T040211Z&X-Amz-SignedHeaders=Host&X-Amz-Expires=600&X-Amz-Signature=91178da69e049fdc43a2d496f9533e4e1295db89b651010224e6610cf8e4443c

The result response via AWS is:

<Error>
InvalidArgument
<Message>
Requests specifying Server Side Encryption with Customer provided keys must provide an appropriate secret key.
</Message>
<ArgumentName>x-amz-server-side-encryption</ArgumentName>
<ArgumentValue>null</ArgumentValue>
<RequestId>933237342E36A1D1</RequestId>
<HostId>
3XmQM+IEGdZUZ5GUnSpTpatksKIN2zb3pCiu8D7Btm09nLxKkfEAkfY8a8T8kcB3lW1p38ic3ZE=
</HostId>
</Error>

The interesting part is it is looking for a parameter of:
'ServerSideEncryption' => 'AES256'
but this is only a parameter required when using the AWS managed key system (SSE-KMS) http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html

Any ideas here?

As per official documentation there is three request header require for SSE with customer provided key:

x-amz-server-side-encryption-customer-algorithm : AES256
x-amz-server-side-encryption-customer-key : base64(secretkey)
x-amz-server-side-encryption-customer-key-MD5 : base64(md5(secret
key))

Please update code as per above

'SSECustomerAlgorithm' => 'AES256',
'SSECustomerKey'       => base64($somerandom32bitkey)
'SSECustomerKeyMD5     => md5(base64($somerandom32bitkey))

Hope this will help.


ISO 27002 Controls - Which Ones to Implement First Im struggling to understand in which order I should implement the ISO 27002 controls.  I was thinking about using the CIS Top 20 to help but what is the best route?

This really doesn't have a straight forward answer, as it depends on your organization. It's important to remember that 27002 is simply a guideline for IS. It does not have a certification, nor do you have to meet each control. It is just a suggestion of things you should consider.

In most cases, you need to implement some sort of security policies so that you can implement everything else. Obviously, those policies can and will change as you implement other controls. For many organizations, the focus is on access control after some sort of baseline policies are in place. This includes all of your password policies and role based access to your network.


Pure SRP authentication without TLS IF using a SRP for client/server application authentication without TLS. Will it be vulnerable to man-in-middle attack, since if using SRP, the public info doesn't really useful to calculate the session key.

SRP is a password-based key exchange protocol, which implies mutual authentication (the client has a guarantee that it talked to the right server, the server has a guarantee that it talked to the right client). By definition, this rules out any man in the middle attack. This applies to the complete SRP protocol; if you look at the design page, you see that client and server first exchange a pair of messages (I,A from the client, s,B from the server), and then do some computations which yield the common session key K for both. But the authentication is not complete at that point; as the page says, client and server still "need to prove to each other that their keys match" so there are a couple extra messages to be exchanged.

At that point, client and server have "mutual authentication" in the following sense:

They both know the shared session key K.
The client (resp. server) knows that only the rightful server (resp. client) knows the key K.
They both know that the rightful server or client was indeed involved in the process (the authentication is explicit).

(The extra "key match" messages are needed to make the authentication explicit, but also to make the protocol robust -- the cryptographic details are intricate.)

But this is not enough. Indeed, when you want authentication, you don't just want some knowledge in abstracto that the intended peer exists and is not dead yet; you want to authenticate a session, i.e. subsequently exchanged data. An attacker in the position of doing a MitM attack could just let the messages pass, and then hijack the transport medium and inject his own data packets. To authenticate the session, the shared key K must then be used to compute a Message Authentication Code over the data chunks which the client and server then send to each other. In many cases, encryption will also be needed. Applying a MAC and possibly encryption to streamed data, in a safe way, is known to be a difficult task; there are details.

If you implement SRP and then add a transport layer for data which computes the MAC and encryption and does everything that is needed to make the session safe (including key diversification to prevent an attacker from making the server talk to itself; sequencing, to prevent reordering of data chunks; verified termination, to prevent truncation; and so on...), then you end up with something which is, basically, TLS. TLS with SRP is about the minimal protocol that uses SRP to authentication a session. It would take a very special situation to warrant inventing your own protocol (an highly risky endeavour) instead of just using TLS.


Are there any good brute force programs in C#? I'm planning to research & learn from brute force methods, but all the popular ones I found like John the Ripper or hashcat are written in C & OpenGL which I don't have much knowledge about so far. Can anybody recommend a decent brute force program written in C#, if it includes source code that would be nice.

I don't know any particular brute force in C#, but having worked in both C and C# (and inferring that you know C# from your question) I think with a good reference you should be able to jump into C. You will of course need to be very careful with garbage collection (malloc, etc.) and it will require learning procedural vs. object oriented coding but it's doable.

Here's a good thread: https://stackoverflow.com/questions/4002442/learning-c-from-a-background-in-c-sharp

One of the recommendations is The C Programming Language which is a classic. For something much lighter and very funny I'm a fan of Dan Gookin's C for Dummies which is light but still informative.

Good luck!


Homomorphic encryption used for e-voting? I was reading wikipedia about homomorphic encryptions, and one part got me a bit confused:

  "The homomorphic property of various cryptosystems can be used to
  create secure voting systems, ..."

How would you possibly use homomorphic encryption to secure the voting process? Of course, you won't be able to intercept the results, but what if someone "injects" their own ciphertext into the ballot ciphertexts?

Wouldn't it be possible to forge an election, by tampering with the encrypted data?

Homomorphic encryption is one of the two main structures for e-voting protocols, but the encryption part is not the whole protocol.

What homomorphic encryption does well is tallying. In such a system, each voter encrypts his vote (a zero or a one). Since the vote is encrypted, it can be managed rather easily: there is no problem in associating the vote with the voter. So the votes can be accumulated on a public bulletin board and everybody can check that his own vote is taken into account, or that nobody voted twice. When all the votes are obtained, homomorphism is applied to get the encryption of the sum of the votes, and the sum is then decrypted; the decryption private key is split among a few partially trusted authorities, who collaborate only for this single decryption. As long as at least one of the authorities is honest, the individual votes cannot be decrypted, and vote anonymity is maintained (we cannot know who voted what).

The tricky part in such systems is how to make sure that an encrypted vote is really the encryption of a 0 or a 1, and not the encryption of something else. Practical protocols for e-voting which rely on homomorphic encryption, use non-interactive zero-knowledge proofs, which are rather technical but boil down to the following: with sufficient mathematics thrown at the problem, it is possible, for some asymmetric encryption algorithms and with the cooperation of the voter himself, to prove that an encrypted value is really the encryption of a 0 or a 1 but not of anything else. This, of course, cannot be done without the cooperation of the voter himself, otherwise it would be a gross weakness of the encryption system.

The other main structure for e-voting protocol is mix networks: the votes go through a sequence of entities who shuffle them randomly (this has applications others than e-voting, e.g. Tor). Nested encryption is used so that the shuffling cannot be traced externally. At the output of the last mixer, the votes are decrypted, but cannot be associated with the voters, as long as at least one of the mixers is honest. Since the votes are decrypted, they are trivially verified to be syntaxically correct (a 0 or a 1, nothing else). On the other hand, convincing voters that their vote was not lost, or that nobody voted twice, becomes much harder -- solutions for that involve, again, some ZK proofs.

The International Association for Cryptologic Research, when it must vote to elect its directors, uses Helios Voting, which relies on homomorphic encryption (with the ElGamal algorithm, and Chaum-Pedersen ZK proofs).


How does a client know an SSL cert has been signed by a CA if the client doesn't have the CA's public key? I'm still learning how SSL/TSL works, so apologies if this question is very basic.

I understand that the server offers the client its SSL certificate, which contains the signature of a CA.  I also understand that the client will usually have a list of certificate authorities it trusts.  But what if the SSL certificate is signed by a CA that the client is not aware of?  How will the client validate the certificate then?

When the client is verifying a certificate, there are three possibilities:

The certificate is signed by a CA that the client already trusts (and for which it knows the public key). In this case the client treats the certificate as valid.
The certificate is signed by a CA about which the client has no knowledge at all. In this case the client treats the certificate as invalid (and the browser will likely display a warning message instead of loading the page).
The certificate is signed by a CA that the client doesn't know, but which has a certificate that is signed by a CA that the client does know. (In this case the server must usually send both its own certificate, and the certificate of the CA - called the "intermediate CA" - that signed its certificate). Since the intermediate CA's certificate is signed by a CA that the client already trusts, it knows can trust it, and since the server's certificate is signed by the intermediate CA, the client knows it can trust it too.

Note that CA certificates are "special" - just because you have a certificate signed by a trusted CA, that doesn't mean you can then sign other certificates and have clients trust them - unless your certificate is marked as being valid for signing other certificates.


How hard is it to break an 8 digit pin of AES 256 encrypted external sata enclosure? I am looking at external sata enclosures for 2.5" drives, there are some with keypad on them and protect the data with pin that is usually limited to around 8 digits. Drive is protected with AES 256 encryption.

How fast can this pin be cracked ? I assume in theory the keypad can be connected to a computer.

I don't know if these sata enclosures usually force a delay after some failed attempts, if someone knows please let me know.

It doesn't matter. If these devices make any sense at all (and use the built-in encryption that modern SSDs and hard drives have):

The device's decryption key is stored within a microcontroller that simply will delete the key if you tried wrong PINs too often.

In other words: although it might maybe only take thousandth of a second to try one PIN, after three PINs (or whatever the manufacturer designed the microcontroller for), the device is bricked and there's effectively no way to recover the data.


Is there a compelling reason to ssh tunnel RDP connections? We don't run any Microsoft products natively in our office, but there are a few folks who use a linux RDP client to access an application on remote virtual desktops with a service provider. Would it be worth the effort to tunnel the RDP through ssh, or should I not be too concerned?

We're currently using Remmina which in turn uses FreeDesktop (RDP version 6) with TLS.

Update: The question has since it was originally posted been edited to highlight one difference, namely that RDP v6 over TLS is used. While the answer may still be considered "okay", I must now argue that tunneling TLS over SSH is unnecessary due to a lack of relevant and likely threat-scenarios - assuming correct configuration of TLS certificates etc.

In an ideal world security decisions should always be supported by data, factual and objective data. Determining whether or not it's "worth the effort" to tunnel RDP through SSH would be done by combining knowledge of known attacks, classification of the information accessed (from a confidentiality, integrity and availability perspective) and the "cost" of implementing countermeasures.

Fact - There are a number of issues with protocol versions < 6.0 of RDP, such as MiTM-attacks (weak authentication, as briefly described here).

While I'm not aware of any real attacks leveraging the above mentioned vulnerability one clearly can't exclude the possibility of that happening, or to have happened. There are however a number of demonstrations scattered around the web illustrating how it could be exploited.

There are a number of things you need to figure out to make a "good" decision.

"Sensitivity" of the information accessed
The effort (time) of implementing the countermeasure (SSH-tunneling)
Likelihood of someone intentionally targeting you to leverage the vulnerability to realize the threat. (Unfortunately very difficult, since data sharing within the security community of past incidents are few and far in between!)

If the effort for tunneling the connection over SSH is not overly costly and time consuming it would be a reasonable countermeasure to use as it would mitigate the above threat entirely.


Is Bluetooth Low Energy Injection possible? Mike Ryan claims that it is possible to inject packets (probably with Ubertooth) in an ongoing BLE conversation. His attempt to do so lead to jamming the connection (Sources 1 and 2).

The Bluetooth specs (v4.0) state that the time between sending 2 packets is 150µs. So if one device starts listening after 150µs and the other one starts sending after 150µs then the only time one could inject a packet would be when one of the devices is also transmitting.
This would cause an interference which would result either in "losing" the packet or receiving a faulty packet. Thus  for the attacker an injection would never be successful and lead to a DoS in the "best case".

So is successful injection of packets possible or is ubertooth advertising an "impossible feature"?

P.S. Let me know if you know a more appropriate forum I can ask this question.

Bluetooth LE isn't a protocol per se.  iBeacon, altBeacon, and Eddystone are examples of Bluetooth LE protocols which do not inherently have a security mechanism.  For example, an attacker knowing that a particular beacon has a given set of IDs (which are broadcast indiscriminately over the air on a known frequency) can use these same IDs to "spoof" the beacon.

Bluetooth also employs MAC addresses which are also well-known to anyone listening on the Bluetooth frequency and can also be spoofed.

Bluetooth device pairing is an unsecured, coupling mechanism to help users manage devices but does not provide a reliable security layer.  Bluetooth standards have been evolving steadily in response to user and hardware needs but are unlikely to be secured in the same way other high-speed wireless protocols are. You can read a good summary about the evolving Bluetooth standard on Wikipedia


Documentation on Snort rules and alert tuning, especially for new users I just started using Snort. There is a lot to it. I'm just looking for better documentation of what some of the Snort rules actually mean -- i.e. How I should react to them when I have an alert for a given rule pop up. It seems that the Snort docs, examples, and forums assume a lot of esoteric network security administrator background knowledge that I appear not to have (yet).

For example, I found this:

https://www.snort.org/rule-docs/119-3

However that section of the Snort website is woefully out of date and the search part doesn't work, and 404's pop up when I manually input many of the rule ids I'm interested in.

Example, for the stream5 preprocessor:

https://www.snort.org/rule-docs/129-1  <-- This works
https://www.snort.org/rule-docs/129-12 <-- This is 404

The second one, "129:12", has a text description of "Consecutive TCP small segments exceeding threshold". What does that even mean? In what way is that indicative of a problem? I examined our network, and there's only acceptable network activity (that I could tell). During an event where Snort was very verbose about this particular problem (on the order of 100 messages per minute), the problem was traced to authorized traffic passing out through our squid proxy.

So what, should I just suppress all of these messages?
Is that a normal way to tune Snort? Just suppress the noise? That strikes me as crazy... If I suppress all these messages, what if there are messages of this class that actually indicate a problem?

I hope you get the idea.

Currently I am using pulledpork to assemble rulesets, and suppressing noisy rules via suppress directives in threshold.conf.

Lastly, I should mention that I'm running Snort in a fairly non-conventional way, as a workaround to satisfy IDS requirements for PCI, while running in the AWS cloud. Long story short, we have Snort running on all boxes that we classify as "edge" boxes, and are sniffing traffic on those. I'll provide more detail if requested, but that doesn't change the basic gist of this question.

You're encountering one of the most basic issue with pretty much ALL monitoring system: how to handle the data generated properly and separate the signal from the noise.

Unfortunately for you, there is no easy answer because it all depends on your what your resources are and the value of what you're protecting.

Let me be more specific: if you're working with a small, high-value network and have plenty of (competent) people to handle the task, you can leave all alerts on and investigate all of them completely. That is obviously very expensive and you need highly trained people (and probably very smart software) to be able to handle it correctly.

On the other hand of the spectrum, if you have a large, low-value network with few people available for incident handling, then you could decide simply to log everything and only investigate issues that are explicitly flagged as incident through a different channel ("Who changed the password of the CEO's email?"). Your IDS will still be of value to you because you can use the logs for some post-mortem analysis of an incident but it will not allow you to react proactively.

Most networks falls in between these two extremes so you're supposed to create alerts that match as closely as possible your actual threat level and response capacities. That takes time and it's a process that should be continuous: you'll have to adjust your rules to react to new threats, changes in usage or in capacity all the time.


Is there any added security benefit to username complexity requirements? I've come across several sites lately that have complexity requirements for usernames like "must be 8 characters long and contain at least 2 numbers". Is there any real added benefit to this from a security standpoint?

I would think that since a username is designed to be an identifier and not a secret that this is an unnecessary and annoying policy to have. It annoys me particularly because it comes across as a "security" requirement that provides only the illusion of security at the expense of convenience.

I cannot think of a tangible security benefit, other than maybe possibly it being a little more difficult to enumerate the user names.  Some practice of security through obscurity, i would think that would have the disadvantage of then requiring your users to have to write down their username to remember it, maybe defeating the purpose of a complex user name.

On the other hand, I'm not certain how prevalent it is to use keystores like KeePass; sort of making remembering the username irrelevant.


Radio transmission on my whatsapp voice note I was sending a voice note to a friend and when I listened to it, the first ~6 seconds were completely normal and then something weird happened. A radio transmission from some radio station (I don't know which one) cut in after a weird sound.
Does anyone know what could have happened? Is it possible some radio transmission could have mixed up with my voice note? Do I need to be worried about my privacy?
Ps: no, it wasn't some radio app on my phone, I checked that. I wasn't listening to anything either, the room was silent.
I've tried saying the same thing in a voice note and nothing happened. Also, the phone is an iPhone 12 pro max without a built-in radio.

Injected parasitic frequencies used to be quite common in the days of AM radio. Close or particularly powerful AM radio station signals showed up everywhere, I've even gotten radio stations on vinyl record players and audio amplifiers.
AM radio is still around today but much less common, but that's what I think is most likely.
Other non-AM transmitters that are really close can occasionally induce audio signals but that's much less common.
In any case, this is essentially outside interference. It may degrade you recordings but it's not a privacy issue.


ssl - Can the attacker generate his own symmetric key if ClientHello and ServerHello are intercepted? After reading this awesome explanation of how SSL works, I now have a confusion.

The answer states that the first messages of SSL are ClientHello and ServerHello(in response to ClientHello). Both of which are unencrypted, correct me if I am wrong. Also the client does not start sending encrypted until ChangeCipherSpec is issued.

So both ClientHello and ServerHello contain the "client random" and "server random" and also the session-id.  Now AFAIK the data is encrypted using a symmetric encryption key, that is, the client and server both have a copy of the same key and encryption/decryption is done via that single key for that SSL session.

And isn't that key suppose to be computed using the "client random" and "server random" ?

So if the ClientHello and ServerHello are both plaintext can't the attacker just use the same algorithm as the client and generate his own symmetric key and converse with the server impersonating the client ?

How is this not possible ? What am I missing here ?

UPDATE:
The phases of ServerKeyExchange and ClientKeyExchange also happen before ChangeCipherSpec so they are also suppose to be unencrypted.

You are missing the coolest part. Diffie Hellman Key Exchange: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

This part is the bit that allows the keys to be generated at each end by swapping details in the clear. Even if an attacker intercepts the clear communications they cannot themselves recreate the output. Very clever as the algorithm is known to everyone and by knowing that offers the attacker no advantage.

Also worth noting that if a man in the middle attacker intercepts and actively changes anything within the protocol while it is not encrypted when the protocol conducts the message authentication stage it would notice it had been tampered with and fail.


Access to a router's GUI During a recent visit to a coffee shop, I noticed that they hadn't bothered changing their default user name and password for their router.

I realise that someone could log on and be annoying to other users (kicking people off the network, locking the network), but what other malicious activities could be done with this kind of access?

For info, the coffee shop ran an open wifi network.

I did tell the coffee shop about this problem, but they didn't really care (or understand?)

The other answers are correct, however there is one big fish being mostly ignored:

  DNS cache poisoning

As @Larry said, since you own the router you own the DNS. Meaning you can cause any other user of that network, use any server you want for any address they request.

But more than that:

You can make leave your DNS ownership in place, even when you're not there anymore other users will continue to use your servers.
Even after the other users leave, you can still own whatever address they try to access.
To clarify, let's assume some victim at some point uses the coffeeshop to access http://www.google.com/. This should resolve to 209.85.143.104. However, because you pwned the router, you're sending anyone who requests http://www.google.com/ to 207.200.14.140. This will continue to happen, even after you go home...
Now, what happens if you set the TTL for the DNS response (the one returning 207.200.14.140 for http://www.google.com/), to some value far in the future? The victim will go home, back to his "secure" network, and at some point will again browse to  http://www.google.com/. Shouldn't be a problem, right? Well, the TTL caused the DNS response to stay cached on your machine, so your browser now doesnt even bother making another DNS request - it just sticks with the 207.200.14.140 it got at the coffeeshop. That you gave it. 3 weeks ago.

Just a suggestion? A bit borderline, but since noone at the coffeeshop cares (or probably even knows how to logon to a router what that even is), do them a favor: change the password for them. Write it down for them, hand it to the manager, and if he really needs it, he'll figure out what to do, and maybe even learn a lesson.
Of course, this is borderline ethical, maybe even illegal, so caveat emptor. But other users WILL be grateful (even if they know nothing about it).


Being told my "network" isn't PCI compliant. I don't even have a server! Do I have to comply? We are a brick and mortar company... literally. We are brick masons. At our office we connect to the internet through our cable modem provided to us by Spectrum Business.

Our Treasurer uses a Verifone vx520 card reader to process credit card payments. It connects via ethernet. We don't store credit card data.

We got a vulnerability report stating that we were not PCI compliant.

They scanned our cable modem.

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability
Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0
Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

I don't understand what they mean. We don't have a server or an online store or anything. I was told they scanned our network and this is what they found. They told us to get with ISP to fix issue.

How is the ISP supposed to get an SSL certificate installed on a cable modem? I did call our ISP and he didn't know what to tell me.

We just use the card reader and it connects to our payment processor.

Am I supposed to do something here? Is any of this applicable to us?

At our office with connect to the internet through our cable modem
  provided to us by Spectrum Business.

  Our Treasurer uses a verifone vx520 card reader to process credit card
  payments. It connects via ethernet. We don't store credit card data.

It sounds like you fall under SAQ B-IP (and you will be amused that the mnemonic is that "SAQ B-for-Brick-and-Mortar"):

  SAQ B-IP has been developed to address requirements applicable to
  merchants who process cardholder data only via standalone,
  PTS-approved point-of-interaction (POI) devices with an IP connection
  to the payment processor

It sounds like someone did an external ASV ("Approved Scanning Vendor") scan on your known IP address and found the cable modem was, unsurprisingly, not up to snuff.

  Am I suppose to do something here? Is any of this applicable to us?

Yes, this is applicable to you, and many other things besides, all of which are outlined in the Self Assessment Questionnaire linked above.  And if your other office systems - desktops, printers, whatever - are also sitting on the same network behind that cable modem, then the requirements of the SAQ apply to those as well.  Things like patching and access controls.

For now, you will need to continue to work with your ISP.  They either need to update the modem, upgrade it, or get it to stop accepting connections from the Internet at large.

To break down those error messages for you:

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability

There's likely a self-signed certificate on that device, common for things like cable modems that need TLS but don't care about being trusted by random users.  (PCI cares, though, even when users don't).

Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0

When you go to a secure web site today, the newest you'll see is TLSv1.3, however most websites only support up to TLSv1.2 or TLSv1.1. TLSv1.0 is old, relatively insecure, and PCI declared it unacceptable to use a few years ago.

Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

TLS gets to pick from multiple algorithms; over time, weaknesses are found and individual algorithms get retired because of it.  RC4 got retired a few years ago.


Detecting SMIME type using OpenSSL CMS Is it possible to detect S/MIME content types (enveloped or signed) using OpenSSL CMS API? I would prefer to avoid pre-parsing S/MIME headers and let OpenSSL to detect whether message is signed or encrypted.

I'm looking for a method that would extract smime-type from CMS_ContentInfo.

After formulating a question, I've noticed solution myself. In case this might be useful for someone else:

CMS_get0_type - converts CMS_ContentInfo into ASN1_object pointer

OBJ_obj2nid - gets one of the following NID values from ASN1_object pointer:

NID_pkcs7_data

NID_pkcs7_signed

NID_pkcs7_digest

NID_id_smime_ct_compressedData:

NID_pkcs7_encrypted

NID_pkcs7_enveloped

For details see:
http://wiki.openssl.org/index.php/Manual:CMS_get0_type(3)


Command Prompt Opens and Closes Immediately When command prompt opens and closes suddenly. It changes proxy settings of Google Chrome and Every browsers present in the system.

and i think because of that my homepage get changed also. It shows adds on my browser.

How can i get the rid of this? It is safe?

the files mentioned in images are recreated after deleting....how to delete them.?

This problem can be caused by two things.

The first is browser extensions. I you have installed any extension from any unknown source that may cause changing your home page and showing ads. All you need to do is to remove that extension. If that doesnt solve the problem you may need to uninstall the browser and delete the files in this folder (check all user accounts for this location):

C:\Documents and Settings\*UserName*\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions

Second, if you have malware, adware or whatever you need to find it. See how to find manually a virus malware adware or any infecting file.


I'm leaving my job and want to erase as many personal details etc. as possible; any tips? Obviously this is very open-ended. But, I'm just paranoid about people going through everything on my laptop after I leave my job. Here are the things I'm planning to do:

Completely wipe all browser caches/histories/passwords, etc.
Delete my Skype database files and configurations so that nobody can log into my account for view my old messages.
Delete the Outlook data file for my gmail account, and the archive files for my work e-mail. I realize there's nothing I can do about the e-mails on my work e-mail account that are on the mail server... unless somebody has an idea?
Delete anything non-work related from the hard drive. Though, from what I understand, there are ways of restoring deleted files from a hard drive, right? Is there any way to prevent that, short of doing a DOD wipe on the entire drive?

That's about all I can think of. Does anyone have any other suggestions? Is there anything that the IT people might try to do that I'm not aware of? I'm not trying to hide anything weird or illegal; I'm just concerned about my personal privacy.

Thanks.

The proper answer for this question is very situational, and dependent upon the policies and procedures in place at your company.  Many companies have in place methods of backing up portions of the drive meant for user data, or even the entire drive, across the corporate network.  If they've performed such backups on your system, there's nothing you can do to prevent them from accessing your data.

Beyond that, if your company allows, the only things you can do to definitively prevent restoration of your data off the laptop drive, is to do a secure wipe of that data or the whole drive, degauss, or outright destroy the drive.

EDIT:  While the above discusses what you might be able to do about your privacy now, there really is a larger issue at hand.

If you're really concerned about your personal privacy, don't use corporate resources for personal purposes.  Most companies have included in their Acceptable Use Policy or similar documentation, a clause that specifically says you may be subject to monitoring and have no expectation of privacy when using their systems.  In many jurisdictions, this means that they can do whatever they want to observe and record your activities with or without your explicit consent (generally, your consent is given implicitly upon your agreement to the AUP) and/or knowledge - causing any retroactive attempts at personal privacy to be futile and ineffective.

Case in point:  At one former workplace, I heard of a user who decided to do some, let's say, "very personal" web browsing on a company laptop while he was on his home network.  Apparently he was under some delusion that whatever he did with the company's hardware was none of their concern if he did it on his own Internet connection.  To be safe though, I'm sure he had some good history cleaning software in place and in use.  He was also technically savvy enough that he probably did some manual cleaning of his own, periodically.

What he didn't know was that the company had monitoring software installed locally and running in the background.  This software would record his Internet activities at all times, and relay the logs to the corporate servers whenever the laptop was connected to the intranet.  You can imagine the resulting disciplinary actions when this occurred.

TL;DR:  Keep your business on your hardware, and company business on company hardware.


Security Operation Center (SOC) I am looking for resources and details on establishing a security operation center (SoC) or network operation center (NoC) based on ITIL or any other applicable regulations. Where can I find good details or experiences of others except for hiring consultants.

Here is some experience about establishing projects, especially security projects, that applies to consulting and outsourcing that I wrote up on a security stackexchange answer about incident compromises.

As for resources, well it is highly dependent on your environment as to what you would need to build and how many people to hire (and at what levels of qualifications). In many ways, a good strategy consultant or two could push you into making better decisions, but if you want the real story -- let me give you some additional advice.

Security events and incidents are best tracked by personnel that are already familiar with SIEM and incident detection & response (IDR) panels -- so look for candidate with past hands-on and strategic long-term experience with SIEM/log-management/IDR. For staffing, Lance Hayden analyzes the current security event/incident stream using Poisson distribution in Minitab, as explained in his book, "IT Security Metrics". He also goes into business workflow and other concepts that are highly important to building a quality SOC.

For IDR panels, consider AIRT or RTIR -- or build a custom one, perhaps based on their wireframes and workflow. Many organizations integrate IDR into their ticketing system, such as Remedy.

SIEM costs money, but there are books and resources to get a SOC started. Most security incidents in 2011 are SQL injection (or other web app layer attacks) and client-side browser/document attacks (e.g. Adobe Reader/Flash, Microsoft IE/Office/ActiveX, Oracle Java applets, etc). It is highly suggested that your SOC team be familiar with the techniques and tools outlined in this blog post entitled Closing The Loop. While not to tone down the other, more important information in that blog post -- there is something of specific interest to you, [PDF] [the CSIRT Handbook]6 [download]. That paper is old, but still very relevant.

For more up-to-date resources, check out the guides and many other resources at FIRST.

These books will also be helpful, in order of necessity:

Security Information and Event Management (SIEM) Implementation
Security Strategies in Windows Platforms and Applications
Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code
Malware Forensics: Investigating and Analyzing Malicious Code
Network Security Hacks, Second Edition
Security Power Tools
Pro Open Source Mail: Building an Enterprise Mail Solution


Reverse Proxy or direct? imagine I have an architecture as shown.

In order to get to the internal web server, should I use a reverse proxy like as shown and redirect traffic to my web server? Is this a more secure way instead of just opening rules at Firewall A and B and let traffic through? And why is it more secure?

thanks

Using a reverse proxy can thwart some exploits targeting the webserver.

Reverse proxies are usually simpler than webservers, so they are (in theory!) less likely to have vulnerabilities.
If the proxy is exploited, this does not yet give the attacker access to any data on the webserver or other systems behind the DMZ

Note that this only applies to low-level exploits targeting the webserver directly. Any application-level exploits won't be affected by this at all. The proxy might also directly forward some exploitative connections as they are, so they work even through the proxy.


Several processes are listening to the same interface: any problem? I wonder if some processes may get less packets than others if they are all listening to the same wireless interface.

I'm running for example the basic mitm schema using arpspoof, sniffing packets with ettercap, running urlsnarf to see some GET requests and tcpdump saving the dump packets into a file. All in different terminals listening to wlan0.

Assuming the network stack was competently programmed, no.  An interface in monitor mode should hand off a copy of each packet to any program that wants it.


Is Ghostery safe to use? I've heard about Ghostery, a browser extension/plugin that blocks web trackers.  But according to this link it sells our data. Are add-ons and plugins open source in Firefox? Is there another alternative to Ghostery?

You can prevent Ghostery from selling your data by opting out of the Ghost Rank feature. The feature is opt-in, so if you didn't already opt in there is nothing you need to do. It is then safe for you to use.

Using a clone of Ghostery which is identical in every aspect except not having the Ghost Rank feature would make no practical difference from running Ghostery without opting in to Ghost Rank. If your intention is to actively punish Ghostery for their evil data trading by boycotting them, then you will achieve nothing. They already gain nothing from you commercially when you run Ghostery with Ghost Rank disabled. If anything you help them by uninstalling Ghostery because you no longer consume any of their resources.

But if you are really looking for an alternative option: the classical method is to edit your operating systems hosts file and forward the hostnames of known trackers and advertising networks to 0.0.0.0. There are recommended blocklists available which you can find with a websearch (I can't vouch for their quality, so I won't recommend any specific ones). The advantage is that it doesn't just block advertisements in one web browser, but in all web browsers you have installed and in any other applications which might access these hosts for whatever reason. The drawback is that you will have to maintain your blocklist manually.


Can someone steal cookie contents via a phishing attack? If someone successfully set up a phishing website on a fake wireless network for say, bankofamerica.com, and lets pretend that SSL was not used, would they be able to run a script on the server that reads the cookie contents of anyone who connected to it (for example, a long-term authentication token)?

Assuming a pharming attack rather than phishing... This is where the domain name is redirected to a fake site rather than Typosquatting or tricking the user into visiting a totally different site that is made up to look like the target.

The difference here is crucial - the effective domain of the fake site as seen from the victim that is actually the same as the real site will cause the browser to treat the fake site as the same Origin.

This means that cookies, local storage, et al, will be available to the fake site.

Two mitigating points:

If the Secure Flag has been set on any auth cookies, they will not be sent to the domain unless it is accessed over HTTPS.
If HSTS has been set for the domain either because the user has visited the site before and has an HSTS entry for the domain in their browser, or the site is in the HSTS pre-loaded list, the user will not be able to connect to the fake site over HTTP (nor over HTTPS if the certificate causes browser warnings).

If neither of the above apply and the user had an authenticated session against the fake site, then the cookies will be sent to the fake site, including any used for authentication. Hopefully a bank will have taken either of the above precautions but not always the case.


How to kill a process with multiple threads? I'm dealing with a malware which has multiple threads monitoring each other, I'm unable to kill all of them at once so I can't get rid of it, how do I go about this? I was thinking about using a kernel-debugger but maybe there's a better alternative.

If you can either identify how the malware is started on boot or where it is stored one possible option would be to shutdown the machine, boot from another medium (such as a Linux or Windows PE live USB) and make changes from there to stop it launching on next boot. This will involve either removing files containing the malwares executable code or modifying system configuration to stop it from launching again on boot.

If you are strugling to identify the executables follow the steps suggested by baldPrussian -

  Get the names of the threads, which can tell you the executable that runs. Find where the exes are and the reg keys (possibly the run key) that call them

I would suggest checking the system multiple times over the next few days to ensure nothing was left on the system to allow reinfection. You also want to do everything possible to determine the infection vector - again so you can take steps against becoming reinfected.

If worst comes to worst swallow your losses and nuke it from orbit.


Does nmap limit probes when using time limiting on decoy scans? If I set a rate limit (e.g. -T1) on an nmap scan that uses decoys, does the rate limit apply to all probes, or just each individual source? I checked the documentation, but can't see anything specific. I'm primarily concerned about this from a stealth scanning perspective.

From the source:

    This function also handles the sending of decoys. There is no fine-grained
    control of this; all decoys are sent at once on one call of this function.
    This means that decoys do not honor any scan delay and may violate congestion
    control limits. */
static UltraProbe *sendIPScanProbe(UltraScanInfo *USI, HostScanStats *hss,
                               const probespec *pspec, u8 tryno, u8 pingseq) {

It appears that each probe will be sent from your real source address according to your timing options, but at the same time it will be sent from all your decoys. So your target should see synchronized -T1 scans from number_of_decoys + 1 different sources, which will be number_of_decoys + 1 times more packets than a non-decoy scan.


Colons in URLs: Safe? A friend asked me if it is relatively safe to click on the following link:

https://disq.us/url?url=https%3A%2F%2Farstechnica.co.uk%2Finformation-technology%2F2017%2F01%2Fantivirus-is-bad%2F%3Av0Er-2ea1-t4FcbndbRV_9xv5-4&cuid=977864

contained in the comment on this page:

https://betanews.com/2017/05/09/microsoft-fixes-crazy-bad-windows-vulnerability/#comment-3296284701

Taking a look at the link, I rewrote it to go directly to the article it was referencing, and provided my friend with the simplified link. (Note that I am neither condoning nor condemning any positions in the article itself.)

But taking a look at the original URL, you will notice it contains a colon in an uncommon position (the colon is encoded as %3A after bad%2F).

From a security standpoint, does that colon represent any hazards?

Also from a security standpoint, are there any serious hazards created if a user clicks on the original disq.us link above?

In HTTP(S) URLs, the : (in its direct form) has these purposes:

delimiter between scheme and hier-part (http://example.com)
delimiter between host and port (example.com:80)
(deprecated) delimiter between name and password in userinfo (user:password@example.com)
in the host, it may be part of IP addresses

In the path, the query, and the fragment, the : can be used to represent data. So there is no technical difference between a path like /hello and a path like /:hello.

In your example, it’s percent-encoded (as %3A). Any percent-encoded character can appear in the path/query/fragment, where it represents data.

(Terminology based on the URI standard)

There is nothing problematic for security about : or %3A in the path/query/fragment, compared to any other character that can appear there. Whatever could be done with : (e.g., using it as prefix for a user tracking string) could as well be done with !, ;, etc.

What probably happens in your case (just a guess from observing the link/redirect, I have no experience with Disqus):

When a user posts an external link, Disqus doesn’t link it directly. Instead, they link to their own service http://disq.us/, which then redirects to the original URL.
Disqus adds the original URL as value for the url parameter (to which it adds a cryptic string prepended by :), and an ID as value for the cuid parameter.

The :-string is generated (and remembered) by Disqus (see point 3 for what it might be used).
The cuid indicates the Disqus account of the site owner where the comment with the external link was published (probably for analytics purposes).

For a specific original URL, the redirect only works if the disq.us URL contains the same :-string that was generated when the original URL was first submitted. This could prevent that their redirect service gets used for URLs that were never posted in a comment.

So clicking this link can affect your privacy, even if you have disabled sending of the Referer, and even if you don’t execute JavaScript:

The linking site owner can know that you clicked their link.
Disqus can know that you clicked this link (and on whose site, possibly also page).
The linked site owner can know that you came from a link in a Disqus comment, and possibly also from which site/page (e.g., if the Disqus cuid can be found in a search engine).

To prevent this, you could extract the url parameter value, remove the last part prepended by (and including the) %3A, and percent-decode the result once. This allows you to visit the linked document directly, without going through Disqus’ redirect service. This works as long they decide to include the target URL in their redirect URL (which they wouldn’t have to).


Why does this Laravel CSRF vulnerability work? Recently Laravel 4 was updated to address a security concern: there was a CSRF vulnerability in their code.

Here's the old code:

if (Session::token() != Input::get('_token'))
{
    throw new Illuminate\Session\TokenMismatchException;
}

And here's their fix (note the !==):

if (Session::token() !== Input::get('_token'))
{
    throw new Illuminate\Session\TokenMismatchException;
}

I understand the difference between == and === in PHP (basically the latter is more strict because it checks type), and I understand what CSRF is and how to address it, but I don't fully understand why this specific case creates a vulnerability, or how an attacker would exploit it.

chrismsnz here...

Long story short, DarkLighting is pretty much right.

Input::get() usually reads from request parameters, but if the request is JSON then it reads from the JSON body. JSON allows you to specify the type of data so instead of a CSRF token string, I sent an int(0) which will pass that loose comparison most of the time.

The other trick is that usually you cannot send JSON requests cross-site, due to the CORS check in browsers. However, Laravel has a very poor JSON check, it basically checks to see if the string '/json' is anywhere in the content type and if its there, runs the whole request through a JSON parser and feeds it into Input.

Therefore you can exploit it using something like this (jquery example)

$.ajax("http://<laravel app>/sensitiveaction", {
    type: 'post',
    contentType: 'application/x-www-form-urlencoded; charset=UTF-8; /json',
    data: '{"sensitiveparam": "sensitive", "_token": 0}',
});


Which Rogers internet compatible router is most secure? Without telling you which specific Rogers-provided router, version, nor the terrible but verified security bug that exists for it (them), would any dear somewhat security conscious Rogers customer here please provide an alternative, and hopefully more secure, modem to use with Rogers?

Actually, to switch the router to another make and model was recommended to me by Rogers internet staff themselves.

It isn't fixed, and since I seem to have no way to be able to update the firmware by myself, I'm assuming this is 0day.

This all seems too crazy to be true - that they've let this slide for a number of months now, without knowing about it - both the original manufacturer, and more so Rogers.

Instead of placing your trust in Rogers (or any internet provider), you can certainly take responsibility for your own security.  Purchase your own router/firewall appliance, and connect all your home machines to it.  Then connect your router to the Rogers router.  That way, even if your Rogers' router is compromised, the infection remains isolated outside of your devices.

Inexpensive routers are widely available.  And if you still don't trust them, you can purchase the kind that lets you replace its firmware with an open source alternative, like OpenWRT or Tomato.

While there may not be much difference between a Rogers router and a cheap router, keep in mind that most router attacks are perpetrated by attackers who are using robots to sweep millions of machines looking for vulnerabilities.  Once the robots find them, the thief enters the network and sees what they can steal.  If they break through your Rogers' router and find only another firewall, they may decide your system is not worth their time to attack.


A protocol to authenticate users without login/password A casual message exchange on reddit yesterday got me thinking whether it might be possible to design a protocol that removes the need for users to remember a unique password for every service (s)he connects to.

The idea is that essentially each user supplies identifying credentials (name, date of birth, city of birth) and a secret pass-phrase. Based on this information, and the service being accessed (optional, in case the user does not want to be tracked across services), the client software can deterministically generate a RSA keypair (using a secure hashing scheme, SHA-512 maybe).

The public component of this keypair is passed to the service, and serves both as an authentication token and an encryption key. User need only remember one pass-phrase, and credentials to access any service from any client, with the public key being her secure identification.
Ephemeral session-specific keys can still be used be used for forward secrecy.

I'm wondering what the drawbacks to this scheme are? It is not susceptible to spoofing unless the imposter gets hold of the private key, lack of multiple passwords make it more secure and reliable for users. It is susceptible to MITM and a compromised client (because it sees the pass-phrase), but that is the same as SSL today, and the threat of key-loggers.

So, I'm just wondering if there are any serious drawbacks I have missed, and also if someone wanted to experiment with this, would it make sense to build this on top of TLS (an extension to http, maybe), or to replace it?

Thank you!

Edit:
Thanks Thomas Pornin for the well-reasoned answer.
I wonder if the following are valid rebuttals to the (well-founded objections) you raised:

1.Since there is only one password in this scheme, it is not unreasonable for there to be stringent complexity requirements (e.g. at least 128 bytes etc), so it is not susceptible to dictionary attacks. Dictionary attacks are really the same as saying if the attacker has infinite resources at his disposal, he can brute force any scheme. As long as the scheme is such that no information can be obtained by guessing portions of password, then it is surely possible to make dictionary attacks impractical?

Regarding need for changing the password: this would not be possible within the limitied protocol described in the question. Maybe when registering the users' public identity, the server can send a secret encoded with users' key that should be used only to invalidate the identity when required?
As long as there is a public key per service (i.e. generated deterministically based on an unentangleable combination of user password and service identity, then an attacker can only compromise the access on a particular service).

Btw, do you know of any well known algorithms to generate the key pair based only on a (for instance) 512 bit number? I suppose this is same as asking if there is a way to find the closest safe prime given a number. Thanks!

Your idea is twofold:

Use an asymmetric key pair client-side for authentication.
Generate the private key deterministically from a password.

First part is standard issue in SSL; see the standard. Web browsers support it (but their GUI has long been ugly, confusing, or both).

Second part is not supported by widely deployed software, but it is not new, and it works, with the following caveat: it allows for offline dictionary attacks. Indeed, the client public key is public and is sent "as is" (within the client certificate) to any SSL server who asks for it. Also, by nature, the server must see it at some point. Since the private key is generated deterministically from the password, an attacker can then "try" passwords on his own machine, looking for a match with the observed public key.

This is actually very generic. Consider a system and protocol, where both client and server are "open": none of them stores any secret value, in the eyes of the attacker -- if the server can store secrets, then the proverbial list of (hashed) passwords in the server's database is enough. The only secret in the whole system is the user's password, which is stored in the user's head, and is unknown to the attacker. The attacker wants to recover that password.

Under these conditions, for any protocol you may come up with, offline dictionary attacks are possible. That's consubstantial to the openness of the systems: since the attacker is assumed to know everything about the whole setup except for the user's password, then he can emulate the whole thing on his own machines, for each potential password: the attacker runs both client and server in a virtual environment on his own cluster.

Throwing in RSA and hashing and whatsnot won't change anything to that. Once offline dictionary attacks are possible, you are back to the robustness of the password itself. There are ways to try to cope with offline dictionary attacks, but the situation is still, on the whole, uncomfortable.

To resist offline dictionary attacks, you must have a secret on either the client or the server. On the server, this is the usual model of hashed passwords in a database which the server tries to protect (with more or less success); the passwords are not stored "as is" but hashed, as a second line of defence. On the client, just store an asymmetric private key; possibly, encrypt it locally with a password, as a second line of defence. This is supported out-of-the-box by existing browsers (well, at least Firefox and its "master password").

Apart from the security concerns about dictionary attacks, there are practical issues with deterministic private key generation from the user password. In particular, what happens when the user changes his password ? His key pair mutates. Thus, all servers with which the private key is used must be contacted to acknowledge the new public key to accept. This brings to the dance the usual problem of public key distribution, then PKI, certificates and their ilk. This has long range ramifications.


Disadvantages of a single administrator checking all file permissions What would be the security disadvantages of a single administrator checking every file permission in a network of computers? Obviously this is a theoretical question.

I'm thinking that the fact that one entity has control over every file in the system would mean that:

a) The administrator could accidentally or purposely cause harm to important files.

b) A malicious entity could gain access to the administrators account and cause significant damage to the whole system

Is there anything else I should consider? I need to think about this in terms of likelihood or extent of damage caused by an attack.

Thanks

If the task assigned to the staff member is simply to check file permissions not modify them, then a copy of the file system's access control table could be given to the staff member by a more trusted administrator. The staff member could then review the file permissions, independently of the actual access control list. NTFS for example. Directory listing tools and scripts could provide the same information.

If an untrusted staff member needs the root privileges for modification, installation or other activities; I can think of two precautions off-hand:

Backup the computer before giving them access. Revoke access after the work is complete, and then compare the computer against its backup to see what exactly was changed.
Route all console commands through audit logging proxy box that the staff member does not have access to. This way at least the staff member can't pretend they didn't run various suspicious commands. Limited to monitoring non-interactive tools, unless the proxy machine also video logs all screen display and audio.


JSON Web Token secret storage I'm building an app where the client will be issued a JWT. The JWT will be passed to my API for every request. I'm leaning in the direction of hosting my webserver and SQL server separately from each other using EC2 and RDS.
SECRET = bin2hex(random_bytes(32))
My question is... which is the better practice for storing the secret?

Creating a file on my server (outside of my webroot) that stores a single secret that is accessed by my API's PHP scripts.
Creating a file on my server (outside of my webroot) that stores a list of individual secrets per user that is accessed by my API's PHP scripts.
Creating a SECRET column in my database where each user has their own JWT secret.

My thinking on #2 and #3 is preventing a brute-force attack from potentially affecting everybody.

Using per-user secrets - stored in either the database or the file system, or indeed anywhere else - completely misses the point of JWTs. Well, one of the points, and using symmetric secrets (rather than public keys) means you don't get the other, either.
If you have to look up a value before you can even verify a JWT, you've destroyed the scalability and statelessness of the format. Sure, in practice you'll store lots of info in the DB, much of it per-user, that you'll be requesting all the time anyway... but if you're going to make your session management system depending on those kinds of lookups then you should really consider just using random blobs for your session tokens. Same lookup hit, less compute time after retrieving the secret to verify it, and you can actually revoke them without complicated shenanigans.

To answer your actual question, the ideal setup is an HSM of some sort (such that actually extracting the keys is just not possible), but lacking that the usual approaches are:
A. Stored in a KMS (Key Management Service) that the server can talk to; server retrieves the secret(s) at startup / periodically and stores it/them in RAM. Of course, proving identity to the KMS often adds another layer of "where do you store secrets?"; the main advantages of this scheme are a central location to manage keys for a whole cluster, and the ability to keep the keys off of any persistent storage outside one particular system.
B. Stored in an environment variable or command-line arg passed to the server. Obviously the process that invokes the server needs to know the secret too, but this can be combined with the previous approach to have no persistent storage on the server host but also allow creating arbitrarily many short-lived instances of the server without each one pinging the KMS. Alternatively, supports starting the server process via remote command, with the secret not resident anywhere on the server host (even in memory) until the server starts.
C. Stored in a file outside the webroot, but somewhere the server has access to (your #1). Ideally, the location should not be somewhere the server has persistent access to, though, either because it drops privileges after reading in the secret, or because the secret is read through a named pipe or something and not available on demand.
For simple systems like you're probably envisioning, where quick development and low cost matters more than security in the extreme edge cases, you probably want to go with approach #1 / C, if you use JWTs at all.

Speaking of extreme edge case concerns, brute-forcing any reasonable length (typically cited as 128 bits i.e. 16 bytes) of cryptographically random data (which PHP's random_bytes provides) is not remotely a concern. With a 256-bit (32-byte) value, assuming Moore's Law continues on track (which it hasn't quite, lately), the entire world's compute capability, working together, might be able to brute-force a single secret... if you give them three to four centuries to do it. You probably won't care by then.


Is it possible to Identify a VPN user by finding relations in traffic? If I am using VPN service to protect my identity, can my traffic be used to identify all my traffic?

For example, if I am accessing two services:

Some service A, where I do not leave any identifying information.
My personal E-Mail account.

Can someone find a relation between (1) and (2), such that he will be able to tell that both are accessed by the same person.

Naively I would think that it is impossible and someone would at most be able to tell that I am using VPN provider to access my E-Mails, without knowing about (1).

But perhaps my computer, browser or something else leaves some kind of signature in the data, which would enable someone to find a relation?

This depends on whether you are worried about being convicted, or dealing with probable cause (in the U.S.).

Let's assume that you are at home.  You start up your VPN and connect to your offsite VPN provider.  If I am monitoring outgoing traffic (from your house), I know that you just connected to a certain IP address, and that the IP address is a VPN provider.  Everything inside the payload of the packet is encrypted.

You then decide while at home, to check your email.  I happen to be monitoring outgoing traffic from the VPN provider (which is not encrypted).  I record it all using snort, and run Wireshark against the output.  I see a connection to your email address and an email written.  This may be protected by SSL if it's webmail.  If it's regular email, it's likely plain text.  If it's not plain text, I can try to intercept it at the receiver.  The email is of no legal significance (i.e. you aren't using it to plan something unlawful).  However, I make note of the fact that you confuse the use of their, there, and they're.  I'll also notice a few idioms you like to use.

Over the course of monitoring outgoing traffic I see your account write several emails.  I note patterns of misspellings, and more figures of speech.  I collect these over a period of a month or two.

I then put the items that I notice into Wireshark.  I add several things that you are known to say.  Every time a misspelling occurs, or the use of an idiom (that you use) is found in the content of ANY packet that is outgoing from the VPN service you use, I view it.

Given another month or two I have a lot of data points.  Some are sites you went to, others are not.  The first thing I do is eliminate all of the data points that exited the VPN service provider while you were NOT on line (i.e. I didn't see you online from home, remember I started by monitoring that connection).

Then I look at the remaining traffic and see if I have any cluster points.  Lots of recurring themes.  Same subject matter over an over.  I compare that to your unencrypted traffic, and your email.

I haven't applied enough filters to isolate you from the noise (people that use the same idioms/spelling errors you do), but I would have a good case for probable cause.  If I have enough points of reference, it is just like a fingerprint.

Essentially I'm applying a Bayesian analysis to a corpus of work, to state something about the likelihood that I believe an exemplar to be a member of the set constructed by my suspect. The collection of works that I would compare to comes from any work that the suspect has publicly acknowledged they are responsible for.  That analysis is well-known (and there's a whole statistics StackExchange site, too).

I'll let you answer, what would I come up with at this point?


IKEv2 Authentication - why/how does it work? I am currently trying to understand the IKEv2 protocol which is used for IPsec and am wondering why/how the authentication process works.

From my understanding, in the prior IKE_SA_INIT exchange, the Initiator and Responder agree on a crypto suite, send each other their DH values and a nonce.

The following IKE_AUTH exchange is supposed to verify the peers identity to each other. The protocol derived a lot of keys from the shared secret SKEYSEED that got calculated using the DH values and nonces.
In the IKE_AUTH exchange a one of the keypairs is used to basically just sign a block of data - a copy of the prior IKE_SA_INIT exchange, the peer's nonce and prf(SK, ID).

What I don't understand is the fact that since the DH values and nonces are sent unauthenticated and unencrypted in the IKE_SA_INIT exchange, couldn't an attacker just spoof the identity of the opposing communication partner and perform a MitM attack?

At what point in the protocol would such a MitM attack, that e.g. replaces the DH values, be recognized by the other side?

Thank you very much in advance!

The point of DH is that only the two parties can generate a shared secret (gxy) for the DH exchange.  SKEYSEED is not the shared secret for the DH exchange.  In fact its derived from the DH shared secret and the nonces; not from the transmitted DH parameters.  SKEYSEED is never transmitted over the wire.

Once the DH exchange is complete, and encryption/integrity keys are generated, the AUTH messages are used to prove the identity of each side.

RFC 5996: Section 1.2

  The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload (see Section 2.15).  It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s).  If any CERT payloads are included, the first certificate provided MUST  contain the public key used to verify the AUTH field.

For a MitM attack to work you would need to know the DH shared secret.  You can't simply replace the DH parameters.  The values exchanged are gx mod p and gy mod p.  You need to know x or y.  These are not easily calculated because you need to perform a discrete log on a (what should be) very large number.

You can try and impersonate one side of the negotiation, but that's not really a MitM.  And IKEv2 is not what would protect against this type of attack.  That would be the job of firewall rules and what not.


Is it insecure to temporarily save user's data in a session while they register? My plan is to save the registration, as they go along so if they close the page by accident they will still have all of there information saved so they can continue it again.

But my question is it secure to save there data (like passwords) in plain-text on a session?

It is never ok to store a user's password in plain text. Let them retype their password.

Perhaps letting their browser's form filler remember the data will work better. Those are generally careful about doing the right things with passwords.


Malicious Twilio XML response object So I was looking at some firewall logs and saw some strange activity on a remote IP address. I checked out the address via browser since https was open, the certificate was for *.twilio.com and twilio.com. It's an AWS address which is a popular choice for hackers who want to spin up a free server.

My first question is how could they get both the certificate and key for the twilio wildcard certificate?

My second question is what does this XML response mean? The page is masquerading as the twilio website. They owners of the firewall use twilio for phone and text purposes, could this XML response be used to do that? There were 2 recent attempts to execute this code.

<TwilioResponse>
<Versions firstpageuri="/?Page=0&PageSize=50" numpages="1" end="1" total="2" previouspageuri="" lastpageuri="/?Page=0&PageSize=50" uri="/" pagesize="50" start="0" nextpageuri="" page="0">
<Version>
<Name>2008-08-01</Name>
<Uri>/2008-08-01</Uri>
<SubresourceUris>
<Accounts>/2008-08-01/Accounts</Accounts>
</SubresourceUris></Version>
<Version>
<Name>2010-04-01</Name>
<Uri>/2010-04-01</Uri>
<SubresourceUris>
<Accounts>/2010-04-01/Accounts</Accounts></SubresourceUris></Version></Versions>
</TwilioResponse>

Yea it was a legit twilio server. Jumped the gun a bit. We are concerned about insider and outside threats due to two strange server failures. The /etc directory and /usr/bin directory have been deleted on both occasions so there is some type of foul play going on,not sure from where though.


CSRF Protection on static pages I have a static site which has forms. The forms submit to a Rails endpoint which captures the submitted data. The static site and the Rails endpoint are on the same domain, on different subdomains and all traffic is completely on HTTPS.

I understand how Rails CSRF works for server generated forms. But in my case, these forms are on static HTML pages. I understand all request headers can be faked, so can't rely on that.

If a strong solution is not possible for this scenario then my last option would be to move to server generated forms (which I want to avoid for now).

Any suggestions on a good approach to this would be most welcome. Or any pointers to a system or a library which already does this.

I could implement a REFERER check on the HTTPS POST request (in my case) - is that enough ? Can that not be spoofed ?

The CSRF prevention cheat cheat sheet says: Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. - I don't quite understand this.

Any help would be much appreciated.

Personally, I do not recommend using the Referer header to stop CSRF attacks.  It has two issues:

First, it is fragile.  There is a long past history of attacks on the Referer header, involving (variously) exploits on plugins (e.g., Flash), bugs in browser APIs (e.g., XHR), and redirection.  To be clear, I'm not saying that checking the Referer will necessarily be insecure; I'm just arguing that I think it's more fragile, and I would have more confidence in a solution that uses CSRF tokens.
Second, some browsers and corporate firewalls block the Referer header for privacy reasons, meaning that you'll be forced to block legitimate users.  So the Referer header is simply not a good solution.

Instead of using the Referer header, I would recommend that you use CSRF tokens.


Are there potential risks to sending HEAD requests to user-supplied URLs? I have an application that unshortens URLs by using the python requests library to send HEAD requests with allow_redirects=True. I don't do anything with the response except check the response URL. Since the URLs are provided by users, is there a risk of the production machine being compromised by a malicious server?

You're providing a tool for outside attackers to probe your internal network. By specifying different hostnames or IP addresses and different ports, an attacker can enumerate the portion of your network that is invisible to them. Even if you don't return any actual information that distinguishes between "there's nothing there", "there's a machine at that address but it doesn't listen on that port", and "there's a machine at that address listening on that port, but it doesn't speak HTTP", an attacker might be able to figure out the difference from timing or other side channels. Additionally, if you have any internal web services (fairly likely) and they respond to any requests with redirects to other internal services, you will end up directly exposing those redirected-to internal addresses to the attackers.

Although the maximum impact of this kind of attack is fairly low in isolation, the information gathered can be quite valuable for future attacks. The more understanding an attacker has of your network topology and running services, the faster the attacker can pivot across your network to reach their target (source code, credentials, sensitive data, critical systems that a ransomware attack would really matter on, etc.) once they manage to breach some system on the periphery of your network. Since incident response is largely a matter of speed and you can never assume your periphery is fully secure, this could be the difference between "somebody breached our bastion host but we stopped them before they got anything sensitive" and being the next Equifax or Target or whatever.

You can, of course, mitigate this risk by filtering the requests to only external sites. It can be tricky, in a large company, to determine what is and is not external, though; what if somebody uses this to port scan your recent acquisition to whom you've added into your VPC but not yet updated your "external" list? Also, many companies have their own URL-shortening schemes, which would of course go to an internal service but which a user might reasonably want to unshorten.

EDIT: You're also adding a system that will serve attacker-controlled content to users. If a user sends a query to a malicious URL, and the server responds with a malicious redirect header, you will presumably return this value to the user. Depending on how the returned value is presented and what format it's in, you risk enabling attacks such as XSS or header injection. Obviously, there's ways to handle potentially-malicious user-supplied content (escape/encode output, and potentially also validate content as a defense-in-depth), just make sure you use them here.


Changing session id after login My web application is only accessible for authenticated users. Before login the user can only see the main page with a button to log in. The application assign a session ID on the main page, the authentication is handled by other application.

After login and coming back to my application the user still has the same session ID. However, it will be changed after logout.

OWASP ASVS states that session id should be changed on login, but I do not see a clear point why it is necessary for this situation? Is it necessary to change it?

The reason why it is best to change session ID's upon login is due to potential man-in-the-middle vulnerabilities. If an attacker captures your session ID, they can use it to pose as the legitimate user. This is called a session-fixation vulnerability. Changing session ID's upon every login will help to prevent this vulnerability, as the previous session ID will be deemed invalid and the attacker can not use it to authenticate anymore.

References:

https://www.owasp.org/index.php/Session_fixation
https://www.owasp.org/index.php/Session_hijacking_attack


Detecting GSM activity Is it possible to detect the GSM usage activity using SDR? I know that it's possible to do this using EMF meter, for example. What about SDR?

Radius of the range: 30-40 meters

P.S. ..GSM activity - by that I mean the usage of GSM networks by mobile phones, for example.

P.S. ..GSM activity - by that I mean the usage of GSM networks by mobile phones, for example.

Depends. If you just want to see if there is any activity I suppose you could simply have a look at the frequency bands activity in e.g. gqrx. The frequency bands available are listed here.

It's possible to script gnuradio to watch multiple channels for activity so you might be actually able to watch the GSM band without really looking into decoding the actual GSM protocol on the fly. But that really depends on the capabilities of your SDR device.


Preventing dangerous CSV Formula Injection I have a form that takes user input and records them in a table. My form sanitizes user input by deleting certain characters (mentioned below). I can export a CSV of the table, which outputs the cells as it is.

The correct way to prevent a CSV injection is to prefix a single quote to the start of a cell that looks like a formula, i.e. those starting with =, +, -, @ or |.

However, if the input instead escapes characters like ;, ! and | by deleting them before it gets recorded in the table for CSV export, will that be sufficient by itself?

So far, the only 'injection' I have managed to do is '=SUM(1+1)', due to it being impossible to use popular payloads like @SUM(1+1)*cmd|' /C calc'!A0 or DDE ("cmd";"/C calc";"!A0")A0, as the key characters get deleted.

I don't think that stripping some characters can be a strong solution, especially if you develop the functionality by yourself: someone could manage to bypass this check by encoding these characters for examples, and get the formula executed anyway (Maybe your CSV reader, i.e. Excel, parse the formula differently than you and execute it anyway). Best solution is to use already tested mitigations, like the one you mentioned of putting a single quote at the beginning of the string. Another solution is provided by NCC Group in this report:

  When performing a CSV Export, for any cell that starts with an =, -,
  ", @, or +, add a space to the beginning and remove any tab characters
  (0x09) in the cell. Alternatively, prepend each cell field with a
  single quote, so that their content will be read as text by the
  spreadsheet editor.


Bypassing CVE-2010-4478 (J-PAKE parameter validation) in OpenSSH 5.1 Did anyone successfully exploit CVE-2010-4478 in the past? This is insufficient validation of the J-PAKE public key parameters in OpenSSH up to 5.6.

I'm dealing with a vulnerable machine running OpenSSH 5.1 p1. I need to get a flag but in order to do so, first I need access to the server. I found the vulnerability of jpake, but I've been trying to exploit it with no luck.

I downloaded the code from https://github.com/seb-m/jpake/tree/master/openssh-jpake then downloaded a OpenSSH client v5.1 p1, replaced the files downloaded from github and ran make. The code won't compile unless I comment lines 156-159 and 1316-1317 in sshconnect2.c.

I don't think those lines are relevant but when I try to use the exploit as said in the readme, ./ssh -o "ZeroKnowledgePasswordAuthentication yes" user@host, I'm getting an error saying that this option doesn't exist, so I don't know whether it's due to comment those lines out or due to another thing.

That's why I'm asking whether is there someone who have successfully exploited this vulnerability in the past, and can throw some ideas about why it's not working. Also, if you know any other way to bypass the authentication of this version of OpenSSH, it is very welcome.

edit: I already got access to the server by another mean, but I'm keeping this question opened to see whether or not someone has something to say about it.

It's unlikely that the server actually supports J-PAKE - it has never been enabled in any shipped version of OpenSSH. I don't know of any OS distribution that enabled it either.

Unless the server's admin manually enabled it by setting an undocumented build-time preprocessor flag, then the server won't support it.

You can check by running "ssh -vvv user@host" and looking for a line:

debug1: Authentications that can continue: ...

And looking for "jpake" in the list.