In SSL/TLS, what part of a data packet is Encrypted and Authenticated? I'm trying to wrap my head around the Application Data record that carries secured traffic.  I understand TLS/SSL is a "authenticate-then-encrypt" protocol, which means an HMAC is calculated over the Plain text, and the resulting digest is appended to the message.  Finally, the whole packet is encrypted using the negotiated cipher.

I also know that the first three fields of an "Application Data" record are:

Content Type (0x17 to indicate Application Data)
Protocol Version (0x0301 for TLS1.0, et al)
Record Length (length in Bytes of encrypted content)

Given the following (simplified) "Data"

GET /index.html HTTP/1.1
Host: helpme.com

What would the resulting encrypted packet look like, and what parts would be encrypted, and what part would be Hashed?

Please use the following (again, simplified) illustration to make answering this easier:

01   |  ContentType  |  ProtocolVersion  |  RecordLength  |
02    GET /index.html HTTP/1.1
03    Host: helpme.com
04   |  HMAC  |  Padding  |

My best guest from reading through RFC 5246:

Lines 01-03 are included in HMAC
Lines 02-04 are included in Encryption

Any help is appreciated.

SHORT ANSWER

In the case of HTTPS, any data that would have been sent had the connection not been secure, will be sent as encrypted application data. Additionally, for historical reasons, the MAC and Padding will also be encrypted. In SSL 3.0 and TLS 1.0, this means that the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (encrypted)    GET /index.html HTTP/1.1
03 (encrypted)    Host: helpme.com
04 (encrypted)    |  MAC  |  Padding  |

Note that, strictly speaking, the MAC is only a HMAC in TLS 1.0 and up. In SSL 3.0 it was a special mode used only in this protocol.

SLIGHTLY LONGER ANSWER

Starting with TLS 1.1, if a block cipher in CBC mode has been negotiated, an explicit IV will be inserted at the start of the encrypted data:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02                IV
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com
05 (encrypted)    |  HMAC  |  Padding  |

The IV is there to make the cipher text unpredictable and less susceptible to certain cryptographic attacks. Implementations might treat it differently both at encryption and at decryption. Some implementations might generate it from random, while others might generate it as the cipher text of the last block of the previous fragment XORed with a constant value. Conversely, at decryption, implementations might treat it as either an independent field or as the first block of cipher text (and discard the corresponding decrypted block before outputting the decrypted plain text fragment, just as the HMAC and Padding is discarded).

Starting with TLS 1.2, an AEAD cipher might be negotiated, which means that the MAC mechanism is integrated into the cipher mode and no HMAC will be required. In this case the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (plain)        Nonce
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com

Note that the length of the cipher text corresponding to field 03 and 04 will be longer than the length of the corresponding plain text. The exact layout will depend on the details of the AEAD cipher mode. Normally, it will just end with a MAC.

Now, to complicate things further,  in all protocol versions and cipher modes the MAC will be calculated over data that differs from both the plain text (optionally compressed) fragment and from the encrypted fragment. In particular, the RecordLength field will have the plain text / compressed value (not the encrypted value) and a Sequence Number will be inserted to prevent replay attacks. The MAC itself is obviously not included in the data the MAC is calculated over, and neither is the padding. The last part, the MAC not being calculated over the padding, is the reason some of the attacks against SSL/TLS are possible.

IMPLICIT SSL / EXPLICIT TLS

HTTPS is an instance of Implicit SSL, which roughly means that SSL/TLS will be the outer most protocol layer of the connection. The first thing to be sent over the connection is a SSL/TLS handshake, and all application data will be sent encrypted. HTTPS will always be Implicit SSL.

By contrast, Explicit TLS means that SSL/TLS will be negotiated explicitly as part of the underlying application protocol. This is common e.g. in the case of application protocols such as SMTP, POP3 and FTP. When Explicit TLS is used, the first data sent over the connection will be the opening protocol messages of the application protocol.

Note that the "SSL" and "TLS" part of Implicit SSL and Explicit TLS is a misnomer, in the sense that it is perfectly possible for a client and server to negotiate TLS 1.0 or higher over an Implicit SSL connection, and conversely to negotiate SSL 3.0 over an Explicit TLS connection.

CAN CLIENT AUTHENTICATION AND SESSION RESUMPTION BE TRUSTED?

To complicate things further, it should be remembered that encrypting something for someone, doesn't guarantee that entity will be the only one reading the encrypted data, because there is never possible to prevent the recipient from simply forwarding the decrypted plain text to a third party. This is in particular important in the case of SSL/TLS, because authentication normally only goes one way (the server authenticates itself to the client) and a special handshake is required to authenticate the client to the server.

This attack demonstrates how this fact can be exploited with current protocols and some cryptographic primitives. There are however a few things that can be done to prevent this from happening. For instance, the following rules will prevent the attack, but might break compatibility with existing implementations:

When the server requires client authentication, either:
a. Send a hello_request first thing after the initial handshake has finished and request client authentication for this second handshake, or
b. implement the application protocol (or the application using the application protocol) in such way that no data sent prior to client authentication will be treated as authenticated by the client, e.g. by internally starting a completely new application session and having the client resend anything it sent prior to the authenticated handshake.
When a connection has been initiated with a resumption (abbreviated handshake) treat any hello_request or client_hello messages over that connection as errors.


Can Self extracting rar file (SFX) be used to automatically install malicious software? Self extracting RAR files can be made containing dangerous files but can these SFX files be used as a tool for social engineering attacks (email attachments or on promotional CD-ROM etc.) to trick a user to install malicious software (RAT or keyloggers)? or are these SFX files detectable by security software?

As SFX are executable program files they can at least be infected by a malware/virus/trojan, like any other program. Such malwares can be used to install malicious software, directly or indirectly (by dowloading something, for example).

I don't know whether there are specific exploits tied to SFX though. The above is general to executable files. The only SFX vulnerability I found so far is this one, which doesn't prove there is no more harmful one.

Reading this link from RARLab.com can be interesting for more details: http://www.rarlab.com/vuln_sfx_html.htm

Also, when you wish to unpack a SFX, nothing prevents you from opening it with WinRAR instead of executing it as a program. This way the unpacking executable part of the archive won't be executed. This is just a first level of protection though as once again I'm not sure whether SFX-specific exploits exist.

Regarding the detection of such malwares, it is all up to your antivirus. Basically, they won't be detectable at the very beginning ("the first day") but will probably be after the next "malware definition files" update of your antivirus. (More about that in this other answer: https://security.stackexchange.com/a/140450/126594)


How can I delete a password and lock the account in one step? I have a minimal server install on a remote machine with a root password set to a temporary, but chosen, value.

I have added a separate administrator user. This user has an authorized key for SSH, no password access, and passwordless sudo.

I would like to remove any trace of the root password and lock the root user.

This can be done with passwd -d root && passwd -l root. However, this leaves a window between the two operations for bad behavior. How can you take both actions in one step?

This is more of an academic question than a practical one. My solution is sed -e -i -e 's/^root:\([^:]*\)\(.*\)$/root:!!\2/' /etc/shadow, but it feels like there should be a less error-prone, idempotent operation.

You may want to try:

usermod -p '!!' root

usermod with the -p parameters takes the raw value to bet set as encrypted password in the /etc/shadow files.

The traditional usage of this parameter is to give to usermod an already encrypted password, but it accepts also the '!!' flagging the account as locked.

In the end, this command will remove the current password and leave only the exclamation marks setting the root account as locked in the passwd way¹, all in one move using a safe and standard command, thus fulfilling the request.

¹: According to this discussion, there is no established standard on the way to lock an account. So usermod -L uses only a single exclamation mark (!) in front of the hashed password to lock it, while passwd -l uses two (!!).


What is the best way to track the authenticated user on the server side? For a web app, the client side is javascript in the browser. The server side is ASP.NET with a REST API. At present there is a single server but we plan to scale out with a server each in the US, UK, and AUS (on Azure). We'll have redis (but that does not sync up instantaneously). They will (almost) always be using SSL.

When a user logs in, we authenticate them. It's easy to pass back the primary key of that user record in the DB and on subsequent calls in, pass that PK to identify the user. It's also trivially easy to then impersonate any user.

What's the best way to implement this? The two things I have thought of are:

Return a guid and require that guid on all subsequent calls.
Store the PK in the Session data on the server side and use that to identify the user on all subsequent calls.

Both of the above work if an existing session continues to go to the same server (which I believe it does) for each subsequent request.

So, what's the best way to do this? Either of the above two? Or is there another approach that's better?

thanks - dave

In ASP.NET you can keep the session in a data store instead of in memory, this is useful for load balanced deployments. The session can be kept in SQL and I have also found an example of using Redis to store it so retrieval is faster.

So in your case I would use ASP.NET authentication and then use the session to keep the primary key you mentioned in order to recognize the user.


NTLMv2 Reflection Attack I am trying to figure out if NTLMv2 is vulnerable to a reflection attack. I cannot find a citation that clearly states NTLMv2 as being vulnerable. NTLMv1 is horribly insecure so there really is not point in even discussing the security of NTLMv1. No client should initiate NTLMv1 and no server should accept it.

The reason I have doubts is that NTLMv2 has "Target Information" that includes the name of the server the client is initiating to. Here is a screenshot of this Target Info from a typical NTLMv2 over HTTP authentication:

If an attacker tried to reuse this challenge by sending it back to the server over a separate authentication instance, the server could clearly see the target information was simply not correct. And you can't change the target information because it's factored into final token so the hash would come out wrong.

