How to use TPM to perform platform authentication?

What you need is remote attestation (QUOTE operation).

The Endorsement Key (EK) is not directly accessible as this would be privacy issue - we could track a system using this unique identifier. The EK can be used in conjunction with an Attestation Identity Key (AIK) or using Direct Anonymous Attestation (DAA).

The AIK model make use of a Privacy CA (Certificate Authority) which assert the validity of your EK to a third party. Multiple AIKs can be created to protect your identity (e.g. one AIK per thrid party, one AIK per security domain).
The DAA model use 'Zero-knowledge proof' to anonymously verify your EK. See this to get a general idea how zero-knowledge protocols works.

I suggest you take a look at OpenAttestation open-source solution from Intel, PrivateCA and this presentation.


Firefox presenting a Deceptive Site warning when trying to download a popular github resource. Should I ignore it?

Most Releases on GitHub are hosted on GitHub's own servers (codeload.github.com), so if this URL is pointing somewhere else it may be purposely hosted elsewhere by the developers rather than Github's own distribution systems.

I would exercise caution. Firefox (and other browsers) don't generally inspect the content of downloads and leave that up to the security software on your system if present. They do evaluate the hosts you are connecting to and use a combination of blacklists and other techniques to determine the safety level. The error could simply indicate that suspicious content is located somewhere else on the same host, or that the content you are actually trying to address is hosted in an insecure fashion and that the integrity of the content is questionable.

Be sure to use independent verification methods for any content you eventually download, such as PGP signatures or published hashes. If you trust the source, then a hash match or signature verification shows that you do indeed have exactly what they published.

Finally, the connection you are using may be suspicious. I don't know where you are, but some ISPs may intercept and modify traffic in-flight which Firefox is alerting you to.

Proceed with caution regardless, and if you genuinely believe it is a false positive, you should raise it first with the site owner, and encourage them to take it up with your browser's developer.


Should I accept a self-signed certificate from my university?

It is not a problem to use a self-signed cert provided that you distribute that cert to users so that they can verify that the cert they are approving is the cert for the genuine site and not some site spoofing it. In this situation, you are told to approve it but you have no way to validate that you are connecting to the correct site.

So there is definitely a risk for accepting it. If someone was able to create a fake site, put their own self-signed cert on it, and somehow convince you to go there (via social engineering, DNS tampering, WiFi attacks, etc...), you'll approve a cert for the attacker's site and never see that warning again. Then you'll happily pass your credentials to that site. Very bad.

What you need is to get the fingerprint of the actual self-signed cert then compare it to what your browser is seeing (see this page for reference). But I'd guess that you will have a hard time getting any more information from the site's owners. So you have to decide if you are going to take the risk or not. One way to lower the risk a bit is to try to make the initial connection when you approve the cert happen over a more secure internet connection. For example, a hard-wired connection is likely harder to be altered by an attacker than a WiFi connection.

Depending on how the site is configured, you may be able to connect to it, approve the cert, login with your school id, then immediately change your school password (best if from another browser altogether). That will reduce the window of exposure if the connection is being snooped. Hopefully the site will allow you to stay logged in for subsequent accesses so you don't have to do this every time.

In the end, you'll have to get more information about the cert so that you can verify it by hand or cross your fingers and hope for the best.


Can do I brutefore wifi password with handshake without wifi detection?

Since you have written that you captured the handshake.The next logical step is to bruteforce the cap file that you obtained at the handshake part.For that use the following command
aircrack-ng capfile -w wordlistfile

ofcourse change the capfile to the name of your cap file and your own wordlist

P.s:- You should really google first before asking


Why am I asked personal information when creating an OpenPGP key?

First of all, you don't need to enter them, or you can enter false ones if you like, so go ahead and do so if you so prefer.  (You may need to read up on the options to disable the fields.)

But the reason PGP asks for such information is that it's not just a tool for encrypting messages—it's also a tool for defeating impersonation, i.e., proving that message senders and recipients really are who they claim.  The point is that, as long as you control your private key (nobody has stolen it from you), and other people are confident that your public key belongs to you (the web of trust has tied your public key to your identity), now:

People who send messages to you can be confident that they're reaching you, and not an impersonator;
People who receive signed messages from you can be sure they come from you, and not an impersonator.

Note also that it doesn't matter if the identity tied to your key is your real name, or an alias, or whatever—it just needs to be something that other people will recognize you by.  It's just the answer to the question "whose key is this"?  PGP doesn't care if the answer looks like "Jane Smith ", "John Doe" or "spaghettiman123"; only the people who try to use the public key will care.

  Another suspicious thing was after what time the key should expire. Is the information about expiration date contained within the key (I don't think it is) ? So is the key stored on a server somewhere or what? How does it work?

The expiration date is stored in the key.  The idea is to protect you if your private key gets stolen without you noticing—the expiration date means that the person who stole it only gets a limited time window during which they can impersonate you.

PGP doesn't automatically store keys in servers, and doesn't connect to any server as part of routine operations.  But public keys can and often are uploaded to key servers so that people can download them off there.

  The reason I ask is that this whole PGP thing seems more centralized than I thought. Why can't the PGP software just have a "Generate a new key" button which generates both the public and private key for me to copy and use (+ of course an option to encrypt/decrypt text) ?

It's not centralized, but it does want to interact with other systems—public or private—in order to work ideally.  But you don't have to use any of that.  You can just generate a key pair with no identity attached to it.  You can manually give the public key to a counterparty in person, e.g. in a flash drive, and that will work fine.

The tricky issue here is: how do you securely get another person's public key over the Internet?  If you just downloaded Jane Doe's public key from some web site, you have no way of knowing whether that's really her public key or an impersonator's.  So all that extra functionality you're seeing is about providing tools to attack that problem.  Again, read up on the web of trust, and on public key infrastructure.


Does sending credit card info over email violates PCI DSS?

Yes, PCI DSS requirement 4.2:

  Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

Unless the email is somehow encrypted, you are not allowed to use it to send cardholder data.


Snort Rule Writing (Alert Fires But Traffic Does Not Match *Intended* Rule)

Boyer-Moore isn't the problem.  Snort should match the entire string, always.  It doesn't make sense to have the "within:100" in the second content match because http_header is a completely different buffer.  That should be removed.  But that doesn't explain why this would alert if the content wasn't in the original packet.

Do you have a pcap of traffic that trips this?

Thanks,

~Patrick


Contents for Security Operations Reporting

This is pretty loaded and will likely be dependent on your organization and business vertical. For instance, your organization may be interested in receiving monthly reports on failed logins for executives, but some orgs may not care about that (for various reasons...).
In general though you will likely want to receive a number of reports, such as:

1) A report breaking down all critical or high risk incidents and their corresponding investigations for the month.

2) A report breaking down events be severity and category (as defined in conjunction with the SOC and the business). This can help with trend spotting.

3) A report discussing activity within the environment over the month such as it may affect the SOC and organization (such as EPS trends and so on).

Rackspace has something on this with sample reports here: https://www.rackspace.com/sites/default/files/white-papers/7_rackspace_managed_security_-_sample_reports_copy.pdf


Is it generally a bad idea to encrypt database fields?

General comments. It sounds like it would be helpful for you and your boss to learn some basic security concepts, before proceeding.  Security is a specialized field.  You wouldn't ask a random person on the street to perform open-heart surgery on you; and you shouldn't expect an average software developer to know how to secure your systems.

I sense some misconceptions here.  For instance, it sounds like your boss has equated security with cryptography.  But this is a mistake.  As Bruce Schneier has emphasized, Cryptography is not magic pixie dust that you can sprinkle on a system to make it secure.  And as Roger Needham once famously said, If you think cryptography will solve your problem, either you don't understand cryptography, or you don't understand your problem.

When securing a computer system, one important concept is the threat model.  This means you need to think carefully about what kinds of attacks and adversaries you are trying to stop, and what you aren't.  A failure to think through the threat model clearly can lead to security theater: security mechanisms that look good on first glance, but actually are woefully inadequate in practice.  Good security management often comes down to risk management: careful analysis of what are the most serious risks, and then devising strategies to mitigate or manage those particular risks.

It is also important to understand that security is a weakest-link property: the security of your system is only as strong as the weakest link.  A vulnerability in any one part of the system can compromise the security of the entire system.  This means that there's no one answer that's going to be sufficient to protect your system; instead, to defend your system, you have to get security right in a number of places.

Diving into details. It sounds like your goals are to prevent unauthorized disclosure of sensitive data.  If so, you're going to need to focus on a number of items.  There's no one simple magic silver bullet that is going to solve this for you; you are going to need to work on application security generally.

Let me suggest some things that should be priorities for you, if I've understood your goals correctly:

Application security. You need to start studying up on web application security.  It doesn't matter how much crypto you throw at the problem; if an attacker can find a security hole in your application code, you are hosed.  For background on web application security, OWASP has many excellent resources.  Make sure you learn about the OWASP Top Ten, about XSS, SQL injection, input sanitization/validation, output escaping, whitelisting, and other concepts.
Access control. Your web application needs to have solid access controls, to ensure that one user of your system cannot access information of another user (without authorization).  The details of this will depend upon the specifics of your particular system, so if you want additional help on this, you'll probably need to post a separate question with more details about your application and your current strategy for access control.
Authentication. Your web application will need a way to authenticate its users.  The standard least-effort scheme is to just use a username and password.  However, this has serious limitations in practice that are well-understood.  If users choose their own passwords, they often choose poor passwords, and this can subvert the security of your system.
Secure software development lifecycle. You need to integrate security into the software development process.  When you work out the software architecture, you should be thinking about the security requirements and performing threat modelling and architectural risk analysis.  When writing code, you need to know about common implementation errors that can breach security and make sure to avoid them.  After the software is built, you need to test its security and constantly evaluate how you are doing at security.  When  you deploy the software, your operations folks need to know how to manage it securely.  Microsoft has some excellent resources on the secure software development lifecycle (SDL).  See also BSIMM for more.
Security assessment. If you are concerned about security, I suggest having the security of your application assessed.  A simple starting point might be to have someone perform a pentest of your web application, to check for certain kinds of common errors.  This is by no means a guarantee of security, but sometimes it can help serve as a wakeup call if there are many major problems present.  You might look at WhiteHat Security's services; there are also many others who will perform web pentesting.

If you are getting the sense that this is not a trivial undertaking, I apologize, but that is indeed the case.  On the other hand, the good news is that there are a lot of resources out there, and moreover, you don't need to become an expert-level security guru: you just need to become familiar with some basic concepts and some common security mistakes in web programming, and that will take care of most of your needs.


How to have client encryption without server encryption key

First: The very first rule of cryptography: Don't roll your own crypto!

Second: Why do you want to setup this service? Signal (+ OTR or Axolotl) does all this already for: It's open-source, allows peer verification, offers end-to-end encryption, offers client-side encrypted storage and is trusted by all well-known cryptographers.
Disclosure: I do use Signal and I'm convinced of its quality, I'm not working for OpenWhisperSystems or otherwise affiliated.

But now, let's head over to actually answer your questions:

  I understand that this is what SSL basically is, but is it really the
  best option out there especially if the certificate servers are US
  based?

SSL (or more modernly called TLS) usually provides transport security between the end-user and your servers. It does not by itself do anything beyond that. You could let the clients establish TLS sessions between each other (resulting in good end-to-end encryption) however TLS is more designed to be a (somewhat) real-time security protocol. Concerning the certificates, if you do use something else than the RSA key exchange, a leak of the private key won't allow TLS data decryption (if you deleted the ephemeral (EC)DHE keys) but would allow man in the middle attacks (this assumes you use anonymous / ephemeral (EC)DHE). Adapting a TOFU-style approach or another key-update mechanism could make the connection resistant to man in the middle attacks after the initial connection.

  Is it possible to have dynamically generated client keys only stored
  on mobile devices that can't be cracked by me?

Absolutely. OTR already includes such a functionality. Basically you want to end up as a relay for the messages the clients transmit (much like the standard internet infrastructure) while they securely negotiate a shared secret via your servers. You can verify your peer than by comparing the hashes of the shared Diffie-Hellman secret (or the public key of the other party used to authenticate Diffie-Hellman public keys) out-of-band.


Why do banks still hack-up autocomplete=off functionality?

While there are aspects of truth in what you say, you have to look at the bigger picture and look at where banks have liabilities and risks. Banks look to minimise the risk down to a certain level (eg there is a fraud appetite that is accepted by banks, as to try and reduce it further costs more and more, rapidly becoming unworkable) and many of these drivers conflict with user experience requirements.

Additionally, technical requirements form a good part of the risk profile and appetite for a bank. So that also leads to trade-offs.

Allowing user devices to store credentials could be a way for attackers to gain even easier access than their current phishing success rate, so unless you have a strictly enforced set of standards by which all password managers work, that can also be audited and assessed by the banks, you are in a position where you may be improving security but you may be decreasing it.

The worst case for the banks there is that security becomes reduced, customer accounts are attacked, and the banks are held liable for it.

So keeping the onus on the customer to control their credentials is generally considered better for the majority of customers, and the bank as a whole, while for some customers it will be worse. And for those customers, they can improve their security through awareness training.


The hidden meaning of the source code of the malware?

Why not declare the name of dll as below? Is it just a certain insertion of a null char?

No, these two lines of code create identical null-terminated strings in the resultant binary:
char dllA[] = {'K','E','R','N','E','L','3','2','.','d','l','l','\0'};

and
char dllA[] = "KERNEL32.dll";

Perhaps the malware author believed there was a difference, but more likely, it's a style choice only.

It doesn't do anything. Why need this code?

It's almost certainly a NOP Sled.  When placing a buffer overflow, it may be difficult to calculate exactly where the instruction pointer will land.  By preceding the meat of the overflow code with a series of No-Op instructions (which do nothing) that instruction pointer can slide smoothly along until it reaches the exploit code, as long as it lands anywhere in the NOP Sled.


I'm not familiar with libqs-openssl, but

The documentation clearly says that the necessary cipher support is for TLS 1.3, while your code insists on using TLS 1.2
You are trying to use ciphers which require RSA certificate, even though you don't have a RSA certificate

This together means that there are no ciphers which could support the authentication method available with your certificate. In other words: no ciphers and therefore also no shared ciphers.


Why did Apple think OS/X was virus proof?

Compared to Windows, Mac OS X has:

Smaller user base: Means it is less interesting to malware creators, thus fewer viruses. Although there are viruses for Mac OS X, they're not as much as Windows malware. In the past few years, this has been changing, and it's backfiring. Because people think they're less prone to malware, they tend to develop bad usage habits, such as trusting, downloading, and executing everything.
Better access control: Unlike Windows, with Mac OS X you don't have access to root/admin account by default. Starting with Vista, Windows starting using UAC, which is way better than nothing, but still provides easy access to root/admin privileges.

Apple never explicitly said that Mac is virus-proof (there are many nasty viruses for Mac out there), but they implicitly manipulated the users into thinking so. While keeping that in mind, it's also good to know that on average (and with an average usage behavior) you'll definitely be less likely to be infected by malware while using Mac OS X than using Windows.


client_id vs distinguished name in mutual tls

Client Identifier
The client identifier (client_id) is a string chosen by the authorization server (AS) during the client registration, as defined in the OAuth 2.0 RFC.

2.2.  Client Identifier
The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client.  The client identifier is not a
secret [...] The client identifier is unique to
the authorization server.

If the client wants to authenticate at the AS, the client uses his client_id to tell the AS which specific client is going to communicate with him.

Distinguished Name
The distinguished name is part of the X.509 PKI Certificate Specification:

4.1.2.4.  Issuer
The issuer field identifies the entity that has signed and issued the
certificate. The issuer field MUST contain a non-empty distinguished
name (DN). [...] distinguished names are composed of attributes.
4.1.2.6.  Subject
[...] the subject field MUST contain an X.500
distinguished name (DN).  The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field.

So the issuer of a X.509 certificate writes his distinguished name inside the certificates he issues, as well as the distinguished name of the subject he issues a certificate for. A DN consists of multiple elements, e.g. country and organisation. For StackExchanges certificate, the issuers DN consists of US and Let's Encrypt, while the subjects DN consist of multiple Subject Alt Names, that are DNS names.

PKI Methode of mTLS OAuth 2.0 Client Authentication
In OAuth mTLS, the AS uses the client_id to look up the clients configuration and expected credential, as explained in Section 2:

For all requests to the authorization server utilizing mutual-TLS
client authentication, the client MUST include the "client_id"
parameter [...] the "client_id" parameter enables the authorization
server to easily identify the client independently from the content
of the certificate. The authorization server can locate the client
configuration using the client identifier and check the certificate
presented in the TLS handshake against the expected credentials for
that client.

In contrast to the Self-Signed Certificate Method of authenticating the client, the distinguished name is only used in the PKI Methode, where it is used to identify the client in a verified way:

PKI Mutual-TLS Method relies on a validated
certificate chain [RFC5280] and a single subject distinguished name
(DN) or a single subject alternative name (SAN) to authenticate the
client.

During the OAuth Dynamic Client Registration, a client registrates at the AS. During this process, the client sends metadata, that is stored by the AS and later used during the client authentication. So the tls_client_auth_subject_dn is an information, a string, the client sends to the AS during registration. It is thus not an action. It is the piece of information the AS will use at a later attempt of the client to authenticate to identify the X.509 certificate and to verify the certificate belongs to the client, as written in Section 2.1.2:

A client using the [...] MUST use exactly one of the
[...] metadata parameters to indicate the certificate subject value
that the authorization server is to expect when authenticating the
respective client.


How to tell if a "PGP PRIVATE KEY BLOCK" is passphrase protected?

Is this passphrase-protected? There's a high probability it is!

  How can I know if this is passphrase-protected?

Simply enough: import the exported key and try to use it; if it was originally created with a passphrase, it will be exported with the passphrase. You need to know it after the import, too.

It is possible to create a passphrase-less key pair, but after confirming this three times and then finally re-entering the empty passphrase you should already be pretty aware that this isn't smart:

  How can I tell if this is passphrase-protected?

You can also analyze the key with gpg --list-packets --verbose private-exported.asc.

On a password protected key you'll see something like this:

    pkey[1]: 010001
    iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: 85B065E6EAFE95F6
    protect count: 2752512 (181)
    protect IV:  e6 47 c1 03 96 b1 5c e8
    skey[2]: [v4 protected]
    keyid: F5798EF2ECAC2051