So can some explain to me precisely how a reflection attack would work with NTLMv2?

UPDATE:

Ok, then let's talk about this "SMB Relay Attack" which several people have mentioned. I am interested in any NTLMv2 exploit.

Specifically, the links posted by markgamache are not clear about NTLMv2. It does not explain the precise mechanism. Yes, a man-in-the-middle is easy with the NTLMv1 NTLMSSP_AUTH hash (not to be confused with the password equivalent hash obtained from something like meterpreter> hashdump). But NTLMv2 is different. It was specifically designed to thwart MITM types of attacks. My understanding is that it uses the "Target Info" block which contains the "DNS computer name" and "NetBIOS computer name" of the target (see screenshot above). This block of data is factored into the computation of the NTLMSS_AUTH hash. Therefore I would think that either the client or the server would detect if this information is incorrect (with or without signing).

Unfortunately it seems like a lot of the documented exploits are 90% about NTLMv1 and then they just casually claim that NTLMv2 is equally vulnerable without providing the details. It makes me wonder if they are mixing up unrelated concepts. For example, if an attacker obtains the raw password equivalent hashes, they can be used with NTLMv1 or NTLMv2. But of course this requires either Administrative credentials (to insert code into lsass.exe to dump passwords) or brute force NTLMSSP_AUTH hashes which is difficult.

UPDATE 2:

After a lot of web searching, I think this link (provided indirectly by atdre) is the best description of the Reflection / Relay issue which are largely the same:

Protecting Privileged Domain Accounts: Network Authentication In-Depth

Regarding the Target Information block, I can only conclude that clients simply do not try to verify that the name matches the target for whatever reason.

Reflection? Not unless the system has failed to patch MS08-068.

Relay? Yes, NTLMv2 is vulnerable because of SMBv1/v2. Here are details on that attack -- https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/november/introducing-chuckle-and-the-importance-of-smb-signing/

The SMB Relay and NTLM Relay attacks are thwarted if SMB signing is enabled, if Enhanced Protection for Authentication is enabled, or if all clients are Win10 while all servers (including domain-functional level) are Server 2012 R2 or higher. See more in this answer -- https://security.stackexchange.com/a/139578/140


Why would I 'have been pwned' on a website that I never had an account on? I was recently sent a notification by https://haveibeenpwned.com/ that one of my email addresses has been found in a breach, in particular in a breach of https://www.chegg.com. I am positive I never signed up for an account there, it's a US education company and I am not from there, nor did I ever have anything to do with US education.

I have verified the email is actually from haveibeenpwned.

I figured it's possible they merged with another company and took over their user base, but I can find no evidence of that.

If I try to sign in to chegg.com I do get a notification that I should reset my password for logging in. I did this and got a reset password email, what makes it even more dodgy is that I am adressed as Hi , to reset your password...  so obviously they left out the name I should be addressed by after Hi.

I actually logged in with the new random password and it seems my account did have a free ebook purchase there, but it's definitely not a book that I ever was interested in. I suppose the likely scenario is that chegg never did email validation and someone just used my email address? Are there any other options?
I also don't remember getting any signup emails which is common for services even if they don't verify email addresses.

The main thing for this is because databases that got compromised did contain information that came from other websites you were registered on.


Should a backup server be on a separate subnet / vlan from other machines on the network? Should a backup server be on a separate VLAN/subnet from the systems it backs up?  And should the routes only go one way from inside the VLAN/subnet of the backup server out to the clients and subnets that it backs up?  So that the clients can't get to the backup server?

The reason for backups is to add redundancy, allow for business continuity and disaster recovery. Having the backup server on a separate VLAN and having access controls around it is also a good idea. From a network and security architecture point of view all servers should be on separate VLAN from clients ideally with a Firewall in between, it makes sense to take this a step further and give your ‘crown jewels’ (i.e. potentially valuable, business critical data) an extra layer of protection.

Network segmentation could potentially contain malware outbreaks and/or limit how far an attacker can pivot around the network. From this point of view alone it is sensible to contain your backup server.

You should only allow exactly what traffic is required, no more or no less. This goes for protocols, routes etc. In the same vein you should only allow the for the minimum administrative controls as well, for example any users that look after the backups should only have backup rights rather than full domain rights.

Remember however that is the fact that clients are backing up to the server in the first place means that there is some kind of communication between clients and the server. This maybe via CIFS, SMB, a management protocol etc. So there is still a residual risk if even if configured or protected correctly.

Ideally you want to go further than this and have off-site backups if possible as well as offline backups stored in a secure location with appropriate controls protecting against physical destruction.


Decryption After Public-Private Key Pair Revocation Once a key pair has been revoked, is it still possible to decrypt messages that were previously encrypted?

What if the key is / isn't protected with a strong passphrase?

From what I understand, it is possible since the private key is not modified (or is it?) when revoked.
Even if the private key is modified, the numbers making up the private key can be extracted and thus possible to create a new, non-revoked key that can be used to decrypt the messages.

Quoted from https://emailselfdefense.fsf.org/en/

  If you lose your private key or someone else gets ahold of it (say, by stealing or cracking your computer), it's important to revoke it immediately before someone else uses it to read your encrypted email or forge your signature.

A revocation doesn't actually change the key - it simply signals others, that they are no longer trustworthy - if the private key has been stolen - or functional (i.e. the receiver is unable to decrypt any messages any longer) - if the private key is lost.

As long as you're in possession of the private key, you can decrypt anything encrypted with the corresponding public key - in fact anyone in possession of the private key can do that.

A passphrase is just a means of protecting the private key by encrypting it - for example if somebody copies the key file.


Trusting data from an API I read an interesting security article recently that amongst other recommendations suggested data from an external API should be treated like user inputed data.

Well of course that makes a lot of sense. But is anyone sanitising data from well known companies, is there a real risk there?

What kind of things should be mitigated against, just SQL injections and code injections? Is there anyway server-side code could be manipulated if data is not sanitised?

You need to sanitize it like it was user inputed data. It doesn't need to be ment evil by the API provider or it could also be the fault of the user giving the data to the API provider. Who says the API provider sanitized the data? Who says the API provider needs to sanitize the same way like you? Maybe the special character is valid for him.

A "'" might be a valid character for the API provider and a persons name could be called "Robert'); DROP TABLE students;--" and you got SQL injected without evil intentions of the API provider but by a mum naming her son like this.

For another example you get data from an API provider and display it on your website and you don't sanatize it: It might contain a special character which breaks your webpage or whole website. It might contain evil javascript/html code which can infect the user machine with a virus.
It might contain evil javascript/html code which has the same rights as the user viewing it. A logged in administrator views the page and the javascript deletes or manipulates the website/creates a new user with admin rigts/many more things.
Depending how the API data is stored/processed it might read/write security relevant files on the system or create/change files executed on the server. For example a file could be created which is executed by the webserver instead of sent directly to the client.
So always sanatize third party data.

Edit to make sure there is no misunderstanding: i am talking about data in the meaning of information representation, not about information per se. Information would be, that an actress is Robert's mum. Information representation could be

  {actress: "Robert's mum"}

So make sure this data does not cause an SQL-injection at your side. If you trust the information that the actress was really Robert's mum is another topic.


Reflected XSS via $_FILES Is it possible to perform a reflected XSS attack via the $_FILES variable?

The vulnerable code I am imagining might look like this:

echo $_FILES["file"]["name"];

I read that it's not possible to programmatically upload a file from a persons computer without their actual interaction (which makes sense, as that would be a giant security issue).

But is it possible to automatically submit an HTML form that PHP would interpret as file upload and thus populate the $_FILES variable, resulting in XSS?

I'm looking for solutions that work inside a browser with HTML and JavaScript and result in an actual security vulnerability. (so using curl or violating cross origin policy isn't really what I'm looking for, as that would not be exploitable).

My initial thoughts on this:

The content that is submitted for an input of type file is this:

Content-Disposition: form-data; name="fileinput"; filename="filename.php"\r\nContent-Type: application/x-php\r\n\r\nfile content\n\r\n

The content for eg input of type text is structurally different, looking like this:

Content-Disposition: form-data; name="textinput[]"\r\n\r\ntext content\r\n

I haven't yet found a way to create a HTML form that sends data of the first type via an input type different than file, and I haven't found a way to pre-populate an input field of type file.

I found this answer about sending files via JavaScript, but even though it seems like a cross origin write, I get a warning about violating the same origin policy.

This is not possible.

It is not possible to manipulate an HTML form using JavaScript as far as file upload fields go. As noted the form must be submitted as multipart/form-data and the filename needs to be submitted as part of that:

Content-Disposition: form-data; name="file"; filename="foo.exe"

The value of an input with type file is readonly in JavaScript. This is to prevent a malicious webpage from selecting a user's local file and uploading it without their knowledge.

Constructing the whole POST request in JavaScript is also not an option. This is because the response from the request will be retrieved as JavaScript data, not as a displayed page like with an HTML form. As you noted, the Same Origin Policy will prevent the response from being read anyway - but this does not matter. Even if it could be read, say if CORS is enabled, and the JavaScript renders the response as HTML - this HTML and any malicious script will be rendered in the attacker's origin - not the origin of the target site where the victim's session is required to be compromised by the attacker.

The only attack that comes to mind is setting the enctype of a HTML form to text/plain and trying to construct the

Content-Disposition: form-data; name="file"; filename="foo.exe"

line using a hidden input like this does for JSON. However, this will not enable the correct Content-Type and boundary to be included in the request header for correct parsing by PHP and will fail:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarykjwI5NtRzEheYJYc


How to safely renew user and CA certificates in a PKI I am currently developing my own PKI where x.509-client-certificates are issued by a public server. At the moment, the CA-public key is distributed with the binary and there are no routines for renewing neither client nor CA-certificates. What should I think about when implementing these routines? My thoughts are:

For updating client certificates:

It does not seem to be sufficient to verify the new keypair with the old keypair. For example if the old keypair is compromised.
Could a client instead store a set of future authenticators and pass them to the server upon first registration. These authenticators should only then be used for certificate renewal. Or is there a better way?

For updating the CA certificate:

One could use another CA to verify the CA-cert but I do not want to trust entities outside the system.
One could display the CA-cert-fingerprint to the user of a client but I would prefer to automate the process without user interaction.

Can anyone provide me with som pointers about this issue? What are the best books on the subject? I have already tried the "Handbook of applied cryptography" but could not find anything useful about certificate renewal.

The "right" way to think about renewals is to ask yourself why you want to renew.

As I understand it, you have a root CA which is hardcoded in some application installed in the clients. Moreover, the clients themselves own certificates, presumably issued (directly, or indirectly through an intermediate CA) by that root CA. This hints at some mutual authentication setup, e.g. some SSL with certificates on both the client and the server. The important point to remember is that when you own a certificate (i.e. you know the corresponding private key), then you don't have to validate that certificate; your certificate is for the benefit of other people, not you. In particular, clients don't need to trust or even know the root CA in order to use their own certificates; they need to trust the root CA to verify a certificate sent to them (e.g. a certificate presented by a SSL server to which the clients connect).

Therefore, the notions of "root CA update" and "client certificate update" are really unrelated to each other. It will be simpler to think about both kinds of renewals in a separate way.

For root CA update, we have the following setup: an application has been deployed, and contains the root CA name and public key, hardcoded in the application. This is called, in X.509 terminology, a trust anchor. The application uses that TA to validate incoming certificates (e.g. SSL server certificates).

For some reason, you want to change the TA name or key or both. The normal mechanism for that is an update of the application. It would be inordinately naive to believe that a given deployed application is free of bugs, and if it is involved in security-related actions, then bugs can turn into vulnerabilities. So you must have some update mechanism which allows the safe replacement of the application binary with a newer version. Some software distribution platforms (e.g. Google Play for Android, or the packages for a Linux distribution) provide such a mechanism.

By definition, the application binary is trusted (since it is that code that manipulates the sensitive data) so the update mechanism must be protected against hostile alterations. Thus, embedding the new TA in the application and pushing it as an update is the primary (and, really, the only) method by which you can "renew the root CA".

If the outer platform does not provide for a safe update mechanism, then you must build your own. This may be as crude as sending a new cdrom to each user... But if you want to automate things, you will need either a signature or at least some authentication. For instance, the application could connect to a specific HTTPS server (which implies some validation of the server certificate) to download the update, reputed correct since it comes from the specific update server.

The reason why you need to push a new root CA is important, especially with regards to timing. There are two main cases: either you need to react fast because the root CA key was compromised, or you have time (e.g. you want to change the CA key for a longer one because the one you used becomes a bit too short with regards to cryptanalytic advances):

If you have time, then you can sign the new application binary (which includes the new root CA) with the old CA. This will allow for a smooth transition.
If you do not have time (e.g. root key compromise), then you are in deep trouble. The best you can do is handle it as a "critical vulnerability" and make a lot of fuss about it so that users manually connect to some distribution server (protected with a "mainstream SSL certificate" that you buy for a hundred bucks) to download the new application.

This is still a very bad situation and you would prefer not to encounter it. The classic way to keep your root CA key safe is to keep it offline: never plug the root CA to some network. This means that your PKI must have an online intermediate CA to issue the users' certificates. You manually (i.e. with USB flash drives) obtain CRL from the root CA as a regular procedure (e.g. on a weekly basis).

Alternatively, apart from the root CA, you may keep in an offline machine an unrelated "update package signature key" which you use when you need to build and distribute a new version. The application binary would contain a copy of the corresponding public key, which has nothing to do whatsoever with your root CA key and certificates; it is like an "extra root" used only to verify application update packages. Being kept offline at all times, that machine should be safe from remote attackers, and thus you may work on the assumption that the package signature key will not be compromised.

All other things being equal, it is best if you never renew the root CA key. As far as we know, a 2048-bit RSA key ought to be good for a substantial number of decades, and may be broken only by yet undiscovered but devastating attacks. There is no indication, currently, that such attacks will be discovered in the future or even if they exist at all; and there is no indication either that a longer CA key would fare any better (that's the problem with speculation on unknowns: it is speculative and rarely yields any useful information).

For client certificate renewals, the problem is completely different. A client certificate is not something that the client itself trusts.

Since a client certificate contains the client identity and public key, a first "renewal" method is to simply have the CA renew the certificate on its own accord, by taking the old, changing the validity dates, and signing it again. The client key and name are thus unchanged. The "renewal issue" has been reduced to the question of pushing the new certificates to whoever needs to know it. Usually (but not necessarily), it is best if the client itself knows its own certificate, because it allows the client to send that certificate as part of some network protocols (e.g. in SSL/TLS, when the client uses a certificate for authentication, the server learns that certificate by virtue of the client sending it).

Certificates contain only public data and are signed, meaning that they can travel safely on the Internet. You just need to setup some regular, plain HTTP request by which a client may ask some server whether a new certificate exists, and obtain it. For that mechanism, the client may contain a copy of the issuing CA public key, or some higher CA, in order to check that the certificate is the right one -- the client does not trust the root CA, but you want to avoid wanton disruption by ill-intentioned attackers who corrupt renewed certificates while in transit: this would be a DoS attack. An altered client certificate will not be accepted by any server, but it is best if the client application notices the foul play upon certificate download rather than later, upon certificate usage.

The reason why you want to renew the client certificate is, again, important:

The official reason for enforcing end-of-validity dates in X.509 certificates is to make sure that revocation lists (CRL) don't grow indefinitely. The less official reason is that one-year certificates ensure yearly renewals, that can be turned into yearly access fees. If you renew client certificates for these reasons, then you can renew on the CA side as explained above.
If you need to change the client key, then you are reacting on some abnormal and exceptional situation, e.g. a client key compromise. In that case, the client has just lost its main method to demonstrates its identity to any server, in particular your CA.

At that point, you have to consider how you issued the certificate in the first place. A certificate binds an identity to a public key, so you had, at that time, a way to verify the purported client identity. The generic recovery method after a private key compromise is thus using the same initial authentication method again. At that point, the user is normally actively collaborating -- after all, the compromise is normally discovered by the user himself.

Details on the possible emergency recovery methods vary a lot, depending on your context. When the notion of identity that your PKI uses is "same user" (anybody can register and there is no formal physical identity, but a user should be able to demonstrate that he is the same user as previously), a practical method is to issue, along with the initial certificate, a "recovery code" that the user writes down on a piece of paper, and types again when he has lost exclusive control of his private key: either the private key is known to some attacker, or the user's phone broke down and he cannot use the key anymore, or both (typical case: the user's phone or laptop has been stolen). The recovery code is the method by which the user can demonstrate to the CA that he is the same user as the one who previously owned the certificate that is to be renewed.


Malicious email attachments analysis I have a question regarding incoming emails with malicious attachments on my email server. So, my idea, in my ideal setup, is to have a machine aside running virtualization software. This would run all the tools needed to do the malware analysis where I would send the supposed malicious attachments to from another system where the suspicious email would have been seen.

Now, the question is:

What would be the ideal mechanism to use to transport the suspicious attachments from the email client to the analysis system with a minimum amount of interaction with the file, in order to minimize the risk of infection on the primary system?

Encrypt it.

As soon as you identified the file as malicious, encrypt it with a keypair where the private key is on the analysis VM and don't decrypt it until you have it in the save environment where you want to analyze it.

As soon as the file is encrypted, no device in between will be able to do anything with it, no matter what they try. So it's now safe to use whatever file transfer mechanism you consider most convenient.

Possible weakness: A bug in the encryption software itself which can be exploited when a malicious file is encrypted. But considering that most encryption systems are quite simple and quite rigorously tested I would consider that unlikely.


What prevents criminals from buying a new PC and going on public wifi? Imagine this scenario:

A criminal wants to commit a crime online. He buys a brand new pc, finds an open WIFI, connects to TOR network, and commits a crime.

How would authorities possibly detect/find him?

Frankly, there is nothing stopping a criminal from doing those things and making it impossible for authorities to catch them. But, it can be far simpler and cheaper than your scenario.

I run honeypots and I analyze hackers and their techniques. I was able to fully identify an Eastern European hacker (name, address, employer, phone number, even his favourite coffee shop) because of a series of small mistakes he made. I didn't trace his IP or traffic to find him, though I did anyway and found he used a pre-paid cell plan for data. But, there were pieces of data that I put together to paint a picture of who the person was. It was a dozen small things that were nothing on their own, but in combination, was enough to id him perfectly.

Your question assumes that criminals are detected through traces and logs. That's not the typical scenario, unless mistakes are made. There are "fingerprints" left behind that can be clues, but the way that criminals are traced are through their actions after the crime has been committed: selling, storing, bragging, etc.