While the unprotected key reveals all the keys like this:

    pkey[0]: BC1A19AD1A1AC852F7A5E....
    pkey[1]: 010001
    skey[2]: 02CA55EDF940900EFFD2A....
    skey[3]: D477DA74DF0DCD8E991AA....
    skey[4]: E2A43778C36FEE7E27903....
    skey[5]: E0CC81786737F2838A7FE....


Directories enumeration by errors. CVSS3.1 and remediation

It is difficult to determine a correct CVSS score as the internal tree structure is not exactly what we can call a "secret".
So the confidentiality impact has to be discussed.
Gaining information about the target makes furthers attacks simpler, but it is not an attack.
This difference is sometimes materialized by the concept of "non compliance" which is different than "vulnerability".
The remediation for this specific example is often to capture and log every error (so you get notified when there is an error 500 and other important ones) and to display a generic error message with a code 200 OK to the browser.
This way, you can also get rid of many web scanners


If it is only for development purpose you can add process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0; in your source code or use environment variable on your system with :

$ export NODE_TLS_REJECT_UNAUTHORIZED=0

For production, it's mostly recommended to use a trusted CA certificate.


I take it when you say WPA2 you mean WPA2-Personal. It is good enough in most cases at the moment as long as its combined with a really good password. https://www.grc.com/passwords.htm is a good generator for them.
Disable Wi-Fi Protected Setup (WPS). Otherwise, an attacker only needs to break an 8 digit PIN -- and that is perfectly doable.
Cloak your SSID. It won't stop a determined attacker but will stop some of the script kiddie like attackers.
Only allowing specific MAC addresses can be a good step to manage user access. But once again won't really slow down a determined attacker, as they can just see what MAC addresses are currently connected to wireless in plain text anyway.
If possible a good tactic to reduce the chance of your WiFi being attacked is to position your wireless access point well so that the minimum amount of signal is broadcast outside of your building. That way the attacker needs to be closer to start the attack unless they have improved wireless antennas to grab from miles away.

Yes people can broadcast a stronger signal to try and get you to connect to them instead of your actual desired access point using tools like Karma. I don't know any specific ways to protect against this except not to allow any automatic associations instead each time you wish to connect to wireless, you should do it manually and verify you are connecting to the correct access point.


What tools are available to compare a 'before' and 'after' security baseline of a Windows machine?

As Serge's answer mentions, you may want to consider some contractual controls for this situation, in addition to your technical approach. I am going to assume for this discussion that this action has already been approved through your company's Compliance Program and complies with your Policies. Don't grant low-level systems access to a third-party like this without first confirming the origin of the request and authorization, etc.

But since you asked for tools... ReverseDSC might be an option. It uses PowerShell capabilities to produce an inventory of the system's current settings. It's not going to catch absolutely everything, but it should give you a decent baseline for comparison.

Check out Nik Charlebois' Blog for an introduction to the tool. Or if you prefer some good audio content, RunAsRadio Episode #566 is an interview with Nik and covers some of the same concepts.

In full disclosure, I don't even work in a Windows environment, so I've never used this. But in theory, it sounds like what you're looking for.


Buffer overflow: How is it actually implemented in a pen testing environment?