Identification of File Deletion Time following problem:

A file is marked as being deleted without a tracked time-deletion date. However, timestamps such as File Accessed, Entry Modified etc. point e. g. to the 30.12.2019. Is it safe to assume that the deletion must have happened at or later than the 30.12.2019 as the file was accessed/created/modified/changes in the mft entry occured or are there other operations that might have triggered the timestamp changes apart from user actions after the file deletion?

After a file is deleted, there are no updates to the MFT entry, so yes the deletion occurred on or after 30.12.2019.

Caveats:

This assumes normal functionality. Clearly specialized tools can muck with the MFT.

If all the MAC time stamps are the same (in particular the modified time), then the file was deleted directly bypassing the Recycle Bin. Had it gone to the Recycle Bin, it would have been renamed with a new modified time. Similarly most wiping programs rename first with a new modified time created prior to the actual wipe.

You may be able to find the actual deletion time in the MFT Journal.


How to handle a phishing site? I launched my company website a month ago, now when I google using website name a phishing site that has exactly copied my site appears in the first page. It also has a better rank than my website which was initially at first page, but now it isn’t. How to handle this situation and prevent this in the future since a part of my service includes developing websites for my clients.

You can start by reporting the website to multiple parties in order for it to be blacklisted. An example is Google Safe Browsing which ships with Google Chrome and Mozilla Firefox, you can start by filling out the form.

Decent Security also has a dedicated guide for steps to take when reporting phishing sites.


What are mitigation techniques against Cache-timing attacks on AES? I read here a paper of Daniel Bernstein

  This paper demonstrate complete AES key recovery from known-plaintext timing of a network server of another computer. This attack should be blamed on the AES design not on the particular AES library used by the server.
  It is extremely difficult to write constant-time high-speed AES software for common general-purpose computers

There is countermeasures for new processors and architectures ?

Why is so o write constant-time high-speed AES software for common general-purpose computers ? What is the problem ?

It's not that creating a constant time implementation is inherently problematic, it's mostly a matter of efficiency and awareness.

The table based implementations are fast. Constant time implementations are possible, but tend to come at the cost of reduced performance compared to the table based version.

Additionally, and the more likely culprit, is the awareness level of the implementer of the existence of cache timing attacks. This is not something that is immediately obvious to the uninitiated. Implementations that are constant time are generally not so by accident - they were written that way with explicit intention by the implementer. A good example is bearssl.

Lastly, many modern CPUs have the AES-NI instruction set, which basically offloads the AES computation to a dedicated hardware circuit, and should run in constant time.


Is it sensible to tunnel TLS traffic over another TLS? I'd like to secure my application's traffic using TLS with pre-distributed self-signed certificates (as a drop-in replacement of plain TCP).

In some cases, two clients won't be able to talk to each other directly because of presence of NAT and will have to resort to an accessible relay to tunnel their traffic between each other. I'd like to protect the connection between client and relay, and I also don't want the relay to see the plain text intended for clients.

It seems that a client would have to connect to relay via TLS and then estabilish another TLS session to the second client over the existing TLS connection. I know that encrypting twice isn't stronger than encrypting once, but how much would a client be in trouble in this case?

If I understand it correctly, this is a rough network diagram of your situation:

You're saying A and B want to talk, but they can't directly so they use Relay. You are thinking of having A set up an encrypted connection (TLS) to Relay and then using Relay as a proxy for connecting (over yet another TLS tunnel) to B.

This sounds complicated, but basically if you use an https proxy or any VPN server (say, mycompany.example) and connect to another https site (say, bank.example), you are already layering encryption on encryption. Let's see how the possible options work out (layering or not layering).

Option 1: encrypt A<->B but not A<->Relay nor B<->Relay

If you don't tunnel inside of the tunnel, you would be sending packets from A to Relay and from Relay to B unencrypted. But since they are destined for B, the traffic will be encrypted for B, nobody can read the connection contents (only A and B themselves). The only information you are leaking to anyone listening on the path between A<->Relay and Relay<->B is that A and B are communicating. The Relay will not be able to read the connection contents.

Option 2: encrypt A->Relay and A->B

If, like you're asking, there is a tunnel between A and Relay and between A and B, then people listening on A<->Relay can only see that A is communicating with Relay; and people listening on Relay<->B will again only see Relay communicating with B. The Relay will not be able to read the connection contents.

Option 3: encrypt A->Relay and B->Relay

Finally there is the option of encrypting the connection from A to Relay but not from A to B (and assuming B still sets up a (TLS) connection to Relay because it's behind NAT). In that case the traffic is transparent for Relay, but anyone observing will only see the connection from A to Relay and from B to Relay.

So it depends on whether it's an issue if people intercepting the lines can see the destination of the packets (namely A and B). Double encryption means double CPU power for A and B (only singular for Relay since it doesn't decrypt the contents, only the outer layer), but I'm not sure that makes a big difference or you would have mentioned it.

(Credits: the image was made with https://draw.io. The XML is in the source of this post.)


So where do I start learning about Cyber Sec? I'm an 11th grader interested in the whole field/world of IS and what not so I decided to look around this site and various others, and I have come to the conclusion that I have no clue where I am to start.

I would like to learn more about IS and in the near(not so near) future and go along a route leading to security engineering or something of the sort, but there are so many different fields and specifications and just stuff, and I quite frankly am not sure where would be a relatively good place to start my search for knowledge.

if you ask me, of course i'll tell you read a lot about IT.
because IT world is so big, and also create more IT field so cant list on by one at here.
most important is be realistic, dont idealize. focus on one field.


XSS in HTML title tag I got a parameter in URL that displays in the HTML <title> tag. The > and < are properly escaped. Charset cant be changed. No variants (e.g. hex, url, double url, base64) of encoding < and > are working.

The title tag is somewhat of a special case, since it doesnt have any onEvent attributes. Is there any other way to perform an XSS attack without closing the tag with </title>?

I would not treat the <title> tag any differently than I would treat any other tag, lika a <div>. The context you are talking about (inbetween HTML tags) is what OWASP call "HTML Element Content" in their XSS prevention cheet sheet. They recommend the following substitution rules:

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;
/ --> &#x2F;

However, I can not for the life of me figure out how you would be able to do any mischief without < or >, so I think (as opposed to know) that you are safe. Still, there is no harm in following the OWASP recommendations to the letter.

In other contexts other sanitation rules are required, so do not take this as just endocing < and > is always OK. It is not.


PCI Compliance requirement when storing card data on user's device I have an application where I take the user to a PCI compliant payment gateway for completing the payment. I want to give the functionality of "Remember my card" so that the user does not have to enter the details again in the future. I am thinking of storing the card data on the user's device itself (encrypted and not hashed because I would need to reverse it to the actual card number as required by the payment gateway). The CVV would not be stored.

Is storing the data on the user's device that in most cases would be used by the user only, a violation of acceptable security standards? If yes, then what are the levels of PCI DSS/PA DSS compliance requirement here?

PCI-DSS rules generally require that any PAN stored be encrypted in such a way that it requires not one, but two authenticators to decrypt.

In practice, this would normally mean that even if you intend that the end-user is the only one with an encrypted copy, this would be insufficient from a regulatory standpoint. "Who" has a copy is irrelevant, in this respect. If decryption can be accomplished by a single key from the provider (i.e., you), and you cannot affirm that the device it's stored on is encrypted (that is, a client responding with a true/false about the filesystem encryption following a transaction request is not currently a capability of any mobile device I'm aware of), then you will have no way to declare the end-user devices out-of-scope during a PCI audit.

One scenario might work: if you have an application which generates and secures its own key for storing the card information, and which then can respond to your server-side payment application with a token for previously-used cards at that site, then you can (probably) satisfy the basic requirements. As long as the server-side application can satisfactorily store and retrieve the PAN upon presentment of a reference token during the transaction, you're fine. However, even in that case the CVC or CVV must be manually provided by the user— that is explicitly not allowed to be stored together with the PAN.

Having the end user store their own card may also possible, but no program or application can be allowed to request that data from the end-user and expect to receive the response automatically, unless you store a unique key for that user server-side for decryption of the PAN. This is why the current strategy is for Android and Apple to store "card details" and autofill fields when they recognize a request to fill out transaction data. That should be fine, but a pedantic auditor could easily demand that you have some way of confirming the end-user's device only works with an encrypted filesystem.

Long story short: you effectively just want a page whereby someone's mobile browser can work with "autofill" in a friendly way. You'll get the same results, without having to worry about additional PCI PAN storage limitations.


SSLv3 HandShake but TLSv1 client hello I am trying to understand the handshake protocol, when we had our ssl debug mode on we saw that the handshake is SSLv3, but the Client Hello as TLSv1.

http-8443-14, READ: SSLv3 Handshake, length = 87
*** ClientHello, TLSv1

What does that mean?

The client sends a SSLv3 ClientHello so that a server who understands only SSLv3 can process that message, and continue with a SSLv3 handshake. But the SSLv3 ClientHello also says "by the way, I know TLSv1, so if you know TLSv1 too, let's do TLSv1 instead of SSLv3.

Please correct if this doesn't make any sense, I am not a networking/IS guy.

Your last paragraph is correct: indeed, in the ClientHello message, the client announces its "maximum supported version". So a client that supports both SSL 3.0 and TLS 1.0 will say "I know up to TLS 1.0" (internally, "TLS 1.0" is encoded as "SSL 3.1"), but will still accept to use SSL 3.0. The protocol version which will be used is chosen by the server (in its ServerHello message).

What you observe, though, is an artefact from another peculiarity of SSL, which is that the version is indicated twice. Namely, all traffic in SSL is sent as records, and all records have a five-byte header that indicates:

The type of data in the record (type being "handshake message", "alert", "change cipher spec" or "application data")(one byte).
The record protocol version (two bytes).
The record length (two bytes).

So the report line you observe:

http-8443-14, READ: SSLv3 Handshake, length = 87 *** ClientHello, TLSv1

probably means: "A record of type 'handshake message', version SSL 3.0 and length 87 bytes, has been observed. Its contents turned out to be a ClientHello message that internally says 'I, the client, support protocol versions up to TLS 1.0'."

It is customary for SSL clients to use a "low" version (3.0) on the first record because there are old and broken SSL servers that not only do not support TLS, but also panic and die when faced with a record tagged "TLS 1.0", even though the format of an unencrypted TLS 1.0 record is absolutely identical to that of an unencrypted SSL 3.0 record (except for the version in the record header).

For more information on such details about SSL, read this.


XSS in Content-Disposition Lets assume i have found a xss on  site example.com, now to trigger an XSS, i use the following URL:

https://example.com/a.php?v=%22%3E%3Cimg%20src=x

Which results in following response:

HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Mon, 27 Jul 2015 02:15:23 GMT
Content-Type: text/html;
Content-Length: 44
Connection: keep-alive
Strict-Transport-Security: max-age=31557600; includeSubdomains;
X-Permitted-Cross-Domain-Policies: master-only
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: sandbox
Content-Disposition: attachment

"><img src=x

Does this pose a security risk considering XSS protection is enabled and also the CSP sandbox and content-disposition attachment mitigates this so that even if injection was successful, code will not execute for XSS.

Yes this still poses a security risk.

From what I understand this header is only used by IE 8 and newer tell the browser to use it's built in XSS filtering.  Even if modern versions of other browsers user it, there are certainly older browsers that do not.  In addition - I would not trust IE's built in XSS protection to keep anyone safe.

If preventing XSS were this simple XSS would not be a thing.

UPDATE:

Regarding the Content-Disposition: Attachment this will make XSS more difficult, but it seems like there are still a few ways to get around this:

http://i8jesus.com/?p=64
http://sirdarckcat.blogspot.com/2007/12/bypassing-content-disposition.html
https://bugzilla.mozilla.org/show_bug.cgi?id=392459

Even if it is not exploitable in it's current state I would still say that this is a very bad security practice.  It would leave the site in a position where a seemingly minor code change in the future could open things up to an XSS vulnerability


XSS inside HTML attribute where < and " are filtered Is it possible to bypass an XSS filter where < and " are encoded as &lt; and &quot;, but > is not escaped?

My data is injected into an HTML value attribute. However I can't get out of it since " is escaped.

Characters that are filtered:

'';!--"<XSS>=&{()}

are evaluated as:

&#39;&#39;;!--&quot;&lt;XSS>=&amp;{()}

No, if " is properly escaped there is no way to get beyond the HTML attribute value.

Your browser parses HTML as a state machine. To verify which state transitions are possible with your available characters, you can look up the state in the HTML5 syntax specification. In your case, these are the options:

8.2.4.38 Attribute value (double-quoted) state

Consume the next input character:

U+0022 QUOTATION MARK (")
    Switch to the after attribute value (quoted) state.
U+0026 AMPERSAND (&)
    Switch to the character reference in attribute value state, with the additional allowed character being U+0022 QUOTATION MARK (").
U+0000 NULL
    Parse error. Append a U+FFFD REPLACEMENT CHARACTER character to the current attribute's value.
EOF
    Parse error. Switch to the data state. Reconsume the EOF character.
Anything else
    Append the current input character to the current attribute's value.

As you can see, the only way to get out of the quoted Attribute value state is via the corresponding quotation mark (" or ' respectively). Any other character just adds to the current attribute's value. Even angle brackets and control characters have no special meaning inside an attribute.

So, in this particular case it's also irrelevant how < and > are handled. This does not trigger:

<input type="text" value="<script>alert('No bounty for you.')</script>">


Capturing (1x Only) HTTP POST Request [tcpdump] Every now and then;
I like to fire up tcpdump and just watch the network traffic as the packets flow on by.

For example:

user@host:~$ sudo tcpdump -Aevvv

Will parse & print all local network-traffic to the standard output, in real time, instead of writing (saving) to file. It's great for taking a quick glimpse at what's happening on the local network.

It's not uncommon to find packets coming through in larger quantities/at higher speeds than what is comfortable to parse and/or read. In such cases, I usually indicate a desired target host like so:

user@host:~$ sudo tcpdump -Aevvv host security.stackexchange.com

Obviously, the desired target host in this example is security.stackexchange.com. This is for no reason other than being the first to come to mind and can, of course, be set to any host you like. Using the host filter can clean up the results quite nicely, but I would like to take it one step further and specify certain HTTP Web Request types such as HEAD, GET, POST, & so on.

To continue in the spirit of our example, I would like to specify a tcpdump packet-filter rule for capturing HTTP POST Requests; so as to demonstrate what's happening behind the scenes when submitting content to a remote host like security.stackexchange.com.

So that is my question: (When using tcpdump..)
How can I specify a filter for POST Request packets only?

You can't for various reasons:

tcpdump has no idea of application level protocols.
That this is a TCP connection containing a POST is only known after the TCP handshake is already done, that is you either would loose the connection setup or you would need to capture everything and store it somewhere in case it might turn out to be a POST later.
There can be multiple HTTP requests inside a TCP connection and the POST might not be the first one.

Note that you might try to capture only the packets starting with "POST" as proposed in a different answer. But, this will capture also other packets starting with POST (and not only the POST requests), will not capture the payload in most cases (only if it is really small and contained in the same package) and will not capture the response.

Instead I recommend to capture all the traffic which might contain a POST and then later filter the captured traffic using wireshark/tshark, see https://serverfault.com/questions/309515/how-to-make-wireshark-filter-post-requests-only


diffie-hellman size 2048 and key with size 1024 I want to increase the security of my Tomcat and to configure diffie-hellman module size 2048.
I want to add to my CATALINA_OPTS -Djdk.tls.ephemeralDHKeySize=2048
What happens if I have configured it 2048 but the Tomcat SSL key has size 1024?

Will handshake success?

Will server start?

added

The certificate key size is 1024.

Note that increasing DH bit size to 2048-bit means that the DH public key will be 2048-bit.

Now the server has to make a digital signature on the public key of 2048-bit. You are using a 1024bit private key to do this. The DH key is hashed and signed by your 1024-bit key (i.e: RSA). The hash function shrinks data to fit on a target size.

Sounds good to me. Furthermore, in every exchange the DH public key will be different, since it's using an ephemeral scheme.


Are there any tools that focus on shellcode analysis? Shellcode presents certain challenges for disassembly. It often self-modifies, jumps to the stack (where the shellcode will likely be placed), and relies on certain unusual tricks that standard disassembly tools don't focus on.

With this in mind, what tools are available for disassembling and analysing shellcode?

Since shellcode is just a raw block of instructions, these tools aren't really suited.

Wat? Executables are just raw blocks of instructions too! No really. Ok, maybe there's bits of data in there for PE/ELF headers or the like, or just plain program data, but the data is the same binary as instructions. To the point sections of executables are labelled (text, data) so the OS knows what to treat as what.

For a demo, take any set of assembler and type:

nasm -f bin <asmfile.asm>

That'll do absolutely no additional work bar translating the assembler instructions to opcodes and writing it down in a binary file. This is how you'd go about writing a bootloader or the like.

Now, if you wanted to analyse some shellcode, there's a multitude of ways you could do it. For starters, you could just use a harness:

#include <stdio.h>

char shellcode[] = { ... };

int main()
{
    int (*function)() = shellcode;
    function();
}

and voila you're off - simply get gdb or the like to single step through it. Of course, if you wanted to analyse that particularl piece of shell code statically, well, there's a way for that too:

#include <stdio.h>

char shellcode[] = { ... };

int main()
{
    FILE* f = fopen('test.bin', 'wb');
    fwrite(shellcode, sizeof(shellcode), f);
    fclose(f);
}

and now you have a binary blob to work with. Actually, chances are you had to do the inverse of this to load the code into the test harness (i.e. escape it) anyway.

If you're looking for tools, I suggest the x86 wikibook. Basically, it comes down to picking one or more you can afford and having a play.

Unless the shellcode contains anti-debugging measures (remember, it's space-constrained) chances are a runtime debugger with the test harness will work just fine.


Perfect forward secrecy using XOR I understand that Perfect Forward secrecy is meant to prevent the data sent between the client and server being decrypted in case the private key is leaked some time after the data being sent.

But why do we need something complicated like Diffie-Hellman key exchange to do this? Couldn't we simply use XOR instead, like this:

The client generates a random encryption key, K and a random number of the same length, R1
The client sends K xor R1 to the server
The server generates a random number R2
The server sends K xor R1 xor R2 to the client
The client xors the message with its random number, sending K xor R2 to the server
The server xors the message with its random number too, which results in the key, K, which is then used to encrypt all communications

If a key that isn't generated by only the client/server is needed for some reason, then this process can be repeated again by the server and then the two keys can be xored to get the final key.

Unless the SSL private key is known when this exchange happens, which would allow for a man-in-the-middle to modify messages sent between the client and server, no one will be able to figure out what the key is.

I understand that XOR is vulnerable to known-plaintext attacks, but since both the random numbers and the encryption key are used only once, I don't see why this should matter.

Anyone observing the exchange can just trivially calculate K!

K = (K xor R1) xor (K xor R1 xor R2) xor (K xor R2)

This are exactly the three messages which are sent in your protocol...


What are locked domain names technically? I just learned about domain name locking at registrar level.
I’m having problem to understand what it is, all I found is it’s a protection against domain name takeover through transfer.

Now, I also found unlocked domains for several major websites.
But without even understanding what locked domains are, I don’t know if it would allow takeover (or even a threat at all since I couldn’t found a list of supported tld).

My current case is there are only server status codes in whois, not clients ones.

Locked domains are domains which require additional hoops be leapt through in order to change ownership.  The lock is requested by the owner of the domain and implemented by the registrar of the domain.

Historically, transferring ownership of a domain required something like one of the authorized contacts faxing in a signed paper.  And, believe it or not, there were people out there who would fraudulently sign papers and fax them in so that they could steal the domain.  It's called Domain Hijacking and during the dot-com era it was a reasonably large problem.  It happened to my company around 2000 and it took us months for the lawyers to convince Network Solutions that the domain had been fraudulently transferred and that it should return to us.

Domain locking means that the registrar must unlock the domain before making changes, and that therefore they are triggered to apply extra scrutiny to the transfer.  Some might argue this merely makes them "do their job"...

The law of unintended consequences means that domain locking became a weapon in the registrar wars.  As new registrars came online and tried to capture business from the (more expensive) older registrars, domain locking was urged upon domain owners with the unstated goal of making it harder to hop from one registrar to the next.  Every domain registered at Network Solutions "comes with the free Domain Protect feature enabled," for example.

Your biggest question seems to be is domain hijacking an important threat?

Yes, but relative to the value of your domain.  For example, "sex.com" was an attractive and lucrative target (link goes to article, not named domain).  Other domains would have lower value.

Update

I was unable to find a way to query ICANN to find out which TLDs support domain locking, but I was able to find this (very comprehensive) list on a registrar site which indicates that .co does support domain locking:

And, if you go to the .co whois server, you can see that locking attributes are listed for their domains:

For at least two of the TLDs listed as not supporting domain lock in that list (.cn and .uk), I pulled up whois details for a couple domains and did not find any indication of EPP status codes that would indicate domain locking.  (As a negative inference, that's of limited use, but it beats contradiction).


SSL self-signed certificates in development vs acquired cert in production? I am a developer, I have created self-signed certificates before for my work.

This time, I am involved up until going live with the whole app (usually there was someone else in charge of this).

Questions:

Is it ok to use self-signed certificates for development, and then use the acquired one for production only?
Does using self-signed certificates imply that in development, the clients need to add my CA to their list?
When we go live, using the actual acquired certificate, will there be any change in clients?

I am ok with just links to documentation, I did some search but couldn't find specific answers for the whole workflow.

Is it ok to use self-signed certificates for development, and then use
  the acquired one for production only?

Yes, that is the way almost every one does. You don't have to pay a certification authority to certify that you are talking to your own server. Self sign it until production, buy a real certificate later.

  Does using self-signed certificates imply that in development, the
  clients need to add my CA to their list?

Yes, that's correct. Or that or the dreaded "The server you are connecting to can be trying to stab you" will display on their browsers.

  When we go live, using the actual acquired certificate, will there be
  any change in clients?

Nothing will change. Unless you have employed Key Pinning with a long max-age, you put a valid certificate on your server and forget about it until it's time to renew it. Your clients will never see any difference.

But if you are using Key Pinning, you must use at least two certificates. If you pin the wrong certificate, it expires, gets compromised or lost, your clients will not be able to connect until the pinning expires. Having a backup pin (the second, valid certificate) will ensure you can pin another certificate and fix any mess.


OpenSSL 0.9.6a PRNG algorithm weakness: How to exploit? I saw an OpenSSL security advisory for Openssl 0.9.6a

  Recently a cryptographic flaw in OpenSSL's built-in pseudo-random number generator (PRNG) was pointed out to us by Markku-Juhani O. Saarinen , who showed how an attacker could reconstruct the PRNG's internal state from the output of a couple of hundred 1-byte PRNG requests. This problem dates back to SSLeay, which OpenSSL is based on, and was found in other SSLeay-based toolkits as well. While a number of enhancements have been done to the original PRNG during the development of OpenSSL, this design error was overlooked so far.

  The PRNG (implemented in source code file crypto/md_rand.c) uses a hash function, by default SHA-1, to update its internal secret state and to generate output. The secret state consists of two components: A chaining variable 'md', sized according to the hash function's output (160 bits for SHA-1), and a large buffer 'state'. 'md' is always replaced by a hash function output during the PRNG's operation. 'state' is accessed circularly and is used for storing additional entropy.

  When generating output bytes, OpenSSL versions up to 0.9.6a set 'md' to the hash of one half of its previous value and some other data, including bytes from 'state'. The design error was that the half of 'md' input to the hash function was the same half that was also used as PRNG output, meaning that it in general cannot be considered secret. Also the number of bytes used from 'state' depended on the number of bytes requested as PRNG output and could be as small as one, allowing for easy brute-force analysis of all possible cases. The combination of these effects made it possible to reconstruct the complete internal PRNG state from the output of one PRNG request appropriately sized to gain knowledge on 'md' followed by enough consecutive 1-byte PRNG requests to traverse all of 'state'.

See also: SecurityTracker Alert ID: 1001961

From the security advisory that you posted, it appears to me that the design error can be summarised as

The PRNG is a hash function. the input to the PRNG(hash function), half of it is from the previous PRNG output, which is known, you can just read it off the previous output. So essentially the hash-function SHA-1's strength becomes halved - 80 bits instead of 160 bits.

So if the OpenSSL's libray is used in key generation, you may perform a brute force attack on the remaining 80 bits key. It is definitely a big vulnerability and breakable by today's processing power standard. But it is still a huge task.


Implementing 'Remember Me' for a mobile application I am developing a mobile application wherein I need to implement the 'Remember Me' functionality. There are certain pages within the application which require you to login. What I need to do is, if the 'Remember Me' checkbox is selected, then I need to store the username and password so that it can be populated later if the user logs out and arrives at the login page again.

In my previous implementation, I just captured the data from the login form and stored it in local storage. However, I now need to know how I can secure it.

I have followed the advice given in this answer to implement a sample implementation. I am using SJCL to encrypt and decrypt the data (in javascript).

function encryptLoginData(data) {
    //Generate PBKDF2
    var result = sjcl.misc.cachedPbkdf2(data.password, {count: 1000});
    var key = sjcl.codec.hex.fromBits(result.key);
    var salt = sjcl.codec.hex.fromBits(result.salt);

    //Encrypt data using the key and the salt generated from password
    var finalData = sjcl.json.encrypt(key, JSON.stringify(data), {salt: salt});
    var encryptedData = JSON.stringify([key, finalData]);
    return encryptedData;
}

Later, to populate the data I am using this:

function decryptLoginData(data) {
    //Decryption of login data
    var fetchedData = JSON.parse(data);
    var decryptedData = JSON.parse(sjcl.json.decrypt(fetchedData[0], fetchedData[1]));
    return decryptedData;
}

Now if you notice, I have to store the key and the encrypted data together so that I can decrypt it later. However, anyone who has access to the javascript and the key can easily decrypt the data using a single sjcl.json.decrypt. What I think is, I am just obscuring the data further and not really securing it? Am I missing something? Is there a more secure way of doing this?

PS: I am new to cryptography.

PSS: I have gone through this and this but dont really follow how to use it my context.

When you are new to cryptography, don't use cryptography. Nothing personal here; that's because you cannot test for security. You cannot easily (or at all) know if some system/protocol/algorithm is secure or not. Such tests simply do not exist. This is very unlike functionality, which can be tested: it is easy enough to see if a server boots up and answers requests, but it is impossible to verify if all this happens securely. Theoretical reasons for that have deep fundamental roots like the halting problem.

The only known way to use cryptography correctly is to let it in the hands of people who have devoted their lives to the study of cryptography. If those guys cannot collectively come up with an attack on your system, despite years of silent toil and meditation, then your system is probably secure, or at least more secure than that of your competitors, which is often good enough.

A "remember me" feature is about keeping some state on the user side, so that when the user comes back to the server, the server will automatically recognise him, and won't ask for an irksome password entry. Whatever way you put it, this means that the user device (mobile phone, as I understand it) contains everything which is needed to "log on" the server without any special user interaction. In particular, if the mobile phone is stolen, then the thief can obtain the same data and then log on the server. This is unavoidable, and that's (again) fundamental: if the user needs not enter his password, then there is nothing specific about the human user, and his physical presence is not required. That's more-or-less the point of the "remember me" feature.

No amount of cryptography anywhere will change that. If the app can log on the server without user intervention, then it can.

A "remember me" feature is thus an inescapable risk which you must balance with the improved user experience (users basically prefer not entering their password over entering their password). There are some ways to make the trade-off a bit more favourable for you:

Whatever the app stores, don't make it password-dependent. Don't store user passwords or any hash computed from the user password. User passwords are sensitive data whose scope extends beyond your app; user passwords are highways into their brains. Instead, store a "session key" which was generated randomly server side. Make it 16 byte long (at least), and use on the server a cryptographically secure PRNG to produce it (e.g. /dev/urandom or a wrapper around it).
If using a random session key, then you can cancel it on the server at any time, which is a good thing compared to the user password, because you cannot make the user "forget" his password, let alone any potential attacker.
Make it time-limited; for instance, make the "remember me" feature valid for one week. This will force the user to re-enter his password regularly, but you can choose the schedule; yet again, trade-offs. With a time-limited session key, you can contain the damage from any attacker within a strictly bounded time frame.

So now your problem is "simply" a matter of:

obtaining a random session key from the server;
storing it on the user device;
sending it back to the server when needed.

In an HTTP/Web context, all of this already exists and is called HTTP cookies. Just make sure that you set the "Secure" and "HttpOnly" flag, and that you use SSL (HTTPS) (if you are not using SSL, then you already have a lot of bigger problems, so do that first). The system which is easiest to implement securely is the system which has already been implemented securely by someone else. So just use it.

Now, if your app is about logging on an uncooperative server who is totally unaware of your "remember me" feature and will not send a session key as a cookie, then you have a problem. In that rotten situation, you have to store user credentials on the client side, and that's not good. Password manager software tries to cope with such issues, but the trade-offs are not as good as previously described. Users, generally, won't like it. There will be some local encryption with a user "master password", and that's a hard problem; moreover, Javascript is not at all the right language for that (in particular because of its low performance, which contradicts slow hashing).

It is highly preferable if you do not go there.


How secure is NOPASSWD in passwordless sudo mode? On all our boxes we have ssh access via keys. All keys are password protected. At this moment the sudo mode is not passwordless. Because the number of VMs are growing in our setup, we investigate the usage of Ansible.

Ansible itself says in the docs:

  Use of passwordless sudo makes things easier to automate, but it’s not required.

This got me thinking about passwordless sudo and I found some questions/answers here. However, I couldn't really find anything about the security concerns of passwordless sudo per se.

It could happen in the future user Bob has a different password on machine X than Y. When Bob is a sudoer, this gives problems with Ansible to enter one sudo password for all boxes. Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password): how is the security affected when NOPASSWD is set in the sudo file?

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use because the attacker can plant a keylogger-type program that records the user's password the next time he enters it at a sudo prompt or in a screensaver.

Nonetheless, requiring the password does raise the bar for the attacker. In many cases, protection against unsophisticated attackers is useful, particularly in unattended-workstation scenarios where the attack is often one of opportunity and the attacker may not know how to find and configure discreet malware at short notice. Furthermore it is harder to hide malware when you don't have root permissions — you can't hide from root if you don't have root.

There are some realistic scenarios where the lack of a password does protect even against sophisticated attackers. For example, a stolen laptop: the user's laptop is stolen, complete with private SSH keys; either the thief manages to guess the password for the key file (perhaps by brute force), or he gains access to them from a memory dump of a key agent. If the theft is detected, this is a signal to investigate recent activity on that user's account, and this means that a planted malware should be detected. If the attacker only had user-level access, anything he did will leave traces in logs; if the attacker obtained the user's password and ran sudo, all logs are now compromised.

I don't know whether the downsides of NOPASSWD balance the upsides for your use case. You need to balance that against all the other factors of your situation. For example, it seems that you allow but don't enforce having different passwords. Can you instead use a centralized account database? How much containment do you need between your systems? Are you considering alternatives to Ansible that would support differing sudo passwords? Have you considered other authentication mechanisms?


Bitcoin and fraudulent transactions I was reading Police suspect fraud took most of Mt. Gox's missing bitcoins, and its effectively claiming the missing 650,000 bitcoins vanished:

  Of the 650,000 bitcoins unaccounted for -- worth about US$208 million
  today -- only about 7,000 appear to have been purloined by hackers,
  the newspaper reported on New Year's Day, adding that investigators
  have yet to identify who was responsible.

How does a bitcoin vanish? How can there be no record of the transaction?

Was this someone gaming the system with double-spending, or is this another attack?

In the Bitcoin system, "coins" don't exist as such.  Rather, there is a central list of transactions and the wallets that own the results of those transactions (the "blockchain").  In a simplified form, "spending" Bitcoin means generating a transaction that says "take this transaction output, which I can prove I own, and transfer ownership of part to wallet X, and part to wallet Y", and having that transaction accepted into the blockchain.

If you lose access to the private key for your wallet, the coins in that wallet are effectively lost forever: the relevant data is still in the blockchain, but without the ability to prove your ownership, nobody has the ability to spend them.  Since wallet IDs are not tied to real-life identities, it's also impossible to tell who owns the coins in question.

Mt Gox is renowned for the incompetence of its programming.  It's known that a large number of automatically-generated wallets were used for various purposes, and it's quite possible that the missing Bitcoins were transferred to wallets where the private keys were never recorded.

It's also possible that the "missing" Bitcoins never existed in the first place.  Mt Gox had none of the internal control and audit systems a reputable financial institution would have, so it's possible that a bug, an outside attack, or even insider shenanigans artificially inflated the apparent balance of Bitcoins held by Mt Gox.

It's reasonably certain that the missing coins are not the result of a double-spend attack.  To reliably perform such an attack, the attacker needs to control 50% of the Bitcoin computing power, and nobody has ever managed to accumulate that much.


If someone hacks my wi-fi password, what can they see and how? If someone knows my wifi password (be it WEP or WPA) what can they see? Do they just see URLs I visit, or can they see everything in my browser, or even everything I do on my computer? Does using HTTPS make any difference?

Secondly, If the attacker does not live nearby, is it possible for them to set up a laptop in my neighbour's house and record all my traffic or otherwise relay the data via the web?

If someone knows my wifi password (be it WEP or WPA) what can they see on my screen? Do they just see URLs I visit, or can they see everything in my browser,....or can they see everything I do on my computer? Does using HTTPS make any difference?

They can't see anything on your screen (unless you've enabled some sort of unencrypted remote desktop screen sharing program).

They can, however, observe all the data being sent to and from your computer (I'm assuming for WPA/WPA2 they observed the 4-way handshake at the beginning of each session; or trivially forced your computer to start another handshake), unless you encrypted that data using a protocol like HTTPS.  They would typically run a packet capture program like wireshark to decrypt the wifi encryption.

Again, they'd be able to see what HTTP webpages you requested, what links you click, the HTML content of the webpages you requested, any information you post to a web site, as well as all data (e.g., any images/movies) sent to you or by you.  They can also interfere with the traffic being sent to you (e.g., alter the content you see).  Granted anyone nearby can always interfere and cause denial of wifi service without knowing your password (e.g., often turning on a microwave oven will interfere with all wifi traffic being sent to you).  Or have their own computer/router that they fully control that sends impersonated messages as you or your router.

If you visit HTTPS sites only, they can't decrypt the data (unless they have somehow additionally compromised your computer).  However, even with HTTPS they can see what IP addresses you are sending/getting data from (which usually will let them tell what domain e.g. if you went to 69.59.197.21 it's stackexchange.com).  They also will know when and how much encrypted data is being sent.  This is possibly enough to give away private information.  Imagine you went to a webpage via HTTPS that had results of your HIV test, and an eavesdropper was listening.  If the web page for a negative result showed 3 images (of specific sizes) and a 10 MB PDF file on safe sex, while the page for positive results had 15 images and three PDF files that were 8MB, 15MB, and 25 MB respectively you may be able to figure out what their results were by observing how much data was sent and when.  This style of attack has been used to figure out what people were searching for on a popular search engine (from the instant results provided for different queries) or roughly estimate what kind of income someone had at an https tax site.  See Side-Channel Leaks in Web Applications (pdf).

Granted all this information is also available to your ISP as well and to every intermediary router between your computer and the server you are trying to visit.

  Secondly, if the attacker does NOT live nearby, is it possible for them to set up a laptop in my neighbours house for example, and programatically record all my traffic...or alternatively can they relay the data from the laptop to their own computer elsewhere, via the web?

Either is trivial to program up assuming your neighbor doesn't mind them putting a laptop in their house (or they found a power source and place to hide their computer).


Efficient Way to Brute Force With Large Wordlist I am considering attempting to perform an SSH brute force attack on my own device in order to test its security, but I have run into an issue with the wordlist. I know my own password format, as well as that of a few other devices, so I have used Crunch to create a wordlist that fits the parameters of the passwords.

The resulting file is almost 15GB. How can I efficiently test all of these passwords? The RAM on my device cannot even hold this file all at once, but I know that the password to every single device I test against will be somewhere in the list.

Is it possible to cut the large file into a bunch of smaller files and run a sort of multi-threaded brute force attack using each of the smaller files? Thanks in advance!

The resulting file is almost 15GB. How can I efficiently test all of these passwords? The RAM on my device cannot even hold this file all at once

There is no reason you would need to keep the entire file in memory.  Just read the file part by part.  Achieving this and speeding it up is just a matter of how you code it.

In addition, if it's your own device then you can cut out the SSH client and server completely and simply perform the brute forcing directly on the password hashes in your shadow file.

Instead of reinventing the wheel, there are pre-existing solutions for brute-forcing hashes as quickly as possible.  There are also pre-existing lists/generators so you can use what a real attacker might use to get a bit more of a real-world test.

It looks like you're trying to brute-force your own passwords using a generator tailored to your own password format.  The usefulness of this is dubious.  Are you just trying to get a sense of how brute-forceable your passwords are?  The use of your custom generator would render the results fairly meaningless.  Even if you switched to pre-existing brute-forcing tools with pre-existing wordlists/generators the results will be of limited use (unless you succeed of course!): you don't just want passwords that can't be brute-forced easily, you want it so that it has additional entropy spare even after that point so it's practically not achievable.  You can get a general sense of how much entropy exists in your password by inspecting it and having a good understanding of how much you need.


tcp seq number prediction While testing a system, nmap told me that the tcp seq number prediction is really low, (trivial joke). There is only one system in the whole range that gives me that answer. Some papers, e.g. a weakness in the 4.2 bsd unix tcp/ip software, that even though it's old, describes the problem, seem to point that today seq numbers are generated more securely.

I wondered, is there any other tool then nmap with which I could verify the tcp seq number prediction? It'd give me more confidence in the result.

You can use hping --seqnum to get a dump of sequence numbers, with differences shown. For extremely trivial sequences, this might give you a result.

#hping2 win98 --seqnum -p 139 -S -i u1 -I eth0
HPING uaz (eth0 192.168.4.41): S set, 40 headers + 0 data bytes
2361294848 +2361294848
2411626496 +50331648
2545844224 +134217728
2713616384 +167772160
2881388544 +167772160
3049160704 +167772160
3216932864 +167772160
3384705024 +167772160
3552477184 +167772160
3720249344 +167772160
3888021504 +167772160
4055793664 +167772160
4223565824 +167772160

I don't know of any tool (other than nmap) that'll directly analyse the predictability. You could always collect a few hundred thousand and send the number through Diehard to see how well they perform, but I don't know how meaningful that'll be.

As an aside, this article on attractors in TCP sequences is a very cool visualisation of the poor RNG techniques used in some systems.


How (un)safe is it to use TKIP? I have recently bought a wifi range extender to improve the signal coverage through the house. When I set it up, I noticed the iOS 14 recognizes it as unsafe since it uses TKIP and advises to set it up to use AES instead. I did my research and according to the manufacturer, it seems the device automatically uses WPA2 for devices that support it, but there is a WPA-TKIP combination also available for older devices and there is no way to disable it.
So the question I've got, is how safe/unsafe it is to use it anyway, considering the fact that there are only a few mobile devices ever connected to it and all the rest are connected to the main router which uses WPA2? What real-world attacks am I exposing myself to and are they only limited to the extended network or is it possible for the attacker to also access the main one (the main router)?
I apologize if there are potential trivial things I don't know about this and I'm asking some rather obvious question, networking and security are not exactly my strong points. Appreciate the help.

TKIP is deprecated since 2010, and practical attacks exists against it. You should not use it. Since you do not have devices that requires it, you have no reason to leave it activated and all the reasons to disable it. I suggest you look into your range extender manual for how to configure it.


Is it possible to fake an AES-encrypted data? The requirement is we want to generate a bunch of keys, and we need a way to validate if this key is generated by us. My suggestion is to generate a UUID, do a HMAC use a secret key on the UUID, then the UUID+HMAC result should be the key. The problem here is UUID+HMAC is too long, so we can use only part of them as key.

Meanwhile, my colleague suggests another way is to generate a UUID, do an AES on it, use the encrypted data as a key, he thinks the encrypted data can not be faked, but I am afraid this is not a safe way. As we don't do any other validation here.

So the question is: is it possible to fake an AES-encrypted data, that can be decrypted by a given secret key? If it is not possible to fake an AES-encrypted data, which one should we use? HMAC or AES?

Performance should be considered, because we have about 1 billion requests to handle every day.

So the question is: is it possible to fake an AES-encrypted data, that
  can be decrypted by a given secret key?

If there is no authentication added to the data, then yes, easily. Block ciphers are really just permutations of all possible plaintext blocks to all possible ciphertext blocks. Or, in other words, any 128-bit block of data is a valid ciphertext for some plaintext, for any encryption key.

However, if we require that valid plaintext blocks have some structure, like trivially requiring the last 64 bits to be zeroes, with the data in the other 64 bits, then only 1/2^64 ciphertext blocks will produce a "valid" plaintext. But that only works for one-block messages, and is harder to do with multi-block messages, so one might as well use something designed for authentication.

  The requirement is we want to generate a bunch of keys, and we need a way > to validate if this key is generated by us.

This doesn't sound like something that would require encryption (making sure third parties can't read it), but authentication (making sure third parties can't fake it). Some message authentication code would seem to be in order (be it HMAC with some hash function, CMAC if you prefer AES). Note that there's no need to use the full authentication tag produced by the MAC. You can instead truncate it to trade off some security for a shorter length.


How secure is binding to localhost in order to prevent remote connections? Let's say we're running a service that's bound to localhost (127.0.0.1), and the goal is to only allow local clients (i.e. from the same machine only)

What techniques might be used to break this security, are there additional measures that could be used to enforce it?

The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to 127.0.0.1.

Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local listening services.

I do not know which kind of other services are listening on your machine, but if any service can be used as a relay you must ensure it is properly configured to prevent to relay anything to the local listening services.

For instance, if you have an HTTP proxy running on this host, an attacker can use this proxy to request the host "127.0.0.1": from the firewall perspective this will be a legit connection coming from the network to the proxy service, and locally this will be a legit communication between two local services (the proxy and the targeted local port). The HTTP proxy here is just an example, such technique may also work with other services, including services where relaying connections is not the main functionality (the FTP bounce attack for instance is a classical example of such threat).


Windows API call sequence monitoring I need to monitor an API call sequence created by a process running on Microsoft Windows, to analyze malware behavior.

I know we can do user mode or kernel mode monitoring. I have tried some tools that can intercept API calls, like Detours, EasyHook, and NTHookEngine, but all of them, in my understanding, utilize the user mode monitoring. This makes it impossible for them to detect malware running in the kernel mode (like rootkits).

If we try to hook API call using Detours or EasyHook we have to define our own hooking function which in this case I don't need to. I just need to know the function that is being called by a monitored process and its parameters.

Is there any way to do it in efficient (few line of codes) and effective (user mode and kernel mode monitor) way?

Regarding user-mode hooks, perhaps you can write a generic stub function that

Hooks onto all the kernel32 calls.
Passes the call to the original API address (you'll have to build an array of all the original API addresses to determine the correct address).
Compare the callee's address against the IAT to the original API address.

This call sequencing technique for rootkit detection can clearly detect hooks, but I can't imagine it would work for runtime patching - AKA inline hooks, as they don't build a stack frame.

If you're reluctant to go down this route, you might consider hooking onto the Native API in kernel mode, which has about ~290 functions for Windows 7 SP1. You'll have to disable or bypass PatchGuard on x64 systems though.


Good Security API package for Java Is there a good security API (all in one) for Java to prevent things like SQL injections, Cross site scripting and those owasp top 10 vulnerabilities?

No.

Prevention of Cross Site Scripting, SQL Injections and the like are implementation details. They depend on the care and expertise that the developers put into the code, and no library can solve this for you. There is a broad spectrum of utility libraries available that can help you with this task. Trying to create a comprehensive list would be beyond this answer.

Trusting automatic mechanism, especially a single library to blanket-solve mentioned security issues, is a breeding ground for security vulnerabilities. There is no way around the fact that securing a system costs time, energy and resources. A better understanding of the nature of these vulnerabilities might be the first thing necessary to prevent the same.


Are Security Auditors liable for breaches? For someone who is conducting a security audit.
Can the security auditor be liable for any security breaches?

Professionally competent auditors having exercised due care generally
  cannot be held liable for a security breach due to undiscovered
  vulnerabilities

The main reasons for this are explained below.

  Reasonable assurance vs. absolute assurance

An inherent limitation of any audit is that assurances they provide are reasonable and not absolute based on the evidence gathered by the auditor. It is not possible to achieve absolute assurance. As long as auditors follow professional audit guidelines and properly document their work, they are ordinarily protected. It would be not be feasible for an auditor to guarantee absolute assurance in that all security vulnerabilities will be found, due to constraining factors such as audit resources allocated, management cooperation etc.

The same can be said for security controls in that such controls only mitigate but not completely eliminate risks, otherwise defined as an threat exploiting a vulnerability. The extent to which risk mitigation is achieved is mainly a function of how well the control is designed and operating. I said mainly in the previous sentence because even if a particular security control (example: Segregation of Duties) is both designed and operating effectively, human collusion or management override can render the security control ineffective.

  Management Control over security controls

A security audit (or any audit) cannot by itself prove anything other than an audit was done. The main reason is that security controls, as a subset of the internal controls of a company, is overseen and owned by management of that company. Auditors, as external independent actors, cannot attest to security controls not subscribed to by management. Therefore, auditors may only attest to the assertions of company management  management, and if necessary security controls to achieve particular principles are missing or inadequate, should qualify their opinion issued to management. It is management who ultimately can decide to secure an organization, not the security auditor.


How to know for which packet snort alert triggered for How can we know exactly which packet alert triggered for?

Please let me know how I can find exact packet. I understand that IP addresses are an indication but there are mostly too many packets in pcaps for one IP.

If you use a recent build of Wireshark, it has a Snort post-dissector which substitutes the packet number into the fractional part of the timestamp before it feeds each packet to Snort.  When an alert fires, it can then attach the alert info to the correct packet (showing the correct timestamp) in the Wireshark packet list.