Most of the times you'll have to emulate the target's system and develop your exploit locally. About how to learn about the target's system, that has to do with the enumeration process. Of course depending on the binary you're trying to exploit, it may be possible to achieve an information leakage, and in that way you'll be able to make your exploit work even remotely even if your system is a bit different from the target's system (of course if your target uses e.g. linux you'll have to use linux also, but not the exact version).

For example, in case of a format string vulnerability you may be able to leak libc remotely. But there are other cases also, for example if the binary uses a string writing function, like puts (or printf etc...), it may be possible to use that function to leak libc base address from a GOT entry in runtime so you can construct a multi-stage exploit that bypasses even aslr. Now about how you can compute libc base address from a leak, there many ways (you can either use libc database or a web wrapper of libc-database here etc...).


I don't think it would be a wise idea to give how-to's on XSS attacks; though many resources exist e.g. Ch. 12 of the WAHH on XSS.

The best way to prevent XSS attacks is to substitute every special character used in these attacks (e.g., <, >, &, ",'  with their html character equivalent &lt;, &gt;, &amp;, &quot;, &#39;) for all user-provided text and only allowing users to markup their comments using a limited non-html markup language (like markdown) that only gets substituted into a safe subset of html at the last step of processing.  (Also be careful their comments never get executed in any sort of javascript processing  you wrote).

If you choose to ignore this, and only sanitizing specific tags (like <script>, <object>, javascript check the sanitation is being done recursively (so <scr<script>ipt> doesn't become <script> after a single-pass sanitation), is case/white-space insensitive, and only stops when the last complete sanitation attempt did not change the input.  In python something like

import re
def sanitation_single_pass(user_input):
    pattern = re.compile('<[^>]*(script|object|meta|style)[^>]*>', re.IGNORECASE)
    # this is very quick sample regex that could appear in a sanitation routine
    # not meant to be inclusive of most XSS threats;
    # e.g. this doesn't prevent having javascript in links or img src, etc.
    return pattern.sub('', user_input)

def sanitation(user_input):
    processed_user_input = sanitation_single_pass(user_input)
    while processed_user_input != user_input:
        user_input = processed_user_input
        processed_user_input = sanitation_single_pass(user_input)
    return processed_user_input

Also pay attention to encoding issues, make sure you define a charset (<meta charset="utf-8"> at the top of your html templates) and that you force user input into this encoding before sanitization.  Also try to recognize that some browsers will interpret things like java&#x0A;script as javascript (&#x0A; is a line break), etc.


Making 2 yubikeys generate the same password

If they were initialized with the same seed and had been through the same number of iterations, it's probably possible.

What you should be doing is registering the two different keys to the same account. Should you lose one, invalidate it.


Why do cipher suites with message authenticated cipher modes also specify a hashing algorithm

While AES-GCM and ChaCha20-Poly1305 use AEAD cipher modes, and thus do not require a MAC on the encrypted data, there are still some parts of the TLS protocol which require a hash function.

The first is for handshake validation. When the Finished message is sent, it contains a hash of all the previous handshake messages sent, which allows TLS to validate that handshake messages sent before the key exchange weren't tampered with. The hash function used here is the one specified in the cipher suite. You can read about this in RFC 8446 Section 4.4.4.

The second is for key derivation. While the session master key is exchanged or agreed upon via ECDHE or a similar mechanism, this master key isn't directly used for encryption or authenticity verification. Instead, a PRF based on a HMAC is used to derive keys for various purposes (e.g. encryption), and the underlying hash of that HMAC is specified in the cipher suite. You can read about this in RFC8446 Appendix E.1.1 and in more detail in RFC 5246 Section 5.


Can a spam email full of junk characters be dangerous?

It's probably an encoding or rendering error by the sending software and/or (less likely) your mail delivery infrastructure or mail client. It would be helpful to see the Content-Type and Content-Encoding headers and MIME headers to see how the sending software specified your client should read the message.
It's always possible that it's just nonsense spam, sent to distract spam filters and harm their accuracy so that spam with real payloads can be delivered later (see also Hash busters and Bayesian poisoning), but it's more likely that the attacker messed up the encoding.
Remember that lots of spam comes from botnets, meaning the message content needs to sneak through anti-virus, then decrypt/decompress, then spew out into the world. There are lots of places that could have gone wrong.
The likelihood that this content could itself be harmful to your computer is close to zero. There could be some odd 0-day that it takes advantage of, but not that I've heard of (that would be huge).


How to secure a truecrypt container allowing access with multiple SSH public keys?

The data itself can only be encrypted by a single key without having to encrypt the information multiple times (which also wouldn't allow for information to be shared between users).  What you would want to do is have a master key which is then protected multiple times, once for each of the users.  Each user could then access the key to access the container by using their own key.

I've not worked with TrueCrypt myself, so I'm not sure if it is viable to do this in an automated way or not.  It's worth noting that this would also likely not provide a guarantee that any one user not masquerade as another.  It would be far more complicated to pull something like this off as I would think it would require some kind of a versioning system where each revision was stored, signed by the user and then applied, but then changes would have to be replayed (either to get the current state of the data, or played in reverse to validate the revision history hasn't been tampered with).


Windows BitLocker- Is the drive Password the same as the Key used by AES to encrypt the drive?

BitLocker, and most full disk encryption systems, do not directly use your password for encryption. Instead, your password is used to encrypt a random, computer-generated master key which is used to encrypt data, and the encrypted version of the master key is stored on the hard drive. When you unlock the drive, you decrypt the stored master key which is then able to encrypt and decrypt the rest of the drive. This scheme makes it possible to change your password quickly without needing to re-encrypt every byte on the drive (only the comparatively small master key needs to be re-encrypted).


This does not protect against a breach of SSL. If an attacker can breach the SSL connection he can read both the nonce send from the server and the encrypted password and can thus decrypt the password. Even if it is not encrypted but hashed together with the nonce (as done usually in digest authentication) the attacker could simply replace the script used for encryption to leak the password because this script is sent by the server too inside the breached SSL connection.

Apart from not protecting against a breach of SSL this proposal (and also digest authentication) also needs the password to be stored in clear text (or equivalent) at the server for comparison. This actually makes the system less secure in case of a server hack than the usual systems where the password is stored as a one-way hash.


By definition, if it doesn't matter if someone has access to or modifies your data, then it isn't sensitive and doesn't have to be secure.  For things that have to be secure, then it is ill advised to use a custom protocol unless you can invest the huge amounts of time and resources necessary to ensure its security (millions).

Note that there is also a difference between the security and data protocols though.  You could use something like SSL and use any protocol you want for exchanging the data.  Similarly, you could have your own system for verifying the user credentials, but the hash algorithms and encryption algorithms and anything else that can use standards should do so.

There is a lot more flexibility in how you use the standards together than in trying to make your own standard.  Certainly it is preferable to use a complete standard system if possible, but it is far less burdensome to prove the security when you are using components that can be assumed to do their job in a secure and well understood manner.


What solution is compliant with HIPAA for for web-based electronic digital signatures?

The last place I worked we were in the in the process of using the Topaz signature pads. They have an SDK that allows you to grab the signature image off of the pad. From that point you could just embed it in your PDF (if you are creating them using something like iText to generate your PDF).


How to prevent SSH host impersonation attacks?

I have SSH server, where users can login to with their username and password

Here's the obvious way to fix the problem. Don't use passwords. Instead of letting users choose a password (or generating a password for them) let them upload a public key (or generate a key pair for them). With key authentication, an adversary who can intercept communications can impersonate the server to the client, but cannot obtain the credentials to impersonate the client to the server.
To completely prevent the risk of impersonation, you can provide the server's public key out of band and instruct users to add it to their known hosts file. Using certificates for this makes management easier if you control multiple servers, but it doesn't simplify the initial client provisioning.


If you voluntary contribute to a Distributed Denial of Service attack you are being an accessory if someone uses the botnet (you are voluntary part of) to perform an illegal action such as taking down a website. If this take down results in financial damages you may be hold accountable for those damages.

Here's a small excerpt of an interesting article on LOIC:

  Getting back to DDoS arrests, there are many, many precedents of the
  law catching up with anons who turn out to be not so anonymous. In
  late 2010, a 16 year old Dutch teenager was arrested for using LOIC as
  part of Operation Payback against companies that had begun refusing to
  process payments to WikiLeaks. This lead to retaliation against the
  national prosecutor’s website which quickly results in the arrest of
  another Dutch teenager, this time a 19 year old. Apparently the guy
  just fired LOIC up from his own PC connected directly to the internet
  without taking any identity obfuscation measures. As the article in
  the link says “That's a pretty silly mistake to make if you're going
  to attack the website of your country's national prosecutor”. Indeed.
  Then there was Giordani Jordan in the US a couple of years back,
  Dmitry Olegovich Zubakha in Cyrpress and a two unnamed teenagers in
  Norway last year plus of course Christopher Weatherhead in the UK who
  we now know is in jail. It’s a rapidly growing list of global arrests.

Also installing a program which makes you part of a botnet is a bit retarded. You are voluntary building a potential backdoor into your system which will likely be used for malicious intent.

Note that all of the above is when you intentionally install custom versions of LOIC or additional programs which allow remote users to use your machine.

That said, if want to test a company's network (on their request with complete legal paperwork which state that they are aware what a DDoS actually does and that they are aware that this can take down their systems) then it should be OK to proceed. LOIC can be used to do this, or you can use Apache Benchmark as an alternative if you want to test a website.  There is nothing wrong in using the tool, it is what you are using the tool for. It's similar to using a knife to kill someone or make turkey sandwiches.

Intent is key here.  If you visited the website with the intent to view information, then this might be regarded as normal usage. If your intent is to take down a website in an orchestrated attack then yes it is illegal.


Can cross origin iframe be detected in web logs

I don't see how. When creating an iframe, a GET request is sent to the iframes src, but not to the server hosting the iframe.

So deskofhelp[.]com will likely have tupperware.com in its logs as referer header, but not the other way around.

Cross-origin frames can be logged by using a frame-src CSP directive combined with report-uri (or the newer report-to), but it seems that tupperware.com isn't using CSP at all.


Safely Use sudo Without allowing Other applications root privileges on Mavericks

Alright, after doing some research into the issue, it turns out that this behavior is because OS/X spawns the same TTY over and over again, and since sudo has a timeout, applications in the background automatically receive sudo permissions when you give sudo permissions to a completely different application.

Thankfully, the fix isn't hard. All you need to do is edit your sudoers to add the following line:

Defaults:ALL timestamp_timeout=0

(Thanks to a certain Themson Mester for suggesting this config option!)

This will make the behavior a lot stricter - only your application gets the sudo permissions, and it times out immediately. I used this as a reference to make this change, and it has a lot of helpful tips if you're looking to change other things in your sudoers.

Thanks for the great question, I learned something new today. :)


To decrypt you need the private key. The server's certificate, sent as part of the initial steps of the SSL connection (the "handshake"), only contains the public key (which is not sufficient to decrypt). Some people call "certificate" the union of the certificate and its private key, while some others (like me) say "certificate" only for the public part (as per X.509), hence an endless stream of confusion.


The objective really depends on what trade-off between efficiency/productivity and security you're willing to make.

Stopping general phising (the mass mail, badly written, generic kind) is't impossible, and can be achieved without too much sacrifice, through proper employee training. Highly targeted, professional grade phising though, is incredibly hard to stop, as it may appear to be from (or be from) legitimate email accounts, be well written and highly relevant to the person receiving it. I would say stopping this kind of attack is near impossible for any organization that relies on interaction with the outside world.

There have been some examples of these attacks recently (against people who most likely do have employee training):

http://www.canberratimes.com.au/it-pro/security-it/hackers-breach-reserve-bank-20130311-2fv8i.html
http://www.h-online.com/security/news/item/Highly-specialised-MiniDuke-malware-targets-decision-makers-1813304.html

Of course training employees to exhibit "proper" behavior requires the proper internal organization to support it. There's not much point in telling employees not to do something that will actually be required of them (for example clicking links to change their user details, etc).

The average person can first of all be highly critical of any email received.

Does the email use properly constructed English?
Is this email something you asked for or were expecting?
Would an email purporting to be from paypal or your bank ask you to follow a link to wallyswatersking.com/wp-content/acdasdc.php? Note that links that appear to go to certain places may not (can often be detected by hovering the mouse over the link, or by examining the source code of the email).
If an email has an attachment, is it from someone you know? If not, it's probably a very bad idea to open it.

Technical solutions to mitigate these problems might include

Up to date AV (although this will likely not be effective in targeted attacks).
Application sandboxing.
Using an email provider that actively works against phishing and spam (like Google or Microsoft).

More on phishing here

http://www.onguardonline.gov/phishing
http://www.microsoft.com/security/online-privacy/phishing-symptoms.aspx


Performance comparison between ed25519 vs AES

You're comparing a signature scheme (ed25519) for integrity / authenticity with an encryption scheme (hybrid RSA / AES) giving you confidentiality. As such, the comparison makes very little sense.
If you want to speed up encryption then you could replace RSA encryption of the key with ECIES, for instance using X25519 as key agreement scheme for Curve25519. You would still need the AES encryption as ECIES is really just Diffie-Hellman key agreement: the actual encryption still needs to be performed using a symmetric cipher. You can choose any symmetric cipher for that, but on most modern computers AES is pretty fast. There are however stream ciphers such as ChaCha20 that are extremely fast where hardware AES acceleration is not available.
Obviously then, the above scheme will only remove the slowdown of the RSA (un)wrapping of the AES key. No asymmetric scheme is likely to be faster than AES.
If you go for the curve with stream cipher approach you might as well use one of the NaCL compatible libraries. Another advantage of doing that is that you will get a lot of low level security and performance for free (assuming you manage to choose a secure & fast implementation).


How to be sure laptop's trusted certificates are safe

Most of the certificates are updated through whichever update mechanism that is available to the system. You cannot be certain that the certs that are installed with the browser are not effectively used for mitm. On the other hand, you could write a small script that uses openssl client mode to retrieve the x509 certs of SSL based targets and from there do a comparison with the incoming site's signature.

This does not scale very well though. Also you might be aware that, at least of macosx, there is the ocsp client that also functions to revoke x509 certs. The problem is such that once you have a rogue root cert installed in your system, just about everything can be spoofed, which includes downloading of any solution over https. At the very worst, you can download, at least for firefox, the set of certs that are installed in the browser and do a quick corroboration test. But over the same broken system? Boot up in a livecd, possibly ubuntu, and do the downloads that way.

Please hug your poor system administrator that has to confirm whether your certs are in order.


Should I assign my various passwords to my keyboard's macro keys?

This is a bad idea.

As user mentioned in a comment, anyone with physical access can just press the assigned macro key and the password will be revealed.

You also have a high chance of accidentally pressing the macro key, thus typing in your password in places where you didn't mean to.

The macro data also needs to be stored somewhere, and is likely stored in plain text. As such, storing your password in a macro is akin to storing it in a plain text file.

Instead, use a password manager. An offline password manager allows you to store your passwords in an encrypted form, protected by a master password. Many offline password managers also include functionality to write your password for you, just like a macro, except that this is much safer.


What is the point of secure email gateways?

If gives you the assurance that the email, and the sensitive data it contains, never transits over an unencrypted channel, with a side-benefit of allows you to audit access.

Generally with SMTP, you don't know what happens after it leaves the edge of your network to the edge of the next.  It could be insecurely transferred from one MTA to the next, it could be transferred insecurely to the client via cleartext POP3 or webmail...This is all out of your control, and unfortunately none of these scenarios are uncommon.  The gateway allows you some level of assurance that the sensitive data is not directly exposed on the network.

It isn't foolproof.  Of course the emails letting the end-user know that they need to create an account on the gateway, and subsequent confirmation emails are just as exposed and can potentially be exploited, but that requires an active attacker and protects the sensitive data from being passively sniffed.


Will "upgrading" www-data user open up known security issues?

In general this is a flawed approach to permissions.  You should keep www-data,  and then create a new account "dropbox",  which performs the required dropbox actions on behalf of the web application.  One implementation of this is that a php application could run commands as that user only when needed and perform all other actions as the usual www-data.


Does padding an AES key hurt security (besides lowering the strength of the key)?

There is no known weakness in having a "padded key" for AES, besides the obvious weakness of the key space size being reduced (a 52-bit key space can be explored exhaustively with some PC and some patience). However, AES security was not studied thoroughly for that kind of property, so anything goes; for instance, AES is known to be relatively flaky with regards to related key attacks, which operate in a similar area. To be safer, consider hashing your key elements with SHA-256, and using the hash output as key for AES.


What is the impact of the Bluebox Android APK integrity vulnerability?

The practical exploit is the ability to later substitute different code from that signed, either on an individual basis or wholesale.

The ability to substitute entirely different code, without changing the signature means that the application could undergo rigorous review, and be signed off as a harmless or beneficial application, but the installed version would run an entirely different set of code which had never been reviewed. Yet the signature would be the same, so as far as Android is concerned it is still a trusted application.

Worse, this could be implanted into the device by anyone with physical access without special knowledge. For example, if the APK was stored on an SD card, the SD card could be slipped out, altered, and replaced in minutes. But as far as android is concerned, the signature is the same so it must be the same app.


Is it safe to ask users to curl a raw file from GitHub?

Is it safe?
Not completely; just because you're fetching safe code now doesn't mean that link will always point to safe code, and many command-line tools don't verify certificates, which could lead to a MITM attack.

Is it safe enough?
Yeah, for most use cases, probably. The attack scenario is pretty rare, and an attacker who is positioned to pull it off can probably pull off something more serious.

What's a safer way to do it?
The best we can do is for all downloaded software to be cryptographically signed and for the signatures to be verified before installation. Most modern system package managers (think apt, yum, etc.) do this automatically, but you can do it yourself using gnupg.

Ideally you'd only sign a package if you've verified it and trust it. That doesn't mean you're right to trust it, but at least it makes you accountable for it. Of course, there's the problem of getting the signer's public key onto the user's computer in such a way that that transfer won't be tampered with... chicken, meet egg.


Just because a webserver returns a 200, that does not mean that there has to be content there. Why this site is returning 200 and not displaying anything is not something we can tell you.

Just having a page or a directory is never a vulnerability on its own. Returning a 200 and not displaying content is not a vulnerability. But they are reasons for looking deeper.

dirb is part of the "recon" phase.


Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X?

Yes. The traditional keylogger is a hardware device that intercepts data between the the keyboard and the intake of character data at the Keyboard Controller (mostly USB Device, HID Keyboard). The physical components are few and various tamper evident seals may be used to assure the integrity of the physical system. You would need a initial check to insure that no physical keylogger exists then attach or install the seals. Frequent or periodic checks of the seals must then be performed to verify that the hardware's integrity is intact.
However most modern keyloggers are software or firmware based and thus may only be defended against by software security methods. This includes the chain from the keyboard controller IC firmware, keyboard controller device driver, OS level USB subsystem, keyboard buffer, and shell software.
This would require you to find the firmware or software for each component in the chain and verify that it has not been tampered with. This is usually done by obtaining from the manufacturer a cryptographic hash of the firmware or software for the component and computing the cryptographic hash of the software currently in use on the system in question. If the cryptographic hash values match then the firmware or software is unmodified.
The more software in the chain, the harder it is to protect and verify just by the nature of growing complexity and more permutations of instruction sequences.

There's several places in my ‘personal security infrastructure’ (is there a better phrase for that?) where I find myself typing very important passwords into text-fields on OS X (for instance, dis-encrypting and mounting thumbdrives containing very sensitive data.)
I'm (perhaps unreasonably) afraid of keyloggers

In hardware keyloggers yes, in software keyloggers no.

as these [Keyloggers] are the only method I can think of short of a system-level vulnerability or physically watching (or recording) my activities when entering the password.

No, there are many other ways of determining your password. The most common one is to find a exposed password or phrase from another system and attempt to use it on the system in question. This is usually successful as most people reuse passwords.
Another trivial example is to attempt to find frequently used keys on your keyboard either from dirt or ware and try the limitied combinations of those frequently used keys to find the password;

Additionally there are various forms of social engineering and phishing that are quite effective.

In other secure systems I use, there's an option to enter a final part of the password using the mouse or similar, to help avoid keyloggers making an attacker's job too difficult.

There are two posibilites here. They keys is split, meaning that part of the key is stored in a container on the system and part of the key is stored in you mind. Or the full key is stored in a container and the system only needs a few charactors to determine which key you need.
There are also two general types of key splits: one I call sectioned, and one I call full key length split. The sectioned one takes a key with n bits and divides it into two or more parts.
For example: take a key 0xA55AC33C and split it to 0xA55A and 0xC33C.
The full key length split takes a key of n bits and divides it into two or more parts of length n.
For example: take a key 0xA55AC33C and split it into 0x42244224 and 0xE77E8118.
The sectioned split is a poor choice for several reasons including exposure to brute force attacks, and problems recombining the key in the correct endianess and order.
A sectioned split might seem to foil a keylogger, but not if entering the same split allows an attacker to access the sensitive data. For example: if you only need to enter 0xC33C and the keylogger records this then an attacker can enter 0xC33C and gain the same access.
Generally, shell level commands which do not output sensitive charactor data to the screen or to the shell log buffer are more secure than graphical components.


How to protect file integrity and history containing counters

You need a Consensus Protocol for that. Keep the file saved on 3 (or 5, or more) distinct servers, and every time the file is modified, send the new version for those servers.

The servers, in turn, verify if the file is a new version with the incremented counter, and if so, they can store the hash of the file on the ledger after the majority of the servers agree the file is a new one.

To verify any file, you submit your file to the server, the server verifies if he have the same version, and tells you if your version is an older version, the current version, or a version never seen before.

This way, an attacker would have to compromise the majority of the servers to revert any file to a previous version.

Or you can use existing solutions for that. There are current solutions for storing data on the blockchain. There are Ethereum smart contracts for that: you can store the counter and the hash of the document, and keep track of changes. If anyone tries to revert the counter, you can search on the Ethereum blockchain and detect it.


Is it secure to have source code for website public?

If your website is secure, even the source code wouldn't help an attacker in a perfect world. But we do not live in this world.

By making the source code public you are simultaneously holding yourself to a higher standard coding wise, and introducing more risk. Since you're giving away your code to anybody who asks, you'd better make it rock-solid. (In fact, you should be doing this anyway, but I'm sure you know that!)

Releasing your source will allow for good, helpful people to point out bad things, and it gives a motivation for you to write solid code at all times. I'd say it's a good idea. However, you should talk about the risk with the website owner. Private repos do exist on GitHub and you can stand up your own Git server/local Git repo for private version control.

Suggested Reading:

Pros and Cons of Open Source implementation
Kerckhoffs's principle


Certificate transparency: should the certificate be submitted to ct-logs if the pre-certificate is already submitted

it gives public confirmation that the certificate
  was indeed issued (and not only the pre-certificate)

To quote RFC6962bis (draft-ietf-trans-rfc6962-bis-28), section 3.2:

"signature" MUST be from the same (root or intermediate) CA
that will ultimately issue the certificate.  This signature
indicates the CA's intent to issue the certificate.  This
intent is considered binding (i.e., misissuance of the
precertificate is considered equivalent to misissuance of the
corresponding certificate).

Essentially, what that means is that if a precertificate in a CT log is present, then in any sense related to certificate transparency the final certificate was, indeed, issued.

Further operational details (e.g. was the certificate issued then, was the issued certificate then sent to the customer or not, has the customer received the certificate, have they deployed it, etc.) fall out of scope of the certificate transparency framework.

(It is also understood, I believe, that in case the certificate has been actually issued, and not only issued but has been actually obtained by the customer of the certificate authority, then the customer — usually referred to as a "server operator" in CT-related documents — may submit the final certificate theirselves if they have such a policy.)

Hence, there are no advantages left. Yet, the drawback you've mentioned still persists. So, the final score is 0:1 against submitting final certificates.


Is there an easy way to know if a regex is "evil"

The answer is that you don't know. This is the classic halting problem.

Basically you should not allow users to set their own regexs wherever possible. If you do allow them to set their own regex, then you could mitigate it in other ways such as only allowing them to set regexs when it affect their own service, or by setting execution timeouts. You could possibly flag long running regexs so you are aware if any of your users are attempting a ReDos.


Do virus author's purposely speak in broken English to avoid linguistic evidence?

False flagging is a common methodology to throw off defenders when trying to attribute TTP’s.


Winrar encryption/decryption Veracrypt RAM recovery

Short answer: there are no guarantees that it will be "100% in RAM" in any case.

Long answer:

With RAR/ZIP/7Zip you usually have to extract file to a temp folder to open it with another application. This is how passing files works (in Windows, and many other OSes). So, it is always extracted to some kind of temp storage. Worse yet, even if you drag&dropped it in windows, it will still go to a temp directory first, only then windows will copy it to where you wanted it to go (drag&drop doesn't tell application where the file has to go, only that is has to go [except for windows explorer, it does things without temp]).

With Veracrypt, it does decryption on fly, system doesn't see any kind of encryption. But this doesn't give you any guarantees. System can be low on RAM and decide that some pages that contain unencrypted data can go to swap. So unless your swap is encrypted too, you have no guarantees. But if you use application that has this unencrypted data, chances are system won't write that data to swap. For OS, all storage mediums are equal, it won't care that it saves data from encrypted volume to unencrypted volume.


SIEM Question: Excessive Firewall Denies / Rule Edit Question

This looks like a QRadar rule. It would be good to ask the question on the IBM developer forums as you will have more QRadar administrator eyes on it.

That being said, firewall denies are inevitable if you have a DMZ. The flaw is that many people look at just firewall denies, but do not look at firewall permits. Denies are only affirming what you hope to see. The permits are where the real danger lies.

For misconfigured services:

If the denies are related misconfigurations or known services, either fix the services or add them to the false positives list.

For any non-legitimate services or malicious network scanner:

Create a rule that catches more than X number of firewall denies in X minutes (These are numbers that you should be comfortable with). Then use that rule to add offending source IP to a reference set (For example, call it: Reference Set: Malicious Scanner). Finally, create another rule that checks for BB:CategoryDefinition: Firewall or ACL Accept (assuming you are logging permits) and checks against the Reference Set: Malicious Scanner. When a firewall permit is logged from an IP in the Reference Set: Malicious Scanner, a new offense should fire. This way, you are catching when a known-suspicious IP address manages to successfully get past the firewall.

If you are not logging permits, but are using netflow data, create a flow rule that checks against the Reference Set: Malicious Scanner for any traffic that does not hit the DMZ network. This may help you identify if an IP manages to bypass the firewall. Netflow data is not as accurate as logs.


Is blocking a country's access to a website a good measure to avoid hackers from that country?

Country-based blocking is usually put in place as a result of some organisational policy whose intention is indeed to "block hackers". This sort of things fail on three points:

Such a policy assumes that malicious people can be categorized by nationality. This is old-style, World-War-I type of thinking.
Geographical position is immaterial for computers; a firewall can only see IP addresses. Inferring geography from IP addresses relies on big tables that are never completely up-to-date.
As you observed, working around these blocking systems is trivial for attackers; it suffices to use a relay host outside of the blocked country, and this happens "naturally" when using Tor. Most attackers will use such relays anyway, to cover their tracks.

So the usual net effect of such a blocking is to irritate a few normal users (who might have been customers, but will not now that they are angry), without actually impeding the efforts of competent attackers.

On the bright side, though, "country"-based blocking is sometimes put in place to prevent thousands of mindless drones from spamming the connection logs. For instance, the sysadmin might have noticed a surge of dummy connections from some botnet, most machines of which being located in Venezuela. In that case, blocking Venezuela altogether may help prevent the clogging of log files, while implying only minor impact on business (assuming that the server in question has very few honest Venezuela-based customers). Thus, it is conceivable that a risk/cost analysis has determined that such a large blocking would improve things.

However, in most cases, the "country blocking" is there for the show: a whole-country blocking helps sysadmins demonstrate to managers that they are doing something for security, in a way that managers readily understand. This is the usual predicament of security: when all things work well, security is invisible. It is unfortunately hard to negotiate budgets for activities that don't imply any visible result. Even though the whole point of security is to avoid having visible results, e.g. a defaced Web site or a list of 16 millions of user passwords leaked and hitting the news.

In the case of media distribution, some distributors enforce country-based blocking because they did not have whole-World retransmission rights, and by doing a modicus of blocking effort they fulfil their legal obligations. Arguably, this case is also "for the show".


How does MalwareTech make the WannaCry ransomware live map?

He owns the most of kill switch domains (used to stop the malware execution). One of which I am know to is this where he says "Upon running the sample in my analysis environment I instantly noticed it queried an unregistered domain, which i promptly registered."
The number of DNS requests he is getting, he notes that using some auto-script and represents here. He is also getting the ip geolocation on a real-time basis and hence he is able to represent it on a map.

Maybe he is using something more than this to detect if it is from a browser or not to get the actual data.


Here are a few other "fuzzy hash" algorithms:

Nilsimsa: was developed for email spam detection. However it results in more false positives then some others.
TLSH: (https://github.com/trendmicro/tlsh) A Trend Micro fuzzy hash.
Sdhash: another fuzzy hash like algorithm. http://roussev.net/sdhash/sdhash.html

These are used for several things. One is to forensically locate similar files. Another is to identify malware, even if some of the code is changed. A third use is in spam detection


Is it possible to use ECC private key for encryption?

No. In Public key Infrastructure(RSA, ECC) the private key is used to decrypt and the public to encrypt.

Furthermore, you can use private key to sign  with digital signature. And the Public key to verify the integrity of the signature.


Why do browsers disallow accessing files from local file system even if the HTML document is also on the local file system?

I'm going to pull an old article here on an attack that used known image locations on hosts to map out networks for attacks (from 2006):

https://www.cnet.com/news/javascript-opens-doors-to-browser-based-attacks/

Initially, JavaScript had a lot more access to the system than it does today, but over time the value of having a widely permissive javascript agent allowed attacks more visibility to the end point than they should have. If you allow your browser to browse all your files, you give your attacker the ability to launch malware from your browser even while you're just looking at tame cat videos. Oops.

As systems progress, I imagine JavaScript will continue to retain a fairly restricted access level because of the issues open access caused in the past. As the most recent JavaScript zeroday announced on Microsoft demonstrated, it's a pretty big deal causing companies to rip out JavaScript libraries before they could be executed.

Now, you'll notice that I've focused a LOT on JavaScript and it's because of JavaScript that this is really an issue. HTML is certainly benign by itself, but as soon as you open a script block, you've opened a can of worms that need to be retained.

Finally, the reasons why browsers don't support this in any capacity is because it's not a feature you really need for 99% of the population. The webbrowser is not intended to be a web server and is only a client. Building in the server type functions would bloat the browsers which is the opposite function all the browsers are trying to implement (lightweight, fast, resource anemic)

That said, with the increasingly open model for browsers (Microsoft is adopting Chrome), I'm guessing you could attempt to write a module that bakes this functionality in, and I would further guess there would be some developers who would be happy. You just need to see if that niche really wants a local server that doesn't require installing apache, iis, or nginx.


PHP registration script, how to check if request is coming from a credible source

Fundamentally, you can't.

Because the user has all the code necessary to communicate with you on his device (I.e. JavaScript), he also has the best possible Algorithm Description Document (I.e. JavaScript) one could ask for.

The only way to protect the code is to run it on the server... But this means that every request must go through the server, not just the "valid" ones from your script.

All you can do is raise the bar of complexity.

For example, if you were to hash (e.g. SHA256) the contents of the JavaScript code used to generate the request and all the data in the request and submit that with the request, you could have basic validation. This validation is easy to crack because all a user has to do is figure out what the hash of the JavaScript code is and do the hash themselves, but it makes it a little bit more difficult.

Another option, as mentioned in the comments, is to use a captcha.

Another option is watching source IPs or patterns in the requests.

But. fundamentally, there is no way to validate that the user is running your code vs their own code on their own device.


Is it okay from a security perspective to read foreign (untrusted) cookies in a trusted network?

Cookies which are sent by the client to your server are just parts of the requests sent by the client to your server, and, as such, should be considered as "potentially hostile" by default. If the client may be an attacker (and it would be quite naive to dismiss this possibility), then anything which the client sends is suspect and could be crafted in order to maximize disruption or do even more evil things. SQL injection attacks, for instance, are a common example of attacks in which the client sends such "bad" requests. Cookies, in that respect, are no different. A cookie is stored on the client side, and the client can alter his cookies as he sees fit.

Since a cookie is meant to be stored "as is" and sent back unaltered (that is, that's what honest clients do), you can include in your cookies a message authentication code: that's a kind of checksum which uses a secret key. This way, your server could verify (by recomputing the checksum on an incoming cookie value) whether the cookie is "genuine", i.e. is a cookie value which was, at some point in time, sent by the server to a client (not necessarily the same client ! If one client can be hostile, two can be hostile as well, and collude). Such a distinction between genuine and crafted cookies can help in protecting your server against hostile cookies; but it won't totally replace care, and, of course, a request contains other elements besides cookies.

Cookies (sent over HTTPS) have security value in another attack scenario: if the client is honest and manages its security properly, then the cookies your server sends to the client will be unaltered during their transit, and will come back untouched, and, moreover, the cookie contents will remain unknown to outsiders (HTTPS relies on SSL/TLS which provides confidentiality and integrity for data in transit). HTTPS protects your server and the client against third parties; it does not protect your server against the client itself.


Why should an IKE responder change the cookie secret 'frequently'?

Suppose that the "secret" is kept unchanged for weeks. As an attacker, I could make many connections without IP spoofing, spread over several weeks. I would thus gather possibly millions of "valid cookie values", each for a given source IP address and associated parameters (the Ni, IPi and SPTi values from the RFC). This is the preparation step.

Then, when the attack should actually occur, I replay them all en masse, within a 5 minutes time frame, with the required IP spoofing so that the cookie values match, forcing the server to allocate resources for millions of clients. This will drown the server quite effectively.

By construction, this attack is limited to the number of valid cookies ("valid" in the sense of "will be accepted by the server at the time of attack") that the server could generate. Every change of secret invalidates old cookies. By changing the secret often, the maximum size of the set of currently valid cookie values is kept low, avoiding the attack described above.

Now, of course, claiming that the secret should be changed "more often" in case of attack is just a shamanistic dance to propitiate the Spirits of IT Sec. Similarly, when I see that a homemade construction of "hash the data with the secret appended" is described as "a good way", I cringe and growl and shed tears of blood. Haven't they heard of HMAC ? Do you want to follow cryptographic advice from people who have not heard of HMAC ?


Rainbow tables and hash tables pre-calculate password hash data. The point of them is to greatly reduce the time it takes to recover passwords by using computing resources before they are needed.

I'm not sure what you mean by start with a hash value, so here are multiple answers:

You may be asking why you match a pre-calculated hash to a target hash, rather than looking at the password possibilities first. If you are talking rainbow tables then you cannot pick a specific list of plaintext values to try, that's now how rainbow tables work. With hash tables if you want to find out the password for a given hash the most efficient way to do it is to do a db lookup on it. If you were looking for specific passwords in a list of hashes then you could limit the lookup to specific password plaintext, in my view that would be a bit pointless.
If you are talking about calculating hashes and comparing them to hashed passwords then you are describing a completely different technique, either a brute force or dictionary attack. If you have rainbow tables and hash tables that would be a complete waste of time, kind of like turning a speedboat's engines off and using oars instead


In my opinion, risks are low in this case, unless we start making suspicions on the people involved in the project about insider trading.
I see a potential risk in information exfiltration made by a rogue project member that leverages the VPN's encrypted traffic to access some resource at the IT company (e.g. storage) to later retrieve it (probably the employee will be able to access the same VPN from home).
But since the people on the project are limited in number, it's not my choice to make suspects upon them. Maybe they are trusted enough.
Or if the VPN, as in my comment, also allows for Internet access, different evil may happen. Suppose none of the users are insider traders (rogue), if the VPN allows for internet you are at minimum giving up on antivirus protection from proxy, unless the IT company protects the VPN with a restrictive proxy/filter. This is why you should talk with WellKnown LLC to make sure they block general internet access, of course unless it's really really fundamental for the project.
As you said, you are using Cisco AnyConnect. That is a tool widely used on the market, and as any tool, it shall be installed from trusted source and by verifying the author's digital signature, which is something Windows is good at.
The risk of the AnyConnect binary to be tampered with is negligible unless the company is enough high-profile. By the way, Govern... (I mean, determined-attacker)-level attacks are often out of the scope of this board because it's basically not possible to defend from a determined attacker with unlimited budget forever. AnyConnect needs Admin privileges and can modify system settings, so that's a tool sensitive enough to use care when being installed on corporate machines.
As a side note, stating that "I don't trust Cisco's AnyConnect because it could do malicious stuff" is like refusing to install MS Windows itself after not having verified its source code (which is the reason why Chinese government owns its customized and vetted MS Windows version: protect from potential US tampering).


What SQL payloads can be injected for a numeric field?

It depends on the code of your application whether this input can be misused, not on the database or the query (disregarding parametrized queries).

If your application rejects all but valid numbers, there is no possibility that the input can be misused, since only "harmless" numbers will be inserted into the query.

If your application does no proper validation and inserts the input directly to the SQL statement, SQL-injection may be possible. You didn't include your query so i will invent an example. Following query should list all articles of a given category:

SELECT name FROM articles WHERE category = 1

Instead of 1 our input is 1 UNION...

SELECT name FROM articles WHERE category = 1 UNION SELECT password FROM users

This would return a much larger list...


Why is whatsapp using 6 digit codes for verification?

Why are there not less than 6 digits?

The longer the code, the harder it is to guess. One could argue that 4 is already enough if you discard the code after a failed attempt, but why should you throw away a little bit more security?

Why are there not more than 6 digits?

I think that's not related to security but to usability. WhatsApp tries to read the verification SMS automatically, but there are cases where the user has to enter the code manually. For example if the SMS takes long to receive, the app won't wait for it, but prompt you to enter it when you finally receive it.

Therefore the verification code should be easy to remember. Miller's law states that the number of objects an average human can hold in working memory is 7 ± 2. Seven digits would be a logical choice, but it's much easier to remember 6 digits, especially if you're distracted by your environment while using your mobile phone.

Conclusion

It's a compromise.


What are the security risks of allowing users to add iframes?

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


Letting client encrypt his/her data. How to ensure the client doesn't lose his/her private data?

Is it safe to store passwords on the client?

Yes, if done correctly. Depending on the client, they might have access to a secure storage offered by the operating system. Using this storage will allow you to store passwords/keys safely.

Does storing passwords on the client introduce vulnerabilities?

Yes. Knowing a password is always safer than writing something down. Malware on the client PC might be able to read it out, but this is turning into the realm of possibilities.

How should changing the password be implemented?

Downloading the data, decrypting it with the old key and re-encrypting it with the new key is not a good idea. It's not wrong, in the sense that it has some privacy impact, but it's not feasible for large data.

Imagine that your client has to deal with a 2 GB large file. First they would need to download 2 GB, then decrypt 2 GB, then encrypt 2 GB, then upload 2 GB again. And that's just for one file.

A much better approach would be to create two keys: A data encryption key (DEK) and a key encryption key (KEK).

The DEK is chosen randomly through a proper cryptographically secure pseudo-random generator. When implemented correctly, the DEK is impossible to crack. You can either choose one DEK per user, or one DEK per file.

The KEK is derived from the user-supplied password through a modern key-derivation function, such as Argon2d.

As their names imply, the DEK is used to encrypt the actual data. The KEK is used to encrypt the key. Given that the key is rather short (in comparison to the data you might encrypt) with 128 or 256 bit, decryption will be very fast.

When the user wants to change their password, all they have to do is decrypt the DEK with the old KEK, create a new KEK and use it to re-encrypt the DEK. The data never needs to be touched.

How to treat salts?

AES does not require salts. You have no benefit of adding salts. Salts are used to counter pre-calculation of hashes of weak passwords.

Please make sure you understand the reason why certain cryptographic measures exist before attempting to implement them yourself. I personally would suggest contacting a company of security consultants and have them review your cryptographic concept. They will be much better equipped to find flaws and nuances in it, as they will have full access to your concept, rather than limited information on a public site.

What if a user really forgets their password and we don't want to store it?

I would display a warning to the user that appears as follows:

  Encrypting your data can lead to irreversible data loss if your key is lost!

  <Our Company> treats privacy very seriously. For this reason, we do not ever store your key on our servers. This means that if you forget your password, we have no way of recovering your data.

  Please ensure that you use a safe passphrase when encrypting your data, which you will not forget. For more information please click here <link that will lead to some password best practices>


I think as the first step you should create a Data Classification policy where you would define different levels of data sensitivity (such as public, internal only, confidential, secret etc).  Then you would have a clear guide which data is valuable enough to be protected with encryption, either at rest or in transmission.  Defining the data classification would greatly help both the enterprise employees (to know which data to protect and how well) as well as the internal and external auditors.

In terms of Encryption Policy itself, I would recommend to explicitly state prohibition on creating own encryption schemes - everyone should be using the industry-standard well-established encryption library and mechanisms.


I wouldn't send his credentials via SMS, but perhaps a code that can be used to reset his password. Sending the password unencrypted back via sms is sometimes seen as a violation of privacy. (it shouldn't be possible to do the unencryption in a good setup)


RRD Performance reporting with GSA/OpenVAS

Quoting the relevant part of the source code documentation:

Prerequisites for generating system reports:

A program in the PATH, with usage "openvasmr seconds type", where
seconds is the number of seconds before now that the report covers,
and type is the type of report.  When called with type "titles" the
script must print a list of possible types, where the name of the
type is everything up to the first space and everything else is a
title for the report.  When called with one of these types openvasmr
must print a PNG in base64 encoding.  When called with the special
type "blank", openvasmr must print a PNG in base64 for the Manager to
use when a request for one of the titled types fails.  openvasmr may
indicate failure by simply refraining from printing.

Disclaimer: Answer of a NVT Dev @ Greenbone


Is VPN the only way to stop my ISP from logging my traffic?

When you use a VPN service, your provider won't be able to log anything except encrypted communication with the VPN service. However, the VPN service will be able to log all of your traffic instead. Whether or not this is better depends on who you trust more: your ISP or your VPN provider.

An alternative to VPN providers is TOR. It also encrypts your traffic and proxies it through other users. But keep in mind that the exit node can see your connection in clear-text. Even though it doesn't know your IP address it might be able to deanonymize you as soon as you transmit private information. Unfortunately TOR is quite slow, even compared to cheap VPN providers.


How to operate PHPmyadmin with an SSH tunnel?

Only expose phpmyadmin to localhost (if this is the only thing running on your webserver, you can bind to localhost; otherwise, do this with ip restrictions in your server of choice). Then, when you want to connect, use ssh to forward a tunnel:

ssh -L 80:localhost:80 your-server

and access it via http://localhost/phpmyadmin.

Clarification notes:

The your-server part is actually Usual_User@Server_IP. The usual user is of course the main working user which isn't root, so it would be like user1@111.111.111.111.
The your-server can come before the -L or after the last edge (last 80), it doesn't really matter.
Execute the command inside your Putty or OpenSSH session, that uses you to operate your server in an SSH tunnel through port 22.
If you use the exact same keys you use to authenticate the port 22 tunnel with Putty, you should create a version of them that suites the Linux OpenSSH. Why? Well because the formatting for OpenSSH is slightly different. This can be done from the Putty bundle itself, by Puttygen.

Read more on authentication here, if you feel the need to it: Public key and private key. What comes where.


AES-256 is perfectly adequate (in fact, AES-128 is perfectly sufficient too, and arguably better according to some experts' opinion) to protect any data that you may have, provided that

Your password is not only long (as you stated) but also not guessable.
The software you use has no backdoor (Veracrypt to my knowledge doesn't have one).

However, the mere fact that someone knows you have something important may already be undesirable. It may rise their attention.

If someone sufficiently evil (criminals or governmental agencies) is sufficiently convinced that you have something of value that they want, but they cannot get it without the key, they will force you to hand over the key.
In other words, anything you encrypt is, in the end, only as secure as you are (which is not very secure at all, if you care about your health).


differentiate correct and incorrect password

You have mentioned that you are using a file for single user and another file for single password.

Users File:
C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt
Passwords File:
C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\psw.txt

But you have used the switch -l instead of -L to specify the users file .
Refer user$hydra -h for more help.


Why aren’t collisions important with HMAC?

From RFC 2104 § 6 describing the security requirements for an HMAC:

  The security of the message authentication mechanism presented here depends on cryptographic properties of the hash function H: the resistance to collision finding (limited to the case where the initial value is secret and random, and where the output of the function is not explicitly available to the attacker), and the message authentication property of the compression function of H when applied to single blocks (in HMAC these blocks are partially unknown to an attacker as they contain the result of the inner H computation and, in particular, cannot be fully chosen by the attacker).

So it's not that collisions are not important for an HMAC. It's that a collision attack against a hash function does not affect that hash function when used in an HMAC construction. In particular, an HMAC demands much weaker security guarantees from the hash function than many other applications it may have. It only requires weak collision resistance from the underlying hash.

HMAC is defined as HMACK(m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)) where opad and ipad are constants and H is an at least weakly collision-resistant hash. The key K is not known to an attacker. To trigger a collision with an HMAC, an attacker would need to do one of the following:

Find a collision that is valid for a number of keys.
Perform a successful key recovery attack.

Both of these are extremely unlikely to be possible for even the worst of cryptographic hashes, assuming the authentication tag is sufficiently large (typically at least 128 bits).


A daemon to tell when do apps access the cell phone camera?

If you're using CyanogenMod, Privacy Guard has this functionality.

Optionally, disable it in the app's settings and set it to 'Ask' for permission every time, which will give you a warning each time.


Legality of writing exploits for educational purposes (USA, Canada)

I don't know about the CFAA specifically, but good general guidelines for educational, or exploratory penetration testing are:

Only attack servers that you control, or that you have express permission to attack. For example, some people leave up websites with known vulnerabilities so that others can "practice hacking" on them. These sites usually have a disclaimer expressly giving you permission to attack them. Without that disclaimer, you can get in big trouble for launching an attack on a domain that you don't control.
Only publish exploits for known (and patched) vulnerabilities. If you are playing with exploits that have already been published in academic journals / conferences, or are otherwise well known, then you're probably ok to post it on the internet, especially if a patch is available. However if you discover a new exploit, or are unsure if it's new, then it's better to go through official channels and notify the vendors before making anything public.

EDIT:
The OWASP  WebGoat Project exists specifically to address issue (1.) :

WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons.

You can download and install the WebGoat packages onto your own machine and then run all the attacks you want!
If you have strong concerns about issue (2.) and publishing, you could always get in touch with your local OWASP Chapter and ask them.


Is a pre-set password in an embedded system secure enough?

Alright, the main concern here is that an attacker could intercept the traffic between the chipset company and your server.

How does the device know it's talking to the correct server? If I intercepted the traffic between the device and the server and pretended to be the server, would the device happily give me its password?

The "correct" way to do this is to use client-authenticated SSL. This means that instead of a "password", each device gets a unique RSA or ECC keypair, and a corresponding certificate from the server (which is a Certificate Authority in this case). This allows you to use the bi-directional Client-Authenticated TLS Handshake.

There are secure ways to do authentication using a pre-shared secret known to both server and client, but "here's my password, make sure it matches!" is not one of them (at least not without independently solving the "how do I know I'm talking to the correct server?" problem). One way is having both ends MAC the massage with a key derived from the shared secret. Then the other party can compute the same MAC using their copy of the shared secret and make sure they come up with the same MAC. Another way is to use AES in Authenticated Encryption (AE) mode.

... Or as @SEJPM points out, skip the whole "rolling your own" thing and just use one of the Transport Layer Security pre-shared key ciphersuites (TLS-PSK).


How do Pentesters approach attacking 2FA (two factor authentication)?

Your goal as a pentester is to identify previously unknown or unrecognized threats.

Be extremely clear that anything you do here must be explicitly authorized by your client.  Failing to do so can get you in serious trouble.  If you are wondering about details on that ask in the Law Stack Exchange.

Attacking two factor can be easy if it is misconfigured.  In many cases there are reset or bypass mechanisms that fall back to email.  If it is properly configured it becomes impractical to attack directly and you need to look at avenues of capturing tokens or compromising an authenticated application directly.

If the second factor is a hardware token, you will need to MitM the application that is consuming the token.  If the application is HTTP or another unencrypted transport this can be achieved with network capture (not really MitM but you need a MitM position to do the capture).  If the application is using TLS with an invalid cert you can achieve this via DNS poisoning (waiting for DNS requests for the target domain and sending several DNS replies with large TTLs directing the user to your MitM with its own self-signed cert.  If the application is using HTTPS with valid certificates you could compromise an endpoint via other techniques and capture token entry on the user agent directly.  It may be worth compromising an application that consumes the token.  If they are using a TOTP token system you can compromise the weakest of the services using the same token serial and then reuse the token within the expiry window.  If they are using a managed one time token system like Safenet Cryptocard this will not work since the token is consumed on use regardless of timeout.  The trick there would be to capture the token on the first attempt, substitute a fake value to the real authenticator, and side-channel a separate session to authenticate.  That way the user will think they've mistyped and just re-attempt.  While you are in that position you may be able to directly hijack the session cookies or other tokens directly if complementary defenses like device/IP locked sessions or anti-CSRF are not employed.

If the second factor is already done over email then your attack vector is network capture of inbound SMTP at the MX.  This may not be practical if the customer is using a secure outsourced provider.  It should be relatively easy if they run their own mail servers.

If the second factor is done over SMS it may be possible to shoulder-surf tokens of you are physically present since many phones are autonaticLly configured to show texts even when locked.  There are more sophisticated attacks involving compromising phones that can be used otherwise.

Social engineering is the ultimate hack here though.  If you can somehow get a user to call you for help by posing as IT Support or otherwise they may just tell you the token directly as you "help" them fix their issue.


How do open-source projects prevent disclosing a bug while fixing it?

They don't. By releasing code, they automatically "disclose" the issue to those who can reverse engineer the patch. But they can delay explaining or providing the details for easy consumption.
If they delay releasing the code, they force users to use known-vulnerable code.
If they release the code and do not announce it as a security fix, then users might not patch and end up running known-vulnerable code.
So, they fix the code, release it, announce a security fix so that people assign the appropriate urgency, but they can delay explaining all the details to make it a little harder for attackers to figure out how to exploit the vulnerability.
Is that effective?
To some degree, "security by obscurity" has a place in a strategy in order to buy some time. Since it costs nothing, and it can have some positive effect, it seems like an easy call to make.


Certificate Transparency: Log a legit precertificate and issue a rogue certificate

Guessing: Wouldn't work. Same thing when some CAs tried to use a nonstandard redaction scheme. -- Which is just a specific variant of submitting one cert while actually issuing another. This was dectected by browsers that actually bother to check. -> My site has Certificate Transparency enabled but Chrome is still showing NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
-- CT enforcement is up to the browser. And AFAIK only required by Chrome for Symantec certs. But the CT-everything requirement is on the horizon for Chrome for October 2017. See: https://groups.google.com/a/chromium.org/forum/m/#!topic/ct-policy/78N3SMcqUGw
Edit 1: What is CT good for?
You wrote:

The very objective of CT is to prevent CAs from issuing certificates for what it should not.

It's not. The objective is not prevention but accountability.
A CA can issue a cert for any domain anytime. That part is NOT changed by CT.
What is a game changer is that when a rogue cert is issued one of two things may happen:

If the CA doesn't submit to CT at all or submits with a different host name then (as soon as browsers actually enforce this) the browser will reject the cert. And the rogue cert will be useless.
If the CA does submit to CT with the right host name then the cert will be public. And a domain owner who cares may place an automated watch job for all his domain names on the CT logs. (Facebook offers a such a service for free.)

In their own words:

Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.